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

Summers Pittman supittma at redhat.com
Mon Mar 16 10:02:22 EDT 2015


I didn't catch what you are asking.

On Mon, Mar 16, 2015 at 9:59 AM, Andres Galante <agalante at redhat.com> wrote:

> Which are the UI libraries though about as base?
>
> On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> 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/0528b3ae/attachment-0001.html 


More information about the aerogear-dev mailing list