On 2014-06-13, 9:12 AM, Garvan Keeley wrote:
Currently, the stumbler code uses a sync adapter. The problem with this is that
it creates a sync account in the Android settings. We don't want this.
Ideally, I wouldn't have to rewrite this chunk of MozStumbler, since it is a
working component and, well, I'd just rather not because there other tasks todo.
We can't piggy back on Firefox account sync as that may not be set up by the
user.
I am thinking I have no choice but to rewrite this component.
Of the list of features sync provides, we don't need any of them. An async task
to periodically upload the data would do the same thing, and remove the need
for external XML resources.
The list of features the sync framework provides is:
- plug-in architecture
--> don't need
- Automated execution based on a variety of criteria, and queued transfers.
Automated network checking
--> Checking if the network is on is trivial, and we have no elaborate
execution criteria. If the service sees an upload hasn't happened in a few days,
then when it detects network availability, do an https post with our data.
- Improved battery performance
--> this is designed for multi-way (pull and push), complex, synchronization
apps. We just make a post request every few days. Don't need this.
Account management and authentication
--> We just use an API key on the upload url. Don't need this.
Opinions/advice?
I agree that you don't need a SyncAdapter for your use case. It's a
pity that SyncAdapters are tied to Account types, because the
SyncAdapter life-cycle is actually good for your situation, but we
definitely can't add an Account type for stumbling, so it's moot. We
have a background uploader service for the Firefox Health Report data,
and this can be similar. (I wouldn't suggest trying to unify these two,
given the separate code bases.)
Nick
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
