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:* What you need to add to your gradle file: https://github.com/secondsun/WipDemo/blob/master/app/build.gradle#L29The 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 MartinRed Hat MobileTwitter: @irldavemIRC: @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.
