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
TL;DR what Firebase does is uses a Content Provide (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 and is called *before*
all other Android kinds of stuff in the Android lifecycle (including
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
with the recent work on the mobile initiative around Openshift, more and
more repositories in AeroGear land are containing GOLANG code.
Our own Dara Hayes is willing to give a little intro and reflect some
experiences from his recent work on this repo:
Abstract: In this short talk demonstrates a very simple and developer
friendly workflow for releasing containerized services written in Go. It
also cover some lessons the team learned, when starting to build their
first Golang service, and provides some helpful tips and tricks for keeping
developers happy as they work with Go.
Time: Thursday. 29th of March, 2pm (GMT)
Looking forward seeing you all there (yes, the video is going to be
1. I got our RH video ccs guy to review and he's got some good news and
> Not overly long, good audio/video quality, descriptive voiceover which
> is easy to follow along with. Only a few minor things:
> * Describing cutting the video until the process finishes usually
> isn't necessary, it's something you can visualize with a
> transition/cut/sped up footage, and having the narrator say
> something along the lines of "This process may take a few minutes"
> usually suffices. This would probably save you 30 sec to a minute
> of time.
> * Title and ending slides are good bookends for the video. Instead
> of doing the intro VO on the catalog screen, which has a lot of
> visual noise and can be a little distracting, creating a clean,
> unified title slide with the title, name of the narrator, and
> their title is a good way to start and end the video, and is
> overall less distracting. The final slide can simply be a "Thank
> you" slide or a slide with the Keycloak logo on it.
> * If there are any KBase/documentation articles that relate to the
> video, putting them in the description is pretty useful for those
> who want more information.
> That's more or less what immediately stands out to me. Overall great job!
2. On the point about title slides, would it make sense to have a
running slide deck, on which each slide acts as a title for the
recording and is then updated to capture the url of the video after
Mobile Docs (github: finp)
Wei recommended me to start further discussion about viability of making
E2E tests for regression testing of our SDKs. There was some debate around
it, so I'm putting it also to the mailing list.
I have done Appium UI test
<https://github.com/aerogear/aerogear-sdk-e2e-tests/pull/1> of the example
app included in AG Android SDK 
<https://github.com/aerogear/aerogear-sdk-e2e-tests/pull/1>. It has been
done for Auth functionality. This test checks happy path of login and
Is it worth doing it this way? Is it worth doing it at least for some
My take TLDR:
+ it tests real end-user/developer usage of the SDK in the real device
In the middle:
= it requires running emulator or connected device to the test server
- test stability (it can go wrong because of load on the test server)
- test speed
- UI change volatility can break the test - this is partially avoided by
using page objects  <https://martinfowler.com/bliki/PageObject.html>
I think the real environment is clear benefit, for OpenID authentication,
it's difficult to do it other way than from UI and using real browser. I
don't know if this is true for other functionality. But writing tests at
least for happy paths can be beneficial.
SENIOR SOFTWARE ENGINEER, RED HAT MOBILE
Remote Czech Republic
vsazel(a)redhat.com IM: vsazel
shortly after AeroGear.org project was started, and different technologies
and scopes were added, we started to reflect that with multiple different
JIRA instances. For instance besides the canonical AEROGEAR instance we
have a bunch of them for iOS (AGIOS), Android (AGDROID), All things Push
(AGPUSH)* or Cordova (AGCORDOVA), to name only a few.
I am proposing to retire all instances and start using only the AEROGEAR
In Push, we had similar discussion, we had different instances for
simplepush, ups and webpush; For sanity we ended up running all things in
AGPUSH, and using components and better version strings (e.g.
simplepush-1.0.0 or ups-1.2.4). And this works great
So, I think it does make sense to stop hammering new issues into all the
different "technology silos", like AGDROID or AGPUSH. Instead I really
think we should unify one JIRA instance, with proper components and much
better version strings, allowing us to really use one instance for all of
Today, to me, it does look a bit that our multiple instances of JIRA can be
really done w/ one JIRA (and components/versions) instead - we don't really
have much more value w/ all the different instances.
I'd like to retire the new instances, in the near future, moving forward
with just one JIRA instance. At some point - later this year - we could
than try to delete the other redundant JIRA silos.
Before retiring the instances, we will review the existing backlogs and
port over valid tickets. So no *relevant* ticket will be lost, and outdated
tickets kinda gets cleaned up, doing this excercise :-)
Feedback, thoughts, tomatos ?