File upload in background: thread/service/AIDL...?

by Mark Murphy » Tue, 02 Mar 2010 01:31:53 GMT


Sponsored Links
 


In which case, do the following:

Step #1: Implement your Service as a subclass of IntentService.
IntentService handles the whole background thread thing for you, so you
will not need an AsyncTask.

Step #2: Put your file-upload logic in onHandleIntent() in your
IntentService subclass.

Step #3: When you have something to upload, create an Intent that
identifies the service (e.g., new Intent(this, MyService.class);) and
put a string extra on it (via putExtra()) that contains the thing to upload.

Step #4: Call startService() with the Intent from Step #3.

Step #5: In onHandleIntent(), you are passed the Intent, so you can call
getStringExtra() to get the value and use it.

Step #6: There is no step #6. Your service will automatically shut down
when there is nothing more to upload, and it will be restarted
automatically if another upload is required.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com  |  http://twitter.com/commonsguy 

_Android Programming Tutorials_ Version 2.0 Available!

--



Other Threads

1. onClickListener for tabs in TabActivity

Hi

I have a tab activity with 4 tabs. How do I set a onClickListener for
the tabs?

The onTabChangeListener only works if I click on the inactive tabs. I
would like a callback even if I click the current/active tab.

Any suggestions?

BR
Martin

-- 

2. comments on the 'Integrating Application with Intents" blog

I would like to make a few comments on the 'Integrating Application
with Intents ' blog posted on the developers.android side.
Specifically, as to the definition of the reserve action and the data
specifications.

Neither of these specifications are generic and exhibit a very narrow
view of the reservation concept. The restaurant reservation concept
should be abstracted as it will have a multitude future
implementations in terms of activities and services by other vendors.

Action specification presented by the OpenView,
"com.opentable.action.RESERVE", incorporates 'opentable' in its
namespace. Such common actions, as it is with the restaurant
reservation action, should avoid any proprietary names and strive to
define a standard action specification that can be used by other
activity implementations of the reservation functionality.  The
generic approach to these specifications should be a driving force for
all of us. An example of a generic action specification could be;
ACTION SPECIFICATION: "action.RESERV", CATEGORY SPECIFICATION;
''service.food.restaurant".

Data specification; as defined by the OpenTable, also violates basic
URI format specification;  "reserve://opentable.com/2947?partySize=3".
The first element of the URI specification should be a protocol
specification, 'reserve' is an  action name and not a protocol name.
The action should be defined in the argument part of the data
specification. The domain name should also be a generic name since we
do not want to target a specific implementer of the reservation
activity. For example; a  rel="nofollow" href="http://android.com/size=3">http://android.com/size=3?
datetime=09-11-2009T12:30.  In cases when we do intend to invoke
activities implemented by a specific party we should be using a
CATEGORY SPECIFICATION; "manufacture.software.company.name.OPENTABLE"
or such.

This message is not intended as a criticism of the proposed
specifications. It is a way to point out a generic nature of
abstractions implemented by many activities and the necessity of using
generic action, category and data specifications.

-- 

3. Passing a Hashtable in Intent Extras..

4. Toggle state button

5. SDK 2.0 vs SDK 1.6

6. ngemis invite google wave T_T

7. Listening to Beacons