03-12-2009 10:36 AM
I've been using JSON to transfer objects over HTTP(S) between BlackBerry devices and services for sometime now. I also use it on Android. Here's a tutorial (http://developerlife.com/tutorials/?p=624) with helpful tips on how to do object exchange between clients (on BlackBerry and Android) and services. Code is provided for a JSON object generator that generates java code for you to do serialization and deserialization. This stuff is in used in this mobile blogging BlackBerry app (for 4.6 or higher OS) - http://screamingtoaster.com/?p=234.
I'm about to release a mobile blogging app in the next few weeks which uses JSON as well. This BB app will allow you to edit your blog from Android and BlackBerry smartphones. If you have your own blog, you will be able to view/edit/manage it on the fly from BlackBerry and Android smartphones. You can see a beta of this (tied to 1 blog) running here - http://screamingtoaster.com/?p=234. You can also download it and beta test it from here http://developerlife.com/bbota/. Note that this beta is only tied to one blog.
Here's a list of other tutorials on developerlife that might help with BB development - http://developerlife.com/tutorials/?cat=63
03-12-2009 10:52 AM
From what I'd seen, Android was using JSON as a synonym for a binary format at least
for the GPS data and a couple of notes I'd skimmed. The actual java overhead for
a binary format is probably similar and network usage can decrease but there can
be problems with human readability and familiarity with simple text processing tools.
If you want to modify an ASCII file or check an ASCII stream that is pretty
easy but binary becomes harder to manipulate without a little care.
I would mention that once you have something like urlencode and decode scripts
however, it really isn't that hard to convert back and forth easily.
03-12-2009 11:14 AM - edited 03-12-2009 11:19 AM
There is a good start of a json pull parser on google code at http://code.google.com/p/jsonpull/
There is some functionality missing, but with a little thought you can update it correctly. I had made quite a few changes and submitted the code back to the guy running the project, but he decided not to accept the updates for some reason... which is beyond me.
There is a good json formatter at http://jsonformatter.curiousconcept.com/
Json usually does not have line breaks when sent through the network, so a formatter makes readability very easy.
I prefer json over xml.
03-12-2009 01:02 PM
The term "JSON object" seems to be used
for anything that looks like a properties table ( name-value pairs)
and can be transmitted in "json" or binary formats ( I think BISON or something
comes up along with others in some forums ).
Is android largely going with the "protocol buffer" approach?
I'm starting to think there would be benefits to this in many cases even if
BW is reasonably good as with wifi.
05-27-2009 01:26 AM
You prefer, JSON is the best tool for Object exchange. Is JSON the only way to support serialization or object exchange?.
And I am confused with so many tools which support for JSON like, json-lib, xstream, etc. which one is the best?
Which is popular tool?. Is everybody using JSON?.
08-14-2009 01:29 PM
@marchywka - Google's protocol buffers don't work if you don't have Java 5 language support, so that's out of the question for BB. Personally, I find JSON much easier to work with, and I've created my own JSON code generator, which handles all the dirty work of creating Java code for my data models. On Android, you could use Proto buffers, but I would suggest using JSON. I develop for desktop/web/BB/Android and so I like to use JSON, I just have to write things once. You can compress the Strings generated by JSON and save a ton of bandwidth. All of this is used in my ScreamingToaster ONE Platform apps - Wicked, MyListy.
08-14-2009 02:37 PM
Is everbody using JSON? It's definitely popular, but perhaps not that much. It is much more compact than XML, and does just as good a job as XML for many applications, but it lacks built-in support in most execution environments. So you trade off communication and storage overhead with bulkier software. There's no one answer for everyone.
Hope this helps.