* 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)..
* For #17805 - Fix adjustResize deprecation
To handle the deprecation of `adjustResize` I've moved it from `styles.xml` and `AndroidManifest.xml` to `Activity.kt` as a fallback for devices with Android < 11. For Android 11 and up `setDecorFitsSystemWindows(false)` and `OnApplyWindowInsetsListener` will be used to handle app insets. Normal use activities should call `enableSystemInsetsHandling` in `onCreate` as to properly display system bars and for proper keyboard handling.
The IntentReceiverActivity one is particularly useful to quickly determine
when we can begin executing code in the WARM VIEW case (i.e. "Set selection
begin here").
The HomeActivity one is useful for COLD start up analysis in similar
ways and to see the Activity transitions in WARM VIEW.
* For #16373: Added performance Inflater to counter # of inflations
This class is quite straight forward. The only thing that I have to point out is the onCreateView method. It usually
calls its super if you don't override it. The problem with that is that the super.onCreateView actually uses
android.view. as a prefix for the XML element it tries to inflate. So if we have an element that isn't part
of that package, it'll crash. As I said in the code, a good example is ImageButton. Calling android.view.ImageButton
will make the app crash. The method is implemented the same way that PhoneLayoutInflater does (Another example
is the AsyncLayoutInflater)
* For #16373: Added test for PerformanceInflater
This test got quite awkward / complicated fast. I wanted to test the to make sure we don't break *any* of our layouts
and to do so, I decided to just retrieve all our XML in our /res/layout folder. However, this gets quite a bit outside of a unit test scope.
The point was to get every layouts and get their LayoutID through the resources using the testContext we have. It gets even weirder, since some
of the XML tags have special implementation in android. One of them is the <fragment> tag. That tag actually is inflated by the OS using the Factory2
that the Activity.java implements. In order to get around the fragment issue, we just return a basic FrameLayout since the system LayoutInflater doesn't deal
won't ever get a <fragment> tag to inflate. Another issue was the <merge> tag. In order to inflate those, you need 1) a root view and 2) attach your view to it.
In order to be able to test those layouts file, I had to create an empty FrameLayout and use it as the root view for testing. Again, I know this is beyond the spirit of a unit test but if we use this inflater, I think it should make sure that no layouts are broken by it.
* For #16373: Overrode getSystemService to return PerformanceInflater
This allows PerformanceInflater to be called in every inflation to keep track of the number of inflations we do.
* For #16373: Added UI test for # of inflations
* For #16373: Lint fix
* For #167373: Changed the LayoutInflater cloneInContext to take this instead of inflater
The inflater parameter is set on the first call from the OS from the Window object. However, the activity itself sets multiple factories on the inflater
during its creation (usually through AppCompatDelegateImpl.java). This means that, once we initially set the inflater with a null check, we pass an inflater
that has no factory initially. However, since we keep a reference to it, when cloneInContext was called, it cloned the inflater with the original inflater
which didn't have any factories set up. This meant that the app would crash on either browserFragment creation or any thing that required appCompat (such as
ImageView and ImageButton). Now, passing itself with a cloneInContext means we keep all the factories initially set by the activity or the fragment.
* For #16373: Fixed code issues for PR. No behavior change
* For #16373: fixed some code nits
In a followup PR, we need to add state to strictModeManager (the
number of suppressions). This is much simpler to do when this is defined
as a class rather than an object. However, when this is defined as a
class, `resetAfter` needs access to the strictModeManager. Instead of
passing it in as an argument, it made sense to move this function onto
the strictModeManager instead.
Since folks are used to calling:
```
StrictMode.ThreadPolicy.allowThreadDiskReads().resetAfter
```
We're going to have to add a lint check to prevent them from doing that.
I originally tried to create this PR leaving this as an object to keep
the change simple but it wasn't worth it - once the object started to
keep state, we'd need to manually reset the state between runs. Also,
the tests were already getting hacky with static mocking so it was
easier to address some of those issues this way too.
* Remove search fragment
* Use new folder to search dialog
* Rebase and lint
* Update tests with search dialog nav directions
* Rename interactor to match naming convention. Remove old controller and point everything to the dialog controller.
Sebastian Kaspari
mcarare
Michael Comella
MarcLeclair
Mihai Adrian Carare
Vitaly V. Pinchuk
Arturo Mejia
Roger Yang
Codrut Topliceanu
ekager
Jonathan Almeida
Gabriel Luong
Christian Sadilek
sraturi
Grisha Kruglov
Elise Richards
ekager
Kainalu Hagiwara
Jeff Boek
Tiger Oakes