[aerogear-dev] Android roadmap review
Glen Daniels
glen at thoughtcraft.com
Tue Oct 9 10:50:26 EDT 2012
Hi Marko, all,
Thanks for the review! Comments inline.
On 10/9/12 9:41 AM, Marko Strukelj wrote:
> 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.
I'll update.
> - 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.
Yep, and I agree it would be nice to have the server template app
included. I guess we can get the same result by just pointing to the
TODO app, but something even simpler might be good for a template.
> Release Roadmap ===============
>
> 1.0.0.M1 --------
>
> - TODO integration for example app
>
> I'd rephrase this a bit - just: TODO - example Android application.
OK.
> 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.
+1
> - Solidify requirements
>
> Like Bruno pointed out ... this should be removed from roadmap.
Done.
> - 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?).
I agree, and also brought that up on the other thread with Daniel's pull
request.
> - 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
I'll work on rephrasing this.
> - 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).
We need to get cracking on a prototype for this.
> - 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)
That seems right.
> 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.
Took that from the JS roadmap, which has "API and Documentation Review".
I can see removing it, or I can also see leaving it but making it more
explicit : "Collect and review comments from community". This seemed
like a non-functional placeholder to make sure that we'd gotten
sufficient external validation and review. Not part of the design, but
still part of the roadmap. We can also remove it.
> - Data synchronization prototype
>
> For starters Data Synchronization requires a specification document
> where it would be fleshed out.
+1
> - 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.
WebSockets is certainly possible, but I think that GCM should be the
default implementation - it's going to have the most familiarity to
Android developers, and it's also likely to have the best battery usage
characteristics.
> - Query/search support?
>
> Absolutely. We need paging support as well.
+1. All of these need server-side support.
> - Release as apklib?
>
> As soon as it starts to make sense.
Yup.
> 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.
Do you think we should remove that line? Are we not hoping to get OAuth
support (or Facebook/Twitter SSO integration) in before 1.0 final?
> 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.
I think we need to consider the types of applications that our target
users will want to build, and try to make our demos reflect those. I
was hoping that we'd get more than one demo done, and that we'd have at
least one demo that demonstrates partitioned (by user, by "channel",
etc) + shared data, and push, by the time 1.0 completes.
> 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.
Yes, this would become part of the aerogear-controller codebase, along
with support for Apple's push messaging. We could look into something
like Urban Airship for this, or just use some of the open-source
implementations that are out there already. But there's also a bit of
custom scaffolding we'll need to build involving keeping track of which
devices/users are "watching" which pieces of data, and which particular
push mechanism should be used to ping each device.
> - 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.
Right - it's both 1) a consistent and familiar Android API for accessing
data in a RESTy way, and 2) a way of exposing data from one app to
another. Mostly we'll be using it as (1) but (2) is a nice side benefit
as well.
Thanks,
--Glen
More information about the aerogear-dev
mailing list