Because objects in JSON are unordered ("An object is an unordered set
of name/value pairs."), a pull parser is going to have to work a bit
differently.One way to make it work is to pass in a map of continuations, or an object or class with methods selected with reflection. However, I have reservations about the whole pull-parsing paradigm when combined with unordered objects, because if you have dependencies in the processing of the fields, it may appear to work OK -- until the order changes, perhaps with a server reboot, or unrelated code change, or anything at all. This sort of situation can make for bugs that are VERY hard to test for and VERY hard to debug -- and often, VERY hard to fix. But if you approach it with the right discipline... Of course, a downside is that discipline might entail designing the JSON payload to use arrays instead of objects. This would impose a readability and upward compatibility cost on the content. (But on the other hand, it'd be a bit more compact and efficient). Still, I think it is prudent to not consider a pull parser for JSON until and unless you have a demonstrated performance problem to solve. The issue doesn't arise to the same degree in XML, because at the level of XML itself, order is meaningful and preserved, even if a higher level may consider order unimportant. XML generators have the ability to control the order of elements; JSON generators do not. On Dec 25, 7:37 am, ko5tik <kpriblo...@yahoo.com> wrote: > Built in JSON is adequate, but as every DOM-Kind of parser pretty > memory consuming. > Pull-Parser is really necessary. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
