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

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(a)redhat.com&gt; 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(a)redhat.com&gt; > > To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing List" < > aerogear-dev(a)lists.jboss.org&gt; > > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev