Okay, so I after playing around with the Android SDK a little I have decided to develop a full application. Not necessarily to release on the store (I don't really have the tools at my disposal to do proper QA and so wouldn't feel right; I could only test on my one personal device) it is mostly just a personal project for fun and learning. In the end, I decided on a camera application because I use my camera fairly often so it is the kind of application I would end up actually using if I made it and also because I am quite excited by the features of the new Camera2 API in Android L and want to give them a try.
Anyway, I have been thinking on the design/architecture of the application for a while and I have come across a potential problem that I cannot really resolve myself as I am not only not really familiar with GUI programming of this nature but also not 100% on Java and the Android SDK. They both sit well outside the purview of my dayjob.
Now I know enough that I really need to keep my UI thread separate from everything else, but what I am unsure about is first of all, what I should devote extra threads to (I was thinking one to handle image capture and storage, and another to handle the settings? perhaps that is over doing it) and also whether to have background threads which the UI thread communicates with through Events or simply to spawn threads as and when they are needed. Perhaps a single intermediate background thread which arbitrates between the UI thread and any background processing that needs to be done? What I mean to ask is, how do I decide these things? Are there general/best practices?
I'm really asking because I want to get this done properly and plan out the application thoroughly beforehand since in the past I have found that if I just dive right in I get confused very easily and end up losing faith and dropping the project. I hope somebody can help. It's not a question that I have found easy to phrase in such a way that Google would provide satisfactory results.
I think you might consider thinking about it this way:
The UI thread is where most stuff runs. It is also, occasionally, called the "main" thread, because it is, uhhh... the main thread.
Unless your program is wildly complex, you probably don't need to worry about an architecture for threads. All you need to worry about is getting slow stuff off the UI thread. That's it. You don't care where they go, just not the UI thread.
If you buy that, there are some nifty choices:
Intent Service: If, a bit metaphorically, the methods you need to run in "background" have void return types, an intent service is the perfect solution. You communicate with it using Intents and, since it has only one thread, tasks you submit to that thread are run in order.
AsyncTask: These are fraught with problems but people get a lot of programming done with them. They run in a pool of around 6 threads, but (surprise!) run in order anyway.
Your own Java Executor: Use this if you need behavior similar an AsyncTask, but with more control.
New thread per task: Just don't do this. Really.
In any of these cases, though, you don't really care on which threads your tasks are running. You make a policy about the number of threads that makes sense on the target device and then run your slow stuff on one of them.
...and "slow" should include all I/O: databases, file system, network, etc., as well as major computation.
You want to keep things as simple as possible. You don't need a thread to set settings, and you don't need an intermediary thread. These things are only going to create unnecessary complication. You only need to take long running operations off the UI thread.
Take a look at the structures the Android framework provides to make multi-threading easier first. This will help simplify your application. These would include IntentService and AsyncTask. If those won't meet your needs take a look at the java.util.concurrent package. Using a raw Thread is often not advisable.
Another library that could come in handy is an Event Bus like Otto. This will prevent memory leaks that can occur with using AsyncTask.
You dont need to worry about threads when it comes to image capture. When you want to take a picture you do so by opening the Camera App on the device. Here is a good way of doing that.
Android SDK provides Asynctask which does things for you in the background thread, like a network call and updates the UI once its done.
You can also use an IntentService, which runs even if you exit the app and does things like upload/download without the user having to worry about it. Loaders are useful when the underlying data often changes and you need to update UI quickly (searching contacts in autocomplete text for example).
http://www.vogella.com/tutorials/AndroidBackgroundProcessing/article.html
Refer to this tutorial, its a good start. Hope this helps.
Related
In Android land, Fragments are aware of the Android lifecycle and are not destroyed when an activity is recreated. Because of this, I have seen people using empty fragments to get around issues with the Android lifecycle destroying references to background tasks and prevent leaks associated with keeping references to activities.
I was wondering how much overhead is associated with using Fragments as hooks to background tasks? I assume that Android decides not to destroy fragments because they are expensive to recreate (could be wrong).
Bonus question. Is there a way we can measure this cost? (maybe implementing alternate methods and checking resource utilisation).
You should not use a 'headless fragment' for background work.
The correct way is to use a Loader or Service (or Intent Service) depending on the duration and type of work that needs to be done.
In terms of overhead, I don't think there is much. You can create 4 apps with these 4 methods and profile them if you want, but the better approach is to pick a method that works for the problem you are trying to solve.
Do not use Fragments to keep tasks alive!
That will do more harm than use.
If you have tasks running long enough that you have to worry if they get killed, run them in a Service.
This is exactly what a Service (or Loader) is for. Fragments should represent a part of your layout, not be used headless.
There is no reason to hack around if a working and intended solution exists.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am new to android and was going through the documentation and some tutorials.
Services
Developer guide says it should be used, when there is required to run a long running task in background, say music player.
Asynctask
Creates a worker thread to perform background task like getting data using api and then notify the UI thread on it's onPostExecute() callback method.
Loaders
Performs operations on separate thread, registers to the listener and notifies on data set changes.
Providers
Share data between different apps by exposing them in the manifest file.
SyncAdapter
For synchronizing data between android device and web server.
Theoretical wise, i understand the above concepts like what they are used for.
I am having difficulty to put them in order like when to use what? what would be the best among them to use? In what scenarios what should be used?
For caching, i used sqlite or library like volley and retrospice
As i said i am android beginner and try to understand these concepts.
Any helps and suggestions would be appreciated.
Thankx in advance.
A couple of things to add to Kaleb's answer:
ContentProvider:
Android has actually many ways to share data. The ContentProvider is a way to share a database between applications. Let's say you have 3 email clients on your phone that cache data from the cloud in case you're offline. It makes sense that you maintain only one offline database of your emails. The same goes if you have an address book, an sms database, or a tweet database. And the same goes if you want to update all that data. You only really want to update that data only once from the cloud, not three times each time, which brings me to the next topic, the SyncAdapter.
SyncAdapter:
A SyncManager is smart enough to do all the synchronization requests in one go, to minimize the time the antenna is powered, and therefore to save battery use. Furthermore, with the help of the AccountManager, the user of the phone can override the synchronization preferences himself/herself, but that's only if the developer chose to use a SyncAdapter in the first place.
Also, a SyncAdapter can only be used with a ContentProvider. So even if you don't want to share your data with other apps, you'll have to use a content provider if you want to use a SyncAdapter.
That being said, ContentProviders are very hard for beginners (even intermediate developers) to implement. I'd suggest you stay away from them for now. You should use a ContentProvider, if there is already one for what you want to do, but I don't recommend you try to create your own.
Loaders:
Loaders are good. Learn to use them if you want to display data from a local database (or from a ContentProvider). They'll save you time. Unlike the SyncAdapter, loaders do not require a ContentProvider for them to work. They can access SQLite directly.
Services:
Learn to use them. There are too many things to say about them. One important point is that you should minimize the time they stay alive by using components like AlarmManager or BroadcastReceivers. Also, you'll need to learn the difference between a Service and an IntentService.
AsyncTask:
AsyncTask is very often necessary in Android to avoid blocking the main UI thread. Don't think that because you're using an AsyncTask, that you can dispense with the use of Services.
Note that many Android tutorials only give you the minimum amount of code to demonstrate a concept, so they'll often skip proper threading. Note that you can start your own thread manually if you want, but AsyncTask does other things for you that make it the ideal choice for many situations where the UI thread gets blocked and you get an "Application Non Responding" error.
Libraries:
There are many good libraries out there. I won't say which ones are the good ones. Learn to use the ones that everyone recommends. Those libraries can do a lot for you (assuming you're good enough to make them work). There is a bit of a learning curve, but it's worth it. And they deal with Android at a much higher level of abstraction, so usually, the threading and many other things are usually taken care for you.
There are many other things that I am glossing over, or that I didn't mention at all, but like I said, I think your question is too broad. And if you really want more details, you should hunker down and read some the developer guides and watch some of the youtube videos provided by Google.
Really quick answer :
AsyncTask : short task that could block the UI thread. You don't mind if they are cancel and you have to re launch them.
Services : use when you have long task that you don't want to be interupted by App changes. Bit harded to implement than AsyncTask.
Loaders : designed for database access
SyncAdapter : here you don't have realtime data. You schedule data sync at a give moment (i.e sync mails, contact data, etc...). Let's say you have fresh data every hour.
Providers : nothing to do with the above. This is used to share data beetween Apps. You don't care how data is retrieve by the sharing App, you just know that you can ask for a given resource.
This infographis helped me understand better the first 3 : https://raw.githubusercontent.com/stephanenicolas/robospice/master/gfx/RoboSpice-InfoGraphics.png
I've been working on an app, and it's came long great. I have a problem though, Android, being greedy with its resources, loves to kill the app when I put it in the background. This is very bad, because the app is actually intended to be an AI assistant, and having to reinitialize every-time I need to use it means that it's not going to be very helpful in a real work environment.
I investigated ways to prevent reinitialization of the AI's brain, however, none of the methods have been very fruitful. Saving the instance of its brain will not work, because the POS models that she needs to operate can't be serialized. And employing a service won't work either, because if I want to communicate with the activity via the service, I have to reinitialize it along with the activity (correct me if there is a way around this, I just notice most tutorials put service.start() in the onCreate methods)
Is there a way around this? I only need to preserve the POS models. They take a while to load in for some reason despite only being a few megabytes.
Please note that this is to prevent data from being killed. There are no background processes that need to be ran.
You need to set a Notification to tell Android not to release your resources.
See this question: How can we prevent a Service from being killed by OS? . While the question itself is not directly applicable the answers have a lot of overlap with this issue.
You should probably be using a Service if you want to run things in the background though as Activities are only supposed to run when you have a layout in the foreground. You could store your required object in the service, grab it as necessary when (re)starting an Activity that requires it and update it when your Activity loses focus.
Edit: I accidentally pasted the wrong link. Now corrected.
Also, have a look at this Android resource if you have not already: http://developer.android.com/training/basics/activity-lifecycle/recreating.html
In the olden days developing windows applications I made use of an API call (LOCKWINDOWUPDATE(HWND)). It would lock updating of the screen while you do stuff so that if you don't want the user to see a complex series of UI changes you can prevent that from occurring. You'd lock the updating by passing in the handle to the window to stop updating, do your changes and then you'd unlock by passing (0) and boom, it's in the new state.
As I understand this is not the intended use of the call but I did it anyway (as did many others) because it was too useful in a lot of situations. Anyhoo, there have been many occasions with Android that I could have made use of such functionality and today I have a need for it again. Does anyone know of any equivalent APIs or techniques to accomplish this?
Again, I want to have the screen freeze at a current state make changes and then show it when it's in the new state. Any idea?
A very simple question:
I know that Android applications run in the background when they are closed. Is it possible for my application to keep working while it is in the background? For example, maintaining a timer in the application to automatically perform a function every hour?
Thanks!
Use services for doing tasks in background. more info is here http://developer.android.com/guide/topics/fundamentals/services.html.
An alarm service should meet your needs; here's an example.
To run things in the background (or outside of the main application thread) there are a few options. To do something very quick in the background the easiest way is to use an AsyncTask. It sounds like you are wanting to implement a bit more than an AsyncTask would handle though. For more longterm tasks that you want to run behind the scenes you probably want a Service.
You can have services that run, do what they are supposed to do and then exit, and you can have ones that keep running. Services have a lot of depth. You could use the AlarmService that is linked above by another user, however another approach would be to just make a simple service and use a TimerTask http://developer.android.com/reference/java/util/TimerTask.htm
Remember though, when you are doing things in the Service, they will be being done on the Main Thread, which could slow down other programs, so any logic over long periods of time needs to be accomplished in an AsyncTask.