[aerogear-dev] LiveOak SDK

[Summers Pittman]

On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote:
>
> Initial email to get some discussion going around the LiveOak SDK and
> AeroGear collaboration.
>
> Essentially in LiveOak we are going to need a few different SDK types
>
> - Client Application SDK
> This is the code which will run on the users device. Initial targets
> here are javascript (+ cordova support), iOS, Android. This type of SDK
> will handle things like getting and sending resources to and from the
> server, handling login/logout/registration, etc. Probably some other
> things like device registration would be needed as well.
>
> Not sure if we want to provide support for some other things outside of
> communicating with the server or not (eg access to device components (eg
> camera, location, etc)) or if these would be best handled by using the
> native environment's SDK instead.
>
> - Server Side SDK
> This is code that runs on the server side, written in JavaScript by the
> application developer. This will need to be familiar to the client
> application's JavaScript SDK, but may not be exactly the same. This type
> of SDK will be able to access the same resources as the client side
> JavaScript, as well as other internal resources and libraries.
>
>
> I am not sure how to collaborate between the LiveOak and AeroGear teams
> here. AeroGear makes really awesome SDKs for various mobile platforms,
> but with LiveOak we are dealing with a specific type of application. The
> AeroGear SDKs tend to handle the more generic case, which I don't
> necessarily think makes sense for a LiveOak SDK.
>
> I do think it makes sense that the LiveOak SDK uses the AeroGear SDK
> internally, but I don't know if we want to expose these AeroGear
> components to a LiveOak developer or not.
>
>
> For me, I envision something like the admin setting up their application
> in the LiveOak console which then generates a json configuration file
> (url locations, resources available, KeyCloak settings, UPS settings,
> etc). The application developer then drops this json file in to their
> application, the LiveOak SDK reads the json file to set it self up and
> then its really easy for the developer to start using it.
>
> [there are also some really cool things we could be doing here as well
> if we can get awesome data sync support for AeroGear. It might be
> interesting to be able to fetch a resource from the server and
> automatically sync its state across between the client and server. This
> way the object appears as a local object: if the resource changes on the
> server, it changes locally as well, if it changes locally, that change
> is pushed to the server. This way you are just dealing with an object,
> and not having to fetch and then push object back and forth between the
> server manually]
>
> Anyone have any thoughts on this?

One of the things which may be useful is aerogear-ios and 
aerogear-android are both modularizing their libraries.  IN theory this 
means that the liveOAK SDK's could be extensions of those modules 
instead of a single monolothic thing.

Sync is still an ongoing discussion in AeroGear, but I think right now 
the current group thought is that we will focus on 409 Conflict events 
(JPA versioning on server side and utilities on the client side) and not 
worrying about realtime sync.


Some notes from out last meeting on the topic :
Client API Strawman :
https://github.com/secondsun/aerogear-android-sync/tree/master/android
Client/Server workflow :
https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit 


Also we are looking at doing something with diff merge patch as well as 
adding in push based data changed notifications later.


> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.