From jgallaso at redhat.com Mon Apr 2 02:57:41 2018 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Mon, 2 Apr 2018 08:57:41 +0200 Subject: [aerogear-dev] Make MobileCore Init automatically called in Android SDK In-Reply-To: References: Message-ID: 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 M: +34618488633 On 29 March 2018 at 23:30, Daniel Passos 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 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/CADF%3Dh2vUzwb1U30O0GB9J4taBkkvAuvU > dSkqHEk7jyQfDhK3Og%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180402/d9a5634b/attachment-0001.html From matzew at apache.org Mon Apr 2 06:21:48 2018 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 2 Apr 2018 12:21:48 +0200 Subject: [aerogear-dev] [mobile-core] OCP v3.9.0 Message-ID: Hi, Openshift 3.9 is out ([1]) - not sure we immediately want to update, however this time it's a bit more work involved than w/ the past version updates between 3.6.x and 3.7.x Patching the version to 3.9.0, gives this status: ? mobile-core git:(v3.9.0) ? oc cluster status Web console URL: Config is at host directory /home/matzew/Work/aerogear/mobile-core/ui Volumes are at host directory Persistent volumes are at host directory /home/matzew/Work/aerogear/mobile-core/ui/openshift-pvs Data is at host directory /home/matzew/Work/aerogear/mobile-core/ui/openshift-data In the Browser I am getting: missing service (service "webconsole" not found) missing route (service "webconsole" not found) I've not really done much, but was thinking to give the update a quick shot :-) Looks like this might need an EPIC and some JIRAs attached to it. Cheers, Matthias -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180402/f1ca68bf/attachment.html From matzew at apache.org Mon Apr 2 06:23:28 2018 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 2 Apr 2018 12:23:28 +0200 Subject: [aerogear-dev] [mobile-core] OCP v3.9.0 In-Reply-To: References: Message-ID: Dat link was missing [1] https://blog.openshift.com/announcing-the-openshift-container-platform-3-9-ga/ On Mon, Apr 2, 2018 at 12:21 PM, Matthias Wessendorf wrote: > Hi, > > Openshift 3.9 is out ([1]) - not sure we immediately want to update, > however this time it's a bit more work involved than w/ the past version > updates between 3.6.x and 3.7.x > > Patching the version to 3.9.0, gives this status: > > ? mobile-core git:(v3.9.0) ? oc cluster status > Web console URL: > > Config is at host directory /home/matzew/Work/aerogear/mobile-core/ui > Volumes are at host directory > Persistent volumes are at host directory /home/matzew/Work/aerogear/ > mobile-core/ui/openshift-pvs > Data is at host directory /home/matzew/Work/aerogear/ > mobile-core/ui/openshift-data > > In the Browser I am getting: > > missing service (service "webconsole" not found) > missing route (service "webconsole" not found) > > > I've not really done much, but was thinking to give the update a quick > shot :-) > > Looks like this might need an EPIC and some JIRAs attached to it. > > Cheers, > Matthias > > -- > Matthias Wessendorf > > github: https://github.com/matzew > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180402/8818466b/attachment.html From dpassos at redhat.com Mon Apr 2 08:00:18 2018 From: dpassos at redhat.com (Daniel Passos) Date: Mon, 2 Apr 2018 09:00:18 -0300 Subject: [aerogear-dev] Make MobileCore Init automatically called in Android SDK In-Reply-To: References: Message-ID: On Mon, Apr 2, 2018 at 3:57 AM, Jose Miguel Gallas Olmedo < jgallaso at 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 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 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/ms >> gid/aerogear/CADF%3Dh2vUzwb1U30O0GB9J4taBkkvAuvUdSkqHEk7jyQf >> DhK3Og%40mail.gmail.com >> >> . >> 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/20180402/4a9a2bdc/attachment-0001.html From wtrocki at redhat.com Tue Apr 3 04:26:28 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Tue, 3 Apr 2018 09:26:28 +0100 Subject: [aerogear-dev] Make MobileCore Init automatically called in Android SDK In-Reply-To: References: Message-ID: 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 at 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 > > > > M: +34618488633 > > > > On 29 March 2018 at 23:30, Daniel Passos 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 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/ms >> gid/aerogear/CADF%3Dh2vUzwb1U30O0GB9J4taBkkvAuvUdSkqHEk7jyQf >> DhK3Og%40mail.gmail.com >> >> . >> 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 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/ms > gid/aerogear/CAGsbZmGiRzbG_b5Tp3i-rCYCUNLrms%2BwGd1c_eq2UXyv > ekGvEw%40mail.gmail.com > > . > > For more options, visit https://groups.google.com/d/optout. > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180403/11e9461c/attachment.html From weil at redhat.com Tue Apr 3 05:16:47 2018 From: weil at redhat.com (Wei Li) Date: Tue, 3 Apr 2018 10:16:47 +0100 Subject: [aerogear-dev] Make MobileCore Init automatically called in Android SDK In-Reply-To: References: Message-ID: 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 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 at 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 >> >> >> >> M: +34618488633 >> >> >> >> On 29 March 2018 at 23:30, Daniel Passos 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 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/ms >>> gid/aerogear/CADF%3Dh2vUzwb1U30O0GB9J4taBkkvAuvUdSkqHEk7jyQf >>> DhK3Og%40mail.gmail.com >>> >>> . >>> 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 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/ms >> gid/aerogear/CAGsbZmGiRzbG_b5Tp3i-rCYCUNLrms%2BwGd1c_eq2UXyv >> ekGvEw%40mail.gmail.com >> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- WEI LI Principal SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180403/52f4800f/attachment-0001.html From jgallaso at redhat.com Tue Apr 3 05:35:53 2018 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Tue, 3 Apr 2018 11:35:53 +0200 Subject: [aerogear-dev] Make MobileCore Init automatically called in Android SDK In-Reply-To: References: Message-ID: @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 M: +34618488633 On 3 April 2018 at 11:16, Wei Li 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 > 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 at 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 >>> >>> >>> >>> M: +34618488633 >>> >>> >>> >>> On 29 March 2018 at 23:30, Daniel Passos 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 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/ms >>>> gid/aerogear/CADF%3Dh2vUzwb1U30O0GB9J4taBkkvAuvUdSkqHEk7jyQf >>>> DhK3Og%40mail.gmail.com >>>> >>>> . >>>> 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 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/ms >>> gid/aerogear/CAGsbZmGiRzbG_b5Tp3i-rCYCUNLrms%2BwGd1c_eq2UXyv >>> ekGvEw%40mail.gmail.com >>> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > > WEI LI > > Principal SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180403/c5334cfb/attachment.html From weil at redhat.com Tue Apr 3 06:04:18 2018 From: weil at redhat.com (Wei Li) Date: Tue, 3 Apr 2018 11:04:18 +0100 Subject: [aerogear-dev] Make MobileCore Init automatically called in Android SDK In-Reply-To: References: Message-ID: 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 at 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 > > > > M: +34618488633 > > > > On 3 April 2018 at 11:16, Wei Li 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 >> 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 at 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 >>>> >>>> >>>> >>>> M: +34618488633 >>>> >>>> >>>> >>>> On 29 March 2018 at 23:30, Daniel Passos 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 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/CADF%3Dh2vUzwb1U3 >>>>> 0O0GB9J4taBkkvAuvUdSkqHEk7jyQfDhK3Og%40mail.gmail.com >>>>> >>>>> . >>>>> 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 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/ms >>>> gid/aerogear/CAGsbZmGiRzbG_b5Tp3i-rCYCUNLrms%2BwGd1c_eq2UXyv >>>> ekGvEw%40mail.gmail.com >>>> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> >>> WOJCIECH TROCKI >>> >>> Red Hat Mobile >>> >>> IM: wtrocki >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> >> WEI LI >> >> Principal SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> > > -- WEI LI Principal SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180403/ae454129/attachment-0001.html From pwright at redhat.com Tue Apr 3 09:22:59 2018 From: pwright at redhat.com (Paul Wright) Date: Tue, 3 Apr 2018 14:22:59 +0100 Subject: [aerogear-dev] Introducing Antora for publishing docs Message-ID: <3f85de37-d3ab-0cf2-9af6-5d44617ba978@redhat.com> Hi Up to now, I've been using asciibinder [1] to preview docs, but Dan Allen (of asciidoctor fame) has released Antora [2], which addresses our use case better, and I'd like to switch to using that. Specifically, Antora is designed to work with: * remote code repos where docs is written along side code * multiple component versions (automatically provides menus to switch between versions) We were trying to script around asciibinder to allow for those issues (remember asciibinder was written for OpenShift, a single product with multiple flavors, rather than a set of versioned services), however I think we can get further faster with Antora . This won't affect the way you author adoc files (in fact it should make it easier), we'll just need to include a structure in each docs directory. If you look at the Antora docs [2] you can see the system in action, the menu at the bottom left allows you switch between versions (currently only 1.0 is available), and a component (Antora Default UI). You'll also see that there's a link to 'Edit this Page' which will direct you to the correct repo and branch as required. There are a lot of other advantages [3], but I've outlined the main ones, and created a rough rendering of what it means for AeroGear [4] Let me know of any objections, thanks, Paul [1] http://asciibinder.org/ [2] https://docs.antora.org [3] https://antora.org/ [4] https://drive.google.com/file/d/1l4AJGKSLI2e7vy9emIkVNTojf-C1waFM/view?usp=sharing -- Paul Wright Mobile Docs (github: finp) From pwright at redhat.com Mon Apr 9 04:16:04 2018 From: pwright at redhat.com (Paul Wright) Date: Mon, 9 Apr 2018 09:16:04 +0100 Subject: [aerogear-dev] Make debugging compatibility issues easier Message-ID: <7cba7c48-0a9d-850d-b80d-5986a466e3f9@redhat.com> Hi, I've been thinking about some simple debugging procedures, seems like we'll be asking users to: 1. Reload config json for mobile app (cos something might have changed on OpenShift side) 2. Check a Compatibility Matrix to make sure that your sdks and services all match up That second step seems to be a non-optimal user experience, could we add compatibility information to config json? This would mean the user would not have to leave their IDE to check out a compatibility issue. How might it work? Each update to a service could include the following info: * compatibleWith * incompatibleWith and as part of updating a service, include known compatibility, for example with Keycloak Service v2.3.1 you might have "androidSDKCompatibleWith":[ "2.x.x", "3.x.x" ], "androidSDKIncompatibleWith":[ "2.0.x" ] The user can then check the SDK version and take action as required, WDYT? Paul -- Paul Wright Mobile Docs (github: finp) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180409/ceea0e99/attachment.html From tigert at redhat.com Thu Apr 12 05:48:38 2018 From: tigert at redhat.com (Tuomas Kuosmanen) Date: Thu, 12 Apr 2018 12:48:38 +0300 Subject: [aerogear-dev] aerogear.org refresh work Message-ID: Hello. I am a designer at the Open Source and Standards team at Red Hat. We help communities with various things. I have been working on the aerogear website refresh which is viewable here for now: https://tigert-work.github.io/ It's a github pages site that follows this repo: https://github.com/tigert-work/tigert-work.github.io The idea behind the change comes from the effort to split documentation into a separate site that focuses on being developer friendly and usable, and the main aerogear.org would have more focus on showcase of the project. The plan is to move the repo over to aerogear github organization eventually, but right now I am requesting help with the content, because I do not have much hands-on experience in AeroGear myself. My brief discussion on IRC also revealed that some of that content I took from the old site as a starting point is indeed old and no longer true. What we have so far: Front page: - The two columns' wording is rough, but it tries to explain that we have a toolkit with different modules for mobile development with OpenShift / Kubernetes as the service platform. - It also showcases the three featured modules and links to per-module pages that will explain a bit more of each. Get Started: - Getting Started is something I need help with. The process as far as I understand, involves your own private openshift instance and probably more things I am not aware of. My understanding is that the user will spin up the service catalog and start the aerogear service, then install the sdk and build an example application (probably push notifications) that you get up and running. There then needs to be a link for more examples covering the other modules on the new documentation site. This would be something we should try to make as easy as possible to get started, but the requirement of your own openshift kind of makes it quite a different scale than just installing a plugin on your android sdk and building an example app. Ideas are welcome :-) Documentation: - This link is currently broken as new docs are being split into docs.aerogear.org that does not yet exist. Community: - This is from the current site, and it is probably OK apart from the "Contributing to AeroGear" links that needs to be rewritten and link-fixed once the new docs are in place. Module pages: These are under construction as well, whatever content there is is mostly from the existing site. Any help with the content would be appreciated, both structural "flow" and spotting inaccuracies or problems. You can file github issues on the repository for example. Thanks a lot for any time and effort you can spare on this. Tuomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180412/5893b3e7/attachment.html From vsazel at redhat.com Mon Apr 16 04:49:54 2018 From: vsazel at redhat.com (Vojtech Sazel) Date: Mon, 16 Apr 2018 10:49:54 +0200 Subject: [aerogear-dev] Xamarin AG SDK project structure Message-ID: Hi, I merged Core PR. With it it comes unification of project strucure. We have - Core - Core.Platform.Android/ - Core.Platform.iOS/ - Core.Platform.NuGet/ - Core.Platform.Shared/ - Core.Tests/ - Auth - Auth - Auth.Tests - Auth.Platform.Android - Auth.Platform.iOS - Example - - Example/ - Example.Android/ - Example.iOS/ - Documentation -- VOJT?CH S?ZEL SENIOR SOFTWARE ENGINEER, RED HAT MOBILE Red Hat Remote Czech Republic vsazel at redhat.com IM: vsazel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180416/2dc314bb/attachment.html From weil at redhat.com Mon Apr 16 05:11:28 2018 From: weil at redhat.com (Wei Li) Date: Mon, 16 Apr 2018 10:11:28 +0100 Subject: [aerogear-dev] Xamarin AG SDK project structure In-Reply-To: References: Message-ID: Hi Vojtech, That's great. Can you also please create a SDK development document and add the structure to that document, along with some other info that could be useful for the SDK developers, e.g. the high level architecture, how to add shared code, and how to add implementation for platform-specific implementation etc. Thanks. On Mon, Apr 16, 2018 at 9:49 AM, Vojtech Sazel wrote: > Hi, > > I merged Core PR. With it it comes unification of project strucure. > > We have > > > - Core > - Core.Platform.Android/ > - Core.Platform.iOS/ > - Core.Platform.NuGet/ > - Core.Platform.Shared/ > - Core.Tests/ > - Auth > - Auth > - Auth.Tests > - Auth.Platform.Android > - Auth.Platform.iOS > - Example > - > - Example/ > - Example.Android/ > - Example.iOS/ > - Documentation > > > > -- > > VOJT?CH S?ZEL > > SENIOR SOFTWARE ENGINEER, RED HAT MOBILE > > Red Hat > > > > Remote Czech Republic > > vsazel at redhat.com IM: vsazel > > -- WEI LI Principal SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180416/9d259f63/attachment-0001.html From vsazel at redhat.com Mon Apr 16 08:02:33 2018 From: vsazel at redhat.com (Vojtech Sazel) Date: Mon, 16 Apr 2018 14:02:33 +0200 Subject: [aerogear-dev] Xamarin AG SDK project structure In-Reply-To: References: Message-ID: Yeah, I'm doing the docs now. Vojtech On Mon, Apr 16, 2018 at 11:11 AM, Wei Li wrote: > Hi Vojtech, > > That's great. > > Can you also please create a SDK development document and add the > structure to that document, along with some other info that could be useful > for the SDK developers, e.g. the high level architecture, how to add shared > code, and how to add implementation for platform-specific implementation > etc. > > Thanks. > > > On Mon, Apr 16, 2018 at 9:49 AM, Vojtech Sazel wrote: > >> Hi, >> >> I merged Core PR. With it it comes unification of project strucure. >> >> We have >> >> >> - Core >> - Core.Platform.Android/ >> - Core.Platform.iOS/ >> - Core.Platform.NuGet/ >> - Core.Platform.Shared/ >> - Core.Tests/ >> - Auth >> - Auth >> - Auth.Tests >> - Auth.Platform.Android >> - Auth.Platform.iOS >> - Example >> - >> - Example/ >> - Example.Android/ >> - Example.iOS/ >> - Documentation >> >> >> >> -- >> >> VOJT?CH S?ZEL >> >> SENIOR SOFTWARE ENGINEER, RED HAT MOBILE >> >> Red Hat >> >> >> >> Remote Czech Republic >> >> vsazel at redhat.com IM: vsazel >> >> > > > > -- > > WEI LI > > Principal SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > -- VOJT?CH S?ZEL SENIOR SOFTWARE ENGINEER, RED HAT MOBILE Red Hat Remote Czech Republic vsazel at redhat.com IM: vsazel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180416/88b6371b/attachment.html From tigert at redhat.com Wed Apr 18 08:28:33 2018 From: tigert at redhat.com (Tuomas Kuosmanen) Date: Wed, 18 Apr 2018 15:28:33 +0300 Subject: [aerogear-dev] aerogear stickers for red hat summit Message-ID: Hello, I was requested to do some stickers for AeroGear for the upcoming Red Hat Summit conference to give away, so I figured I'd share the design for comments. It would be a die-cut sticker approximately 10cm wide, with the white outline on the cutout to make it stand out from the background (works on dark laptop lids). Best wishes, Tuomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180418/a1686d10/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: sticker-diecut-mockup.pdf Type: application/pdf Size: 61593 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180418/a1686d10/attachment-0001.pdf From pwright at redhat.com Thu Apr 19 08:45:13 2018 From: pwright at redhat.com (Paul Wright) Date: Thu, 19 Apr 2018 13:45:13 +0100 Subject: [aerogear-dev] docs.aerogear.org Message-ID: Hi, We've discussed using github pages to host docs.aerogear.org html, but now I need a repo to store the html/etc for that site (http://shiftgear.org is only a temporary solution). The plan is to use the process described in https://help.github.com/articles/about-supported-custom-domains/#custom-subdomains and therefore to create a repo named "docs.aerogear.org" in the aerogear github org. Any objections or better alternatives? (I thought I'd get the subdomain set up first and then create the repo, but it has to happen the other way round, I need https://aerogear.github.io/docs.aerogear.org/ to work before the subdomain can be configured) -- Paul Wright Mobile Docs (github: finp) From davmarti at redhat.com Fri Apr 20 06:16:00 2018 From: davmarti at redhat.com (David Martin) Date: Fri, 20 Apr 2018 11:16:00 +0100 Subject: [aerogear-dev] docs.aerogear.org In-Reply-To: References: Message-ID: On 19 April 2018 at 13:45, Paul Wright wrote: > Hi, > > We've discussed using github pages to host docs.aerogear.org html, but > now I need a repo to store the html/etc for that site ( > http://shiftgear.org is only a temporary solution). > > The plan is to use the process described in https://help.github.com/articl > es/about-supported-custom-domains/#custom-subdomains > > and therefore to create a repo named "docs.aerogear.org" in the aerogear > github org. > > Any objections or better alternatives? > Sounds reasonable. No objections. I'll create this later today unless things change > > (I thought I'd get the subdomain set up first and then create the repo, > but it has to happen the other way round, I need > https://aerogear.github.io/docs.aerogear.org/ to work before the > subdomain can be configured) > > -- > Paul Wright > Mobile Docs (github: finp) > > -- > 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/ms > gid/aerogear/b67095f2-3fa7-8868-4d6b-4157ca27a176%40redhat.com. > For more options, visit https://groups.google.com/d/optout. > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180420/c9f1b5ed/attachment.html From vsazel at redhat.com Fri Apr 20 08:59:25 2018 From: vsazel at redhat.com (Vojtech Sazel) Date: Fri, 20 Apr 2018 14:59:25 +0200 Subject: [aerogear-dev] [help needed] AG Xamarin multiplatform service module problem Message-ID: Hi, we encountered a problem with Aiden and Massimo with the underlying architecture of the multiplatform project in Xamarin. We need to have Auth service module accessible from application. But module has some platform specific implementations we need to get. 1) Suppose we have some class Auth implementing IServiceModule. We would have it implemented only using platform-independent. So we can simply do MobileCore.Instance.GetInstance() 2) But now we need to have some platform specific stuff done in the module, so we create AuthAndroid and AuthIOS extending Auth (which is now abstract) in platform specific projects. In ordinary pure Android (or iOS respectively) app we can do: MobileCore.Instance.GetInstance() 3) But we can't do that with Xamarin.Forms app where stuff is in platform independent project. We can utilize DependencyService in Xamarin.Forms app project or create separate Xamarin.Forms project with Auth, but it seems that code won't be very pretty in this case. What can we do to solve this problem? I think we can debate it further after todays ST1 standup. -- VOJT?CH S?ZEL SENIOR SOFTWARE ENGINEER, RED HAT MOBILE Red Hat Remote Czech Republic vsazel at redhat.com IM: vsazel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180420/cc6a5b7e/attachment.html From supittma at redhat.com Fri Apr 20 09:28:03 2018 From: supittma at redhat.com (Summers Pittman) Date: Fri, 20 Apr 2018 09:28:03 -0400 Subject: [aerogear-dev] [help needed] AG Xamarin multiplatform service module problem In-Reply-To: References: Message-ID: My first instinct is to use the service resolver to pick the right interface. For example in the fh-xamarin-sdk push APIs we have a interface IPush which is accessed as follows ``` ServiceFinder.Resolve().Register(HandleNotification); ``` ServiceFinder is responsible for determining which implementation is currently linked in the app. What this means is that when you build xamarin forms for iOS you depend on the iOS implementations in your build configuration and likewise for Android. This is probably easiest if you have an Android and iOS forms project which bootstrap the whole thing. Links IPush Shared code : https://github.com/feedhenry/fh-dotnet-sdk/tree/master/FHSDK/Services/Network https://github.com/feedhenry/fh-dotnet-sdk/blob/master/FHSDKPortable/Services/Network/Push.cs Android IPush impl : https://github.com/feedhenry/fh-dotnet-sdk/tree/master/FHXamarinAndroidSDK/Services/Network Ios push impl : https://github.com/feedhenry/fh-dotnet-sdk/tree/master/FHXamarinIOSSDK/Services/Network Example Xamarin apps : https://github.com/feedhenry-templates/pushstarter-xamarin-app I know these aren't forms apps and that creates a bit of a roadblock to your question, but I think Xamarin is meant to have a bunch of small platform specific projects with a few common ui projects. There are a few videos where MS talks about developing Xamarin apps that I can hunt down if people are interested. On Fri, Apr 20, 2018 at 8:59 AM, Vojtech Sazel wrote: > Hi, > > we encountered a problem with Aiden and Massimo with the underlying > architecture of the multiplatform project in Xamarin. > > We need to have Auth service module accessible from application. But > module has some platform specific implementations we need to get. > > 1) Suppose we have some class Auth implementing IServiceModule. We would > have it implemented only using platform-independent. So we can simply do > > MobileCore.Instance.GetInstance() > > 2) But now we need to have some platform specific stuff done in the > module, so we create AuthAndroid and AuthIOS extending Auth (which is now > abstract) in platform specific projects. > > In ordinary pure Android (or iOS respectively) app we can do: > > MobileCore.Instance.GetInstance() > > 3) But we can't do that with Xamarin.Forms app where stuff is in platform > independent project. > > We can utilize DependencyService in Xamarin.Forms app project or create > separate Xamarin.Forms project with Auth, but it seems that code won't be > very pretty in this case. > > What can we do to solve this problem? > I think we can debate it further after todays ST1 standup. > > -- > > VOJT?CH S?ZEL > > SENIOR SOFTWARE ENGINEER, RED HAT MOBILE > > Red Hat > > > > Remote Czech Republic > > vsazel at redhat.com IM: vsazel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180420/92381d77/attachment-0001.html From davmarti at redhat.com Mon Apr 23 05:21:49 2018 From: davmarti at redhat.com (David Martin) Date: Mon, 23 Apr 2018 10:21:49 +0100 Subject: [aerogear-dev] docs.aerogear.org In-Reply-To: References: Message-ID: Created https://github.com/aerogear/docs.aerogear.org On 20 April 2018 at 11:16, David Martin wrote: > > > On 19 April 2018 at 13:45, Paul Wright wrote: > >> Hi, >> >> We've discussed using github pages to host docs.aerogear.org html, but >> now I need a repo to store the html/etc for that site ( >> http://shiftgear.org is only a temporary solution). >> >> The plan is to use the process described in >> https://help.github.com/articles/about-supported-custom-doma >> ins/#custom-subdomains >> >> and therefore to create a repo named "docs.aerogear.org" in the aerogear >> github org. >> >> Any objections or better alternatives? >> > Sounds reasonable. > No objections. > I'll create this later today unless things change > > >> >> (I thought I'd get the subdomain set up first and then create the repo, >> but it has to happen the other way round, I need >> https://aerogear.github.io/docs.aerogear.org/ to work before the >> subdomain can be configured) >> >> -- >> Paul Wright >> Mobile Docs (github: finp) >> >> -- >> 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/ms >> gid/aerogear/b67095f2-3fa7-8868-4d6b-4157ca27a176%40redhat.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180423/9a3e8cb6/attachment.html From vsazel at redhat.com Mon Apr 23 07:56:21 2018 From: vsazel at redhat.com (Vojtech Sazel) Date: Mon, 23 Apr 2018 13:56:21 +0200 Subject: [aerogear-dev] docs.aerogear.org In-Reply-To: References: Message-ID: +1 Paul & David On Mon, Apr 23, 2018 at 11:21 AM, David Martin wrote: > Created https://github.com/aerogear/docs.aerogear.org > > On 20 April 2018 at 11:16, David Martin wrote: > >> >> >> On 19 April 2018 at 13:45, Paul Wright wrote: >> >>> Hi, >>> >>> We've discussed using github pages to host docs.aerogear.org html, but >>> now I need a repo to store the html/etc for that site ( >>> http://shiftgear.org is only a temporary solution). >>> >>> The plan is to use the process described in >>> https://help.github.com/articles/about-supported-custom-doma >>> ins/#custom-subdomains >>> >>> and therefore to create a repo named "docs.aerogear.org" in the >>> aerogear github org. >>> >>> Any objections or better alternatives? >>> >> Sounds reasonable. >> No objections. >> I'll create this later today unless things change >> >> >>> >>> (I thought I'd get the subdomain set up first and then create the repo, >>> but it has to happen the other way round, I need >>> https://aerogear.github.io/docs.aerogear.org/ to work before the >>> subdomain can be configured) >>> >>> -- >>> Paul Wright >>> Mobile Docs (github: finp) >>> >>> -- >>> 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/ms >>> gid/aerogear/b67095f2-3fa7-8868-4d6b-4157ca27a176%40redhat.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (#aerogear) >> > > > > -- > 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/CADvBQ45c45E0Xch50P2B1oMTMguXCUrFtHpmP02L4AqTYBqf7Q%40mail. > gmail.com > > . > > For more options, visit https://groups.google.com/d/optout. > -- VOJT?CH S?ZEL SENIOR SOFTWARE ENGINEER, RED HAT MOBILE Red Hat Remote Czech Republic vsazel at redhat.com IM: vsazel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180423/410f075e/attachment.html From mwessendorf at gmail.com Sat Apr 28 04:36:11 2018 From: mwessendorf at gmail.com (Matthias Wessendorf) Date: Sat, 28 Apr 2018 10:36:11 +0200 Subject: [aerogear-dev] =?utf-8?q?Buffalo_=E2=80=93_Rapid_Web_Development_?= =?utf-8?q?in_Go?= Message-ID: <717C6CB6-537B-4485-B09D-5532F8F01923@gmail.com> https://gobuffalo.io/en Sent from my iPhone