On Aug 11, 2010, at 4:32 PM, glenn andreas wrote:
>
> On Aug 11, 2010, at 3:53 PM, Sandro Noël wrote:
>
>> Greetings
>>
>> I'm having problems unarchiving my data in the iphone.
>>
>> here is the workout.
>>
>> 1: I archive a AttributedString to my CoreData NSData property using
>> NSKeyedarchiver
>> 2: Transfer the database to the iphone.
>> 3: load the data using NSKeyedUnarchiver on the iphone.
>> NSAttributedString *as = (NSAttributedString*)[NSKeyedUnarchiver
>> unarchiveObjectWithData:attributedStringData];
>>
>> that crashes saying:
>> -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class
>> (NSFont)
>>
>> I understand that the NSFont is UIFont on the iphone, or has similarities.
>> so i implemented a Delegate method to replace the class.
>> //------------------------------------------------------------------------------
>> - (Class)unarchiver:(NSKeyedUnarchiver *)unarchiver
>> cannotDecodeObjectOfClassName:(NSString *)name originalClasses:(NSArray
>> *)classNames{
>> if ([name isEqualToString:@"NSFont"])
>> return [UIFont class];
>>
>> return nil;
>> }
>>
>> but that never gets called because the class method does not allow for a
>> delegate and instantiating the unarchiver class confuses me in how I should
>> trigger the decoding once it is instantiated.
>>
>> Any pointers ?
>
> You're going to run into worse problems - UIFont is not NSFont, nor can you
> trivially substitute one for the other.
>
> In general, while you can archive an NSAttributedString on OS X and unarchive
> it on iOS, it's not going to work the way you want it to. Any of the
> "interesting" properties that define things like appearance of the string,
> are platform specific. There is no "NSForegroundAttributeName", for example,
> on iOS, and even if you explicitly look for appropriate key, on OS X this
> will contain an NSColor, which, of course, does not exist on iOS (and UI
> color is similar, but the encoding of NSColor is undocumented, so even if you
> attempt to manually handle the decoding and try to make a UIColor, it would
> require that undocumented information - not to mention that there are parts
> of NSColor such as color space that don't exist at all on iOS). Similarly
> for font information, paragraph style (including alignment, tabs, margins),
> embedded images, etc...
>
> You might be able to get away with using CoreText and it's attributes (which
> are based on CG/CT objects like CGColor and CTFont), but obviously that's not
> what you're going to get from AppKits default attributed string support. So
> you'll probably have to give up on using AppKit's NSAttributedString
> extensions all together, and switch to the CoreText ones (and take advantage
> of the CFAttributedString/NSAttributedString toll free bridging).
What you could do is continue to use the best possible API on both OS flavors.
Then, instead of archiving platform-specific objects, archive primitives that
describe the object instead.
For example, if you have an NSColor on Mac OS X, archive the color components,
etc. as needed. Then, when unarchiving on iOS, rebuild up an appropriate
UIColor.
This is I think the only thing you can do to basically "future-proof" your code
(or come very close to it). Attempting to pick a set of objects that just
happen to be archived the same exact way between OS flavors just seems too
fragile. And, using those objects may not be the simplest thing to do on each
specific OS.
___________________________________________________________
Ricky A. Sharp mailto:rsh...@instantinteractive.com
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
