[aerogear-dev] AeroGear usage in the DevNexus app report

[Summers Pittman]

On 03/13/2015 12:22 PM, Andres Galante wrote:
> Summers, do you think that we can build an Aerogear UI based on a library? Like we do with Patternfly and Bootstrap.
If you mean set up a bunch of default styles and some value add 
widgets/behaviors sure we can do that.

>
> ----- Original Message -----
> From: "Summers Pittman" <supittma at redhat.com>
> To: mobile-internal at redhat.com, "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> Sent: Friday, March 13, 2015 1:09:51 PM
> Subject: [aerogear-dev] AeroGear usage in the DevNexus app report
>
> I made the DevNexus[1] app the past two years and have tried to dogfood
> as much of the Android AeroGear client library as I could. Consider this
> a field report of sorts from a experienced user's perspective.
>
> # Server Background
> The DevNexus website exposes its registration data as a series of JSON
> documents.  It also exposes a custom Google+ authentication endpoint
> used to identify users.  This was used by the app in 2014 for backing up
> user's schedules but was not used in 2015.  The DevNexus website itself
> is a Spring MVC application and is available on github[2].
>
> # App Background 2015
> The 2015 app has custom schedules, a Google Maps view of the venue,
> presentation viewing and discovery, a directory of previous years
> devnexus presentations, and a podcast player with audio from previous
> year's sessions.  It uses the AGDroid pipe and store libraries.  In 2014
> it also used the auth library but the feature using it was removed.  It
> also uses Picasso for image management.
>
> # AGPipe usage review
> The pipe library and its GSON marshalling are very nice and very easy.
> Those were generally wrapped in a android SyncAdapter and fired at
> regular intervals.  Pipe's callback mechanism poses some problems
> however.  Because Android aggressively cleans up objects the code needed
> to provide a lock that waited for the callbacks to finish.  Without the
> lock the code might call an object which has left Android's active state
> and this causes an error.  Over all it is still a very good way to
> handle http networking in Android.
>
> #AGAuth usage review
> The auth module was used in the 2014 application but not in the 2015
> application.  The code however remains and is functional.  I created two
> custom AuthenticationModule objects.  One interacts with the Android
> Account Manager system to get a session token from Google Plus.  The
> other attaches a cookie to http requests and handles auth failures.  In
> general the architecture is sound, but it is a bit of a hack to get
> around the fact that last year we did not have the authz library
> finished at this point which has a better architecture for this type of
> behavior.
>
> #AGStore usage review
> The store library was wrapped in a content provider.  In Android the
> content provider API provides a abstracted way to exposed data to
> activities, services, etc while having the data management and lifecycle
> happen in a controlled, centralized manner.  AG Store made handling
> large JSON serializable objects pretty trivial and most of my issues
> were around the fact that the JSON coming from the DevNexus server has
> some weird architectures.  Additionally, the query mechanism doesn't let
> you query properties of collections of objects.  This will need to be
> addressed at some point.
>
> #Things AeroGear didn't do that would have been nice
> I wanted to have offline support/file management for the podcasting
> system, but there isn't a easy library for doing that (which I found in
> my brief time looking) and we don't have a good solution for that yet
> either.  Additionally wrapping the Stores in Content providers was very
> labor intensive.  There are many projects to automate the various
> Android patterns around Content Providers which we may be able to borrow
> to make this easier.
>
> Additionally Aerogear provides nothing for the Android UI.  I think that
> this is out of scope for our project but it is something to keep in
> mind.  However there are other VERY powerful libraries which help out in
> this regard.
>
>
> #Conclusion
> AeroGear Android doesn't suck to use and provided real value to me. I
> feel like it is stable and well built especially as of 2.0.  Of course
> I'm biased.  If we have a good offline story we will enhance what is
> already a strong service and data connection to Android users.
>
> 1. https://github.com/secondsun/devnexus-android-2015
> 2. https://github.com/devnexus/devnexus-site
>


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.