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

[Summers Pittman]

If you mean implementing some stuff like what is on http://brand.redhat.com/
for websites but for Android I would love it :)

On Fri, Mar 13, 2015 at 1:17 PM, Summers Pittman <supittma at redhat.com>
wrote:

> 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.
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150316/0780ae19/attachment-0001.html