Android Core Proposal Merged (and some follow up goals)

[David Martin]

Hi all,

After a massive 100+ comments, I've decided to merge the Android Core SDK Proposal

https://github.com/aerogear/proposals/pull/9

* Android Core SDK is available from Maven: 

* Repo: https://github.com/aerogear/aerogear-android-sdk

* Example Android App that uses the core SDK:

https://github.com/secondsun/WipDemo/blob/master/app/src/main/java/org/feedhenry/mcp/prdemo/CoreActivity.java

* What you need to add to your gradle file: https://github.com/secondsun/WipDemo/blob/master/app/build.gradle#L29

The amount of comments, calls and back&forth on irc has reached a reasonable level of agreement, with some remaining points of contention.

The contention is mainly around the level of complexity that a developer has to undertake to use the SDK.

After listening to the 3 main voices on this (Summers, Wojciech, Passos), I can see both points of view.

(WARNING: A lot of paraphrasing below :) )

From Passos & Wojciech's point of view, ease of use of the SDK is what's most important. There should be practically no setup/init required other than having a mobile-config.json file in the right place, and call a static method to get an instance of a service (similar to Firebase).

From Summers point of view, ease of use is also important, but something we can improve on iteratively. For example, the default use of a Service will be fine & possible to automate the setup for for 95% of cases. However, the other 5% is what we need to take into account from the beginning.

So, based on this, I would like if the following 2 things were follow up goals for the Core SDK.

I believe these changes will take whats currently there (and working), and move it towards something that is easier to use for developers.

Goal 1:

https://issues.jboss.org/browse/AGDROID-712

Remove the need for static block initialisation/registration of service classes & their dependencies. i.e. this:

static {

   ServiceModuleRegistry.registerServiceModule("keycloak", KeyCloakService.class, "http");

 }

From chatting with Summers, this should be possible now that this PR is merged https://github.com/aerogear/proposals/pull/16 and the config file format is nailed down.

Goal 2:

https://issues.jboss.org/browse/AGDROID-713

Allow a simpler way of getting an instance of a Service class other than below.

   keycloakService = core.getService("keycloak", KeyCloakService.class);

If there are multiple instances registered for a particular Class, it may still be necessary to use the above to get a 'named' instance (much like in dependency injection libs like spring that use annotations).

However, in most cases, the below should be possible:

keycloakService = core.getService(KeyCloakService.class);

Thanks

--

David Martin

Red Hat Mobile

Twitter: @irldavem

IRC: @irldavem (#aerogear)

[Wojciech Trocki]

Added small comments on tickets. From my point of view everything looks great.
From my point of view Goal 2 may be actually not needed depending on how Goal 1 will be resolved.

I we think about it that is just one single ticket that is required to improve overall user experience and API.

> keycloakService = core.getService(KeyCloakService.class);

I remember that service team required to pass additional parameters and going this way will impose some limitations.

What we looking for is probably something like this:

Auth keycloak = AeroGearAuth.create(options)

--
You received this message because you are subscribed to the Google Groups "Aerogear" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aerogear+unsubscribe@googlegroups.com.
To post to this group, send email to aero...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aerogear/CADvBQ454ouqqV8Qr7nHssEYxV932Z-JcBqA36VW6-w_Puoe-ng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki

[David Martin]

Sounds good to me. If it works out that 2 is covered by 1, great.
@Passos @Summers anything you want to add?

Would be great to get feedback from anyone using the sdk already too.

To unsubscribe from this group and stop receiving emails from it, send an email to aerogear+u...@googlegroups.com.

To post to this group, send email to aero...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aerogear/CADvBQ454ouqqV8Qr7nHssEYxV932Z-JcBqA36VW6-w_Puoe-ng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Passos]

TL;DR the goal 1 is my mean goal, as a developer I don't wanna need to register any service provided by the SDK.

And maybe the goal 2 is not needed I'm not 200% sure now

To unsubscribe from this group and stop receiving emails from it, send an email to aerogear+unsubscribe@googlegroups.com.

To post to this group, send email to aero...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aerogear/CADvBQ454ouqqV8Qr7nHssEYxV932Z-JcBqA36VW6-w_Puoe-ng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki

--

You received this message because you are subscribed to the Google Groups "Aerogear" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aerogear+unsubscribe@googlegroups.com.

To post to this group, send email to aero...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/aerogear/CADvBQ44NLBtp18o_aC5ou5gCxgqNViq5Ocv%2BPfbegd9fAr8yRg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

-- Passos