* 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
I'm not convinced this is a useful test because the performance
characteristics seem unfortunately nuanced: if the test fails, it implies
you shouldn't add more but that isn't necessarily true (for example, if
your RV child has a large depth). Furthermore, we haven't measured in a
variety of circumstances that layouts like LinearLayout perform better
as RecyclerView children so maybe it only held for the one small case we
used it in.
STATE_HALF_EXPANDED cannot be disabled while also keeping fitToContents = true
based on which the tabs tray layout is currently set.
To work around this we'll set a a minuscule height for the tab tray when in
this state and then immediately advance to STATE_HIDDEN so to make it
imperceptible to the users.
Since I couldn't write unit tests because of InflateExceptions in Robolectric
I've written UI tests to protect against regressions.
Adam Novak
Oana Horvath
ekager
AndiAJ
isabelrios
MarcLeclair
Christian Sadilek
Sebastian Kaspari
jhugman
Michael Comella
Mugurell