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

Mon Mar 16 09:59:54 EDT 2015

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150316/571e2ce3/attachment.html 