On Mon, Apr 2, 2018 at 3:57 AM, Jose Miguel Gallas Olmedo <jgallaso@redhat.com> wrote:
I don't think removing manual initialisation is too important, I'd expect that from any other library. However auto-magic is way more elegant and user friendly, so +1 from me.

Well, I didn't said it's important, I said it's something I'd like to do.

Just to be clear I'm not going to *remove* the init method it's only will be called by the Android lifecycle but you will still able to call it itself (if you want) including changing the default stuffs
https://github.com/aerogear/aerogear-android-sdk/blob/master/core/src/main/java/org/aerogear/mobile/core/MobileCore.java#L114-L117
 

TL;DR what Firebase does is uses a Content Provide[1] (not really created for this) as a trick to initialize the lib before the app starts

Can you provide some reference for this?

https://firebase.googleblog.com/2016/12/how-does-firebase-initialize-on-android.html
https://youtu.be/AJqakuas_6g?t=20m38s
 

Cheers,


JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat 

M: +34618488633    


On 29 March 2018 at 23:30, Daniel Passos <dpassos@redhat.com> wrote:

Hi,

Revisiting some Google and Firebase stuff Summers and I realized the Firebase Android SDK doesn’t need we do any init to the lib starts/be configured.

TL;DR what Firebase does is uses a Content Provide[1] (not really created for this) as a trick to initialize the lib before the app starts

Why Content provider?

Because it has access to the applicationContext[2] and is called before all other Android kinds of stuff in the Android lifecycle (including Application)

I’d like to do the same for our Android SDK and initialize the lib using the same trick so we can provide a MobileCore.getInstance() already configured with all the things the developer needs (Logger, HttpLayer, Mobile Services info, etc…) without need to create an application class or call MobileCore.init(context) anywhere and kill all static methods we have today in MobileCore

It will also allow us to send the default metrics before the Android lifecycle starts the app and have some controls (when need) to know when the app is in background and foreground, listeners possible crashes and other things without the developer needs to call/configure anything.

PS: This is will probably be the first step to kill the responsibility to the MobileCore instantiate the Service Modules[3]

Any thoughts?

[1] https://developer.android.com/guide/topics/providers/content-providers.html
[2] https://developer.android.com/reference/android/content/ContentProvider.html#getContext()
[3] https://issues.jboss.org/browse/AGDROID-796

--
-- Passos

--
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/CADF%3Dh2vUzwb1U30O0GB9J4taBkkvAuvUdSkqHEk7jyQfDhK3Og%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.




--
-- Passos