If your dictionary has only text values, this should be no problem with the NSJSONSerialization, but if you're sending images, you'll need to convert the images to 16 bit encoded NSData objects.
I guess the bigger question is, "what are the data types within your dictionary"? If it's just text, then you should have good luck with NSJSONSerialization. Another question is, "where are you sending that data to?" What type of service will receive it? Cheers, - Alex On May 7, 2014, at 2:38 PM, Wim Lewis wrote: > > On 7 May 2014, at 11:17 AM, Carl Hoefs wrote: >> Newb questions re: serializing an NSDictionary for network transfer to >> another process. I've read over the Apple documentation, but it seems to >> detail the methods involved but not how to use serialization, and some >> methods seem to require writing archives or plist files to disk. So, I must >> be approaching this all wrong... >> >> (1) I see that NSDictionary has an encoding method: >> >> - (void)encodeWithCoder:(NSCoder *)coder; >> >> but this returns (void), which is puzzling to me. I would expect it to >> return (void *) to a malloced region containing the serialization. Where >> does the object serialization reside, and how do I access it? > > It is accumulated in the coder. NSCoder is an abstract class; the concrete > class you're using (eg NSKeyedArchiver) will have a way to get the serialized > data in or out. > > NSKeyedArchiver also has a convenience method, +archivedDataWithRootObject:, > for the common case of writing a single object (and recursively any objects > it references/contains) and getting the data out. > > Depending on what is *in* your NSDictionary, though, a less opaque > serialization format might be better, such as one of the property-list > formats (see NSPropertyListSerialization) or even JSON. These formats can > only hold a small, non-extensible set of types, and can't encode recursive > structures or preserve the sharedness of parts of the object graph, but have > the significant advantage that they are easier to inspect and are easier to > keep decoupled from implementation details of your app. > > > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
