Hi i am implementing Sticker Feature in my app. Here user can download multiple sticker pack in background like Viber and Line.
I m a little bit confused of the what i use : Thread or IntentService.
also if user go to Sticker pack which is downloading or in queue then i need to show there.
After download i need to store it in database.
please help.
An IntentService has the advantage that the Service will be correctly started and stopped, when its daemon thread is busy. Communicating with an IntentService (using intents) is also simple and provides excellent isolation and thread safety.
If the IntentService is too restrictive (single threaded; one way, Parcelable communications), then you might want to roll your own bound ExecutorService. This is a fair amount of work: you need to manage starting and stopping the Service, handle binding and unbinding the service from client Activities, all the time being careful of thread safety.
... actually, I'm surprised there isn't a library, out there, to do this. It is such a common need.
Use Service with ThreadPoolExecuter instead of IntentService.
Related
I have read one post about Android services within threads but there is one thing that I did not understand. In the post the writer uses a custom service because it allows multitasking while IntentService does not.
https://guides.codepath.com/android/managing-threads-and-custom-services#custom-services
Until there everything is okay, but later the writer uses a HandlerThread which just allow one thread, as my point of view there is no difference between this and a normal IntentService.
https://guides.codepath.com/android/managing-threads-and-custom-services#threading-within-the-service
Am I right? or is there anything that I am missing? I am looking at this due I want to create a android service able to run different tasks at the same time, should I use ThreadPoolExecutor instead HandlerThread?
You should make yourself familiar with the changes to background execution introduced with Android 8.0 - you cannot freely execute background work in Services anymore the way you could when that tutorial was written.
https://developer.android.com/reference/android/support/v4/app/JobIntentService might be for you; if not, have a look at https://developer.android.com/topic/libraries/architecture/workmanager
In the current app that I am developing with a co-worker, we're using IntentServices with Volley calls inside to process RESTful API network requests. It's just simple JSON string data, and some small images.
My question to those experienced in processing network requests is this: is there something more appropriate, or cleaner to implement out there?
From what I understand, the advantage of using an IntentService is that it runs in the background off the main thread, and is typically one of the last things killed by the Android OS. The downside being that IntentServices are run sequentially.
I've been reading a lot about RxJava, and Retrofit, and feel like our needs could be better served with that combination. Retrofit may be enough on its own, but I'd really appreciate some third-party insight.
My general rule of thumb is:
If the network I/O should be under a second, and you don't mind if it does not run to completion, any asynchronous option should be fine.
If the network I/O should be more than a second, or you really want to increase the odds that it will run to completion, use a Service. Whether you use IntentService or some other Service implementation is up to you, but you want to have a Service as an indicator to the OS that you're doing work, so it doesn't terminate your process quite so quickly once your app moves to the background. Remember that "moves to the background" is not always something initiated directly by the user, as incoming phone calls and such also move you to the background.
If the network I/O will take more than 15 seconds, not only do you need to use a Service, but you need to think about a WakeLock (via my WakefulIntentService, or WakefulBroadcastReceiver, or your own carefully-managed WakeLock) and possibly a WifiLock. 15 seconds is the minimum auto-screen-off period in Settings, which is where that figure comes from.
With all that in mind:
The downside being that IntentServices are run sequentially.
I am translating this as "an IntentService has a single thread for processing requests". This is true. In cases where you need a Service and you need parallel processing, create your own Service. Just be sure to call stopSelf() when you have no outstanding work.
I've been reading a lot about RxJava, and Retrofit, and feel like our needs could be better served with that combination
This has nothing to do with whether or not you use a Service. Just don't try doing asynchronous stuff (e.g., a Retrofit call using a Callback) from an IntentService, as you defeat the purpose of the IntentService (indicating to the OS that you're doing work). So, from an IntentService, you would use Retrofit's synchronous API, sans a Callback.
Using IntentServices just to perform a simple network request, IMO, is to much. You should use an AsyncTask if you don't want to use a library or if you prefer to go for Retrofit, Volley... (I would recommend Retrofit).
IMO, Services, or in this case IntentService are designed to execute long background tasks.
The real question is: do you load data to populate an Activity in the foreground or for doing background work, even when no UI is visible?
For background work, a Service is the way to go. You don't even need an IntentService if you rely on the threading management of Volley.
For foreground work, consider using Loaders, or Volley or Rxjava calls directly inside your Activity/Fragment.
I have a two part question. Both are somewhat general.
I'm creating an app that relies heavily on communication with a server. I plan to have different classes for each repository I'll need. Is an Android service the correct pattern to use here? There may be certain situations where I'll want to cache things between activities. Will a service allow me to do this?
Assuming a service is what I want to use for this, how can I load content once the service is bound. When the user opens the app, I want to start loading content. However, binding a service isn't blocking, so I can't write the code that makes requests with the service in my onStart() right? Is there some helper class that will wait for the service to load then execute a function? I know I could put some code in my onServiceConnected() method but I'd like to stay away from coupling like that.
Hopefully that wasn't too abstract. Thanks in advance.
Yes, Service is the way to go, but a started service, not a bound one.
You could make async request methods, and the Service can broadcast the result back to your Activity.
The async request in this case is a startService(intent) with an
Intent containing the request parameters. The service would start a background thread for the operation, optimally you can use a networking library for this (for example Volley).
And the reply is a broadcast by the Service with the relevant data.
This answers the problem of caching, because the Service can decide what to return. So in case the Service does not have the requested resource, it will download (and return) it. But if the Service has the resource, then it will just simply return the cached version.
To start, you should get yourself familiar with these topics:
Started Services (for the requests)
LocalBroadcastReceiver (for the reply)
Event Bus (alternative to LocalBroadcastReceiver, for example Otto)
I don't know much about your concrete needs, but it seems like you want to implement a REST client with cache. There is a really good Google IO presentation on that here. Definately worth to watch!
1)If you need code to run even when your Activity isn't, the correct answer is a Service. If you just need to cache data, then storing it in a global static variable somewhere may be ok.
2)Your service can start a Thread or AsyncTask. These execute in parallel. onStartCommand generally launches it in this case.
As with most things, the answer to these questions are subjective at best. I would need more information then I currently have, but I'll take a vague, general stab at this...
If you need something persistently hitting your server repeatedly I would say use a service.
Where you call it is not nearly as important as how many times it needs to be called. That being said the answer is yes. If you need this data as soon as the application or activity loads, then the onCreate method is where it needs to be loaded.
My reccomendation is either A) service or B)AsyncTask.
Go with A if you have to hit the server repeatedly for data and need it in regular intervals. Otherwise go with an AsyncTask and load all the data you need into an object for storage. Then you can use it as you need and it will essentially be "cached".
The difference between the two is simply "best tool for the job". I see you use some javascript. To give a proper analogy, using a service for a server call rather than an async task, is the equivalent of using a web socket (node js) when you could of just used an ajax call. Hope this helps. Oh and PS, please don't use static variables in Android =).
I have the following task:
I have to do a Wi-Fi scan and then send some RSSs to the a server to obtain a location from the server. After that I should display the location on a map.
I have one activity in my application. What is the best way to implement it? I haven't implemented a thread nor AsyncTask in android before. So I don't know a lot about it. I have read about threads and AsyncTask on android developer website. But I still can't understand everything.
I would appreciate it if anyone can tell me when its the best to use threads, and how AsynTask is different from threads and when to use AsyncTask instead of threads.
EDIT: the task that I have to implement should run only when the user click on actioBar item
.
If you can't understand the read documentation, I'd suggest starting with an AsyncTask, as it already implements a Thread when doInBackground() is fired and it already implements some mechanisms that you would probably have to implement by hand when using Threads (concurrency, Thread start/stop processes, sending information to UI thread, ...).
However, you don't specify what exactly want to do. If you plan to do a long-running process, instead of Threads or AsyncTasks, it's recommended using Service that would start a Thread as implementation, as contrary to popular beliefs, AsyncTasks are meant for short-lasting tasks.
In any case, if you're starting with this, I'd recommend using AsyncTask first, and when understood what it's doing and how, decide by yourself what's the best way to implement what you're planning to do: if running a Service with a Thread inside, a Thread itself or an AsyncTask.
I'm building an Android library to collect data from the host app and send this data to an online server in the background. I realize that this would require some sort of multi-threading/use of a service/forking.
The application simply keeps adding data through library calls, and the library should handle the sending of this data in the background without disturbing the main UI.
How should I got about making this library? Should the entire library run on an Android Service? Should I just use another thread? This is my first foray into parallelism. I'm not sure what the best way to do this is.
A detailed response is appreciated.
Some of the answers aren't quite correct. Services (Android Service component) are NOT made to run in the background, they run in the default UI thread.
In all honesty, the question shouldn't be service or thread or anything. Your library does NOT need to kick start a service, it could simply be a class (singleton/static, whatever it is) that should extend AsyncTask (or anything else running in the background that I'll explain in a bit) and use the doInBackground method to send stuff to the server. Note AsyncTask is nothing but a Thread internally. So here's what I would do:
Let's call your library's main class that interfaces with your server ServerHelper. You can make this a singleton (or static but that's a separate discussion). Within this class create an innerclass say ServerHelperCommandTask and extend AsyncTask. You really should review AsyncTask in detail to understand how that works. Because you would be asked to override doInBackGround. Anything you put in this method will autmoatically get exectued in a separate thread off the UI. Then a callback is invoked called onPostExecute that you can override as you will get the result from doInBackground here. This OnPostExecute is called in the mainThread so you can check for say error results here, etc etc.
This would be the simplest method; however, there are many other methods and libraries that help you with networking and deal with all the background stuff internally. Google just release a library called Volley which you may be able to plugin and use as it would do all the parallel processing for you. But that may take a bit of learning curve. Hope you understand AsyncTasks as in your case if the data pushed isn't a lot, then AsyncTasks is the way to go. Also note that you can call multiple AsyncTasks but while that seems on the surface that it is kicking off multiple parallel threads, that isn't quite accurate since honeycomb as internally you can call 5 Asynctasks but all 5 of those tasks will be executed sequentially so you wouldn't have to worry much about serializing.
Service would be a more reliable solution for situation You described.
I mean running background threads from service, not from Activity. Service itself does not provide separate thread by default, by the way.
The point is that Services have higher priority than acitivities so they will be destroyed with less probabilty, so your long-running task won't be interrupted.
You could do both but here's pros and cons for each solution :
Services are made to run in the background, even when your app is not in the foreground. sers usually don't like having services running for nothing.
From your description it seems that you would only need to have this thread running when the app is in foreground right ?
If so, a normal thread could do the job.
However, a service might be easier to implement.
Hope it helps
You should definitely use a Service in this situation. Async tasks and manually creating a thread is not really suitable for computations that need to run in the background for network communication. Use the Async task for long running local computations (e.g. for an algorithm doing sorting).
Note that if you use a service, it will by nature NOT run as a background thread! You need to handle threading manually. In order to save yourself from this hassle (especially if it is your first time with multi-threading) use an IntentService!
The IntentService may be invoked using the startService method as with any other service, but the IntentService class is able to handle multiple invocations as in a producer/consumer pattern. This means that you can queue commands automatically to the service just using the startService method. In the IntentService class that you make, you can then handle different types of commands by looking at the given action inside of the intent that is sent along as a parameter in the startService method.
Here is an example of how the implementation of an IntentService:
public class SimpleIntentService extends IntentService {
public SimpleIntentService() {
super("SimpleIntentService");
}
#Override
protected void onHandleIntent(Intent intent) {
String commnad = intent.getAction();
//handle your command here and execute your desired code depending on this command
}
}