[aerogear-dev] Android roadmap review

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] Android roadmap review

Glen Daniels
Hi team,

If you would (especially Marko / Daniel), please check out the Android
roadmap at:

https://github.com/aerogear/beta.aerogear.org/blob/master/docs/planning/1.0.0/AeroGearAndroid.asciidoc

Comments / issues / thoughts greatly appreciated.

Thanks!

--Glen
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

Matthias Wessendorf
Hey Glen,

looks solid, but a few comments

- not sure if we _really_ need a chat server;
- talking about 'connectivity', what about integrating WebSocket
support (e.g. via [1]) ?

-M

[1] https://github.com/tavendo/AutobahnAndroid


On Wed, Sep 26, 2012 at 6:57 PM, Glen Daniels <[hidden email]> wrote:

> Hi team,
>
> If you would (especially Marko / Daniel), please check out the Android
> roadmap at:
>
> https://github.com/aerogear/beta.aerogear.org/blob/master/docs/planning/1.0.0/AeroGearAndroid.asciidoc
>
> Comments / issues / thoughts greatly appreciated.
>
> Thanks!
>
> --Glen
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

qmx
Administrator

On Sep 27, 2012, at 5:08 AM, Matthias Wessendorf wrote:

> Hey Glen,
>
> looks solid, but a few comments
>
> - not sure if we _really_ need a chat server;
yeah -500k for this - looks like totally off the others (iOS, js) are doing

> - talking about 'connectivity', what about integrating WebSocket
> support (e.g. via [1]) ?
>
> -M
>
> [1] https://github.com/tavendo/AutobahnAndroid
>
>
> On Wed, Sep 26, 2012 at 6:57 PM, Glen Daniels <[hidden email]> wrote:
>> Hi team,
>>
>> If you would (especially Marko / Daniel), please check out the Android
>> roadmap at:
>>
>> https://github.com/aerogear/beta.aerogear.org/blob/master/docs/planning/1.0.0/AeroGearAndroid.asciidoc
>>
>> Comments / issues / thoughts greatly appreciated.
>>
>> Thanks!
>>
>> --Glen
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- qmx


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

Matthias Wessendorf
In reply to this post by Matthias Wessendorf
any more comments?

-Matthias

On Thu, Sep 27, 2012 at 10:08 AM, Matthias Wessendorf <[hidden email]> wrote:

> Hey Glen,
>
> looks solid, but a few comments
>
> - not sure if we _really_ need a chat server;
> - talking about 'connectivity', what about integrating WebSocket
> support (e.g. via [1]) ?
>
> -M
>
> [1] https://github.com/tavendo/AutobahnAndroid
>
>
> On Wed, Sep 26, 2012 at 6:57 PM, Glen Daniels <[hidden email]> wrote:
>> Hi team,
>>
>> If you would (especially Marko / Daniel), please check out the Android
>> roadmap at:
>>
>> https://github.com/aerogear/beta.aerogear.org/blob/master/docs/planning/1.0.0/AeroGearAndroid.asciidoc
>>
>> Comments / issues / thoughts greatly appreciated.
>>
>> Thanks!
>>
>> --Glen
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

Bruno Oliveira
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:

any more comments?

-Matthias

On Thu, Sep 27, 2012 at 10:08 AM, Matthias Wessendorf <[hidden email]> wrote:
Hey Glen,

looks solid, but a few comments

- not sure if we _really_ need a chat server;
- talking about 'connectivity', what about integrating WebSocket
support (e.g. via [1]) ?

-M



On Wed, Sep 26, 2012 at 6:57 PM, Glen Daniels <[hidden email]> wrote:
Hi team,

If you would (especially Marko / Daniel), please check out the Android
roadmap at:


Comments / issues / thoughts greatly appreciated.

Thanks!

--Glen
_______________________________________________
aerogear-dev mailing list



--
Matthias Wessendorf




--
Matthias Wessendorf

_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

Bruno Oliveira
I'm talking about the demos with chat.

IMO these items are not deliverables, just a common practice.

Solidify requirements 
Follow good Android practice


-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile

On Tuesday, October 9, 2012 at 7:22 AM, Bruno Oliveira wrote:

IMO, this is not high priority.

-1


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

Marko Strukelj

>
>
> I'm talking about the demos with chat.
>

I agree.  
 
>
> IMO these items are not deliverables, just a common practice.
>
>
> - Solidify requirements
> - Follow good Android practice
>

I agree.

- marko

>
>
>
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
> On Tuesday, October 9, 2012 at 7:22 AM, Bruno Oliveira wrote:
>
>
> IMO, this is not high priority.
>
>
> -1
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

Marko Strukelj
In reply to this post by Glen Daniels
Taking a closer look at this, and considering comments made by others ...

>From roadmap:

  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 -----

> Hi team,

> If you would (especially Marko / Daniel), please check out the
> Android
> roadmap at:

> https://github.com/aerogear/beta.aerogear.org/blob/master/docs/planning/1.0.0/AeroGearAndroid.asciidoc

> Comments / issues / thoughts greatly appreciated.

> Thanks!

> --Glen
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

Glen Daniels
In reply to this post by Marko Strukelj
Hi Marko, Bruno, all,

On 10/9/12 6:52 AM, Marko Strukelj wrote:
>> I'm talking about the demos with chat.
>
> I agree.

I wasn't actually trying to say that we'd have to do a chat server *in
particular* (hence the question marks), but having more than just a
single example app seemed like a good idea for the library, which is why
I put that placeholder in.  Happy to remove it.

>> IMO these items are not deliverables, just a common practice.
>>
>> - Solidify requirements
>> - Follow good Android practice
>
> I agree.

Agreed, they're not deliverables, which is why they're not in the
"deliverables" section. :)  I thought that these were important parts of
the roadmap, though, to make sure that we kept in mind that both needed
to happen.  Again, fine with removing.

--Glen

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Android roadmap review

Glen Daniels
In reply to this post by Marko Strukelj
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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev