First question:
I know that in the Activities only view content should be implemented but is it usual to start an own service for each longer computation process?
Second question:
And the communication with the service is really extensive in code. If you want to invoke a method on the service you have to realize the hole IPC-mechanism?? Or is it also possible to invoke methods on local services without using the AIDL-files?
Depending on task you want to perform consider using AsyncTask or IntentService. Using regular Service should rather not suit your needs best here.
If you use regular Service you can easily pass your data or arguments or whatever in Intent. You do not need any IPC for this.
First question: you can start an AsynTask for longer computation process, service are generally used for action when application on background.
Second question: you can call any Method on your service, the use of idle make your services available for multiple applications, witch is not the case of a simple services, also, sample services runs on the same application process as your activities, witch is not the case of idle service.
Related
I´m developing an android app with more people in my team, the app has services to make calls to remote apis and you have to make those calls with in a separate thread with Asynctask.
Now i have to make a new service, and looking through the previously ones done by my mates, i see that one of them instanced the service and inside the service created the AsyncTask, while the other mate instanced the service inside the AsyncTask.
So I was wondering, what is the best practice for this? Or are both ways correct and there is a specific reason for each way?
The Service inside the AsyncTask seems really weird!
It is most common to have AsyncTasks in the Service or Thread-Handler pattern so as to make sure you have the "background" thread for the communication calls.
But if the task of your service is just to perform a call to your remote API and then return results to the caller, I would strongly suggest to take a look at IntentService. The difference is that the IntentService does not need any AsyncTask in order to achieve this "background" (other thread) thing.
Check google doc: http://developer.android.com/reference/android/app/IntentService.html
assuming you are saying Service which is the one in four Android components. a Service could only be instanced by Android system. you can not instance it in AsyncTask. if you instance service by java new keyword, the instance just perform like a normal Java class, out of the android system's control .
you can start a AsyncTask in service, it is a common design.
I just read Android Architecture Tutorial: Developing an App with a Background Service (using IPC). It is basically
Have a service run in separate process.
A repeated timer event will occur in the service.
Within the timer event handler, it will perform networking to retrieve tweet, and inform all the listener attached to it. Listeners are attached to it through IPC.
I can see there are 2 major characteristics with this approach.
Tweet retrieving action run within separate process.
It always run, even the main activity has quit.
However, if "It always run" is not my requirement. I want everything to stop when I quit my main Activity.
Will it be better, if I use AsyncTask (Or Timer) within my main Activity, to perform tweet retrieving action? Everything will be run within single process. No more using Service.
Using AsyncTask (Or Timer), seems simpler. We no longer need to deal with IPC.
Or, using Service approach might be better? Am I missing some goodies provided by Service?
Using service is a better approach as it will allow you to perform the polling independent from the application flow.
As it is a task where no user interaction is required and it has to be done in the background without disturbing the main UI of application and whatever the user is doing, a service is an ideal candidate for its implementation.
It is possible to bind the service with the application in such a way that when the main application terminates, it will also turn off the service.
I would take the view that a TimerTask can be set to execute and repeat at a given interval, Timers run on a separate thread so all this work would occur in the background without disturbing the UI. It would be easy for you to trigger an update within your app when the TimerTask completes and update the UI when you want.
When you exit the app it's a simple case of calling cancel() on your Timer and the purging all the tasks with purge().
Nice and easy and you don't need to implement IPC, which can be very fiddly to get right.
EDIT
Using AsyncTask you can do pretty much exactly the same thing but you'll have to manually schedule the next run. I have used both solutions in the past and found them to work equally well so it's all down to your preference.
At first you have to know, that a service isn't a Thread. If a activity binds a Service and runs as a Deamon, but a ASynchTask is another thread.
ASynchTask's are designed for doing some work which should not running on UI-Thread (for example processing some larger calculations)
Services are designed to run permanantly on Background.
If you want to permanantly check for new tweets, even if your activity is stopped or paused, you should use a Service, which checks into an own thread for new data.
TimerTask are good old java style implementations which run on their own thread.
You can used them for processing some data, but you'll have some problems to manipulation UI. If you want to be it on propper "AndroidWay", use a Handler instead of TimerTask.
First of all, I know the tutorial you are following...I've followed that tutorial myself while trying to learn IPC. One thing you need to know is, The Android docs explicitly say,
Note: Using AIDL is necessary only if you allow clients from different applications to access your service for IPC and want to handle multithreading in your service.
If at all possible, you should just bind to the service.
Also, you must consider, do you really need a service? Consider that the Android Twitter app doesn't even refresh tweets for you, its on an as needed basis. Polling can be battery intensive, so you must consider if this is really necessary.
Also, will you be using these tweets from multiple activities? If so it would be nice to not duplicate the code in multiple places. So maybe you do want a service in this case.
Other than that, I would recommend that you start simple (Async task with a timer to update it), and move to a service if you think you need it.
When something asynchronous needs to be done it is often recommended to put this in a service, maybe an intent service. Great. However, it is also not recommended to startup an activity from a service ... So when asynchronous response comes back inside the service perhaps the user is on a different screen. Then their is the whole aspect of binding to services ... One is left wondering which way is better and why? I mean services are cool but there is the binding to service call and there is also the issue that services should not have callbacks into activities. So which way is better. What is the criteria for using an AsyncTask vs. a Service to do async work? Also there is requestForResult() option too ...
The criterias are basically,
Do you need to update some data regularly or continue some task (android gives an example of a music player where the music continues even when no activities are visible) even when your application activities no longer run? Use service here.
Do you have a need where your data or some task needs to be run by multiple applications? In such case the applications need to bind to your service and access the info.
Do you have a case there is IPC involved? Use a service.
Do you have a case where all u need to do is do a heavy task like downloading data, some kick ass algorithm which takes time? Do all heavy tasks in a background thread and update the UI once completed. use an AsyncTask.
Asynctask is simple. Used mostly in your activities to do heavy tasks in a separate thread to avoid ANR.
Services on the other hand is used to do tasks which needs to run even when your app is not running, other app needs to bind to update data, you need the updated data before displaying your activity.
I am sure there are more criterias, but these are just a few that just came to me.
I am new to android development. I am creating an android application, in which there is a background service always running..
The service's target is to monitor incoming sms messages and do processing based on message filter
However the user would also want to change service bahviour through some UI/Activity. for exmaple user might wanna change the message filter.
SO in this case would my Service and Activity run as one process or seperate process ?
How would I make them communicate ? Please advise best possible model so that the performance is not affected.
Second question: Does an apk always have one processes or can have multiple processes ??
Thanks,
By default, all components of your application run in the same process, but it is possible to arrange for different components to run in different processes by using the android:process attribute in the manifest xml. I would strongly recommend against this for what your are doing.
You will want your Activity and Service to run in the same process, but the Service should arrange to have it's own thread to do processing on, otherwise the Service will run in the main UI thread, which you definitely don't want.
You could use the IntentService class to allow your activity to post Intent's to your Service.
The IntentService class then queues the Intents up and processes them one at a time on a dedicated worker thread that is managed by IntentService.
You might want to look at a Bound Service That page describes how an activity can access methods within a running service in the section 'Extending the binder class'
In Android, if I want to do some background work, what is the difference between
Creating a Service to do the work, and having the Activity start the Service
VS.
Creating a standard java class to do the work, and having the Activity create an object of the class and invoke methods, to do the work in separate thread.
Doing your own threads is overkill, there are solutions for this, so you don't have to worry about the hard parts of concurrency. Have a look at AsyncTask or IntentService. If you go for a service please keep in mind that your service can be killed at any time.
Well, Android provides some useful methods for making worker threads easily. Look at the Looper class definition. It allows you to send events via a Handler to be executed one after another in another thread or transmit messages between different threads.
A service is nothing fancy. Creating a Service is just a way of telling the OS that you need to do some work even when your Activity is not visible.
Depending on the application you're building it might not be an option.
Nearly every network application will have some of its functionality on a Service to allow the user change active Activity while something is being downloaded.
In an RSS reader, for example you can click 'Update all' and, depending on the current data connection, it might take a bit longer than you wish. So if you want the user to be able to get back to the Home screen and do anything else while the files are being dowloaded you'll have to use a Service.
A Service allows you to run tasks on the background while the user is not on your Activity. This doesn't mean it'll be running all the time. Check the Service lifecycle.
BTW IntentService is a service.