[aerogear-dev] Android Core Proposal Merged (and some follow up goals)

[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

On Mon, Jan 29, 2018 at 5:44 PM, David Martin <davmarti at 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 at 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 at redhat.com>
>> wrote:
>>
>>> 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)
>>>
>>> --
>>> 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 at googlegroups.com.
>>> To post to this group, send email to aerogear at 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
>>> <https://groups.google.com/d/msgid/aerogear/CADvBQ454ouqqV8Qr7nHssEYxV932Z-JcBqA36VW6-w_Puoe-ng%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> WOJCIECH TROCKI
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> IM: wtrocki
>> <https://red.ht/sig>
>>
> --
> 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 at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CADvBQ44NLBtp18o_aC5ou5gCxgqNViq5Ocv%
> 2BPfbegd9fAr8yRg%40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CADvBQ44NLBtp18o_aC5ou5gCxgqNViq5Ocv%2BPfbegd9fAr8yRg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180201/1df77ef7/attachment.html