SERVICES

What is a service?

• A Service is a component that can perform long-running operations in the background and does not provide a user interface.

Should I use service only for above purpose?

• No, there is another purpose, if you want to share some functionality with other application, then use Service. Using binder IPC one can share functionalities through a service.

Will the service runs infinitely even if the component that has started has died?

• Yes, it will run indefinitely as long as no one calls stopservice(), or stopself().
• NOTE: this will hold true only if your service is derived from Service class. In case if you have derived from IntentService class, it will be killed immediately after finishing its tasks.

Service means a thread?

• No, a service by default runs in the main thread of process of apk, in which it was started.

So, Can I write any long running functionality in service?

• Yes, but if you feel that if that logic interrupts the main thread functionality then create a separate thread in that service and then write your functionality in that thread.

Can I update UI from that service thread?

• No, directly you can’t update UI [of main thread] from this worker thread[of service]. If you want to do so, use Handlers help from the service. Easiest way is to use AsyncTask instead of raw threads to update UI.

Why I cannot update UI from other thread?

• Because, Main[UI] thread will contain a looper which actually dispatches all the events related to all UI components in that process. So, if some other thread is trying to touch UI components of the UI thread then UI-thread’s looper will not tolerate it. So you have to handle it gracefully by using a mediator class known as Handler class. Using Handler class you can do Inter-thread communication.

How do I use a service?

• A service can essentially take two forms:
  • Started – A service is “started” when an application component (such as an activity) starts it by calling startService().
  • Bound – A service is “bound” when an application component binds to it by calling bindService().

What is the life cycle of a service?

1. Startservice() à onCreate() à onStartCommand() à onDestroy() [stopservice()]

[or]

1. Bindservice() à onCreate() à onBind() à onUnbind [unbind()] à onDestroy()

package com.techpalle.reciver;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.os.Bundle;
import android.widget.Toast;

public class myreciver extends BroadcastReceiver {

@Override
public void onReceive(Context context, Intent intent) {
// TODO Auto-generated method stub
/*
* Here don’t try to do anything which takes more time say
* networking sessions, sd card preparation, image uploading, DB reading etc.
* NOTE : Thumb rule of receiver is to finish your task as soon as possible and return.
* if you are not re turning with in 10 seconds, it[ANDROID] will kill this receiver.
*/
Bundle b = intent.getExtras();

String user_id = b.getString(“user_id”);
Toast.makeText(context, “The receiver of broadcast1 is started.. “+user_id, 1).show();

}

}

                ANDROID training: broadcast receivers

Broadcast receivers

Broadcast receivers are something which will get triggered on some broadcasted message. One can choose to respond to those broad cast messages by registering the receiver to react to that action which has been broad casted.

In case of activities and services, only one component will be triggered for any intent, that is intended for an activity or service.

But if you see the architecture of the broadcast receivers, more than one receiver can get triggered if all of those receivers satisfy the condition of intent-filter testing.

Which means there is a possibility of getting more than one receiver executed for a given broadcast message.Eg: may be more than one application is listening for a broadcast message say “INCOMING_SMS”. Then all those receivers will get executed.

There are two ways to create  broadcast receivers:

• statically – in manifest <receiver>
• dynamically – in code using context.registerreceiver

Note: if you have registered a broadcast receiver in – on resume

Then you should unregister it in on pause

There are three kinds of broadcasts:

• Normal broadcasts -  Context.sendBroadcast
• Ordered broadcasts -  Context.sendOrderedBroadcast –  android:priority
• Sticky broadcasts – Context.sendStickyBroadcast – sticky intent

In case of normal broadcasts, order in which receivers will get executed will not be known. They may get executed parallel or one by one or in some random order.

Where as in case of ordered broadcasts, they will get executed one by one based on the priority given to those components. If two components have same priority then order can’t be predicted.

In case of sticky broadcasts, it acts exactly like sending broadcast by only difference is the intent which you have previously sent will be hold by android. so that if any one calls registerreceiver(intentfilter) with the same action, then

note: Even in the case of normal broadcasts, the system may in some situations revert to delivering the broadcast one receiver at a time

Broadcast Receiver Lifecycle

Valid for the duration of the call to onReceive(Context, Intent)

So, anything that requires asynchronous operation is not available

Because, android will kill that process once control returns from receiver.

e.g.  you may not show a dialog or bind to a service from within a Broadcast Receiver.

you should instead use the Notification Manager