[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Aerogear-dev] Android native libs



Marko,

This is a lot of awesome information! There are a number of items you touched on (OData, security, offline sync, etc.) that we are having ongoing discussions about as a team. I would recommend before you dive too much into any of this that you get up to speed on where the team is on those topics, our plans for them if they exist and how Android fits into that picture. I see a lot of awesome in this e-mail but want to make sure you know where we stand on some of these items before you get too deep into a prototype. If you have time, our weekly team meeting is today in about 45 minutes. I'm not sure of the agenda but we may have time to go through some of this. Just let us (Jay) know you want an invite so you can join the hangout.

Kris

On Aug 14, 2012, at 8:54 AM, Marko Strukelj <mstrukel redhat com> wrote:

> Hey guys,
> 
> I've been looking into OData, and thinking about synchronization and local storage for Android ...
> 
> I like to throw together some prototype, before going too much into describing things that don't yet exist ... But basically there are a few ideas in my head for a prototype:
> 
>  - Make a TODO app based Android prototype:
>    * Local storage using something like JPA over local SQLite for offline mode
>    * Upsync to server via REST
>    * Downsync from server via REST
> 
> OData itself is like a DB - as if you had a CRUD REST endpoints for each 'table', with an additional endpoint representing the 'database', containing schema descriptions of the available 'tables'. It's primary focus is data interchange, not incremental data synchronization. In terms of fomrat it presumes using a prescribed JSON format - a more generic kind of information packaging - instead specific types like Task, Project and Tag, you use more generic structures like described here: http://www.odata.org/documentation/json-format.
> 
> There is a yet unfinished addition to current OData that covers downsync from server to offline device, but not upsync. So, OData would be more like a super-structure on top of current basic JSON REST endpoints that would provide DB-like access to third party tools specifically written to access OData datasources in generic fashion. It is something that can be retrofitted to the application at any time, but there is no compelling reason to use it as a primary data exchange format. Especially since currently it doesn't provide any extra semantics for synchronization.
> 
> For example: for data synchronization purposes there are different levels of reliability. Using synchronized clocks and timestamps should be good enough for most consumer level mobile applications.
> 
> But for completely reliable synchronization on top of OData there is a tech being developed at Microsoft for their Azure cloud for synchronizing data between datasources (not just databases). That one seems to work by tracking all operations on the data source (create, update, delete), and by assigning unique id to specific point in time. The idea is that you can then synchronize local db and remote db bothways in transactionally consistent way, as all you do is communicate tx log additions since some point in time (identified by GUID) and replay the tx log on the other end. There doesn't seem to be any plans to make that part an addition to OData.
> 
> Then with sync there is always a question of conflict resolution - for example:
> I change the due date of my task on a device, but don't sync it with server as I have no network connection. 
> I later do the same via web application and save that, but my change is not exactly the same - set a different date.
> 
> This kind of conflict could use some rule for automatic resolution. It could be that the last change (based on LastModified, not UpsyncTime) simply overwrites any other changes. Or there can be a mechanism for manual conflict resolution, that requires user interaction ...
> 
> Anyhow, for now I plan to explore this further in my github space: 
> 
>   https://github.com/mstruk/android-data
> 
> At the moment it just contains a HelloWorld type Maven project stub for a prototype application - using backwards compatible ActionBar / Fragments API for adaptable multi screen-size UI, ProGuard config for pre-release .apk minification, and RoboGuice for dependecy injection. Target platforms are API level 8 and up (that's Android 2.2 and above: http://developer.android.com/about/dashboards/index.html).
> 
> The debate has already come up on IRC about user management and authentication/authorization. Besides having our own users database as part of TODO app, another common feature for consumer apps is to be able to login with GMail, Facebook or Twitter account. That would be neat to have as part of the app, and is something I'm also looking into. On Android that's integrated with AccountManager system service so it provides the ability to perform authentication and authorization outside of the application (which defers the logging-in and token acquirement to that service), so application itself never has a chance to intercept user and password ...
> 
> We can discuss how all this aligns with TODOs application, aerogear-security, and an overall big picture ...
> 
> 
> - marko
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev redhat com
> https://www.redhat.com/mailman/listinfo/aerogear-dev



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]