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

Summers Pittman supittma at redhat.com
Mon Mar 16 10:44:35 EDT 2015 

Well the redhat pages have nothing around mobile branding and app design so
it is probably worth having SOMETHING.  Even if it is just a bunch of
standard colors, backgrounds, and styles in xml files in a aar project we
can inherit from.  I don't think writing tons of code is necessary, just
sensible defaults.

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

> I don't think we can maintain a hole library. But having a layer of
> styling over material design might be possible. Let me think about it, I
> just wonder if its necessary, material design is excellent.
>
> On Mon, Mar 16, 2015 at 11:31 AM, Daniel Passos <dpassos at redhat.com>
> wrote:
>
>> Andres
>>
>> Somethings like this => https://github.com/navasmdc/MaterialDesignLibrary
>>
>> On Mon, Mar 16, 2015 at 11:27 AM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>> Ahhh.
>>>
>>> There are a few libraries for widgets (especially for material design).
>>> There are also some injection libraries for autowiring views to objects in
>>> the Activity class.
>>>
>>> Picasso comes to mind for images, butter knife does view injection, and
>>> there are too many Material Design libs to count/enumerate.  I also don't
>>> make a list because I haven't tried enough to have an informed opinion.
>>>
>>> On Mon, Mar 16, 2015 at 10:19 AM, Andres Galante <agalante at redhat.com>
>>> wrote:
>>>
>>>> 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
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>> --
>> -- Passos
>>
>> _______________________________________________
>> 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/c148031b/attachment.html

More information about the aerogear-dev mailing list