Bluetooth on Android : Part I

This is a part of a series of posts in which I will put forward a full working app what uses bluetooth on your Android device to discover, connect, pair, send and receive files. The source code would be tagged with each part of this series.

Part 1: The app should be able to discover and list out the devices (paired/unpaired).

To start off with learning about bluetooth on Android, visit the official documentation. The documentation is quite lucid and clear. Here I will try to explain parts of my code.

The first activity (HomeActivity), for now, will have a single button "Discover Devices", which will take you to the activity(DiscoverDevicesActivity) where you can see the list of devices that are visible by your device.

This activity does a few things, quite a few if-else conditions.

• First, you need to check if your device supports bluetooth. If you don't have the hardware capability on your phone, you won't be able to run this application. Eh!! Most of the phones would obviously have bluetooth. Ummm...Yes... But the emulators don't. Arrggghhh!!!!
• Once you are sure that your device has bluetooth capability, the next thing to check if it is enabled or not. If it's enabled, move on to the next step, else you will need to turn it on first.

Intent intent = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);

startActivityForResult(intent, REQUEST_ENABLE_BT);

• Once, you click on "Yes" on the confirmation dialog that you will see, bluetooth radio will be switched on for you. On the screen, the "Scan" button will become active. Once you tap the "Scan" button, the ListView will show the list of devices that your device can discover.

That's all for the first part of the series. But, there's a little more to understand abut discovery.

The process of discovery is asynchronous. The list view, currently shows two kinds of devices.

1. Devices which your phone already knows about (Paired)
2. Devices which are discovered (Which are not paired with your device)

Getting the already paired devices is simple. The BluetoothAdapter will give you details about such devices.

// Check already discovered devices

Set<BluetoothDevice> devices = bluetoothAdapter.getBondedDevices();
for (BluetoothDevice device : devices) {
       adapter.addDevice(device);
}
adapter.notifyDataSetChanged();

Now comes the actual discovery part. For this, you will need to register a broadcast receiver which will be called whenever a new device is found. After registering the receiver, you need to trigger the discovery by calling the startDiscovery() method of the BluetoothAdapter.

// Scan for new devices
IntentFilter filter = new IntentFilter(BluetoothDevice.ACTION_FOUND);
registerReceiver(devicesReceiver, filter);

bluetoothAdapter.startDiscovery();

On the receiver's onReceive() method, we pick up the details about the new device found, and add it to our ListView.

public void onReceive(Context context, Intent intent) {
      String action = intent.getAction();
      // When discovery finds a device
      if (BluetoothDevice.ACTION_FOUND.equals(action)) {
          Log.i(TAG, "Device found");
               
          // Get the BluetoothDevice object from the Intent
          BluetoothDevice device = intent
                  .getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);
          // Add the name and address to an array adapter to show in a ListView
          adapter.addDevice(device);
          adapter.notifyDataSetChanged();

}

The DevicesAdapter is a custom adapter for the ListView which we will be updating in the subsequent posts to show more information about the devices.

As always, you should unregister your receiver, once your activity is paused. Also, in addition to this, you should also cancel the discovery if at all you have started by calling the cancelDiscovery() method of the BluetoothAdapter.

The part 1 of the project can be checked out by fetching the source code and checking out the v1.0 tag from the repository. The complete source code can be found here.

Alternately, if you want to download the source of Part 1 as a zip, use this link to Part 1.

Drag and Drop (Honeycomb/ICS)

Drag and drop is already available with Honeycomb and up. In this example, we will see how to implement a simple Drag and Drop Operation.

We have a ListView with some items. The other half of the screen would have a drop area which has a single TextView. We will see, how to drag items from the ListView, drop them into the drop area, which will update the TextView with the list item's title, and also, that particular item would be removed from the ListView.

We will trigger the drag operation, when you long tap on an item in the ListView. After the drag operation is started, you will see a floating view of the selected item, which you can move around the screen. When you approach the drop area, the background of the drop area would change, which means that you can now drop your item. Once you leave the item, the TextView inside the drop area will show the text of the selected item.

This should also work on Ice Cream Sandwich. You can find the whole source code here. The code is quite self-explanatory. But, if you have any queries, let me know through the comment form. There are a few comments in the code to help you.

Simple ViewPager for Android

You would have seen many applications recently, which make use of the new and awesome ViewPager that allows views to be horizontally scrollable. The new Android Market app also implements a flavor of the ViewPager, although it's a little more complex that what we will see here. This class is not available directly for you to use. Check this blog for some insight. It would required you to download a compatibility library from Google, add it to your project wherever you would like to use it, and go about paging views.

And yes, it's very simple to implement. I have coded up a little sample where it shows you how to use a ViewPager with a simple PagerAdapter. More or less, it works like the ListViews. Although there is not much documentation for this, it's quite easy to set up everything.

Firstly, you would need to add the ViewPager into your layout file.

Listing of main.xml

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical" android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <TextView android:text="Page 1" android:id="@+id/textViewHeader"
        android:layout_width="fill_parent" android:layout_height="wrap_content"
        android:gravity="center" android:padding="10dip" android:textStyle="bold"></TextView>
    <android.support.v4.view.ViewPager
        android:layout_width="fill_parent" android:layout_height="fill_parent"
        android:id="@+id/viewPager" />
</LinearLayout>

In this sample, we are using an extra TextView which would show the current page you are on.

Setting up the ViewPager

ViewPager viewPager = (ViewPager) findViewById(R.id.viewPager);

MyPagerAdapter adapter = new MyPagerAdapter(this);

viewPager.setAdapter(adapter);

This code is almost identical to what we would do for a ListView or Gallery. The only difference is that the adapter here, extends a PagerAdapter instead.

