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.
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. * 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. 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. :) Best, Sebastian
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
