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@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@redhat.com> wrote:
Andres

Somethings like this => https://github.com/navasmdc/MaterialDesignLibrary

On Mon, Mar 16, 2015 at 11:27 AM, Summers Pittman <supittma@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@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@redhat.com> wrote:
I didn't catch what you are asking.

On Mon, Mar 16, 2015 at 9:59 AM, Andres Galante <agalante@redhat.com> wrote:
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


_______________________________________________
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



--
-- Passos

_______________________________________________
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