Provide design for new solution to improve core plugin configuration

[dzuluaga]

Hello Nelson, I hope you're doing well! I just wanted to follow up on our March 23rd call with you and Anton. During the call, we talked about some ways to improve the core plugin to make it more configurable, particularly in regards to defining the gms and non-gms implementations for each service. I was wondering if you had a chance to put together the design for the new solution that we agreed upon? Please let me know if you have any questions or concerns. Thank you so much for your help!

cc - @Anwera64 @nelsonwilches

[nelsonfertica]

Hello Diego, we are reviewing with the team, design and technical details of how implement your suggestions, to at the end use the gradle plugin like the following:

omhConfig {
    bundle("gms") {
        addService(
            storageGms { version = 1.0.1 }
        )
        addService(
            authNonGms { version = 1.0.1 }
        )
        addService("com.my-wrapper.example.maps:1.0.0-SNAPSHOT")
    }
    bundle("hms") {
        // ...
    }

    defaultBundle() {
        addService(
            storageGms { version = 1.0.1 }
        )
        addService(
            authNonGms { version = 1.0.1 }
        )
    }
}

[nelsonfertica]

Diego, one question, in case that i want to use only auth; if i have the following snippet:

omhConfig {
    bundle("gms") {
        addService(
            authGms { version = "0.0.1" }
        )
    }
    bundle("hms") {
        addService(
            authNonGms { version = "0.0.2" }
        )
    }

    defaultBundle() {
        addService(
            authNonGms { version = "0.0.2" }
        )
    }
}

In this case how should i define the version of auth-api itself?

A) Inside each bundle define, add the service:

addService(
    authApi { version = "0.0.1" }
)

B) Inside each bundle define, use authApi directly:

omhConfig {
    bundle("gms") {
        authApi { 
            version = "0.0.1" // <- Define it directly, without adding it as a service
        }
        addService(
            authGms { version = "0.0.1" }
        )
    }
}

? cc - @Anwera64 @nelsonwilches

[dzuluaga]

Thank you for your message. We need to clarify some questions about the purpose of the core plugin to ensure that we have a clear understanding of its functionality.

• How will the core plugin support a single build for both Google Mobile Services (GMS) and non-GMS? Specifically, how will it declare the GMS and non-GMS implementations?
• How will the core plugin support custom implementations or plugins? For example, if a developer wants to use the Overture maps implementation instead of the OMS implementation, how can they swap it in the build.gradle file?
• Can you please provide an end-to-end developer experience from declaring the dependencies to using the APIs in the app codebase?
• We are a bit confused about the bundle with and without the addService method. Can you please explain what you are trying to accomplish without using it?

In addition, we kindly request that you schedule a call with us to discuss these questions further. We believe that a discussion would help us to ensure that the core plugin meets the needs of our developers. Please ping me in Slack to schedule time.

[dzuluaga]

Hi Nelson,

Thanks for setting up the call. Here's a summary of our conversation regarding the above questions:

1. How will the core plugin support a single build for both Google Mobile Services (GMS) and non-GMS? Specifically, how will it declare the GMS and non-GMS implementations?

We discussed that the current omh core plugin can be simplified by using more generic functions like "addGmsService" and "addNonGmsService" instead of "authGms" and "authNonGms" and so and so forth. This will make the purpose of the API clearer and enable us to declare both existing and 3rd party implementations. Also, the omh core needs handle the single build GMS and non-GMS requirement discussed on March 6th.

2. How will the core plugin support custom implementations or plugins? For example, if a developer wants to use the Overture maps implementation instead of the OMS implementation, how can they swap it in the build.gradle file?

We concluded that passing the coordinates in the standard build.gradle format will allow the core plugin to use OMH 3rd party implementations/plugins.

3. Can you please provide an end-to-end developer experience from declaring the dependencies to using the APIs in the app codebase?

We are still pending on discussing how to use the auth/map/storage SDK independently of the GMS or non-GMS implementation. We will discuss this in our next meeting.

4. The OMH APIs should be usable with and without the OMH core plugin. So, developers should be able to create build variants along with OMH dependencies and be able to try the GMS and non-GMS implementations and be able to build a single build along with them. I’ll create a separate ticket to capture this requirement.

Let me know if you have any further questions or concerns. And please go ahead a book time next week to discuss with the team. Thanks!

cc - @rquino @prestonlau @teban1288