Wrapper for reading and writing

[Karl Moore]

I've created a couple of wrapper classes for dealing with the library.  I don't want to have to think is terms of NSObject and would sooner deal with Integer, String, Boolean etc...  I wondered if these might be useful to contribute back?

[Daniel D.]

Can you give an example of your wrapper code?

At the moment converting from any Java object to an NSObject can be done by simply one call to NSObject.wrap(...). Converting back to native java types is a also a one-liner, excepts maybe for arrays and dictionaries, there the content is not converted.

[Karl Moore]

Sure.  There are a few places that NSObject.wrap doesn't work.  It doesn't support Dates, Collections or existing NSObject values.  That should be pretty easy to add.  My use case is that I don't really want to pass around NSDictionary.  I'd prefer it just to be  Map.  I know NSDictionary internally has a map but you don't get the wrap and unwrap behaviour from it.  Hence the abstraction.

Does that make sense?

--
You received this message because you are subscribed to the Google Groups "plist-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plist-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Daniel Dreibrodt]

Ok, I see.

I will extend the wrap method and also add a method to all NSObjects that converts them to their native java representation, so e.g. NSDictionaries will be turned into Map objects and the contents are also converted to native Java objects.

[Karl Moore]

That's awesome.  Some things are pretty simple to convert back e.g. NSString but for things like NSNumber I can imagine you're going to have to do more work to see what type it is before unwrapping it.

Just trying to remember what I've had to do, Collection, Date, handling Objects that aren't serializable (e.g. throw an exception), NSObject and null values.  I've handled null by ignoring the value.  One thing that might be nice is to have an option how to handle empty collections and arrays.  I would like them to be ignored for instance.  I can imagine others might not.

[Karl Moore]

Apologies for the spam, I just remembered, I think I found a bug in the wrap code.  There is no wrap method for int, so all of the values that are created end up being doubles instead of int.  Thus the plist contains real instead of int.

[Daniel Dreibrodt]

Look at r95, it should have everything you need. But empty collections and arrays are not ignored they are just converted to empty NSArrays. And unserializable objects will continue to throw an exception, as wrapping them is simply impossible.

[Karl Moore]

That looks great!  The only thing I think is missing is there is no method on NSDictionary that calls NSObject.wrap.  That way you could have a put that removes the need for all the others.  That make sense?

[Daniel Dreibrodt]

Oh yeah, forgot that one. r96 solves it.

[Karl Moore]

You my friend are a coding super star!  Thanks so much!!

[Daniel Dreibrodt]

Hey Karl, 

sorry for the late reply. I looked at your solution. I do not like that it again blurs the line between NSObject and Object. I would maybe let NSDictionary implement Map<String, NSObject> and if the user really wants to work with Map<String, Object> he should just call toJavaObject. It is possible now to work without any NS-specific code by just calling .toJavaObject on the root of the parsed property list. And then later one can just use NSObject.wrap(..) when it comes to saving the property list. I do not really see the value of re-implementing Map.

Regards,

Daniel

On Wed, Mar 20, 2013 at 4:38 PM, Karl Moore <karld...@gmail.com> wrote:

I've done some more work on this and improved it, see attached.

On Tuesday, 19 March 2013 13:45:27 UTC, Karl Moore wrote:

I've attached an updated version of NSDictionary which implements the behaviour I was discussing last week.  Would this be useful for inclusion at all.  It's basically making the caller unaware of the fact they're using a dictionary and implementing Map behaviour.  Makes my code less NS centric.

You my friend are a coding super star!  Thanks so much!!

Oh yeah, forgot that one. r96 solves it.

Am 15.03.2013 um 11:44 schrieb 

That looks great!  The only thing I think is missing is there is no method on NSDictionary that calls NSObject.wrap.  That way you could have a put that removes the need for all the others.  That make sense?

--
You received this message because you are subscribed to the Google Groups "plist-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to plist-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Karl Moore]

Hey Daniel, 

I totally agree.  I re-wrote the code to simply implement Map<String, NSObject>.  I thought that's what I posted?  That meant that I could use a simple Map transform (of which there are plenty out there) to achieve what I wanted (e.g. automatically) call toJavaObject.

Let me check what I posted.

Karl

[Karl Moore]

Hey Daniel,

Looking at the code implementing Map<String, NSObject> seemed like a no-brainer.  Most of the methods are already provided on NSDictionary anyway it's just that it didn't implement the interface.  The primary reason for doing this is that I need to be concerned with two things.  I need to be able to pass NSDictionary into some custom code which has to take a map, I can call getHashMap but this seemed less elegant as a dictionary is a map.  Secondly I don't want to convert the whole document at once as these can get pretty large.  Sometimes I only need a small part of the pList so I'm using transforms for the bits I need.  Again these transforms accept Map.  I managed to simplify the code right down this way.

Let me know your thoughts.  I'm also doing some profiling right now as I seem to spend quite a bit of time parsing the documents, I might have some performance tweaks to provide.

https://plist-discuss.googlegroups.com/attach/5d9ce7bb3f2efa11/NSDictionary.java?view=1&part=5

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Maps.html

[Daniel Dreibrodt]

Hey Karl,

if you want I can merge your implementation of Map<String, NSObject> for NSDictionary.

Regards,

Daniel

[Karl Moore]

That would be awesome!  I just checked it into a local repo for now.

[Daniel Dreibrodt]

Done in r102.

[Karl Moore]

I've just updated, but it looks like the null check got removed.  So when you do a put with a null value you end up getting an NPE when you try to build the pList.  Likewise all of the extra put methods seem redundant e.g. put(String) as put(Object) will do this all for you.

Done in r102.

To unsubscribe from this group and stop receiving emails from it, send an email to plist-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "plist-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plist-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "plist-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plist-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "plist-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plist-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "plist-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plist-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Karl Moore]

I've attached the files that fix the problem.