Libiphone libiphone → 1.0 Release

Comments and changes to this ticket

• 

  Jonathan Beck November 10th, 2009 @ 07:08 AM

  Yes, this is the proper way to fix libiphone binding.

  The new plist python binding is entirely based on the C++ stuff. It benefits are a good object model, standard conaitners/iterators and most importantly has a lot better integration in SWIG (and thus feels a lot batter from the python side).

  Please provide a patch to be integrated in libiphone.

• 

  Martin S. November 10th, 2009 @ 12:48 PM

  Here we go...

  • libiphone-fix-python-binding.patch 1.4 KB
• 

  Martin S. November 10th, 2009 @ 03:33 PM

  • State changed from “new” to “open”
  • Assigned user set to “Jonathan Beck”

  Actually, attempting to port python-iphonesync to the newer API wrapper, I noticed a few issues.

  Could you give an example on how one would work with the C++ API to create a basic dictionary with a key and string value and output it as XML? I can't really see how that should be possible with the current state of bindings.

  Also why is there the Utils class vs. the Structure class?
  Shouldn't the Node class rather conform to some "IPListSerializable" interface which dictates ToXML(), FromXML(), ToBinary(), FromBinary() methods? So one can do ToXML() on any node type and get appropriate serialization? You would also get recursive serialization for free.

  E.g.: PList::String::ToXML -> value

  The other option, if you planned to have the PList::Structure class as a "serialization container", would be to merge FromXml, FromBin as static methods and get rid of PList::Utils.

  So the workflow would be:

  • Create a PList::Structure (act's as "root node")
  • Add PList::Node instances to the structure (maybe Node->AddChild() is much easier here than SomeNode->SetParent(the_structure_instance_of_step_1))
  • print PList::Structure::ToXML, which generates the XML representation of it's associated nodes
• 

  Jonathan Beck November 10th, 2009 @ 04:53 PM

  Please consider the following snippet of python code to see how to use the new python binding:

  #!/usr/bin/env python
  # -*- coding: utf-8 -*-
  
  from libplist.PList import *
  
  a = Array()
  a.append( String("SDMessageSyncDataClassWithDevice") )
  a.append( String("com.apple.Contacts") )
  a.append( String("---") )
  a.append( String("2009-01-13 22:25:58 +0100") )
  a.append( Integer(106) )
  a.append( String("___EmptyParameterString___") )
  
  print a.to_xml()
  
  d = Dictionary()
  
  d['Boolean 1'] = Boolean(True)
  d['Boolean 2'] = Boolean(False)
  d['string key'] = String('string value')
  
  print d.to_xml()
  print d['string key'].get_value()
  
  d.keys()
  d.values()
  d.items()
  

  The FromXml and FromBin can very well be moved in the Structure Class, but the FromPlist function should stay in utils.
  The PList::Structure class is a serialization container, scalar node should not be serialized.

  Also the SetParent() method should not have been public. I forgot to move it to private as a friend method as it is only used internally (when calling Insert() or Append() on structured types).
  Also keep in mind that PList::Strucutre is abstract and cannot be instantiated as is.

  the workflow is quite close to what you mention :
  - Create a structured type to act as "root node" : either PList::Array or PList::Dictionary. - Call Insert() or Append()

  PList::Array a = new Array();
  PList::String s = new String("some string");
  a.Append(s);
  delete s;
  

  I am not quite happy with the trailing delete but I guess this is non avoidable. In python we do not have this. - Call ToXml() on the structured type (Array or Dictionary)

  I hope I made it clear ! :)

• 

  Martin S. November 11th, 2009 @ 12:45 PM

  • Assigned user changed from “Jonathan Beck” to “Matt Colyer”

  Great, thanks for the explanation.
  Agree about the parent function and serialization then.
  Perhaps that example would fit well into the README.

  Assigning to Matt regarding the patch now though.

• 

  Martin S. November 11th, 2009 @ 03:34 PM

  • State changed from “open” to “resolved”

  (from [28d1fcac0eda09e829ef8c8b46fad0e45590af16]) Require libplist++ in order to fix linking of Python bindings

  [#84 state:resolved]

  Signed-off-by: Matt Colyer matt@colyer.name
  http://github.com/MattColyer/libiphone/commit/28d1fcac0eda09e829ef8...