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

Lifting debug overrides to their own abstraction #5361

Merged
merged 5 commits into from Mar 2, 2022

Conversation

ouchadam
Copy link
Contributor

@ouchadam ouchadam commented Feb 25, 2022

Type of change

  • Feature
  • Bugfix
  • Technical
  • Other :

Content

Lifts the debug only options to their own VectorOverrides class, this class is explicitly for overriding behaviour for testing and is not meant to be user facing. The release build type will use the interface defaults, effectively the same as VectorFeatures.

Motivation and context

To avoid leaking debug only content within the VectorDataStore and provide a single point of reference for adding feature overrides for testing

Screenshots / GIFs

No UI changes

Tests

  • Open the debug menu -> private settings
  • enable force dial pad tab
  • see the dial pad tab in the home activity

Tested devices

  • Physical
  • Emulator
  • OS version(s): Sv2 (31)

@ouchadam ouchadam force-pushed the feature/adm/debug-overrides-abstraction branch from a40b808 to f6735b6 Compare February 25, 2022 13:07
@github-actions
Copy link

Matrix SDK

Integration Tests Results:

  • [org.matrix.android.sdk.session]
    passed=
  • [org.matrix.android.sdk.account]
    passed=
  • [org.matrix.android.sdk.internal]
    passed=
  • [org.matrix.android.sdk.ordering]
    passed=
  • [org.matrix.android.sdk.PermalinkParserTest]
    passed=

@github-actions
Copy link

github-actions bot commented Feb 25, 2022

Unit Test Results

  88 files  +4    88 suites  +4   1m 7s ⏱️ +11s
159 tests +2  159 ✔️ +2  0 💤 ±0  0 ±0 
512 runs  +8  512 ✔️ +8  0 💤 ±0  0 ±0 

Results for commit 350aceb. ± Comparison against base commit 2790506.

♻️ This comment has been updated with latest results.

Base automatically changed from feature/eric/registration-feature-flag to develop February 28, 2022 13:20
@ouchadam ouchadam marked this pull request as ready for review February 28, 2022 16:16
@Provides
fun providesDefaultVectorOverrides(): DefaultVectorOverrides {
return DefaultVectorOverrides()
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Optional: We can remove this entire companion inject if we add @Inject constructor on each of thse classes

It would be nice cleanup that falls well into the scope of this task, but consider it optional though, since I can see we already had this pattern in place

Copy link
Member

Choose a reason for hiding this comment

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

It's maybe because of @InstallIn(SingletonComponent::class) anotation of the interface FeaturesModule but I am not a big specialist of the DI.

Copy link
Contributor Author

@ouchadam ouchadam Mar 1, 2022

Choose a reason for hiding this comment

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

there's two parts to this

  • the default implementations avoid being directly injectable as we want to avoid leaking their implementations and ensure the consumption is only done via VectorFeatures
  • we have separate debug and feature DI modules, debug configurations need to know the implementation details in order to provide fallbacks

*Both debug and release need to provide the interface VectorFeatures

// Release only provides the down scoped interface 
@Provides
fun providesDefaultVectorFeatures(): VectorFeatures {
    return DefaultVectorFeatures()
}
// Debug 
// Defaults are provided but not accessible outside debug variant (could be inlined into providesDebugVectorFeatures
@Provides
fun providesDefaultVectorFeatures(): DefaultVectorFeatures {
    return DefaultVectorFeatures()
}

// debug features which make use of the of the default features
@Provides
fun providesDebugVectorFeatures(context: Context, defaultVectorFeatures: DefaultVectorFeatures): DebugVectorFeatures {
    return DebugVectorFeatures(context, defaultVectorFeatures)
}

// Provides the debug instance as the VectorFeatures for the rest of the app
@Binds
fun bindFeatures(debugFeatures: DebugVectorFeatures): VectorFeatures

hopefully that makes sense (and wasn't me rambling 😅 )

Copy link
Contributor

Choose a reason for hiding this comment

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

I see, this does shine some light on it, thanks!

Comment on lines 45 to 47
private val forceDialPadDisplayFlow: Flow<Boolean> = context.dataStore.data.map { preferences ->
preferences[forceDialPadDisplay].orFalse()
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there any reason we have these separate from the two override functions above? I think it would be much simpler to remove these vals and move their bodies to those functions

Copy link
Member

Choose a reason for hiding this comment

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

the 2 members of the interface could also be vals I think.

Copy link
Contributor Author

@ouchadam ouchadam Mar 1, 2022

Choose a reason for hiding this comment

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

will inline into vals 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated 7637ee4

Comment on lines +48 to +50
copy(
dialPadVisible = it
)
Copy link
Contributor

Choose a reason for hiding this comment

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

Not something to action as this is more of a personal preference thing but I never understood opting for this format rather than a single line copy(dialPadVisible = it). It just personally looks cleaner to me

Copy link
Member

Choose a reason for hiding this comment

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

Yes, when there is only one line it's OK. I think, it's for future hypothetical code to split into 3 lines, so if for instance in the future we have:

copy(
    dialPadVisible = it,
    other = blah
)

But this is definitely not a strong constraint.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't have any strong feelings for either, I chose to stick with the consistency of the file, happy to change!

@Provides
fun providesOverrides(): VectorOverrides {
return DefaultVectorOverrides()
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Same with the above DI comment. Unfortunately I can't run builds on my machine so I can't confirm this myself but it's worth taking a look imo

Copy link
Member

@bmarty bmarty left a comment

Choose a reason for hiding this comment

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

Thanks @ouchadam for the PR, look neat.
Thanks @ericdecanini for the review. I have nothing more to add.
I let you 2 manage this PR until merging on develop!

- also replaces funs with vals as the references are immutable
…vector-im/element-android into feature/adm/debug-overrides-abstraction
Copy link
Contributor

@ericdecanini ericdecanini left a comment

Choose a reason for hiding this comment

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

Thanks for making the changes! LGTM

@ouchadam ouchadam enabled auto-merge (squash) March 2, 2022 10:08
@ouchadam ouchadam disabled auto-merge March 2, 2022 10:08
@ouchadam ouchadam merged commit 0c62890 into develop Mar 2, 2022
@ouchadam ouchadam deleted the feature/adm/debug-overrides-abstraction branch March 2, 2022 10:08
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.

None yet

3 participants