Snippets for BroadCast Receiver

BroadCast Receiver with Custom Intent.

private final String CUSTOM_INTENT="com.android.example.CUSTOM_INTENT" 

 Intent intent=new Intent();

 intent.setAction(CUSTOM_INTENT);//should be as package name

      

       

  BroadcastReceiver receiver=new BroadcastReceiver() {

                 

                  @Override

                  public void onReceive(Context context, Intent intent) {

                        // TODO Auto-generated method stub

                       

                  }

            };

  IntentFilter filter=new IntentFilter("Custom_Intent");

  registerReceiver(receiver, filter);

  sendBroadcast(intent);

BroadCast Receiver with System Events.

Step 1:

Add receiver to Android Manifest File:

<receiver android:name=".PhoneReceiver">

    <intent-filter>

                  <action android:name="android.intent.action.PHONE_STATE" />

    </intent-filter>

</receiver>

Step  2: Define your Broad cast Receiver

public class PhoneReceiver extends BroadcastReceiver {

      @Override

      public void onReceive(Context context, Intent intent) {

            //toDo

      }

}

Important Points:

• Broadcast receiver should complete its onReceive() Method with in 5 sec.
• Difference between sendStickyBroadcast() and sendBroadcast() is:

Perform a sendBroadcast(Intent) that is "sticky," meaning the Intent you are sending stays around after the broadcast is complete, so that others can quickly retrieve that data through the return value of registerReceiver(BroadcastReceiver, IntentFilter). In all other ways, this behaves the same as sendBroadcast(Intent).

One example of a sticky broadcast sent via the operating system is ACTION_BATTERY_CHANGED. When you call registerReceiver() for that action -- even with a null BroadcastReceiver -- you get the Intent that was last broadcast for that action. Hence, you can use this to find the state of the battery without necessarily registering for all future state changes in the battery.

• android:pirority can be used to control broadcast intents between receiver if it was an ordered Broadcast.

Android BroadCast Receiver

Components of Application in Android

1. Activity: An activity represents a single screen with a user interface.
2. Services: A service is a component that runs in the background to perform long-running operations or to perform work for remote processes.
3. Content Providers: A content provider manages a shared set of application data.
4. Broadcast Receiver: A broadcast receiver is a component that responds to system-wide broadcast announcements.

What is Broadcast Receiver?

It is a listening class that can be notified whenever a specific type of system message is sent. These classes are called Broadcast Receiver.

Need of Broadcast Receiver

• If you want Android to instaniate the object whenever an appropriate intent is sent, define the <receiver> in the Android Manifest.xml file.
• Receiver will get called with their onReceive() Method.
• Receiver can define the intent-filter tag under the receiver tag . which defines the type of intent it can receive.

   Receiver tag to read the phone state.

<receiver android:name=".PhoneReceiver" >
 <intent-filter>
   <action android:name="android.intent.action.PHONE_STATE">

</action>
 </intent-filter>
  </receiver>

 Receiver tag to read the custom intent.
  <receiver android:name=".CustomReceiver">
     <intent-filter>
        <action android:name="com.daffodil.android.intent.action.CUSTOM_INTENT">

</action>
     </intent-filter>
  </receiver>

Defining Broadcast Receiver:

There are two ways to make a broadcast receiver known to the system:

1. One is to declare it in the manifest file with this element.

   <receiver android:name=".PhoneReceiver" >
         <intent-filter>
        <action android:name="android.intent.action.PHONE_STATE">

   </action>
         </intent-filter>
     </receiver>

2. The other is to create the receiver dynamically in code and register it with the Context.registerReceiver() method.

There are two major classes of broadcasts that can be received:

• Normal broadcasts (sent with Context.sendBroadcast) are completely asynchronous. All receivers of the broadcast are run in an undefined order, often at the same time. This is more efficient, but means that receivers cannot use the result or abort APIs included here.
• Ordered broadcasts (sent with Context.sendOrderedBroadcast) are delivered to one receiver at a time. As each receiver executes in turn, it can propagate a result to the next receiver, or it can completely abort the broadcast so that it won't be passed to other receivers. The order receivers run in can be controlled with the android:priority attribute of the matching intent-filter; receivers with the same priority will be run in an arbitrary order. 

Android In-App Billing

What is Android In-App Billing?

Android Market In-app Billing is an Android Market service that lets you sell digital content in your applications. You can use the service to sell a wide range of content, including downloadable content such as media files or photos, and virtual content such as game levels.

Why In-App Billing?

Using In-App Billing you are free to use Android Market Application to sell your application's content.When you use Android Market's in-app billing service to sell an item, Android Market handles all checkout details so your application never has to directly process any financial transactions.
Android Market uses the same checkout service that is used for application purchases, so your users experience a consistent and familiar purchase flow.

What Android Market takes from you for this service?

The transaction fee for in-app purchases (i.e is same as the transaction fee for application purchases )=30%.

What You need for doing In-App Billing (or In-App Purchases)?


Before you get started with in-app billing, be sure to review the following requirements and limitations.

• In-app billing can be implemented only in applications that you publish through Android Market.
• You must have a Google Checkout Merchant account to use Android Market In-app Billing.
• If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of the MyApps application. If your device is running any other version of Android, in-app billing requires version 2.3.4 (or higher) of the Android Market application.
• An application can use in-app billing only if the device is running Android 1.6 (API level 4) or higher.
• You can use in-app billing to sell only digital content. You cannot use in-app billing to sell physical goods, personal services, or anything that requires physical delivery.
• Android Market does not provide any form of content delivery. You are responsible for delivering the digital content that you sell in your applications.
• You cannot implement in-app billing on a device that never connects to the network. To complete in-app purchase requests, a device must be able to access the Android Market server over the network. 

Is there any free account for testing In-App Billing?

No, As for now there is no free account available for Google checkout for testing your In-App Billing application. Don't be confuse with sandbox account for Google checkout as they can be used with only Web Applications. We can't use the Merchant Key and Merchant Id in place of public key (explained later in this post) in our security.java file.

Structure of In-App Billing in your Application: