3:02 p.m.
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/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.