Tag Archives: android

We all like a playback progress bar underneath our media players, so we can see how far we are and, if necesary, drag the thumb to were we want it to be.

Lets do this on Android: enter http://developer.android.com/reference/android/widget/SeekBar.html

As we will need a Runnable to update the bar regularly, let you class implement Runnable. Let’s look at the run() method.

   @Override
    public void run() {
        // mp is your MediaPlayer
        // progress is your ProgressBar

        int currentPosition = 0;
        int total = mp.getDuration();
        progress.setMax(total);
        while (mp != null && currentPosition < total) {
            try {
                Thread.sleep(1000);
                currentPosition = mp.getCurrentPosition();
            } catch (InterruptedException e) {
                return;
            } catch (Exception e) {
                return;
            }
            progress.setProgress(currentPosition);
        }
    }

What we’re doing here is set the ProgressBar to our current position, then sleep for a second and do it again.
Continue reading→

I will base this post on the last article: Android ViewFlipper within TabHost for Tabs with different Views … and better memory footprint, where we had a TabHost and a ViewFlipper. To test that our example is still working, we have to start the app, start the tab example, click on the ViewFlipper then change to Tab2 and press the button. Of course you can do this by hand if you must, which basically always happens when you’re in the middle of development -unless you’re doing test driven development. But later on, you don’t really want to sit there and click a lot, or even worse, enter text with your thick fingers on a tiny android device screen. So a good idea to test the UI is to get it automated in some way. That is where robotium comes into the game.

Writing a basic test

So let’s write a test that does what we mentioned above. Go through the view and press everything we got and make sure it behaves the way we want it to.

    public void testTabExample() {
        solo.clickOnText("start tab example");
        solo.assertCurrentActivity("wrong activiy", Tabs.class);
        solo.clickOnText("this is a tab one");
        assertTrue(solo.searchText("this is the other tab one"));
        solo.clickOnText("this is the other tab one");
        assertTrue(solo.searchText("this is a tab one"));
        solo.clickOnText("Tab2");
        solo.clickOnText("do something");
        assertTrue(solo.searchText("this is a tab two"));
        sendKeys(KeyEvent.KEYCODE_BACK);
        solo.assertCurrentActivity("wrong activiy", UCdroid.class);
    }

What we doing here is clicking on the elements we see and clicking on the ones we need to click. We check that we’re running the correct activity and that the right texts show up. The test will run fine now, but it’s missing some abstraction. If we decide to rename a text later, we have to edit the test case. This is less than optimal. So let’s see what we can change to improve the test case.

Changing the application for better testability

Let’s take a look at the layout:

<Button
    android:id="@+id/btn_tabs"
    android:text="start tab example"  
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    />

We can see, that the Button has a hard wired text. That gives us some trouble later, because we cannot look up the text in the string resources. A good idea is to place the appropriate string in strings.xml and put a reference to it in the layout. This has two benefits. First, we can now look up the string in our test case. Second, we now have all the strings we use in the application in one file. This is particularly helpful if we want to have internationalization in the application.

So here is our “new” button

<Button
    android:id="@+id/btn_tabs"
    android:text="@+string/btn_start_tab_example"  
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    />

all we need in the strings.xml now is:

 <string name="btn_start_tab_example">start tab example</string>

after we did this for all the strings we use we can continue.

Writing a more abstract test

So here is our improved test case. Now we do not need to fear changing strings or internationalization.

    public void testTabExample() {
        Activity a = getActivity();
        String tab1c1 = a.getString(R.string.tab1_content1);
        String tab1c2 = a.getString(R.string.tab1_content2);
        String tab2c1 = a.getString(R.string.tab2_content1);
        
        solo.clickOnText(a.getString(R.string.btn_start_tab_example));
        solo.assertCurrentActivity("wrong activiy", Tabs.class);<img src='http://pragmatic-geek.com/uc/sites/default/files/imagepicker/1/android_logo.jpg' alt='android logo' style="float: left" class="imgp_img" />
        solo.clickOnText(tab1c1);
        assertTrue(solo.searchText(tab1c2));
        solo.clickOnText(tab1c2);
        assertTrue(solo.searchText(tab1c1));
        solo.clickOnText(a.getString(R.string.tabexample_tab2));
        solo.clickOnText(a.getString(R.string.btn_do_something));
        assertTrue(solo.searchText(tab2c1));
        sendKeys(KeyEvent.KEYCODE_BACK);
        solo.assertCurrentActivity("wrong activiy", UCdroid.class);
    }

Robtium shortcomings

When looking at the robotium java doc I noticed two things so far which bothered me a bit. Maybe I had a wrong approach or didn’t quite figure out how to do it.

When entering text via .enterText(int index, String text) I have to select the EditText field via its position in the layout instead of addressing it by its name. So as soon as the layout changes, I have to edit my test. Not so good.

The next thing is, when menus open and the item to click needs a scrolling action first I cannot reach it.

I’ll try to tackle those issues and write another post on how to do more complex operations.

Robotium alternatives

To all the Futurama fans, there’s another test framework which name has to sound familiar: Calculon. There is a short introduction on the author’s blog. I might look into that too.

So stay tuned for updates on Android UI testing.

Check out the project and the test on github.

This article is a follow up of Use Android ActivityGroup within TabHost to show different Activity. As you probably noticed or read in the comments, the provided solution in the last article was less than ideal. Even though it does work, it uses multiple activies and therefor has a bigger memory consumption than necessary.

What happens when you use ActivityGroup with Tabhost

In the previous example we had one Activiy per tab. One tab was even holding two Activies and using ActivityGroup to switch between them. That’s a total of five Activites that end up on the activity stack. Also the hierarchy was more nested than needed.

The improvement

