Put all batch options in a new service

[GoogleCodeExporter]

We should do all long running tasks in a Service.  They don't logically fit in 
the TrackRecordingService so we should create another service to run long 
running tasks.

What steps will reproduce the problem?
1. Start export all on a large db.
2. Leave app
3. The export is canceled.

The service should expose method for the following methods:
- Export/ExportAll
- DeleteAllTracks
- Backup/Restore
- Upload
- Import
-Options for notifying progress:
--Handler passed from the activity to the service (service keeps weak reference)
--Broadcast from service to activity

Original issue reported on code.google.com by sandordo...@google.com on 27 Nov 2010 at 6:56

[GoogleCodeExporter]

Issue 171 has been merged into this issue.

Original comment by rdama...@google.com on 27 Nov 2010 at 7:15

[GoogleCodeExporter]

Original comment by rdama...@google.com on 27 Nov 2010 at 7:16

• Changed state: Started
• Added labels: Stability, Targeting-1-1

[GoogleCodeExporter]

Rodrigo, I'm not sure if having a separate service is the right approach. There 
are alternatives way to achieve the same goal.

Keep in mind, that we want to track down the progress, which in case of a 
service, typically indicates introducing either a broadcast or some other means 
of watching the progress (e.g. content provider?).

Just to make it clear, I totally agree of moving the logic away from the 
current service (it simply doesn't belong there).

Original comment by ba...@google.com on 29 Nov 2010 at 12:41

[GoogleCodeExporter]

BTW, I started a similar bug before this one: 
http://code.google.com/p/mytracks/issues/detail?id=232.

I envisioned it by creating a Handler + HandlerThread (a lightweight of 
achieving the same goal).

Original comment by ba...@google.com on 29 Nov 2010 at 12:42

[GoogleCodeExporter]

The logic in the current service, it's in the activity.
A Handler doesn't solve the problem which is the activity being restarted 
(which would make the handler be killed anyway).

Don't worry, I have this fixed in my head, I just need to clear the other 
changes that you guys are reviewing first so I can merge it.

Original comment by rdama...@google.com on 29 Nov 2010 at 2:15

[GoogleCodeExporter]

I meant to say "The logic is NOT in the current service"

Original comment by rdama...@google.com on 29 Nov 2010 at 2:15

[GoogleCodeExporter]

Sure, I trust you.  The only concern I have is the service is more expensive 
than a thread, so consider it as a drawback for older devices.  Also, the code 
is more complex.

I prefer a simple solution if it addresses the problem.  No need to jump a gun, 
unless really needed, IMHO.

Original comment by ba...@google.com on 29 Nov 2010 at 2:45

[GoogleCodeExporter]

So, I guess the question is whether we want something that will keep going even 
if the user closes the activity (e.g. because the export was for a very large 
track which is taking very long and the phone went to sleep). The same is not 
guaranteed for a thread.

Also, many applications use lightweight services like this - e.g. the Android 
Market uses one for downloading apps.

Anyway, the first stage of the refactoring is to isolate all batch operations 
behind a dedicated activity (which only knows how to show progress). After 
that, moving that to a service or not is a separate change.

Original comment by rdama...@google.com on 29 Nov 2010 at 7:22

[GoogleCodeExporter]

Have you considered using 
http://developer.android.com/reference/android/app/IntentService.html ?

Original comment by ba...@google.com on 29 Nov 2010 at 7:27

[GoogleCodeExporter]

And BTW, http://developer.android.com/reference/android/os/AsyncTask.html 
should be useful for our UI operations we have... still learning Android :)

Original comment by ba...@google.com on 29 Nov 2010 at 7:30

[GoogleCodeExporter]

Very interesting indeed, I never used IntentService or AsyncTask, but they 
sound like a good match.

Original comment by rdama...@google.com on 29 Nov 2010 at 9:16

[GoogleCodeExporter]

Issue 232 has been merged into this issue.

Original comment by sandordo...@google.com on 29 Nov 2010 at 4:33

[GoogleCodeExporter]

Original comment by sandordo...@google.com on 6 Jan 2011 at 11:55

• Added labels: Targeting-1-2, Work-Large
• Removed labels: Targeting-1-1

[GoogleCodeExporter]

I'll have to redo this after all the recent changes, keeping as accepted for 
now.

Original comment by rdama...@google.com on 25 Feb 2011 at 4:08

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by rdama...@google.com on 30 Apr 2011 at 5:57

• Added labels: Component-Persistence

[GoogleCodeExporter]

The code is now using AyncsTask for supporting background tasks and progress 
bar.

Original comment by jshih@google.com on 20 Jun 2012 at 5:47

• Changed state: Fixed