[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