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

On Mon, Jan 29, 2018 at 5:44 PM, David Martin <davmarti@redhat.com> wrote:

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.


On Mon, 29 Jan 2018 17:56 Wojciech Trocki, <wtrocki@redhat.com> wrote:
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)

On Mon, Jan 29, 2018 at 4:51 PM, David Martin <davmarti@redhat.com> wrote:
Hi all,

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

* Android Core SDK is available from Maven: 
* Example Android App that uses the core SDK:


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:
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:
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)

--
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 aerogear@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 aerogear@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