Remove JSONModel, return JSONObject from JSONGetter

[vivainio]

JSONGetter should return JSONObject directly. There is no need to protect from multithreaded access since JSON objects coming over the network are typically used in immutable read-only fashion.

[paulirotta]

I agreed. Then when I started to remove the class, I realized we just need to document the purpose in using JSON as an asynchronously-updatable data model better. Update is below.

• The point of JSONModel is, like XMLModel, to allow you to create a local Object of type
• JSONModel which may last the entire life of your application. You can then
• refer to values from JSONModel and know that it always contains the latest,
• best JSONObject received from the server or loaded from the local cache.
• You can update the value in JSONModel by passing it as an object when you
• call JSONGetter(url, myJSONMOdel). If you would like to execute some code such
• as updating the user interface after the JSONModel is updated asynchonously,
• you should chain() that continuation code (a Task or UITask) to the JSONGetter.

[vivainio]

Ok, got it! So Task chain():ed after JSONGetter now get JSONObject is input parameter, right?

[paulirotta]

Yes. JSONModel is a parameter, it holds your current version of the JSONObject. This will automatgically be asynchronously be replaced by the JSONGetter. If you want to be "notified" when this happens, chain().

I don't really like static notifier pattern common in Java. Too rigid. In most cases, the code is much cleaner and most logical flow visible on one screen when you provide your own lambda expression each time you initiate an async operation.

[vivainio]

Yep, but if I chain() a Task after JsonGetter, do I get JSONObject that was received as argument to doInBackground()?

You typically need the whole JSONObject, not the intermediate JSONModel.