| commit | 688a021a66a564f38bd16567d508708bc003968f | |
| author | Michael Comella <michael.l.comella@gmail.com> | |
| Thu, 8 Apr 2021 00:16:31 +0000 (7 17:16 -0700) | ||
| committer | Michael Comella <759372+mcomella@users.noreply.github.com> | |
| Tue, 13 Apr 2021 22:10:36 +0000 (13 15:10 -0700) | ||
| tree | fd8f64875fdcad8694c641a42384366c5bff22f5 | treesnapshot (tar.gz zip) |
| parent | a3902842499c423ef99dcbf4123aec989098c466 | commitdiff |
[fenix] For https://github.com/mozilla-mobile/fenix/issues/18836: replace StartupActivityStateProvider with StartupStateProvider.
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.
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.