3:04 p.m.
One of the things passos and I have discussed in the past is using
dependency injection (possibly dagger) to reduce a lot of the boiler plate
that is in AGDroid projects (think those nasty config blocks in the
quickstarts which exist for EVERY pipe, oauthmodule, push module, etc). We
decided not to do that in the past because to make it work we would need to
use a gradle plugin, extend all the activity and fragment classes to
interrupt the normal lifecycle, or require the user to call magic methods.
This felt out of touch with the "style" of programming Google was
advocating at the time.
With Google play services 7.5 Google is preparing a gradle plugin which
will consume a services file and provide those values to code via static
variables. (Specifically it injects them into the value.xml file which aidl
turns into values in the Resources object). So we've decided to revisit
the issue.
See Epic : https://issues.jboss.org/browse/AGDROID-476
We want to create a Gradle plugin which will parse ups and keycloak json
files and provide convenient tools for managing interactions with those
objects. These tools right now will consist of providing annotations to
inject modules and interaction with the Activity lifecycle.
In the Push Issue on the Jira I have a quick sample of how the code might
look. You can see there is a LOT less boiler plate. The idea is that all
of the values in the PushRegistrar were parsed from json config file
automatically and the PushRegistrar was instantiated and managed
transparently.
wdyt? What are pain points you've had with AGDroid this style of tool
could help? Should we also make plugins for maven applications?
6:42 a.m.
I like that !
But did I understand that is tied to Google play Services ? I mean I could
not use that to inject for instance the Amazon Push Registrar flavor ?
On Thu, Jul 9, 2015 at 10:04 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
One of the things passos and I have discussed in the past is using
dependency injection (possibly dagger) to reduce a lot of the boiler plate
that is in AGDroid projects (think those nasty config blocks in the
quickstarts which exist for EVERY pipe, oauthmodule, push module, etc). We
decided not to do that in the past because to make it work we would need to
use a gradle plugin, extend all the activity and fragment classes to
interrupt the normal lifecycle, or require the user to call magic methods.
This felt out of touch with the "style" of programming Google was
advocating at the time.
With Google play services 7.5 Google is preparing a gradle plugin which
will consume a services file and provide those values to code via static
variables. (Specifically it injects them into the value.xml file which aidl
turns into values in the Resources object). So we've decided to revisit
the issue.
See Epic : https://issues.jboss.org/browse/AGDROID-476
We want to create a Gradle plugin which will parse ups and keycloak json
files and provide convenient tools for managing interactions with those
objects. These tools right now will consist of providing annotations to
inject modules and interaction with the Activity lifecycle.
In the Push Issue on the Jira I have a quick sample of how the code might
look. You can see there is a LOT less boiler plate. The idea is that all
of the values in the PushRegistrar were parsed from json config file
automatically and the PushRegistrar was instantiated and managed
transparently.
wdyt? What are pain points you've had with AGDroid this style of tool
could help? Should we also make plugins for maven applications?
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:09 a.m.
Currently we don't support Amazon in the -push library at all so no. If we
did at a later date, yes.
On Fri, Jul 10, 2015 at 7:42 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
I like that !
But did I understand that is tied to Google play Services ? I mean I could
not use that to inject for instance the Amazon Push Registrar flavor ?
On Thu, Jul 9, 2015 at 10:04 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
> One of the things passos and I have discussed in the past is using
> dependency injection (possibly dagger) to reduce a lot of the boiler plate
> that is in AGDroid projects (think those nasty config blocks in the
> quickstarts which exist for EVERY pipe, oauthmodule, push module, etc). We
> decided not to do that in the past because to make it work we would need to
> use a gradle plugin, extend all the activity and fragment classes to
> interrupt the normal lifecycle, or require the user to call magic methods.
> This felt out of touch with the "style" of programming Google was
> advocating at the time.
>
> With Google play services 7.5 Google is preparing a gradle plugin which
> will consume a services file and provide those values to code via static
> variables. (Specifically it injects them into the value.xml file which aidl
> turns into values in the Resources object). So we've decided to revisit
> the issue.
>
> See Epic : https://issues.jboss.org/browse/AGDROID-476
>
> We want to create a Gradle plugin which will parse ups and keycloak json
> files and provide convenient tools for managing interactions with those
> objects. These tools right now will consist of providing annotations to
> inject modules and interaction with the Activity lifecycle.
>
> In the Push Issue on the Jira I have a quick sample of how the code might
> look. You can see there is a LOT less boiler plate. The idea is that all
> of the values in the PushRegistrar were parsed from json config file
> automatically and the PushRegistrar was instantiated and managed
> transparently.
>
> wdyt? What are pain points you've had with AGDroid this style of tool
> could help? Should we also make plugins for maven applications?
>
> _______________________________________________
> 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
3476
days inactive
3477
days old
2 comments
2 participants
participants (2)
-
Sebastien Blanc -
Summers Pittman