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

Mon Mar 16 10:19:42 EDT 2015

You mention that "there are other VERY powerful libraries which help out in
this regard." I was wondering which UI libraries we can base ours

On Mon, Mar 16, 2015 at 11:02 AM, Summers Pittman <supittma at redhat.com>
wrote:

> 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
>>
>
>
> _______________________________________________
> 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/0391ba8a/attachment.html 