new module proposal: Android Background Services

[Mike Connor]

Since we relaunched Fennec on Android, we've been making increasing use of native background services and we expect to continue that trend. After discussion with the various people involved on Sync, Product Announcements, Software Update and Fennec itself, we've decided it makes sense to create a module to govern all of the code we run outside of the main application and ship with Firefox on Android.

We've nominated Richard Newman as the module owner for this new unified module. Richard has led the development of both Android Sync and Product Announcements, and is also a peer for the main Fennec module. As peers we're nominating Chris Peterson, Nick Alexander, Chenxia Liu, James Willcox, who all made significant contributions to existing background service code, and are de facto reviewers already. I believe this will be very strongly owned module given the people involved.

Name: Android Background Services
Description: Native Android services bundled with Fennec
Module owner: Richard Newman
Peers: Chris Peterson, Nick Alexander, Chenxia Liu, James Willcox
Source Dirs: https://github.com/mozilla-services/android-sync
Bugzilla Component(s): Android Background Services (pending)
URL: https://wiki.mozilla.org/Mobile/Android/Services (pending)
Discussion Group: mozilla.dev.platforms.mobile

Please post followup questions/comments to .governance.

-- Mike

[David Ascher]

This is a nit, but the name and/or placement in the module tree could (should?) specify that this is a submodule of the Firefox-on-android product? I can imagine a future where we have other things on android which have background services, and I would expect if such a future were to occur we'd have a reasonable discussion about whether the same codebase should be used or not.

--da

[Mike Connor]

My belief is that this is not a submodule for Fennec. Much of this is standalone Java code that isn't inherently app specific, and could be used to support multiple/different applications. To me, the closest equivalent for this module would be Toolkit, which is generally where this type of code lives for desktop apps.

That said, I don't think it's necessary to pre-constrain scope here. If we get to a future where it doesn't make sense to depend on this module for a new app, I would expect that we'd have a discussion about the best path forward regardless of how the lines are drawn on paper.

-- Mike

[Mitchell Baker]

I'd loved to see a bit of discussion from the folks involved in the idea
of having of all of these services in one module. It might be the
right thing but i'd love to hear the pros and cons.



mitchell

[holy...@gmail.com]

On Monday, March 11, 2013 10:30:19 AM UTC-7, Mitchell Baker wrote:
> I'd loved to see a bit of discussion from the folks involved in the idea
> of having of all of these services in one module. It might be the
> right thing but i'd love to hear the pros and cons.

Most of the services we've deployed so far, and plan to deploy in the future, do the same kinds of things -- make background HTTP requests, handle certain kinds of failures, schedule timers, preprocess some UI XML during build, etc.

There's a lot of benefit (and not a lot of cost) to developing these services in one place. From a practical standpoint, of course there's code sharing and runtime work sharing, as well as big wins in testability, continuous integration, Android compat, documentation, and development environment setup. Nick in particular has spent a huge amount of time over the next nine months fleshing out a toolchain and docs for getting new contributors up and running building Android code, which is no mean feat.

At a higher level, I think it makes a lot of sense to have a shared pool of knowledge for how to solve the kind of problems we're addressing in doing background work on Android.

To me, those are the two defining characteristics of a dev module: shared code and shared knowledge.

And to a point, what we're doing here is putting a name on what we've already been doing for months -- and that's already working well -- and trying to make sure that it continues to grow in a stable fashion.


The downsides I see:

* Inertia/gravity to continue accretion past the point that it makes sense. Arguably the same thing is true of toolkit to an even greater extent. I'm not too worried about this; Firefox for Android has a much bigger gravity well, and I think we've got a well-delineated scope.

* Growing repo size. We've already addressed this for the Bagheera client for FHR on Android through sensible internal partitioning, and of course our existing m-c codebase is monolithic and abysmal in this regard, so we have a very long way to go before this is a problem.

> My belief is that this is not a submodule for Fennec. Much of this is standalone Java code that isn't inherently app specific, and could be used to support multiple/different applications. To me, the closest equivalent for this module would be Toolkit, which is generally where this type of code lives for desktop apps.

Indeed, the Android Services module can be built, deployed, and largely tested without Firefox being installed on the device; that's been true since its inception in October 2011.

I'm not sure whether I'd pick Toolkit or NSS as an analogy, but I think you get the idea.

[holy...@gmail.com]

On Monday, March 11, 2013 10:30:19 AM UTC-7, Mitchell Baker wrote:

> I'd loved to see a bit of discussion from the folks involved in the idea
> of having of all of these services in one module. It might be the
> right thing but i'd love to hear the pros and cons.

Most of the services we've deployed so far, and plan to deploy in the future, do the same kinds of things -- make background HTTP requests, handle certain kinds of failures, schedule timers, preprocess some UI XML during build, etc.

There's a lot of benefit (and not a lot of cost) to developing these services in one place. From a practical standpoint, of course there's code sharing and runtime work sharing, as well as big wins in testability, continuous integration, Android compat, documentation, and development environment setup. Nick in particular has spent a huge amount of time over the next nine months fleshing out a toolchain and docs for getting new contributors up and running building Android code, which is no mean feat.

At a higher level, I think it makes a lot of sense to have a shared pool of knowledge for how to solve the kind of problems we're addressing in doing background work on Android.

To me, those are the two defining characteristics of a dev module: shared code and shared knowledge.

And to a point, what we're doing here is putting a name on what we've already been doing for months -- and that's already working well -- and trying to make sure that it continues to grow in a stable fashion.


The downsides I see:

* Inertia/gravity to continue accretion past the point that it makes sense. Arguably the same thing is true of toolkit to an even greater extent. I'm not too worried about this; Firefox for Android has a much bigger gravity well, and I think we've got a well-delineated scope.

* Growing repo size. We've already addressed this for the Bagheera client for FHR on Android through sensible internal partitioning, and of course our existing m-c codebase is monolithic and abysmal in this regard, so we have a very long way to go before this is a problem.

> My belief is that this is not a submodule for Fennec. Much of this is standalone Java code that isn't inherently app specific, and could be used to support multiple/different applications. To me, the closest equivalent for this module would be Toolkit, which is generally where this type of code lives for desktop apps.

[rne...@mozilla.com]

Done: https://wiki.mozilla.org/Modules/Other#Android_Background_Services

[rne...@mozilla.com]

Done: https://wiki.mozilla.org/Modules/Other#Android_Background_Services