[aerogear-dev] AGDroid 3.0 improvements

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] AGDroid 3.0 improvements

Summers Pittman
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.


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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] AGDroid 3.0 improvements

Sebastien Blanc
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 <[hidden email]> 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.


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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] AGDroid 3.0 improvements

Summers Pittman
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 <[hidden email]> 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 <[hidden email]> 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.


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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev