Proposal for mobile SDK top level overview

[wtrocki]

Proposal for top level mobile SDK architecture.
Moved from investigation document.
See source if you want to know reasons for proposing this architecture.

[secondsun]

/s/relay/rely

So one core question to this is do we want to expose Rx* APIs in our APIs? In general I am a "no" on that question. Rx can be a implementation detail however.

In Android a lot of the community uses RxJava and RxAndroid. If we include it as a dependency then we end up having to be very careful about dependency management. There are two ways that come to mind to handle this.

The first way is that we enforce some kind of default dependency version (Maven BOM) to avoid potential collisions. It is overrideable so savvy developers can include their own libraries instead of ours and test for breakages themselves. I think this should be the default.

The second way is we shade the Rx* namespaces. This way we don't have to expose ANY information about RxJava and users' are free to choose whichever version they want. This is a lot more complex however.

Can people chime in about other platforms? @danielpassos do you have thoughts on iOS?

[wtrocki]

So one core question to this is do we want to expose Rx* APIs in our APIs?

No. It will be internal.

This is really valuable comment. Maybe we should keep SDK's without many external libraries and avoid using user level libraries like rx?

The last thing we want is to have some poor user experience and dependency collisions on users projects. Those can happen for both Android and IOS.

Good summary of options for IOS: http://blog.sigmapoint.pl/avoiding-dependency-collisions-in-ios-static-library-managed-by-cocoapods/

[wtrocki]

I'm thinking to remove this restriction and do not mention RX for the moment, but the same problem may happen again with other dependencies.

[wei-lee]

+1 on removing this. It is the implementation details for each SDK, not a high level architecture design.

[wtrocki]

@secondsun Let's bring #2 changes here for full overview.

[secondsun]

@wtrocki On it.

[wei-lee]

personally I think these things should be covered separate proposals. Based on the things here, there should be at least one per platform. In the proposal, it should dive into the implementation details of some of the things here. I am not sure if all of these things have anything to do with the high level architecture of the SDKs.

[wei-lee]

any examples? how does this affect the high level architecture design?

[wei-lee]

@wtrocki Thanks for starting the discussion. I know this proposal is still work in progress, but want to give some early feedbacks.

1. It's great to understand why we want to use the modular architecture, but I think in a proposal, I would like to see a bit more on the "how". For the moment, I can't really find anything.
2. It feels like there are a lot things in this proposal, and I don't know what is the main problem/goal is for this proposal. If the main goal is to cover the high level architecture, I think it should stay focus on that, and dive deeper into the "how". Some of the stuff here like git hosting, docs, languages etc I am not sure how they are related to the main problem. In my opinion it's best to have them in separate proposals (looks like we need at least one per platform).

Maybe I misunderstood the goal of the proposal. If that is the case feel free to correct me.

[wtrocki]

@wei-lee Really good points. Thank you for review.

I would like to see a bit more on the "how"

I agree. I will add more details.

How will be done per platform as it will be in implementation details.
For example for android current aerogear libraries implement this idea and we should just have conversation if we can reuse some bits from this or build something new.

It feels like there are a lot things in this proposal

It is overview for SDK and it may be moved to separate proposals at any time.
This proposal should give people overview how SDK's will be done and help us to kickstart this efforts.

I personally wanted first to buy everyone into idea of having separate core sdk.
We working on details how this will look like in each platform.

Some of the stuff here like git hosting, docs, languages etc I am not sure how they are related to the main problem

This is to make sure that all platforms will have this elements covered.
This proposal it's mostly overview and the way to kickstart platform investigations.

I'm investigating IOS at the moment by checking how we can reuse current code. What work is required. @secondsun Is covering android. We going also to cover JS/Cordova/Web/ReactNative sdk by checking how current 5.0 libraries work and what is required later.

As content will grow we can move this to separate proposals. For example:
Distribution mechanism for Android SDK with some details about maven boms etc.
We are clearly not there yet and having multiple proposals can be messy.

TL;DR - Proposal lists common areas and key decisions for our SDK.
Platforms are totally different and we simply cannot provide details about architecture without platform context. We trying to reuse knowledge and code that aerogear team build over the years.

[wei-lee]

I'm investigating IOS at the moment by checking how we can reuse current code. What work is required. @secondsun Is covering android. We going also to cover JS/Cordova/Web/ReactNative sdk by checking how current 5.0 libraries work and what is required later.

I think this is another thing needs to discuss with the team. I am not sure if it's a good idea to try cover the design of ALL the platforms right from the beginning, given that we haven't implemented any one of them. Personally I would like to see both teams focus on 1 platform first - maybe JS, or Android. We can apply the architecture you have suggested during the implementation, and see how it works. Then based on that, at the end of that, we can decide what things we have done right, what we haven't, and try make sure we do not make the same mistake when implement the next one. Another benefit of this approach is to keep both team focus on 1 platform at a time, so that we can all review each other's work and not distracted by different platforms.

@david-martin @secondsun @maleck13 @matzew @johnfriz WDYT?

[maleck13]

I don't really understand this sentence can you elaborate

[wtrocki]

Yes. It's not clear. Going to correct that.

This refers to the services available on the backend - like security, sync etc.
Those can be used separately or in the bundle.

[maleck13]

Is this similar to how Angular 2 does things now? It sounds very similar

[wtrocki]

This aligns with how Google Firebase, Amazon AWS or many other companies split their SDK's now. Angular2 is also very similar, but it has much more modules, with core being lightweight and separate modules for http etc.. To avoid overhead we assume that networking logging etc. will be in core.

[maleck13]

Having top level SDK allows developers to provide fluent api (different forms of the top level api that can be swapped and extended)

Would be good to get some code samples or sudo code examples here to make it clearer

[wtrocki]

Another benefit of this approach is to keep both team focus on 1 platform at a time, so that we can all review each other's work and not distracted by different platforms.

IMHO That's very good idea. I was under impression that we should have all SDK's finished when service is ready and released to community. It will be better for us to deliver only one platform initially, but that will need wider agreement.

If we agree on this - starting on Android makes sense as we all are experienced in this platform.
Then we can gradually split work between IOS/JS.

[maleck13]

I think limiting it to investigation work is ok? Using a modular system similar to how angular approach dependencies seems solid as a principal however I think the boundaries on the modules needs to be clear. Also it is not completely clear to me whether there is a module per service and also many shared modules for logging, network etc?
It seems there is a quite a bit more work needed for this proposal to be complete (some sudo code examples of how these modules would come together) etc

[wtrocki]

Thank you so much for valuable comments.

Tasks

• Add more technical details on how modular architecture will work
• Focus on single platform initially (suggested Android - rename proposal)
• Cleanup proposal from non android related elements
• Investigate module boundaries (single core module vs multiple modules)
• Provide examples (possibly prototype)

[wtrocki]

Separate proposal was created. Closing.

[wtrocki]

Follow up POC will be done as part of https://issues.jboss.org/browse/AGDROID-678
PR will be reopen/updated after that.