search

aerogear / proposals

AeroGear Proposals
Apache License 2.0
0 stars 17 forks source link

Proposal for mobile SDK top level overview #6

Closed wtrocki closed 6 years ago

wtrocki commented 6 years ago

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

wtrocki commented 6 years ago

@secondsun Let's bring https://github.com/aerogear/proposals/pull/2 changes here for full overview.

secondsun commented 6 years ago

@wtrocki On it.

wei-lee commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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?

wtrocki commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Thank you so much for valuable comments.

Tasks

wtrocki commented 6 years ago

Separate proposal was created. Closing.

wtrocki commented 6 years ago

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