Hi Sebastian, On Thu, Sep 3, 2015 at 2:11 AM, Sebastian Kaspari <[email protected]> wrote:
> Hey everyone, > > I remember when I joined Mozilla Michael asked me what's different working > here compared to working at other Android "companies". Back then my answer > was: The build system! Because this was so obviously different and maybe a > bit painful at the beginning. Since the build system gets better almost > every day (Thank you nalexander!) my answer today would be: The big effort > we are making to ship multiple variations of our UI to the different > Android versions. > I don't have direct expertise in maintaining these UI variations, but I would like to pile on that this type of unification is a Good Thing, and I'm happy Sebastian has raised it. > Two examples of what I mean: > > 1) The overflow menu. In Firefox: On most modern devices it's in the top > right corner. On Gingerbread it's a simple, old Android menu triggered by > pressing a hardware menu button. Then there are some devices with Android > 4+ and a menu button. These devices get a menu that shows up from the > bottom of the screen but has more features like the overflow menu. And I > wouldn't be surprised if there are even more variations. :) Touching this > code is not always easy. Writing UI tests can be frustrating because you > have to handle all these variations (even though we do a good job hiding > this behind components). > > 2) Themes: We have a default theme that derives from Android's default > theme (Back then this could be anything, including funky variations shipped > by the device manufacturers), a v11+ theme that inherits from the Holo > theme, a v14+ style that overrides some styles and a v21+ theme that > inherits from the Material theme. In addition to that we define styles in > default, v11, v13, v16 and v19. Some styles are inherited from previous > versions and some are overridden. I recently tried to change the v21 theme > and I couldn't follow all style paths because of the complexity. > > On the one hand, I'm impressed that we have been able to maintain this and > are shipping a Look & Feel that matches the one of the particular platform > very closely, but on the other hand, I don't know of any other popular app > that does that. Instead they ship the same (modern, now: Material) UI to > all devices with the help of the support library and appcompat library (And > nowadays the Android design support library too). > > Some examples: > * The Toolbar API allows us to have the same ActionBar behavior > independently of the Android version we are running on (vs. maintaining > different menus) > * The appcompat library comes with a theme that resembles the Material > theme on all Android versions (as good as it can). This allows us to use > and adapt just one theme. > * We are maintaining some custom components that we could replace with > feature richer and more tested support components, e.g our > TabMenuStripLayout > > But of course there are some downsides: > * We already include the support library and the appcompat library (at > least for builds with MOZ_NATIVE_DEVICES set) but not the design library > (bug 1189306). We don't need it yet but it will grow the APK size. Even > though proguard might be able to reduce this a bit. > The AAR is 200k, of which almost all of that is classes.jar. It's worth investigating the impact of Proguard further, but using this design library sounds like a great idea. The more custom code we replace with upstream code, the easier it is for new engineers to come to the code base. > * Shipping the same thing to all devices with the help of support > components removes the advantage of possible APK size reductions by > splitting APKs by version. > In some ways, yes. In others, no. We do need to be aggressive about guarding features across APK splits. > Okay, this mail got longer than I thought. I wanted to write it for some > time to hear your opinions but now that I saw a new bug about inheriting > styles from AppCompat (bug 1201206) I wanted to get it out. :) > Thanks for this email. I hope that mcomella, mhaigh, and others with more informed opinions will weigh in here to set public direction. Nick
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