The PagerAdapter

The PagerAdapter has a few methods that you would implement. For this example, I have four different views, one for each page. 2 are ListViews, a TextView and a Button, not in that order. Here are the methods that you would need to implement. Look at the MyPageAdapter class for more.

@Override

public void destroyItem(View view, int arg1, Object object) {

         ((ViewPager) view).removeView((View)object);

}

@Override

public int getCount() {
          return views.size();

}

@Override

public Object instantiateItem(View view, int position) {
           View view = views.get(position);
           ((ViewPager) view).addView(view);
           return view;

}

@Override

public boolean isViewFromObject(View view, Object object) {
           return view == object;

}

 And you are done!!! Sweet.... You can find the whole source code here.

Automating Builds on Android - Part 2

In the previous post, Automating Builds on Android - Part 1, we saw how to setup our projects to automate the build process. In this post, we will automate the process further to make Ant automatically use the passwords for our keystore and alias, label our builds to whatever name we like and put it in a specific location on your system (from where others can access it).

1. To make Ant use the passwords for our keystore automatically, we will create a separate properties file in our project folder where. Let's name it "passwords.properties". This file would contain two properties as listed below.

key.store.password=sample
key.alias.password=sample

2. We will need to make a small change in our build.xml file to tell Ant to load this property file while building. To do this, we simply add this one line in the build.xml file.

<property file="passwords.properties" />

If you try to run "ant release" command in your terminal, you will notice that Ant doesn't ask you to enter your passwords anymore. It has picked up the passwords from your passwords.properties file.

3. Adding a name and a time-stamp to your builds while making a release build needs a little more effort. We will now create another properties file called "extras.properties". This file would contain two more properties as listed below.

file_name_format=test_build_hello_world

build_location=C:/Builds/HelloWorld

The file_name_format would be used to name your output builds. Sometimes, you would want to name your builds differently based on whether it is a "daily_build" or "weekly_build" or a "release_build". Instead of renaming the output file manually, you could just change this property accordingly just before your type in "ant release", and your builds would automatically be named as you like. The other property, build_location is again a configurable value here, where Ant would put all your builds in the specified location. This could be a shared folder on your system from where anyone else can access it easily.

4. Now comes the lengthy part. To accommodate these changes in our build process, our original build.xml is not enough. We will have to tweak the actual underlying build.xml to make our build process more streamlined. Let's see how to do it. Pick up the build.xml from the sample project and replace the previous build.xml with this one. It will have a whole lot of Ant scripts. You don't have to worry about most of it, except for these lines.

    <!-- Date/Time format for naming the file-->
    <tstamp>
        <format property="time" pattern="dd_MMM" />
    </tstamp>
    <property file="local.properties" />
    <property file="passwords.properties" />
    <property file="extras.properties" />

Notice, that, we are using a time-stamp property which we would be using in our build.xml to version our builds based on the specific format. Our builds will be names as "test_build_hello_world_22_SEP.apk".

The last thing you need to change is this piece of code. You will find it somewhere in the new build.xml.

    <property name="out.release.file.name" value="${file_name_format}_${time}.apk" />
    <property name="out.release.file" location="${build_location}/${out.release.file.name}" />

5. Here, you can see that we have changed the property "out.release.file.name" to a value that we want the output file to be named as. And also, we changed the "out.release.file" to use our configured directory from the extras.properties file.

The final step is to run "ant release" for the last time, and you will see your final release build placed at your desired location.

You can find the sample project here.

Automating Builds on Android - Part 1

Do you find it hard to get a release build of an Android app? Well, you could say that it's not at all difficult. It just takes about 1 minute to get a build, sign it with your release keys and you are done. For a typical moderately big Android app, you could have a QA process where you send out builds for testing or verification to someone else. And you could be sending out the builds multiple times a day. In such situations, it becomes a tad tedious getting release builds out of your eclipse. In this post, we will try to automate this process of preparing the release builds.

Our tool of choice is Ant. Most of you perhaps already know how to do set it up. We will, however, also see how to version or auto-label your builds in next post. In this post, we will go through the basics.

1. To start off with, create a "HelloWorldAnt" Android project.

2. The next step is to prepare our project to use Ant scripts. To do this, fire up your terminal, go to the directory where your project rests and type out this command.

android update project -p .

3. A few files would be added to your project. Among these, the build.xml is the file that Ant would read and package your apk.

Updated local.properties

Added file ./build.xml

Updated file ./proguard.cfg

4. Now try running this command in the terminal. After we setup everything, this is the one single command that we would run every time we need to create a release build.

ant release

5. You will see a long log of what Ant is doing. Look towards the end of the logs and you will notice these lines:

-release-nosign:

     [echo] No key.store and key.alias properties found in build.properties.

     [echo] Please sign /workspace/HelloWorldAnt/bin/HelloWorldAntActivity-unsigned.apk manually

     [echo] and run zipalign from the Android SDK tools.

6. So, till this point, the Ant tool has prepared an unsigned apk which it has kept in the bin folder of your project and it asks you to manually sign this apk with your release keys. Next step is to automate this process.

7. Put your keystore inside your project folder. For this project, sample_keystore is the keystore that we would be using to sign this application. Now, we need to tell Ant to use this keystore to sign our builds with. Here, we will add a few files to our project.

Filename: build.properties

File Listing:

key.store=sample_keystore
key.alias=samplekeystore

 8. At this point, if you try running "ant release" command, it will ask you to enter the password for the keystore and the alias name, and finally, it would put the release and signed builds in your bin folder. 

The next post will talk about customizing the build process to the next level.

Automating Builds on Android - Part 2

You can find the sample project here.