My vision for building mobile/android

The big goal

The big goal is to enable our main front-end developers, the ones who work with the Java UI source and resources, to live in the IDE of their choice (provided their choice is IntelliJ or Eclipse). To live within the IDE means: to edit source and resources, compile the Java sources, build the Android APK, deploy it to device, and debug it live; all within the IDE. A related goal is to make it easier for new contributors — those with Java and Android experience, but no prior contact with Mozilla — to pitch in with Fennec front-end development. Federico Paolinelli (fedepaol on IRC) has a great blog post about his experience as a new contributor, which everybody should read. While I think lowering the bar to entry is extremely important, I claim that right now we need to focus on driving improvements for our core development team.

Test suites

Some sub-goals I have relate to doing similar things with smaller pieces of mobile/android. A few of these have to do with test suites:

I recently landed a test suite (building, but not yet running on TBPL) called background that is built on the JUnit 3 instrumentation testing framework. This is a natural candidate for its own IDE project: this suite is developed in the android-sync git repository as a separate project! Configuring an IDE project for this suite should be straight forward. This suite is a testing ground for sibling suite, to be called browser, that will test non-UI front-end code (think things like databases, parsing responses from the update server, and uploading telemetry). Using the lessons from the background suite, we should be able to ramp up the browser suite quickly. The pay-off here is getting non-UI tests into a faster to execute and (hopefully!) more reliable testing framework on TBPL, which should reduce intermittent orange pain for the sherrifs and reduce load on releng infrastructure. This project needs love to get it running on TBPL, but making this suite work in the IDE is ripe for contribution right now.

We have a test suite called robocop that is built on the Robotium framework for driving front-end UI tests. Robocop is notoriously difficult to even run locally, and updating it is Kafka-esque ordeal. We would dearly love to create a robocop IDE project to let our developers modify and run individual tests in that suite from within the IDE. There are some technical barriers thrown up by the build system and there are some process hurdles: the test suite needs an ambient HTTP server and a test profile configured to talk to that server; but in theory we can drive this process from within the IDE. One idea I have not had a chance to explore: can we implement a custom Android TestRunner to stand up and teardown the ambient HTTP server? This test runner would only be used by these IDE projects. Making this happen will take a little longer than getting background and browser into the IDE.

Splitting mobile/android/base

Some aspirations I have around pieces of the mobile/android tree:

I would like to build the third-party libraries Sync relies on, and third-party libraries that future Fennec might rely on, as an independent IDE project. This code evolves much more slowly than mobile/android/base and we should not be paying the compilation and especially dexing costs during normal development.

I would like to deprecate the android-sync repository. It has served a valuable purpose and been incredibly useful — I don’t think Android Sync would exist without it — but if we could develop mobile/android/services as a separate IDE project, with the test suite at mobile/android/tests/background/junit3 as another IDE project, perhaps we can avoid paying the git-to-hg overhead. (Of course, we’d lose the github integration — but that’s a separate issue.)

Finally, a pie-in-the-sky goal:

I would like to support an "app tier only" build. That is, a new developer would download the latest Fennec Nightly build from TBPL, clone mozilla-central, run mach bootstrap mobile/android, and be able to develop the front-end code without building libxul.so and the other C++ libraries. Mike Hommey (glandium on IRC) has ideas for how to make this reality, but this is truly future vision.

Conclusion

This is an exciting time for Fennec front-end developers. We’re on the cusp of unleashing better tooling and better testing. In future posts, I’ll dig into some of the technical details of how we’re going to get over the hump.

I’d like to recognize the great work that Brian Nicholson (bnicholson on IRC) has done in service of these goals, but the list of supporters is too long to recite (not least, the build system peers who review!).

Feedback is always appreciated: discussion is best conducted on the mobile-firefox-dev mailing list and I’m nalexander on IRC.