I am in the middle of developing an android application and I have stumbled across something that I don't really know the best way to solve.
What I wwant to achieve is, when a user logs into the application, I want to start a thread if the device is connected to a network(what kind of network doesn't matter)
The thread should perform an action every 10 minutes.
What this thread needs to do is, loop trough a list, a queue to be more exact.
This queue will have objects, and based on the objects in the queue when there is a connection available, execute.
The queue will be filled trough the flow of the application.
For example filling in a questionary.
The answers need to be synched to the server. Every question can include pictures takebn from the camera etc, so I want to save certain data as an object, put them in a queue, and have a thread handle the http requests. This way the UI won't be blocked. It's of great importance to sync whenever possible.
What I want to avoid is having another process run aside from my own APP. That's why I haven't used a service. Or do I missunderstand the concept of services as a whole?
Are there specific queue objects or lists?
I want to loop trough the queue list that can be filled at anytime while the program is alive, with a thread.sleep like method when the list is completely empty.
Please leave me hints and tips on what way to go with this.
A service isn't it's own process... from the Documentation: "A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of."
A service really is the best choice for what you're talking about. You spawn your own thread in the service that then does the following: check your queue for objects and send any to the server (since you're already not on the UI thread, you can do this without spawning yet another thread if you want). If the queue is empty, use a Timer to schedule another invocation of your upload method.
Related
I have a server running on some where and an Android application for end user. From Android application user can delete message, and this delete message will trigger sending a delete request to server through REST and server will delete it.
Does anyone know how the gmail's delete message works? Even if I quit from app or move away from app the send, delete or other operations completes eventually. Are they using AsyncTask or Thread or Service. I guess its not AsyncTask since user can move away from current view or can move away from whole application.
any suggestion is appreciated.
You may want to look at IntentService.
http://developer.android.com/training/run-background-service/create-service.html
"The IntentService class provides a straightforward structure for running an operation on a single background thread. This allows it to handle long-running operations without affecting your user interface's responsiveness. Also, an IntentService isn't affected by most user interface lifecycle events, so it continues to run in circumstances that would shut down an AsyncTask"
I'm not sure how Gmail's REST API works, but for REST calls, AsyncTask is definitely not the way to go. Why reinvent the wheel? Take a look at Volley or RetroFit. They are both REST libraries that take into account a lot of pitfalls one encounters in implementing REST calls in Android.
I'm using an IntentService to perform background tasks, such as updating data from a remote server.
In some cases, the same request can be queued multiple times by the user, but I only want to execute it once (there's no point in updating the data from the server twice in a row).
Is there a simple way to do this using an IntentService, or should I just use a standard Service?
Is there a simple way to do this using an IntentService
Unfortunately, no. The Handler queue used by the IntentService is not visible through the SDK and does not have public methods to let you inspect its contents, anyway.
should I just use a standard Service?
Probably. You could try to keep your own parallel copy of the work queue, flagging duplicates and ignoring them in your onHandleIntent(), but making sure you are always in sync with the real internal queue might get icky.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
I need a good way to get data from a thread to another activity.
I have one gaol: how to develop an Android app that plots bluetooth data forever in real-time.
I inherited a background thread which updates the screen with new data it receives over a bluetooth connection. When I launch my Plot activity I can see a bluetooth background thread continue to write bluetooth data to Logcat forever and ever. So I know for a fact the bluetooth background thread is still running when I launch my Plot activity.
I have succeeded as follows: since this bluetooth background thread seems to run fovever, I decided to use its update() method to call my static Plot.plotData() method to plot the bluetooth data. And this works. It will will run endlessly with out a problem - receiving bluetooth data and plotting it via periodic calls from the bluetooth background method update() to my static Plot.plotData() method.
The latest feedback I have received "It sounds like you're looking for an in-memory way to share data, and that's simply not the way the Android activity model works." In-memory???But this is rediculous. An Android phone has a limited amount of RAM for running Activities (one at a time), threads, handlers, Services, AnycTasks, etc. And an SD card for persisting data.
One critical person basically said: "In order to share data from a bluetooth background thread to my Plot activity (Plot.plotData()) that I must use the SD card." ??? This just sounds nuts, because I have it working using my static method Plot.plotData().
Frankly I don't see anything wrong with my solution primarily because those who criticize it do not follow up with a definitive alternative.
If you find my solution deficient please speak up and provide a definitive solution." Unless I use a new thread, handler, Service, AsyncTask, etc, everyone assumes my solution is not a good one. Why? Supposing the criticism is valid, PRECIOUSLY What should I do instead of what I am currently doing?
One more time: if you have background task running you should create Service. That's how Android expects applications to behave. Otherwise your thread may be terminated at any time (assuming none of the Activities are active).
From documentation:
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes
This precisely describes your case.
Also carefully read Processes and Threads, specifically Process Lifecycle section.
Basically your application falls into Background Process or Empty Process group most of the time. That's why you need Service started in your application.
I'm designing an android app which will need to do the following steps:
user pushes a button or otherwise indicates to "sync data".
sync process will use REST web services to move data to and from the server.
the data will be stored locally in a sqlite database.
the sync process should provide status updates/messages to the UI
the user should not be allowed to wander off to other parts of the application and do more work during the sync process.
The first time the sync process runs, it may take 10-20 minutes.
After the initial sync, less data will be transferred and stored and
I expect the process to take 1-2 minutes or less.
I've been doing a lot of reading about android's AsyncTask and various examples of using a Service ... But I don't fully understand the design considerations and trade-offs of choosing one design over the other. I currently have my demo project stubbed out using an AsyncTask. After watching (most of) Developing Android REST client applications: http://code.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html# I'm left confused the design patterns described here feel overly
complex, perhaps because I just "don't get it" yet.
I come from a java, spring, web and desktop application background. Thinking and designing in terms of a handheld device is quite new to me. (What happens when the screen layout is changed? What happens when the phone rings while I'm running a sync?) Taking 2 steps back, if the initial sync IS going to be such a long running process, is there a better way for me to think about the problem->solution, the user experience, the user expectations of an application running on a phone?
Would love to hear from some more experienced android developers out there who have already wrestled with these questions.
In my opinion this is the most tricky/hard part of a mainstream/average Android development. For instance on BlackBerry this is IN TIMES easier.
Definitely you need to use a Service.
AsyncTask does not suit, because it is tightly "bound" to your Activity via a Context handle (otherwise you would not be able to update UI of the Activity from your AsyncTask). However an Activity can be killed by OS once the Activity went in background. An example reason of going to background can be an incoming call - user switches to Phone application so your Activity becomes invisible. In this case (depending on the current RAM state) OS may decide to kill one of the background (invisible to the user) activities.
Some devs workaround this by arranging a static stuff for having a long-running actions inside of. Some recommend to use Application instance. This is because static stuff and Application exist while the whole app process exists. However those are incorrect workarounds. Processes in Android are also may be killed when OS decides it is time to. Android OS have its own considerations about what it can kill and in what order. All processes are devided to 5 levels of "killability". Here is the doc where those levels are specified. It is interesting to read there:
Because a process running a service is
ranked higher than one with background
activities, an activity that initiates
a long-running operation might do well
to start a service for that operation,
rather than simply spawn a thread —
particularly if the operation will
likely outlast the activity. Examples
of this are playing music in the
background and uploading a picture
taken by the camera to a web site.
Using a service guarantees that the
operation will have at least "service
process" priority, regardless of what
happens to the activity.
Your Activity where users initiate a long-running action should show a ProgressDialog to make sure user does not do anything else while the action is running. The guide is here.
Also, you'd most likely want to use the NotificationManager for notifying the user about your long-running action completion (or failure) if your Activity is currently invisible. Here is the NotificationManager info to start from.
There are multiple considerations that you must weigh in order to best decide how to approach your situation. It sounds like you need a good comparison between the two approaches... So here is a list of similarities, and differences and additional considerations that must be taken into account when working on a handheld device.
A Service is a part of your Application that has no UI. It may be called by a UI(Activity) to be started, or may be started by any other component of your Application. When developing, you have the freedom to place it on a different thread, or even run it in a different Task or Process. This allows you to ultimately separate it from your UI. Additionally, you may start the Service to run independently (startService) or bind your activity to it (bindService) depending upon your needs. By using custom Handlers, you can set callbacks to update the UI with your progress. A Service does not necessarily end if a User changes Activities, but may be ended at ANY time by the OS.
A AsyncTask is always instantiated from the UI thread. It only allows specific callbacks, but simplifies the process of multi-threading for the purposes of relatively short transactions (as compared to dedicated separate threaded services) that are inherently tied to actions performed by an Activity. Whenever a User changes Activities, the AsyncTask is put on "pause" and may even die because there is no UI thread for your Activity any longer.
The thing that I would be most concerned about is if the app is going to take 10-20 minutes the first time, I would ASSUME that the User will either change tasks temporarily or set the phone down until it completes (which can cause all of the same complications if the phone sleeps). Given this consideration, a threaded service bound to your activity may be your best choice. To protect your UI, I would make a Progress Dialog for your Activity that receives your progress callbacks. This limits user input in YOUR app and allows your service to continue the way that it needs to. Then override the Activity onResume to check the status of your Service and if it is running. Then you can reset the Dialog immediately.
Given that this is my preferred method, I would also take into account that the OS may kill the App at any time anyway. So make sure to have some way to detect an incomplete or partial sync. Then you may resume automatically when your Activity or Service restarts.
With AsyncTask if the user goes to another Activity you can't transfer that object to the other Activity so it dies. There are tricks you can play when say the user rotates the screen or something like that, but that doesn't extend to general purpose destruction. AsyncTask can randomly die.
Google Sync is run as a Service in the background because syncing can take a while to complete. You might need to follow their path and create your own sync service that you can communicate with. Here is some thoughts how to accomplish that:
http://mylifewithandroid.blogspot.com/2008/01/about-binders.html
You can definitely communicate between Service and Activity, but it's tricky to do it right.
The choice is mainly dependent on the app design. Since both AsyncTask and IntentService stands their ground, what you may want from the app(user experience) is more important and then choose either or both. Some scenarios are mentioned below (mostly what I experienced while developing apps)
Assume apps that have feeds pages - where more than one api calls are made to make the page presentable ( /getFriends, /getDates, /getPictures etc.) you can warp all such api calls to a single AsyncTask with executor which is multithreaded and the sequence of execution doesn't matter. In contrast to IntentService which runs all calls in sequence in a single worker thread. For a high end device with multi-core the call from AsyncTask is more effective. And if you start the AsyncTask on UI thread then updating IU is a piece of cakes(read less boiler plate code). And even if an user leaves the page, with intelligent use of not holding on to the context the app doesn't crash.
Assuming you are trying to write an app which doesn't need the user to be on view/activity/fragment and the total execution time to show something is not mission critical (assume sync service or user notification/alarm) then IntentService is a better choice. (no hassle to start Asynctask on UI thread so that you don't need to write a Handler to force changes on UI etc. etc. and less boiler plate code)
From my experience - write small app for both and compare the pros and cons to get a better idea. (p.s I'd suggest take a look at the iosched app from google to get a better idea - they use both Asynctask and IntentService)
I tend to prefer the IntentService + BroadcastReceiver combo because they give you a really strong degree of control
You definitely have to make sure the UI is running if you are updating something on the screen. ASyncTask crashes were at once reported to be one of the top causes of Android crashes. This can be avoided by keeping some sort of "activityIsAlive" variable and skipping or delaying a UI update if the activity is dead.
The IntentService + BroadcastReceiver combo is a little more resistant to the crash because most tutorials tell you to shut off the BroadcastReceiver onPause or onStop. If you do not do this, again you'll have to turn off the UI update. There's a runOnUiThread command somewhere that will help you do UI updates.
The IntentService + BroadcastReceiver combo is also more extensible. You can create functions and extend BroadcastReceiver to make a more elegant REST processing solution. However, it does require more plumbing vs an ASyncTask
If you do delay the UI update, you may be able to rig it on OnWindowFocusChangedListener. When that function receives true, it means that the UI is alive.
tldr; Make sure the Activity and/or Fragment is alive before updating the UI if you are running something in the background
2015 Edit: check out Loaders as well. A little harder to grasp because there's a lot going on behind the scenes
Here's scenario:
Client makes remote call to the service (returns void) and provides
a callback object
Service executes some long running logic on the background thread
and then uses callback object to trigger ether success or failure
which (since these manipulate visual elements) execute in
Activity#runOnUiThread block
The scenario runs fine. The question is - can I use AsyncTask to make
code less verbose (how?) and would be there any advantages in doing it
that way?
Or should I just get away from client callbacks alltogether and
execute remote service calls retrofitted to return some value within
AsyncTask#doInBackground?
It is difficult to say whether AsyncTask will make things less verbose, since we don't know the verbosity of your current implementation.
For me, AsyncTask means I don't have to worry about cleaning up threads myself (e.g., post some sort of kill job to a LinkedBlockingQueue my background thread is waiting on). It also eliminates the custom Job classes I used to create for using with LinkedBlockingQueues. And, it simplifies a bit doing final work back on the UI thread.
In your case, with a remote service, the UI thread issue is less critical, since the activity needs to handle that itself.
I don't see what the difference is between your #2 and your last paragraph. In both cases, your service will call the callback object, which will use something like runOnUiThread() to arrange for the work to be done on the UI thread.
AFAIK, the only two ways to have a service doing any sort of asynchronous work let the client know that work is done is by a broadcast Intent or a callback object. Broadcast Intents are convenient but public (i.e., other code can watch for them).
I suspect I probably have not helped much here, but I just don't know enough of your scenario to provide greater detail.
I'm having quite the same question : i'm developping a map activity, with a 'lazy-loading' functionnality (xml from Network, parsing it, then updating my map with the 'items' created from that parsing...)
i wondered what would be 'the best' way to implement it...
async service launched from a thread, an update notification via Intent?
just a thread (no service, since i don't need to expose it to other applications) w/ callback
asyncTask with callback
i'm comparingthese in terms of speed, using the Android SDK performance analysis Tool traceview
I guess a more precise answer might be found from Android contributors on the Android-developper-group...