I have my App which downloads & uploads data from/on the server (I have my WebApp written in Java & hence, used SOAP webservice for the communication between my Android App & Java Web App).
Up till now I've been using
AsyncTask
for calling WebServices to download/upload data.
So far so good with small amount of data being downloaded.
But when I download the large amount of data from the server the App crashes.
In reference with the android ref doc.
AsyncTasks should ideally be used for short operations (a few seconds at the most.) If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java.util.concurrent pacakge such as Executor, ThreadPoolExecutor and FutureTask.
So I think this is the problem with the AsyncTask being used for longer time interval.
Here is a similar old post
But I am not able to figure it out how to call web services using other threading techniques such as : Thread Pool Executor,Future Task or Executor
Below is my LogCat:
Hey, now there is one more problem . I have used IntentService for those long running Network operations (Downloading). Now As My data is big enough while downloading .Hence, in middle of downloading if internet connection is lost then I have to stop the IntentService which I think I can do using.
stopService(new Intent(MainActivity.this, IntentServiceClass .class));
which calls ,
onDestroy()
of the service. But the Code written in ,
onHandleIntent(Intent intent)
will keep on executing. (Which should not happen).
Any long task of this sort should use a android service. The basic problem is the application life-cycle in Android. Any activity and associated threads can be stopped by the operating system. A service by contrast runs background until it suspends or finishes or whatever.
Also good reliable ways to communicate status etc exist to communicate between services and activities.
For details on how to get the service and activity to communicate this question has a lot of very useful information
Related
I do not understand what difference between those two APIs. I mean when to use the first one. Why is there JobIntentService ?
Thanks in advance
I would recommend to read this article explaining about the difference between intent service and job intent service. When we look for the first time at these terms Service, IntentService, JobIntentService they would look almost similar - in one way or other they would perform some operations in background (which user does not notice). But there is few difference in the way they operate,
Service - This runs on the same main thread which invokes this service and performs some background operation. For any long running operation happening on the main thread it is recommended to create a new thread and do the job (eg; Handler) by not impacting the main thread's performance.
Drawback : Runs on main thread
IntentService - Intent service also helps in doing some long running (indefinite) background task. The only difference is that it creates a new thread to perform this task and does not run on the main thread. Does the given job on it's onHandleIntent.
Drawback: The job given to the IntentService would get lost when the application is killed
JobIntentService - Job intent service is very similar to IntentService but with few benefits like the application can kill this job at any time and it can start the job from the beginning once the application gets recreated/up.
But from Oreo, if the app is running in background it's not allowed to start the service in background. Android asks us to start the service explicitly by context.startForegroundService instead of context.startService and when the service is started within 5 seconds it must be tied to the notification to have a UI element associated with it.
Reference : https://developer.android.com/about/versions/oreo/background.html
Both work same but the only difference with JobIntentService is that JobIntentService gets restarted if the application gets killed while the service was executing. OnHandleWork() get's restarted after the application get's killed.
Basically, the two follow the same role, the difference being that an IntentService it is a base class for Service that handles an explicit asynchronous request with Intent on demand, it is starts through the startService (passing the Intent of the service), from hence the service is started as you wish, from the Android Oreo JobIntentService it also performs work processing however it is able to keep running in older versions, it also makes a process simpler. More in fact the 2 APIs have the same follow up. For the Execution of the work from the Oreo uses if JobScheduler.enqueue already in the older versions of the platform, it will be used Context.startService
Hope this helps.
I have a pool of AsyncTasks which pass state data back to the service that executed them, but they keep being killed by Android.
I can't use an IntentService because the Service is keeping track of State used by UI and AsyncTasks.
How do I:
1) keep the service from being killed
2) Replace either service or AsyncTask with something better for this use case?
You should use foreground service. Android OS can kill service if it is running short on resources, but it will always spare foreground service.
The Android system will force-stop a service only when memory is low
and it must recover system resources for the activity that has user
focus. If the service is bound to an activity that has user focus,
then it's less likely to be killed, and if the service is declared to
run in the foreground (discussed later), then it will almost never be
killed.
Note: Another thing you should also consider
Caution: A service runs in the main thread of its hosting process—the
service does not create its own thread and does not run in a separate
process (unless you specify otherwise). This means that, if your
service is going to do any CPU intensive work or blocking operations
(such as MP3 playback or networking), you should create a new thread
within the service to do that work. By using a separate thread, you
will reduce the risk of Application Not Responding (ANR) errors and
the application's main thread can remain dedicated to user interaction
with your activities.
I am using java(Servlets, JSPs) since 2 years for web application development. In those 2 years I never required to use multithreading(explicitly - as I know that servlet containers uses threading to serve same servlet to different requests) in any project.
But whenever I attend an interview for Web Developer position(java), then there are several questions related to threads in java. I know the basics of java threading so answering the questions is not a problem. But sometimes I get confused whether I am missing something while developing web application by not using mutithreading?
So my question is that what is the role of multithreading in Web Application? Any example where multithreading can be used in web application will be appreciated.
Thanks in advance.
Multi-threading can be used in Web Apps mainly when you are interested in asynchronous calls.
Consider for example you have a Web application that activates a user's state on a GSM network (e.g activate 4G plan) and sends a confirmatory SMS or email message at the end.
Knowing that the Web call would take several minutes - especially if the GSM network is stressed - it does not make sense to call it directly from the Web thread.
So basically, when a user clicks "Activate", the Server returns something like "Thanks for activating the 4G plan. Your plan will be activated in a few minutes and you will receive a confirmation SMS/email".
In that case, you server has to spawn a new thread, ideally using a thread pool, in an asynchronous manner, and immediately return a response to the user.
Workflow:
1- User clicks "Activate" button
2- Servlet receives request and activates a new "Activate 4G Plan" task in a thread pool.
3- Servlet immediately returns an HTML response to the user without waiting for the task to be finalized.
4- End of Http transaction
.
.
.
Asynchronously, the 4G plan gets activated later and the user gets notified through SMS or email, etc...
Speaking about a real-world example, there are several reasons to use multi-threading, and I wouldn't hire a web-developer who doesn't know about it. But in the end, the reasons to use multi-threading are the same for standard- and web-development: you either want something that take a while (aka blocking) done in the background to give the user some response in between, or you have a task that can be speed up by having it run on several cores. When multi-threading is actually useful is however a different question.
Situation 1: A web server that does require some processing and has low hits/second
Here multi-threading (if applicable to the algorithm) is a good thing, as idle cores are utilized and threading can result in a faster response to the user.
Situation 2: A web server that does require some processing and has high hits/second
Here multi-threading is possible, but as cores are usually busy with other requests, there are no resources left to use it properly. Actually spreading out the task to several threads can even have a negative impact on the response time, as the task is now fragmented and all parts need to complete, but the order of execution with threads is undefined. So one client could immediately receive a response, while others might wait into time-out till their last fragment eventually gets processed.
Situation 3: A web server has to do some processing that takes a very long time
Here multi-threading is required, there is no way around it. A client cannot wait minutes or probably hours till it receives the response. In this case a callback system is usually implemented, so basically each task has an "API" that can be queried for the current state. Most online-shops are an example for this: you order something and later you can query your order status.
The alternative to threading is process-forking, as Apache does in its standard configuration. The benefit is that load is spread across cores (mostly applicable to situation 2), and the web-code itself doesn't have to do anything to use all those cores, as the OS handles that automatically. However if you have imbalanced load, some cores can be idle and resources are not used in an optimal way. A threading situation is almost always the better solution, if it is done right. But the Apache/Tomcat standard configuration uses a very outdated threading model, by spawning one thread for each request. Effectively given a certain amount of hits/second, the CPU is more busy with threading than with actually processing those requests.
Well this is a nice question and I think most of the developers who work in web application development don't use multithreading explicitly.
The reason is quite obvious since you are using a application server to deploy your application, the application server internally manages a thread pool for incoming requests.
Then why use multithreading explicitly? What is need a web application developer expose himself to multithreading?
When you work on a large scale application where you have to server many request concurrently it is difficult to serve every kind of request synchronously because particular kind of request could have been doing a lot processing which could bring down the performance your application.
Lets take an example where a web application after serving particular kind of request has to notify users through email and SMS. Doing it synchronously with the request thread could bring down the performance of your web application. So here comes the role of mutlithreading.
In such cases it is advisable to develop a stand alone multithreaded application over the network which is responsible for sending email and SMS only.
Multi-treading in web application can be used when you are interested in parallel action, e.g., fetching data from multiple addresses.
As I understand, multi-threading is used in different situation from thread-pool, which can be used to handle requests from multiple clients.
I have two threads, each of which handle syncing data one way either from the server or to the server. The thread for getting data off the server needs to run once a day. The other sending data to the server needs to run every 15 mins. I am currently using an Alarm Manager to create repeating alarms for each of these threads. This is then received by a BroadcastReceiver, from which i call an activity, which then according to the data passed into the activity either runs the to server syncing thread or the from server syncing thread. I am using the activity to display a dialog box, to prevent the user from using the application until the syncing has been completed as they both access the database required by the application. Is this the correct way to accomplish this task, or are there better alternatives?
Thank you in advance
This question is not really fit for SO... This is more a debate without any details on how your app works.
Anyway I would use an Android Service to do so. You do not need to bother the user just to upload data. Also why block the use of the app for uploading? Since for uploading you only need to read, just make a snapshot of the current data and upload it. Any changes the user is making right now will be uploaded in next upload, so that's not a problem.
For downloading, you most likely do need to block the app use, but maybe not. This depends on how the app works. You could start DB transactions to avoid doing that.
I am writing an android application to make server socket and receive messages from server
when I write the same application using Thread, it works pretty well but I am unable to access UI elements in Thread
whereas in case of services, startService method hangs on while(true){ socket.accept()}
You can read about threads and Android on the official documentation. Also, take a look at AsyncTask, that should help you a great lot.