Thanks David. Really good question. 

I ignored mobile implementation in demo as most of the work for this was done on server side.

I'm using different more extended use cases to drive SDK work.

For mobile application there were couple manual steps:

1) Generate mobile configuration using mobile-client (not mobile specific)

2) Drop configuration including URL into application (not mobile specific)

3) Extract URL from configuration.

4) Use AFNetworking framework (IOS) to make network request.

I did not implemented that on Android platform, but flow should be the same. 
After obtaining URL/configuration to service users can make any API calls.

The only complexity will come with authentication - for example when using keycloak, but that will require additional effort.

IMHO At this point it's better to rely on sync service for initial SDK service as it has non trivial client implementation (business logic etc.)
It's also clear that Sync will be used with some modified form. 

For SDK investigations we are focused on extending step 3 and 4 into core of our library.

Once that is done we can simply integrate two most important SDK's: Sync and Push.

Main goals are:

- Investigate/implement android core library that will create map of services from provided json/plist file. 

- Integrate existing SDK sync and push

- Try to extract network into core (using aerogear-android-pipe from push server)

In the mean time we are working on SDK proposal and top level API (using annotations)

BOM style dependency management that will improve user experience and reduce versioning hell on Android platform.

After doing that we can drive this forward and run sync behind keycloak which should show us how we can provide authentication.

We may also extend mobile-cli to provide more service specific information that is needed. 

I think that clearly summarizing entire SDK initiative at this moment. 

On Wed, Jan 10, 2018 at 12:37 PM, David Martin <davmarti@redhat.com> wrote:

Very nice Wojciech.

I'd love to see/hear more about how it works from the Mobile App, if that piece is working.

Did you populate stats using the App, or by just curling an endpoint? (Maybe you said and I missed that)

On 10 January 2018 at 12:22, Wojciech Trocki <wtrocki@redhat.com> wrote:

Forwarding to internal list as AeroGear list seems to be having problems with mail delivery.

---------- Forwarded message ----------
From: Wojciech Trocki <wtrocki@redhat.com>
Date: Tue, Jan 9, 2018 at 7:55 PM
Subject: Mobile Statistics using Grafana, Prometheus running on OpenShift
To: AeroGear Developer Mailing List <aerogear-dev@lists.jboss.org>

Hi everyone

I have been working today on investigation for enabling mobile application statistics on top of OpenShift.

The main target was to enable mobile clients (using our SDK) to send statistics payload to server.

For this purpose we were sending back mobile.next() SDK version from different mobile clients and visualizing that data Grafana.

Demo: 

https://www.youtube.com/watch?v=zC95jJr1kcc

Where is the value? 

Grafana, can be used to showcase various statistics that mobile developers will need without extended development effort.

How we can extend this:

- Investigate different ways to store data in Prometheus (using labels etc.)

- Integrate with Keycloak to showcase SDK capabilities and permissions.

- Golang implementation for service

Regards

--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki

--

David Martin

Red Hat Mobile

Twitter: @irldavem

IRC: @irldavem (#aerogear)

--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki