Hi Marko, all,
Thanks for the review! Comments inline.
On 10/9/12 9:41 AM, Marko Strukelj wrote:
- 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.
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 ===============
- 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
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
- 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
I agree, and also brought that up on the other thread with Daniel's pull
- 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
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,
That seems right.
- 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
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.
- 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)
). 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
- 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.
- 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?
- 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
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
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
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