Following on from Dimuthu and Maurizio's gtalk...

[Dan Haywood <da...@haywood-associates.co.uk>]

Dimuthu,

In your chat yesterday with Maurizio, you asked again about layering.
 Building on top of the stuff that Maurizio showed you, I think you might
now want to consider three layers...

1. the applib, as before (analogous to the RO applib... does the http stuff
and converting JSON docs into in-memory representations)
2. the view models (or to use Maurizio's terminology, the semantic model);
designed fetches out the useful info from the applib representations,
providing backing information for a particular widget (eg Form)
3. the view/UI itself, constructed from widgets, and consuming/binding to
data provided by the view models.

At the moment, looking at the code in the 'general' package [1], these
responsibilities are not clearly separated.  For example, Action,
Parameter, Service and InvokeResult are, I think, view models.  However
Action, Service and InvokeResult all have chunks of JSON parsing in them,
which I would say belongs to the applib layer.  Parameter meanwhile has
getView; this is a UI responsibility, so should be done by code that calls
Parameter (fetching information from it), not the other way round.
 DataConverter is pure UI logic (though needs to be made more extensible).

Now, it might be that you don't want to formally distinguish between (2)
view models and (1) representations in the applib.  If that's the case,
then the Action, Service and InvokeResult are probably ok to be doing the
JSON parsing etc.  However, I think there is benefit in separating them out.

As I think I might have mentioned, I'm currently working with a restful
client on a Windows Store App (metro apps).  There's a (working) skeleton
of the code up on github [2]... you'll see that I've ported the Java applib
to C# (the RestfulObjects.Applib project); it defines representations [3]
that line up pretty closely to the RO spec's representations.  Meanwhile
the view models for the WSA app are defined separately [4]; for example the
hub page [5] provides the data for the first page which lists all the
services and the actions underneath.  These are taken from the
'RootCategories' property, populated on line 85 in the OnNavigatedTo()
method.

You can also see that the view models have lots of stuff to handle
navigation around the app, ie event handling.  This is the way that WSA
apps are written, and there's a good chance that Android apps would have
similar infrastructure.  This sort of stuff definitely shouldn't live in
the (1) applib representations, so is another reason for there being this
separate view model layer.

HTH
Dan

[1]
https://github.com/DImuthuUpe/IsisAndroid/tree/master/IsisAndroid/src/com/dimuthuupeksha/general
[2] https://github.com/danhaywood/restfulobjects-wsa
[3]
https://github.com/danhaywood/restfulobjects-wsa/tree/master/RestfulObjects.Applib/RestfulObjects.ApplibPCL/Representations
[4]
https://github.com/danhaywood/restfulobjects-wsa/tree/master/Client/RestfulObjects.WSA/ViewModels
[5]
https://github.com/danhaywood/restfulobjects-wsa/blob/master/Client/RestfulObjects.WSA/ViewModels/HubPageViewModel.cs