Yes, that's why I am wondering if there is any negative side-effects of
doing it this way. Given that this is really a hack, is it possible that
Google may forbid this kind of usage in the future?
Given how easy it is to initialise the SDK at the moment (one line of code
<
>),
I do have to question if there is enough value in doing this work?
On Tue, Apr 3, 2018 at 10:35 AM, Jose Miguel Gallas Olmedo <
jgallaso(a)redhat.com> wrote:
@Wei I think @Daniel point is that this is a trick/workaround. We
wouldn't
use this content provider to share anything but to call MobileCore.init
only.
JOSE MIGUEL GALLAS OLMEDO
ASSOCIATE QE, mobile
Red Hat
<
https://www.redhat.com/>
M: +34618488633 <
http://redhatemailsignature-marketing.itos.redhat.com/>
<
https://red.ht/sig>
On 3 April 2018 at 11:16, Wei Li <weil(a)redhat.com> wrote:
> By reading the document, it looks like "ContentProvider" is meant to
> provide some data for other applications. If we use it for initialising the
> SDK, what data will be provided to other apps? Is there any other negative
> side effects of using this approach?
>
>
>
> On Tue, Apr 3, 2018 at 9:26 AM, Wojciech Trocki <wtrocki(a)redhat.com>
> wrote:
>
>> Great idea!
>> This will allow SDK to be flexible, developer friendly and more aligned
>> with typical Android patterns.
>>
>> > I don't think removing manual initialisation is too important
>>
>> It will be just side effect after we move to use Android standards like `Content
>> provider` etc.
>>
>>
>> On Mon, Apr 2, 2018 at 7:57 AM, Jose Miguel Gallas Olmedo <
>> jgallaso(a)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.
>>>
>>> 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?
>>>
>>> Cheers,
>>>
>>>
>>> JOSE MIGUEL GALLAS OLMEDO
>>>
>>> ASSOCIATE QE, mobile
>>>
>>> Red Hat
>>>
>>> <
https://www.redhat.com/>
>>>
>>> M: +34618488633
>>> <
http://redhatemailsignature-marketing.itos.redhat.com/>
>>> <
https://red.ht/sig>
>>>
>>> On 29 March 2018 at 23:30, Daniel Passos <dpassos(a)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/Cont
>>>> entProvider.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(a)googlegroups.com.
>>>> To post to this group, send email to aerogear(a)googlegroups.com.
>>>> To view this discussion on the web visit
>>>>
https://groups.google.com/d/msgid/aerogear/CADF%3Dh2vUzwb1U3
>>>>
0O0GB9J4taBkkvAuvUdSkqHEk7jyQfDhK3Og%40mail.gmail.com
>>>>
<
https://groups.google.com/d/msgid/aerogear/CADF%3Dh2vUzwb1U30O0GB9J4taBkk...
>>>> .
>>>> For more options, visit
https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> 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(a)googlegroups.com.
>>> To post to this group, send email to aerogear(a)googlegroups.com.
>>> To view this discussion on the web visit
https://groups.google.com/d/ms
>>> gid/aerogear/CAGsbZmGiRzbG_b5Tp3i-rCYCUNLrms%2BwGd1c_eq2UXyv
>>>
ekGvEw%40mail.gmail.com
>>>
<
https://groups.google.com/d/msgid/aerogear/CAGsbZmGiRzbG_b5Tp3i-rCYCUNLrm...
>>> .
>>>
>>> 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>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> WEI LI
>
> Principal SOFTWARE ENGINEER
>
> Red Hat Mobile <
https://www.redhat.com/>
>
> weil(a)redhat.com M: +353862393272
> <
https://red.ht/sig>
>