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

Which are the UI libraries though about as base? On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman <supittma(a)redhat.com&gt; 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(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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev