Which are the UI libraries though about as base?On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman <supittma@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@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@redhat.com>
> To: mobile-internal@redhat.com, "AeroGear Developer Mailing List" <aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev