This is awesome – thank you for noticing and bringing this up, Sebastian! I'm on board and I filed a meta. [1]
Since Sebastian is PTO for the week, I'll give a quick skim and see where the most actionable and high impact areas are and file a few bugs. You're all welcome to file bugs as well (especially you, when you get back Sebastian! :P). - Mike [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1202076 On Thu, Sep 3, 2015 at 10:46 AM, Nicholas Alexander <[email protected]> wrote: > 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 > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
