000bef020a
The StartupActivityStateProvider uses an imperative implementation, driven by callbacks, to set the state of the application. This is hard to follow as you need to understand which callbacks will be called in which order. For example, to make sense of an implementation like this, COLD, WARM, AND HOT would likely need to be implemented in separate ActivityLifecycleCallbacks. I feel the StartupStateProvider is an improvement because it leverages the StartupActivityLog to query a linear state for a more understandable implementation. Furthermore, it seems accessible to write COLD, WARM, and HOT in the same class because they can all be approached the same way. |
||
|---|---|---|
| .. | ||
| sampledata | ||
| src | ||
| .gitignore | ||
| build.gradle | ||
| lint-baseline.xml | ||
| lint.xml | ||
| metrics.yaml | ||
| pings.yaml | ||
| proguard-android-optimize-3.5.0-modified.txt | ||
| proguard-rules.pro | ||