> >> Integrate into Fennec > > One of the goals you mentioned this morning is to continue being able to ship > from your Git repo. >
My preferred approach is source-based. I could: 1) periodically manually commit code MozStumbler's github code to m-c, tagging in github as an m-c release, or 2) have a script in m-c that pulls from the MozStumbler github branch (or pull from github master for this, and make the dev trunk a branch) > >> no new permissions? > > Ideally. If new permissions are needed, we ordinarily coordinate with other > features that need permissions, which will affect schedule. There's a high > bar for adding permissions, because they dramatically affect user upgrades. > The permissions MozStumbler uses are in Fennec's build already. There is one that isn't, I am looking at pulling it out, don't think it is needed. >> we ask 1 question of the user in Android Notification screen, can we ask a >> 2nd question? > > Paging ibarlow/alam/yuan. We already show a Data Reporting notification, and > probably location stumbling shouldn't be on by default. Adding a second > notification is likely a step too far, so I'd suggest a call to action from a > snippet, or a non-first-run nudge. Provide both incentive and opportunity. On first run, there is a notification prompt to ask if the user wants to contribute to MLS > >> Sync code needs a peer-review > Feel free to flag me for r?. This is definitely my ballpark. > > Where's your bug component? If you don't have one yet, let's fix that. > Mostly items have been in Github. We should stick to Bugzilla for items that aren't related to the stand-alone stumbler. Been using the Geolocation component, having a Geolocation-Stumbling component would be nice. > >> run stumbler service as a separate process, Android *should* be less likely >> to kill it. > > Maybe. It might be more likely to kill it: better it kills the stumbler than > Fennec. And remember that having a third process is expensive, and makes it > more likely that anything will be killed at all! Best practice is to simply > not use extra processes unless you have some clear reason to do so (e.g., > loading NSS for the passwords provider). This is a good topic to decide on early on. The stumbling service process will have minimal memory+cpu usage, and on its own, would be very unlikely to marked for kill by the OS. Indeed, in my stand-alone testing, the OS seems to ignore it. If the stumbler service was not a separate process, the cases I was considering are: 1) Fennec has not been run yet, and the stumbling service starts, the resource usage is only the stumbler, this is ok, and 2) Fennec has been run, and now backgrounded. As a heavy resource using process, it will be likely killed, and the stumbler service along with it. This is problematic (potentially***). This is based on the presumption that Android looks at separate processes within an application as separate items for killing. They are not parent-child related, so I assumed that was the case. Assuming is bad, and the Android docs are not clear on this, but I am sure the facts are out there for me :). *** There is a 3rd point to made in this regard, which is, this all depends on what intents the stumbler service uses for startup. If it listens for sparse events to start (like the BOOT intent), then getting killed is problematic. If it listens for common events, then it will likely get restarted in a reasonable period of time. As an aside, is that when developing, I need only one intent in the manifest to start the stumbler service, which is gps status/fix change intent. The problem with this intent, is that it is undocumented, and likely is not reliable for production use. However, it is the perfect intent in all other respects. _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
