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

[Summers Pittman]

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.