Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: modernization use case example (DRAFT-DO NOT MERGE) #367

Draft
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

markvdouw
Copy link

Instructions

  1. PR target branch should be against development
  2. PR title name should follow this format: https://github.com/mParticle/mparticle-workflows/blob/main/.github/workflows/pr-title-check.yml
  3. PR branch prefix should follow this format: https://github.com/mParticle/mparticle-workflows/blob/main/.github/workflows/pr-branch-check-name.yml

Summary

  • Creating a use case code to outline the discussed architecture and show a real use case and interaction between layers.
    This is obviously a WIP and is intendeed just to show high level interaction between the architecture components.

Testing Plan

  • Was this tested locally? If not, explain why.
  • {explain how this has been tested, and what, if any, additional testing should be done}

Reference Issue (For mParticle employees only. Ignore if you are an outside contributor)

Copy link
Member

@rmi22186 rmi22186 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed. Looks good overall and looking forward to getting started on this project!

Copy link
Collaborator

@einsteinx2 einsteinx2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple comments and a question. Overall looks good though, I'll get a better feel for it once I port it to Swift.

@@ -0,0 +1,6 @@
package com.mparticle.modernization

class MpApiClientImpl {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have an ApiClient interface which this extends right?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, just wanted to outline the idea of the data source itself. We might even have the ApiClient itself without interface if we don't intend to have multiple implementations of it (foe example multiple http clients as tools to resolve the implementation). In the future we could always create the abstraction and change this into an Impl.

@@ -0,0 +1,13 @@
package com.mparticle.modernization
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on latest discussions, we should use the term "nextgen" instead of "modernization"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

@@ -0,0 +1,13 @@
package com.mparticle.modernization

class BatchManager(private val api : MpApiClientImpl) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as other comment, this should take an ApiClient interface of which MpApiClientImpl extends right?

import com.mparticle.modernization.kit.MParticleKitManager
import com.mparticle.modernization.datahandler.MParticleDataHandler

internal class MParticle private constructor(private val options: MParticleOptions) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly does private val do in this constructor parameter? Is it syntax sugar for creating a private instance property called options and assigning it this value?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This enables to use the dependency injection pattern, making the property accesible to be used in the class but restrict visibility from consumers. If options would have been public, MParticle.getInstance().options would have been valid.. Moreover by default properties have public setters/getters so, someone from the outside could eventually temper with the properties within MParticleOptions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants