[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