11:09 a.m.
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.
11:22 a.m.
Summers, do you think that we can build an Aerogear UI based on a library? Like we do with
Patternfly and Bootstrap.
----- Original Message -----
From: "Summers Pittman" <supittma(a)redhat.com>
To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing List"
<aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
12:17 p.m.
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>
To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing List"
<aerogear-dev(a)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.
8:47 a.m.
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>
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>
> To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing List" <
aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:59 a.m.
Which are the UI libraries though about as base?
On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman <supittma(a)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(a)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(a)redhat.com>
> > To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing List"
<
> aerogear-dev(a)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(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
9:02 a.m.
I didn't catch what you are asking.
On Mon, Mar 16, 2015 at 9:59 AM, Andres Galante <agalante(a)redhat.com> wrote:
Which are the UI libraries though about as base?
On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman <supittma(a)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(a)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(a)redhat.com>
>> > To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing List"
<
>> aerogear-dev(a)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(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
9:19 a.m.
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(a)redhat.com>
wrote:
I didn't catch what you are asking.
On Mon, Mar 16, 2015 at 9:59 AM, Andres Galante <agalante(a)redhat.com>
wrote:
> Which are the UI libraries though about as base?
>
> On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman <supittma(a)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(a)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(a)redhat.com>
>>> > To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing
List" <
>>> aerogear-dev(a)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(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
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:27 a.m.
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(a)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(a)redhat.com>
wrote:
> I didn't catch what you are asking.
>
> On Mon, Mar 16, 2015 at 9:59 AM, Andres Galante <agalante(a)redhat.com>
> wrote:
>
>> Which are the UI libraries though about as base?
>>
>> On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman <supittma(a)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(a)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(a)redhat.com>
>>>> > To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing
List" <
>>>> aerogear-dev(a)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(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
>>
>
>
> _______________________________________________
> 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
9:31 a.m.
Andres
Somethings like this => https://github.com/navasmdc/MaterialDesignLibrary
On Mon, Mar 16, 2015 at 11:27 AM, Summers Pittman <supittma(a)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(a)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(a)redhat.com>
> wrote:
>
>> I didn't catch what you are asking.
>>
>> On Mon, Mar 16, 2015 at 9:59 AM, Andres Galante <agalante(a)redhat.com>
>> wrote:
>>
>>> Which are the UI libraries though about as base?
>>>
>>> On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman
<supittma(a)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(a)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(a)redhat.com>
>>>>> > To: mobile-internal(a)redhat.com, "AeroGear Developer Mailing
List" <
>>>>> aerogear-dev(a)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(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
>>>
>>
>>
>> _______________________________________________
>> 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
--
-- Passos
9:42 a.m.
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(a)redhat.com> wrote:
Andres
Somethings like this => https://github.com/navasmdc/MaterialDesignLibrary
On Mon, Mar 16, 2015 at 11:27 AM, Summers Pittman <supittma(a)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(a)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(a)redhat.com>
>> wrote:
>>
>>> I didn't catch what you are asking.
>>>
>>> On Mon, Mar 16, 2015 at 9:59 AM, Andres Galante <agalante(a)redhat.com>
>>> wrote:
>>>
>>>> Which are the UI libraries though about as base?
>>>>
>>>> On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman
<supittma(a)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(a)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(a)redhat.com>
>>>>>> > To: mobile-internal(a)redhat.com, "AeroGear Developer
Mailing List"
>>>>>> <aerogear-dev(a)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(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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
--
-- Passos
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:44 a.m.
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(a)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(a)redhat.com>
wrote:
> Andres
>
> Somethings like this => https://github.com/navasmdc/MaterialDesignLibrary
>
> On Mon, Mar 16, 2015 at 11:27 AM, Summers Pittman <supittma(a)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(a)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(a)redhat.com>
>>> wrote:
>>>
>>>> I didn't catch what you are asking.
>>>>
>>>> On Mon, Mar 16, 2015 at 9:59 AM, Andres Galante
<agalante(a)redhat.com>
>>>> wrote:
>>>>
>>>>> Which are the UI libraries though about as base?
>>>>>
>>>>> On Mon, Mar 16, 2015 at 10:47 AM, Summers Pittman <
>>>>> supittma(a)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(a)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(a)redhat.com>
>>>>>>> > To: mobile-internal(a)redhat.com, "AeroGear Developer
Mailing
>>>>>>> List" <aerogear-dev(a)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(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
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> 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
3570
days inactive
3573
days old
10 comments
3 participants
participants (3)
-
Andres Galante -
Daniel Passos -
Summers Pittman