Re: NSKeyedArchiver on OSX to NSKeyedUnarchiver iOS
Re: NSKeyedArchiver on OSX to NSKeyedUnarchiver iOS
- Subject: Re: NSKeyedArchiver on OSX to NSKeyedUnarchiver iOS
- From: Ricky Sharp <email@hidden>
- Date: Wed, 11 Aug 2010 17:19:54 -0500
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:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden