Hi,

the date format in the unit test is wrong (have a look at http://www.apple.com/DTDs/PropertyList-1.0.dtd):

public static final String VALID_PLIST_DATE_ROOT = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>"
            + "<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">"
            + "<plist version=\"1.0\">"
            + "<date>"
            + "Sun, 13 Feb 2011 12:01:00 GMT-0500" + "</date>" + "</plist>";

The correct date format in plist files is ISO 8601 ("Contents should conform to a subset of ISO 8601 [in particular, YYYY '-' MM '-' DD 'T' HH ':' MM ':' SS 'Z'"]) e.g. 2012-02-24T10:10:00Z but this format throws an exception during parsing.

Can you help please?

Thank you!

I found some timezone problems, the date object in the plist file and the java.util.Date object are different, so if you create a new date formatter and set the timezone (e.g. "GMT+2") the new date object has the wrong time (in this example 8AM instead of 10AM, because of GMT+2) To fix this just set the timezone of the date formatter in your com.longevitysoft.android.xml.plist.domain.Date constructor to UTC (because all dates in plists are in UTC) and everything works fine.

public Date() {
    setType(PListObjectType.DATE);
    iso8601Format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
    iso8601Format.setTimeZone(TimeZone.getTimeZone("UTC"));
}

There's been a report that perhaps Dict inside a Dict breaks. The unit test needs a test case for:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<key>cat</key>
<dict>
  <key>ID</key>
  <string>901</string>
  <key>title</key>
  <string>Title</string>
  <key>thumb</key>
  <dict>
    <key>ID</key>
    <integer>152</integer>
    <key>uri</key>
    <string>http://www.google.com</string>
  </dict>
  <key>order</key>
  <integer>2</integer>
  <key>type</key>
  <integer>5</integer>
</dict>

This is from a find bugs report contributed by D. Borza:

1. com.longevitysoft.android.xml.plist.domain.Data
   line 73:
   public java.lang.String getValue(boolean decode) {
   dataStringer.newBuilder();
   if (decode) {
   return dataStringer.getBuilder()
   .append(new java.lang.String(Base64.
   decodeFast(rawData)))
   .toString();
   } else {
   -> return dataStringer.getBuilder().append(rawData).toString();
   }
   }

The code invokes toString on an array, which will generate a fairly useless result such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable String that gives the contents of the array.

1. class: com.longevitysoft.android.xml.plist.domain.Array
   line 252:
   public boolean equals(Object that) {
   -> return data.equals(that);
   }

This class overrides equals(Object), but does not override hashCode(), and inherits the implementation of hashCode() from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes.

base64 type should have base64 deserialization

hi,

"string" tag parsing is currently not working.

some functions are missing: like getDate()

and it will be wonderfull if you allow parsing an inputstream instead of string XML

regards

The unit test assertions are weak. Also, two new XML got added that are untested in the parser test - they need test cases.

Currently the parser is only working with array and dict elements in the root. This will be fixed in the next version.