The change to the function makes it so when the Settings.kt class is initialized, the isDefaultBrowser, which calls the
BrowserCache, won't get called right away. `isDefaultBrowser()` is known to take quite a while on start up on the G5+ (approx
30-40ms).
* For #16900: implement async navgraph inflation
For #16900: removed nav graph from xml
For #16900: inflate navGraph programatically
For #16900: Made NavGraph inflation asynchronous
For #16900: Changed to block with runBlocking
For #16900: Refactored blocking call into a function
For 16900: NavGraph inflation is now async
We now attach the nav graph (or check if its attached) on every nav call ( an extension function for NavController).
This is done by checking the value of the job stored in PerfNavController.map which keeps track of the job with the NavController as a Key.
If the job hasn't been completed, it will block the main thread until the job is done. The job itself is responsible for attaching the navgraph
to the navcontroller (and the inflation of the latter too)
For 16900: rebased upstream master
For 16900: Rebase on master
For #16900: Fixed Async Navgraph navigation per review comments.
1)The Asynchronous method is now found in NavGraphProvider.kt. It creates a job on the IO dispatcher
2)The Job is tracked through a WeakHashMap from Controller --> NavGraph
3)The Coroutine scope doesn't use MainScope() anymore
4)The Coroutine is cancelled if the Activity is destroyed
5)The tests mockk the blockForNavGraphInflation method through the FenixReoboelectricTestApplication instead of calling the mock every setup()
For #16900: inflateNavGraphAsync now takes navController
For #16900: Pass lifecycleScope to NavGraphProvider
For #16900: removed unused mock
For #16900: Added linter rules for navigate calls
We need linting rules to make sure no one calls the NavController.navigate() methods
For #16900: Added TestRule to help abstract the mocks in the code
For 16900: Fix linting problems
For #16900: Cleaned duplicated code in tests
For #16900: cleaned up NavGraphTestRule for finished test
For #16900: had to revert an accidentally edited file
For #16900: rebased master
* For #16900: Review nits for async navgraph
This is composed of squash commits, the original messages can be found below:
-> DisableNavGraphProviderAssertionRule + kdoc.
Use test rule in RobolectricApplication.
Fix failing CrashReporterControllerTest
Fix blame by -> navigate in tests.
This commit was generated by the following commands only:
```
find app/src/test -type f -exec sed -i '' "/import org.mozilla.fenix.ext.navigateBlockingForAsyncNavGraph/d" {} \;
find app/src/test -type f -exec sed -i "" "s/navigateBlockingForAsyncNavGraph/navigate/g" {} \;
git checkout app/src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker
```
Fix various blame
This is expected to be squashed into the first commit so, if so, it'd
fix the blame.
Move test rule to helpers pkg.
add missing license header
Add import change I missed
fix unused imports
Replace robolectricTestrunner with test rule.
Improve navGraphProvider docs
Remove unnecessary rule as defined by robolectric.
add clarifying comment to robolectric
remove unnecessary space
* For #16900: nit fixes for MozillaNavigateCheck and lint fixes
3 squash commits:
*Changed violation message and fixed the lint rule for MozillaNavigateCheck
*Added suppression to NavController.kt
*Fixed detekt violations
* For 16900: Fixed failing tests
Co-authored-by: Michael Comella <michael.l.comella@gmail.com>
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.
Hopefully this will help us understand behavior of the
`application_on_create` probe, specifically that it seems to take longer
in telemetry than in does locally compared to `home_activity_on_create`
(comparing the medians to local runs)..
Gabriel Luong
Michael Comella
Arturo Mejia
czlucius
Mugurell
Rohan Maity
codrut.topliceanu
Grisha Kruglov
Sebastian Kaspari
Roger Yang
Marc Leclair
Christian Sadilek
Jonathan Almeida
Mihai Adrian Carare
mcarare
Vitaly V. Pinchuk