On 02/26/2015 10:58 AM, Brian Leathem wrote:

On 2015-02-26 07:13 AM, Summers Pittman wrote:

I really, really, REALLY wish Google hadn't made Android a class and had gone for an injection/composition programming model instead.  It's like they weren't even paying any attention to academic and professional literature about OO and Java in 2006...

Agreed - it's a severe limitation indeed.

In terms of landing the google-play-services oauth2-token request feature I am trying to implement, I see a number of paths forward:

1) Rewrite the Aeroegear Oauth2 API altogether to be intenet based, providing users the token via the #onActivityResult method.  This would mostly just be adding a layer in front of the existing API, and shouldn't be too honerous.  It would however be a breaking change for downstream applications.

2) Leave the google-play-services request out of android-authz (Android users can initiate the play-services intent themselves if they want).  Instead I would implement this feature only in the oauth2-codova plugin where I can receive the intent response.

3) Explore using an Android Service to handle Oauth2 token requests.  I believe we would be able to trigger an intent and retrieve the result from within the service, then provide it to the downstream application from the service.  It's a little unclear as to whether starting intents from a Service is good practice.

My vote would be to pursue 2) for now, with a note about 1) being added to AGDROID-319 to be treated in a future revision.

I agree.  For 1 we should leave the old implementation as an option.  Not having your activity die during log in is a good feature and the dialog is the easiest way I can think of it and it keeps it from being a breaking change.

Thoughts?

-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.