On Sep 27, 2012, at 5:08 AM, Matthias Wessendorf wrote: yeah -500k for this - looks like totally off the others (iOS, js) are doing -- qmx

IMO, this is not high priority. -1 -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Tuesday, October 9, 2012 at 6:20 AM, Matthias Wessendorf wrote:

I agree. I agree. - marko

Taking a closer look at this, and considering comments made by others ... Deliverables ============ - Integration into an example application - Possibly native version of TODO app It is now clear that it is a native version of TODO app. - Android SDK template application This sounds like a maven archetype. We should discuss what that would include. IMHO it should be more than just an empty Android application. Maybe with server endpoint template app included. Or maybe we could have several different archetypes from simplest that's client only, to one with JAX-RS endpoint template, and another one with Aerogear Controller endpoint template. The core functionality is client-server connectivity so it's important to be able to see it in action right away. Release Roadmap =============== 1.0.0.M1 -------- - TODO integration for example app I'd rephrase this a bit - just: TODO - example Android application. A question pops up - how do we align aerogear-android-todo which is a different module with aerogear-android? One is a library and the other is a demo app using the library. I would tag them together for releases. - Solidify requirements Like Bruno pointed out ... this should be removed from roadmap. - Basic API structure - CRUD - Data-binding (via gson) This one needs a lot of work. Purely layered view of things ... we have HttpClient hidden behind Pipes API. We have JSON marshal/unmarshal that's either part of Pipes or wrapped around it. We have Authentication that's orthogonal concern, and needs to be appropriately handled without polluting Pipes API. There's this extensibility mechanism with HttpAdapter, HttpRestAdapter (which I'm not sure makes sense anymore - how can you have REST without HTTP? Or, what else does Pipes support except REST?). - Follow good Android practice re: background data transfers / services / etc Like Bruno pointed out this one is too vague. I know Glen started to work on background data transfers / services aspect. So maybe this could be rephrased: + Asynchronous API for remote operations + Client templates to connect Android view layer with asynchronous API - First cut at user/auth integration (see AeroGear Security Plan) (unsure if this will make it in or not - we should be able to design the API anyway, even if not-yet-functional) We already have a better idea of how client server communication works, and what the server-side endpoints are. API should be orthogonal (contextual). - Release as API jar + TODO example app Would that be four downloadable archives? (aerogear.jar, aerogear-sources.jar, aerogear-android-todo.jar, aerogear-android-todo-sources.jar) 1.0.0.M2 -------- - Process API review comments from community Is that 'Process API' or 'API review'? For the first - what would that be. For the second - not really a roadmap item as that's happening continuously. - Data synchronization prototype For starters Data Synchronization requires a specification document where it would be fleshed out. - Push support? This reminds me of Mathias's idea of a websockets support as one communication channel that could be used for this. On Android there's platform push support in the form of Google Cloud Messaging (GCM) (http://developer.android.com/guide/google/gcm/index.html). So this channel exists OOTB. Our custom websockets would be another channel. The idea here should be that multiple instances of an application, and even multiple applications on the same device can all share the same channel. Multiple applications preinstalled on company provided Android phones for example could share a channel to the corporate backend. With GCM it all goes through Google's servers. - Query/search support? Absolutely. We need paging support as well. - Release as apklib? As soon as it starts to make sense. 1.0.0.CR1 --------- - OAuth support? Client only has to deal with OAuth when server requires it, therefore we should wait for server-side support. 1.0.0.Final ----------- - 2nd example app? (chat server?) We need demo apps to push real life use cases that will shape aerogear towards practical usability. I'm for tinkering with many different prototypes, and demo apps ... We may not get so far as to create a second example app across the board - on all platforms, but we need to push limits, and there is a lot of platform specific room for utility libs, that can be part of aerogear. So if someone wants to write a shat server, I'd say sure, go ahead, but it's more as an aside, something to shape the roadmap, not a roadmap item in and of itself. Android Specific Requirements ----------------------------- - Push (Cloud Messaging), including custom broadcast intents for data updates Use case for this is synchronizing state among different devices. For TODO app for example, creating a new Task via browser would fire an event that would get propagated via push, trigger native client TODO app to resync from server. We could have CDI events on the server? If we want to use GCM we need to look at how to integrate that on the server-side. - Server-backed ContentProvider? This is a mechanism using interprocess communication on Android to open up your application as a 'data source' with CRUD operations to other applications on the device. Seems fitting for our remote persistence approach. I'm all for it. - marko ----- Original Message -----