So instead of using a Activity per Tab we can display a View in each. Thus we only need one Activity, all the events are caught by the class, so you need to find an ordered way of catching them. My example will implement the OnClickListener.

To keep the example short, we have two tabs. In the first one, there’s a ViewFlipper which switches between two TextViews when clicked. In the second tab, there’s just a bit of text and a button.

Here’s the code:

package com.unitedcoders.android.examples;

import android.app.TabActivity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.TabHost;
import android.widget.Toast;
import android.widget.ViewFlipper;

public class Tabs extends TabActivity implements OnClickListener {

    Button doSomething;
    TabHost tabHost;
    ViewFlipper flipper;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.tablayout_1);

        doSomething = (Button) findViewById(R.id.btn_do_something);
        doSomething.setOnClickListener(this);

        flipper = (ViewFlipper) findViewById(R.id.layout_tab_one);
        flipper.setOnClickListener(this);

        tabHost = getTabHost();
        tabHost.addTab(tabHost.newTabSpec("tab1").setIndicator("Tab1").setContent(R.id.layout_tab_one));
        tabHost.addTab(tabHost.newTabSpec("tab2").setIndicator("Tab2").setContent(R.id.layout_tab_two));

        tabHost.setCurrentTab(0);

    }

    @Override
    public void onClick(View v) {

        // show a toast in second tab
        if (v == doSomething) {
            Toast.makeText(getApplicationContext(), "doing something", Toast.LENGTH_SHORT).show();
        }

        // toggle TextView in first tab
        if (v == flipper) {
            flipper.showNext();
        }

    }

}

and the layout that goes with it:

<?xml version="1.0" encoding="utf-8"?>
<TabHost xmlns:android="http://schemas.android.com/apk/res/android"
	android:id="@android:id/tabhost" android:layout_width="fill_parent"
	android:layout_height="fill_parent">

	<LinearLayout android:orientation="vertical"
		android:layout_width="fill_parent" android:layout_height="fill_parent">
		<TabWidget android:id="@android:id/tabs"
			android:layout_width="fill_parent" android:layout_height="wrap_content" />
		<FrameLayout android:id="@android:id/tabcontent"
			android:layout_width="fill_parent" android:layout_height="fill_parent">


			<ViewFlipper android:id="@+id/layout_tab_one"
				android:layout_width="fill_parent" android:layout_height="fill_parent">

				<TextView android:id="@+id/tabone1" android:layout_width="fill_parent"
					android:layout_height="fill_parent" android:text="this is a tab one" />
				<TextView android:id="@+id/tabone2" android:layout_width="fill_parent"
					android:layout_height="fill_parent" android:text="this is the other tab one" />

			</ViewFlipper>



			<LinearLayout android:id="@+id/layout_tab_two"
				android:orientation="vertical" android:layout_width="fill_parent"
				android:layout_height="fill_parent">
				<TextView android:id="@+id/textview2" android:layout_width="fill_parent"
					android:layout_height="wrap_content" android:text="this is a tab two" />
				<Button android:id="@+id/btn_do_something" android:text="do something"
					android:layout_width="fill_parent" android:layout_height="wrap_content" />

			</LinearLayout>

		</FrameLayout>
	</LinearLayout>


</TabHost>

From this UI you can use AsyncTask to do your processing and refresh the UI. This will keep your number of Activities and the memory consumption low.

As a little bonus, here are the screenshots of the hierachy view for the
current example and the previous one.

The code is in the UCdroid project on github. You can run it on your device or emulator.

there is an updated version to this article with some improvements. please also read: Android ViewFlipper within TabHost for Tabs with different Views … and better memory footprint.

When you’re using a TabHost each tab has it’s own Activity. Now image you want to change the Activity for a certain tab. If you just go on and create a new Activity and display it, your Tab Layout is no longer visible.

For that reason you need a ActivityGroup within the Tab where you want to change the Activity.
An ActivityGroup is:

A screen that contains and runs multiple embedded activities.

Let's look at this at a real life example. An Android app that shows your podcasts. In the first Activity you get to see all podcasts by subscription. If you touch the subscription, you see the single podcasts you've downloaded for that subscription.

The Tabhost contains three tabs, one for the MediaPlayer, one for the archive and one for available downloads.

        TabHost tabHost = getTabHost();

        tabHost.addTab(tabHost.newTabSpec("tab1").setIndicator("Player").setContent(
                new Intent(this, PlayerActivity.class)));
        tabHost.addTab(tabHost.newTabSpec("tab2").setIndicator("Archive").setContent(
                new Intent(this, ArchiveGroup.class)));
        tabHost.addTab(tabHost.newTabSpec("tab3").setIndicator("Updates").setContent(
                new Intent(this, DownloadList.class)));

The ArchiveGroup takes care which Activity is shown in the second tab. With setContentView you can bring the View to the front.

        View view = getLocalActivityManager().startActivity("ArchiveActivity", 
                new Intent(this, ArchiveActivity.class).addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP)).getDecorView();

        setContentView(view);

Now all you need to do is to bring another View to the front after an action is triggered. In this case, after a ListItem is clicked.

        String album = (String) getListView().getItemAtPosition(position);
        Intent intent = new Intent(getApplicationContext(), ArchiveAlbums.class);
        intent.putExtra("album", album);
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);

        View view = ArchiveGroup.group.getLocalActivityManager().startActivity("ShowPodcasts", intent).getDecorView();

        ArchiveGroup.group.setContentView(view);

You need to tell the ActivityGroup which view is to be on top and set the appropriate Flag, so that the View will be on top.

Of course now you have to keep track which activity is in front, how they behave and what happens if the back button is pressed. But that gives you room for customizing the behavior.

The full code can be found on github in the GpodRoid project.

Another good tutorials are by H. Larsen and Eric Harlow.