We Keep Coding

confused between syncAdapter,services,loaders,providers and asynctask? [closed]

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

Ideas for my app that runs in the background

I'm developing an app that runs in the background that essentially snaps a front facing photo every time the phone is successfully/unsuccessfully unlocked. This isn't an original idea, but I'm developing it as a final project for my college android programming course, with no intent to sell this app. I have a general idea how I am going to go about this via some research but I keep running across a problem.
I know that it is hard and bad practice to run an app continuously in the background, so the idea is you put the app to sleep and set an alarm. My problem is that if the would be phone-snooper were to get really lucky, they could access the phone in between the alarms, and the owner of the phone would never know. I talked with my professor, and he proposed a couple ideas, but we could not come up with a definite solution, so I'm asking opinions here. Any idea how to subvert this dilemma? Thanks a ton.

Your approach is probably not appropriate for the problem. You can't "time" unpredictable events (like someone attempting to unlock a phone). Or else it's not clear how you are setting the alarm.
You should change the approach to an event-based approach.
Either provide a service for a lock-screen app so that it can use your code to capture a pic by sending login attempt events to it. You write that and provide an SDK/API.
Or else create your own lock screen app with your feature:
https://stackoverflow.com/questions/10864300/create-a-lock-screen-of-my-own

How to detect volume buttons when screen is off in energy-saving way

I would make an application that handle the volume buttons when screen is off. The goal would be to turn on or off the front LED.
I know that there many topics here that talk about it, but the recommended solutions (like PARTIAL_WAKE_LOCK) seem to be energy intensive and drain the battery very quickly!
What I want is a solution that is as energy efficient as possible. Is this possible? Maybe some kind of hooking?
Please note that the solutions based on scheduled tasks can not be envisaged for this project because I want detect keys in real time (or close to it)!

Take a look at this question.. if you already haven't ..
Just to make one thing clear. If something is not documented in API docs of android then any hack or workaround you find won't be reliable as Google may decide to change things in future releases, for example there is nothing documented about creating shortcuts after the app is installed ! But Since Android source code is available, developers took that piece of code as how was playstore creating shortcuts.. but its not documented so Google may change it in future !

Battery Drain Issue

I am using many threads in my app that are always running.These are used to send data to server periodically.There are called through services.The problem is that my app drains a lot of battery.I want to fix this.How??
I mean gmail etc dont drains that much of batterry.

Applications like Gmail are not requesting the server at frequent intervals, you may have to check the architecture of your solution, there are other mechanisms to do this you need:
http://developer.android.com/reference/android/os/AsyncTask.html
http://developer.android.com/guide/components/services.html

I would advice you to check Googles Android Training on minimizing the battery usage and focus on ways effectively access the network and send files there.
There is also a nice video presentation from Google's IO event that touches the topic (at around 1/3 of the video). It presents some code an is perhaps more easy to understand but less deep than the previously mentioned documentation

Best option for storing data in running application in android [before SQLite]

I'm new to the android development, and programming in general.
I'm developing app to create football statistics for each player, and in the long run I'm using SQLite to store data. However I was wondering if there is a way and if it will make sense, to store data during the run of my application without inserting it to the db, every time user is trying to add new statistics.
Also I'm wondering if there is a point in doing that, my biggest concern is that inserting data to a db all the time will slow down my app, and I would appreciate what more experienced developers do know, and think about this 'issue'
I was trying to research the topic, however all I got was storing data in db, and using SharedPreferences and I don't think that's what I'm looking for, however I can be wrong.
please help.

SQlite is what you're looking for. SharedPreferences are for just that - preferences, not large amounts of stats.
Put your database code in a separate thread and you won't notice any slow down in your app. Ask back here for help on this.

I can't speak to android directly but I have faced similar design issues on iPhone and desktop applications.
It depends on the specifics of the application as to what would be the best way. If your app is mostly about entering plays and saving statistics, I would keep a small set of the latest statistics in memory enough to populate the user interface and then create a "data manager" running on a background thread whose sole purpose was to insert these newly added statistics to the database.

Honestly, I would put it in the DB immediately. With the way android works, if your user navigates to another app (or possibly even receives a phone call) the data they have already entered could be lost.
It is possible to cover that contingency obviously (saving in onPause, etc.), but I've always felt it was safer to get the data into permanent storage as soon as possible. (Note this is a hotly debated topic, I'm merely stating my preference).
Saving to the DB immediately doesn't affect app speed (depending on how much of what type of data you are inserting) so much as battery life. Accessing permanent storage takes more in terms of power as there are several more steps the processor needs to take.
If you do all your DB activities in a thread other than the UI thread the transactions will be almost completely unnoticable in terms of app speed.

If you use implement Loader callbacks it should not slow your application down. Have a look at the Loader classes. They are available through the Android compatibility library.