NSData from NSArchiver and plist Utility
-
I have a plist that I will store on a server and my app will retrieve it.
I'd like to archive one of the keys (an array) into an NSData and possibly
compress it.... Makes for less storage and thus lower bandwidth for my
server.
myData = [NSArchiver archivedDataWithRootObject:(NSArray*)myArray];
Will something archived with this under 10.5 be readable in 10.4?
This seems like something an existing utility should be able to do... Is
there something that does this? Or do I need to write a simple custom app to
prepare my plist file for uploading?
E.g. I should be able to control click on my array in Plist Utility and
choose "Archive to NSData"
Once it is NSData, I might like to use zlib to build a compressed version of
the data.
Thanks,
Trygve -
On Jun 11, 2008, at 11:35 AM, Trygve Inda wrote:> I have a plist that I will store on a server and my app will
> retrieve it.
> I'd like to archive one of the keys (an array) into an NSData and
> possibly
> compress it.... Makes for less storage and thus lower bandwidth for my
> server.
>
> myData = [NSArchiver archivedDataWithRootObject:(NSArray*)myArray];
>
> Will something archived with this under 10.5 be readable in 10.4?
>
> This seems like something an existing utility should be able to
> do... Is
> there something that does this? Or do I need to write a simple
> custom app to
> prepare my plist file for uploading?
>
> E.g. I should be able to control click on my array in Plist Utility
> and
> choose "Archive to NSData"
>
> Once it is NSData, I might like to use zlib to build a compressed
> version of
> the data.
Hmm. It's not clear to me that an array will be stored more
efficiently as a data object.
If your plist is in XML format, data objects are stored in string form
as a series of hex digits. This greatly expands the space needed,
probably more than you could recover with zlib.
If your plist is in binary format, then I would expect that the format
could be most efficient when it knows the real type of object it's
storing. For example, manually archiving an array into a data object
would "hide" the array-ness from the property list writing machinery,
thereby preventing it from taking advantages of certain array-specific
optimizations it might have. Put another way, if converting an array
to a data object were the most efficient way of writing it, then I
would expect that's what the binary format would use.
I suggest that you just use the binary plist format. You can use the
"plutil" command to convert a plist to that format. In code, you can
use NSPropertyListSerialization to save a plist in binary form
(NSPropertyListBinaryFormat_v1_0). Also, since
NSPropertyListSerialization doesn't deal directly with a file but with
NSData, you can try putting zlib (un)compression between it and the
file. However, the resulting file would not be recognized by anything
other than your code.
Cheers,
Ken -
>> myData = [NSArchiver archivedDataWithRootObject:(NSArray*)myArray];
>>
>> Will something archived with this under 10.5 be readable in 10.4?
>>
>> This seems like something an existing utility should be able to
>> do... Is
>> there something that does this? Or do I need to write a simple
>> custom app to
>> prepare my plist file for uploading?> Hmm. It's not clear to me that an array will be stored more
> efficiently as a data object.
>
> If your plist is in XML format, data objects are stored in string form
> as a series of hex digits. This greatly expands the space needed,
> probably more than you could recover with zlib.> Cheers,
> Ken
>
One other reason to use NSData is to hide certain information from casual
users... though in my testing it is smaller as well which is a nice side
effect.
Just trying to be sure that if I use archivedDataWithRootObject on 10.5 and
write it to disk, then read it with 10.4's unarchivedDataWithRootObject,
that all will be ok.
Trygve -
On 11 Jun '08, at 9:35 AM, Trygve Inda wrote:> I have a plist that I will store on a server and my app will
> retrieve it.
> I'd like to archive one of the keys (an array) into an NSData and
> possibly
> compress it.... Makes for less storage and thus lower bandwidth for my
> server.
Why not just compress the entire plist? In my experience, zlib
compresses markup data like XML by about 10::1.> myData = [NSArchiver archivedDataWithRootObject:(NSArray*)myArray];
There's not much reason to use NSArchiver on plist-compatible data
(arrays, strings, etc.) An XML archive will just be a much more
verbose plist, and a binary archive will be identical to what you'd
get if you used NSPropertyListSerialization to save a binary plist.
(Binary plists are already quite a bit smaller than XML ones, and
conveniently unreadable by eye, so you might just try that.)
âJens -
>
> On 11 Jun '08, at 9:35 AM, Trygve Inda wrote:
>
>> I have a plist that I will store on a server and my app will
>> retrieve it.
>> I'd like to archive one of the keys (an array) into an NSData and
>> possibly
>> compress it.... Makes for less storage and thus lower bandwidth for my
>> server.
>
> Why not just compress the entire plist? In my experience, zlib
> compresses markup data like XML by about 10::1.
>
>> myData = [NSArchiver archivedDataWithRootObject:(NSArray*)myArray];
>
> There's not much reason to use NSArchiver on plist-compatible data
> (arrays, strings, etc.) An XML archive will just be a much more
> verbose plist, and a binary archive will be identical to what you'd
> get if you used NSPropertyListSerialization to save a binary plist.
>
> (Binary plists are already quite a bit smaller than XML ones, and
> conveniently unreadable by eye, so you might just try that.)
Using NSData + zlib on an array of strings and number data in my
binary-stored plist saves about 25%...more than any other way.
While I could compress the entire plist, I would like to keep some of it
user-readable, and other parts obscured.
1714 - original size in bytes of binary plist
1562 - binary plist NSArray put through dataFromPropertyList and zlib
1331 - binary plist NSArray put through archivedDataWithRootObject and zlib
Trygve
