Alpha app should expire after fixed amount of time #1298
Assignees
Labels
Priority: Essential
This work item must be completed for its milestone.
Z-ibt
Temporary label for Ben to keep track of issues he's triaged.
Milestone
Comments
BenHenning
added
Type: Improvement
Priority: Essential
BenHenning
added a commit
that referenced
this issue
Aug 17, 2020
* First phase of introducing automatic app expiration after a fixed amount of time (as controlled by a manifest-defined constant) This approach is based off of the existing onboarding flow, except it refactors that to be a bit more general. Rather than it focusing on whether the user has completed the onboarding experience, it focuses on what the user's app opening experience should be: onboarding, profile chooser, or app expiration dialog. * Post-merge fixes & update AppStartupStateControllerTest to work with the new expiration date check. * Add additional flag for turning auto expiration on/off rather than just using the date value. * Add tests for AppStartupStateControllerTest, and prepare for stabilizing SplashActivityTest. * Post-merge fixes. * Introduce test coroutine dispatchers support in Espresso. This piggybacks off of the solution introduced in #1276 for Robolectric. That PR allows Robolectric tests in app module to share dependencies with production components by creating a test application & telling Robolectric to use it instead of OppiaApplication via a @config annotation. This PR achieves the same thing by using a custom test runner that reads the same annotation and forces Espresso & instrumentation to use the test application instead of the default OppiaApplication. This setup will be easier once #59 is finished since we can specify the application in per-test manifests that both Robolectric & Espresso will respect. Note that while this lets the same test coroutine dispatchers work in both production & test code for Espresso, some additional work was needed to ensure the coroutines behave correctly. In particular, the coroutines use a fake system clock in Robolectric that requires explicit synchronization points in the tests to allow the clock to move forward & properly coordinate execution between background & main thread operations. However, in Espresso, since everything is using a real clock an idling resource is the preferred way to synchronize execution: it allows the background coroutines to operate in real-time much like they would in production, and then notify Espresso when completed. The test dispatchers API is now setup to support both synchronization mechanisms for both Robolectric & Espresso (the idling resource does nothing on Robolectric and the force synchronization effectively does nothing on Espresso). The first test being demonstrated as now stable is SplashActivityTest (as part of downstream work in #1397. * Revert "Fixes #941: Add radar effect in Hints and solution (#1475)" This reverts commit 41eb10b. * Add thorough documentation for new dispatchers. * Clean up comments & add additional documentation. * Fix lint errors. * Fix broken test after changes to FakeSystemClock. * Add splash tests to CI. * Add tests for new SplashActivity behavior. Includes adding an abstraction for metadata checking. Also, clean up the new dialog fragment by moving hardcoded strings to strings.xml & add missing documentation. * Fix broken AppStartupStateControllerTest. * Lint fixes. * Fix one missed conflict. * Post-merge fix.
BenHenning
added
the
Z-ibt
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since the alpha version of the app is a pre-release, we should "bake in" an automatic expiration timer. I think 3 months should be more than sufficient. Users who use a version of the alpha app for more than three months will be prevented from continuing using it until they upgrade via the Play Store.
The production version of the app will not contain this limitation, and will have a more controlled upgrade policy built into it.
The text was updated successfully, but these errors were encountered: