1. Extend your activity from an Android ListActivity
2. Create a class that extends the ArrayAdapter
3. In that class, implement the getView(int position, View convertView, ViewGroup parent) method

Then from your list activity you can create an adapter to show your list. Basically that’s it.
Loading the data initially into your list is no big deal. However, you may experience that when you change the data, and want to reload it that you loose the position in the list where you were. And that’s exactly what we will solve here!

Different ways of refreshing a ListView

To easily explain all this we will start from an easy example where we will list 20 customer-objects. When loading is done we wait for 5 seconds during which you can scroll as much as you want. After those 5 seconds we update one element (the last one) in the list and refresh the list on the device while trying to keep our scroll position correctly set. So ideally when you try this example, you start the demo application, you scroll all the way down in the list, way a few seconds and you will see that the last element in the list gets updated AND that your scrolling position is still at the bottom (and not reset to the top!). So this is the situation we start from:
public class DemoListViewActivity extends ListActivity {
private List customers;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.list_view_layout);
loadData(true);
//Create an AsyncTask taht runs for 5 seconds in the background
//During that time you scroll as much as you like
//After the 5 seconds the list is refreshed and we try to keep the scrollposition
AsyncTask task = new AsyncTask() {
@Override
protected Object doInBackground(Object... objects) {
try {
Thread.sleep(5000L); //Wait for 5 seconds and update the data
customers.remove(customers.size() - 1); //Remove the last element
Customer c = new Customer();
c.setFirstName("Google");
c.setLastName("Android");
customers.add(c); //Add a new element add the last place
} catch (InterruptedException e) {}
return null;
}
@Override
protected void onPostExecute(Object object) {
loadData(false);
}
}.execute();
}
private void loadData(boolean createNew) {
if (createNew) {
//ToDO Load some data from a database, local storage or the web
customers = new ArrayList();
for (int i = 0; i < 20; i++) {
Customer c = new Customer();
c.setFirstName("Dummy " + i);
c.setLastName("Object " + i);
customers.add(c);
}
}
}
}

How to loose your position – part 1

The easiest way is to always create a new instance of your adapter and put the list of objects to display on it:
CustomerListAdapater cla = new CustomerListAdapater(DemoListViewActivity.this, customers);
super.setListAdapter(cla);

Adding these lines at the end of the loadData method works, the list gets updated but you always jump back to the top of the list. And that’s not really what we want…

How to loose your position – part 2

Antoher way is to find out what the index of the first displayed list element is, reload the list and then force the list to scroll back to that index you got:
int fistVisiblePosition = getListView().getFirstVisiblePosition(); CustomerListAdapater cla = new CustomerListAdapater(DemoListViewActivity.this, customers); super.setListAdapter(cla); super.setSelection(fistVisiblePosition);
These lines are again added to the end of the loadData method, and this also works. You even keep your scroll position. Or more or less… If you scrolled the list and the first visible item in your list is displayed only half, then after the refresh it will be displayed entirely. So we are close to a good solution, but you feel this isn’t natural.

How to keep your position

But we can do better, more natural! In the previous two examples you saw that we always recreated the adapter. And that is eventually causing the reset of the scroll position. So what if we could keep the adapter and re-use it?
Well let’s try this. We need to add a method to the adapter to set the new data:
public void reload(List customers) {
this.customers.clear();
this.customers.addAll(customers);
notifyDataSetChanged();
}
And afterwards we can get a reference of the adapater in the ListActivity and call the reload method. If no reference is found we create a new adapter (like in the first method):
if (super.getListView().getAdapter() == null) {
CustomerListAdapater cla = new CustomerListAdapater(DemoListViewActivityPart3.this, customers);
super.setListAdapter(cla);
} else {
((CustomerListAdapater)super.getListView().getAdapter())
.reload(customers);
}


Conclusion

It’s not hard at all to change your implementation and keep the scroll position in the future. And if, in some cases, you have to jump back to the top of the list, you can easily re-create the adapter and job done!

ADB
Before I explain you the solution that comes with the Android SDK I should first get into ADB. ADB is the abbreviation for Android Device Bridge. It’s a utility in the SDK that allows developers to connect to their Android devices (Real devices or emulator devices (AVD’s)) and execute some actions on it. For example with ADB you can reboot a device, push files to it, get files from it, look into the SQLite database instance (only available for dev phones or emulators),… The tool can only be used from command line.

ADB Monkey
So now you what you can do with ADB, there’s even more! Google provides a monkey tester in the ADB. What it does:
It starts the application you want to monkey test and then starts firing all kind of simulated events. An simulated event can be a finger touch, the usage of the back button, usage of the menu button, a press on the camera or multimedia button, start playing music while your application is on top,… Every possible event a user can fire on any device when using your application can be simulated using the ADB Monkey tool. If any of the simulated events causes the application to crash, an entire stacktrace is available at the command line.

It’s quite easy to use. There’s only one thing you need to know, the package of the application you want to test which is defined in your application’s AndroidManifest.xml file. Next open a command line and use it to navigate to the SDK directory. In the SDK directory navigate to the tools directory in the root of the SDK or in the platforms/android-X/ directory. Once you’re there just execute this command (with your package declaration off course):

adb shell monkey -p your.package.declaration -v 500

This command will fire 500 random events to your application and will, if you’re application is properly designed, only output the launch of all the simulated events. An excerpt of the output:

:Sending Pointer ACTION_MOVE x=-3.0 y=4.0
:Sending Pointer ACTION_DOWN x=244.0 y=371.0
:Sending Pointer ACTION_UP x=244.0 y=371.0
:Sending Pointer ACTION_DOWN x=163.0 y=98.0
:Sending Pointer ACTION_UP x=163.0 y=98.0
:Sending Pointer ACTION_MOVE x=-2.0 y=3.0
:Sending Pointer ACTION_MOVE x=2.0 y=-1.0
:Sending Flip keyboardOpen=false
:Sending Pointer ACTION_DOWN x=193.0 y=137.0
:Sending Pointer ACTION_UP x=178.0 y=139.0
:Sending Pointer ACTION_DOWN x=295.0 y=451.0
:Sending Pointer ACTION_UP x=295.0 y=451.0
:Sending Pointer ACTION_MOVE x=2.0 y=-3.0
:Sending Pointer ACTION_DOWN x=249.0 y=465.0
:Sending Pointer ACTION_UP x=249.0 y=465.0
:Sending Pointer ACTION_DOWN x=153.0 y=336.0
:Sending Pointer ACTION_UP x=152.0 y=345.0
:Sending Pointer ACTION_DOWN x=65.0 y=316.0
:Sending Pointer ACTION_UP x=65.0 y=316.0
// Sending event #400
:Sending Pointer ACTION_MOVE x=4.0 y=3.0
:Sending Pointer ACTION_DOWN x=92.0 y=470.0
:Sending Pointer ACTION_UP x=92.0 y=470.0
:Sending Pointer ACTION_MOVE x=2.0 y=-1.0
:Sending Pointer ACTION_DOWN x=289.0 y=234.0
:Sending Pointer ACTION_UP x=289.0 y=234.0
:Sending Pointer ACTION_DOWN x=45.0 y=452.0
:Sending Pointer ACTION_UP x=45.0 y=452.0
:Sending Pointer ACTION_MOVE x=2.0 y=2.0
:Sending Pointer ACTION_DOWN x=59.0 y=459.0
:Sending Pointer ACTION_UP x=59.0 y=459.0
:Sending Pointer ACTION_MOVE x=-4.0 y=1.0
:Sending Pointer ACTION_DOWN x=57.0 y=384.0
:Sending Pointer ACTION_UP x=57.0 y=384.0
:Sending Pointer ACTION_DOWN x=304.0 y=165.0
:Sending Pointer ACTION_UP x=304.0 y=166.0
:Sending Pointer ACTION_MOVE x=1.0 y=3.0
:Sending Pointer ACTION_MOVE x=-2.0 y=-3.0
Events injected: 500
: Dropped: keys=0 pointers=0 trackballs=0 flips=0
## Network stats: elapsed time=7178ms (0ms mobile, 7178ms wifi, 0ms not connected)
// Monkey finished

For more information on monkey and it’s configuration options you can visit the Android SDK webiste: http://developer.android.com/guide/developing/tools/monkey.html

Caution
Before you get to ambitious and want to fire like a 30.000 events to your application make sure that you read the next sentence well! Once the monkey has been started, he can’t be stopped! You can however quit the command line and hope that it sends some kind of kill command to the monkey running on the device or emulator but it won’t stop on your device or emulator. So if you want to fire a really large number of events do it on an emulator (you can always close the emulator when you want) or do it on a device that you don’t need the next couple of hours!

Creating dialogs

As I said before, creating dialogs i quite easy. One thing you need to know is that each ‘type’ of dialog you make requires an id. So let’s assume the following block of code:

    //Constants used to create dialogs
    private static final int LAODING_DIALOG = 0;
    private static final int WARNING_DIALOG = 1;
    private static final int WARNING_DIALOG_DYNAMIC = 2;

    @Override
    protected Dialog onCreateDialog(int id) {
        Dialog dialog = null;
        switch(id) {
            case LAODING_DIALOG: {
                ProgressDialog progressDialog = new ProgressDialog(this);
                progressDialog.setMessage("Laoding...");
                dialog = progressDialog;
                break;
            }
            case WARNING_DIALOG: {
                AlertDialog errorDialog = new AlertDialog.Builder(this)
                    .setMessage("An error occured!")
                    .setCancelable(false)
                    .setNeutralButton(R.string.dialogOK, new DialogInterface.OnClickListener() {
                        public void onClick(DialogInterface dialog, int id) {
                            dialog.dismiss();
                            //dismissDialog(WARNING_DIALOG) should also work!
                    }
                }).create();
                dialog = errorDialog;
                break;
            }
            case WARNING_DIALOG_DYNAMIC: {
                AlertDialog errorDialog = new AlertDialog.Builder(this)
                    .setMessage("An error occured! Time: " + new Date())
                    .setCancelable(false)
                    .setNeutralButton(R.string.dialogOK, new DialogInterface.OnClickListener() {
                        public void onClick(DialogInterface dialog, int id) {
                            removeDialog(MY_EPISODES_ERROR_DIALOG);
                        }
                    }).create();
                dialog = errorDialog;
                break;
            }
            default:
                dialog = super.onCreateDialog(id);
                break;
            }
        return dialog;
    }

Working with the dialogs

As mentioned in the previous paragraph this code snippet does not yet start the dialogs. Therefore we need some code like this:

showDialog(LAODING_DIALOG);
//Do some complicated stuff that requires a loading dialog...
dismissDialog(LAODING_DIALOG);

For showing the loading dialog this should already work. But make sure for loading dialogs you start the dialog in a different thread than the thread in which you do the complicated stuff (have a look at AsyncTasks). For the other two dialogs you only need the ‘showDialog’-call as closing them should be done by the user (in the onClickListener). The code for those would look like this:

showDialog(WARNING_DIALOG);
showDialog(WARNING_DIALOG_DYNAMIC);

As you can see in all the code samples of this article there are two options to get rid off a dialog. And both have their usages.
First you can dismiss a dialog (dissmissDialog(int id)). Dismissing a dialog will make it disappear but the activity will still keep a reference to it. So next time you want to show it, it doesn’t need to be created again, it will just popup. Removing a dialog is exactly the opposite, any reference to the dialog will be removed and next time you want show the dialog it will be re-created.

And that is the big difference. Re-create or store a reference… As you can see in the first code snippet when we want to get rid off the static warning dialog (WARNING_DIALOG) we just dismiss it. When we want to get rid off the dynamic dialog (WARNING_DIALOG_DYNAMIC) we remove it. Why the difference… Well it quite easy. If we show the dynamic dialog for the first time it will show the message ending with the current date and time (for example October 26, 2010 7:21 PM). Now if we dismiss the dialog instead of removing it and we show it a second time the text displayed will be exactly the same as the first time. Because… the dialog is not created again. If we remove the dialog and show it again the second time it will show an updated time (for example October 26, 2010 7:22 PM).
So what does this learn us? Dismissing a dialog is nothing more than just hiding the dialog. So if you have a dynamic dialog you should always get rid of it by removing it. But there’s more… Look back at the loading dialog…

The loading dialog only gets closed in code. Let’s say we have a button on the screen, if the user clicks it some data will be loaded from the internet. Before we start loading the data we’ll show the dialog, afterwards we want to get rid of the dialog. The code snippet above will perfectly do this for you. Only when you click the button the second time, the opening loading dialog will not have a spinning circle. In fact the circle is there but it’s not moving at all! That’s because you have to look at a loading dialog as dynamic dialog. So instead of dismissing the dialog we should also remove it!

showDialog(LAODING_DIALOG);
//Do some complicated stuff that requires a loading dialog...
removeDialog(LAODING_DIALOG);

The rules are:

• Can the text to be displayed in a dialog be different: always remove the dialog
• Does the dialog contains any animation (spinning wheels, loading bars,…): always remove the dialog
• It the dialog completely static (no text that ever changes, no animated images,…): it’s safe to dismiss the dialog

09-11 11:12:41.601: ERROR/AndroidRuntime(264): FATAL EXCEPTION: main
        java.lang.IllegalArgumentException: no dialog with id 0 was ever shown via Activity#showDialog
        at android.app.Activity.missingDialog(Activity.java:2590)
        at android.app.Activity.dismissDialog(Activity.java:2575)
        ...
        at dalvik.system.NativeStart.main(Native Method)

In order to solve this error you need to prevent that your data is reloaded upon changing the screen orientation of the application. Why? Because standard when some Android configuration option changes the OS will drop the current activity and try to re-create it and so call the onCreate(Bundle savedInstance) of your activity again. If you have any loading dialog that you want to be hidden upon finishing, the application will crash because more than one loading dialog has been created and they should all be dismissed but only one will still exist.

AndroidManifest Fix
The easiest way of handling this issue is to edit your AndroidManifest.xml file and declare for each activity that the onCreate(Bundle savedInstance) shouldn’t be called for the orientation changes. This is how you should change your manifest file:

        <activity android:name=".MainApp"
                  android:label="@string/app_name"
                  android:configChanges="orientation|keyboardHidden">
            ...
        </activity>

As you can see we’ve added the android:configChanges=”orientation|keyboardHidden” property to the activity tag. You can do so for every activity where you do not want the activity to be recreated upon changing the orientation. This solution works like a charm but there is something odd. As you see we didn’t tell the activity to skip the recreation only on orientation but also for hiding the keyboard. When you remove the keyboardHidden it doesn’t work anymore. But why?

If we have a look at the Android loggings we can retrieve from our test-device or virtual machine (AVD) we have something like this:

09-11 11:37:56.321: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/1 nav=3/1 orien=2 layout=34 uiMode=17 seq=56}
09-11 11:37:58.141: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/2 nav=3/1 orien=2 layout=34 uiMode=17 seq=57}
09-11 11:37:58.639: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/2 nav=3/1 orien=1 layout=34 uiMode=17 seq=58}
09-11 11:38:00.930: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/1 nav=3/1 orien=2 layout=34 uiMode=17 seq=59}
09-11 11:38:02.995: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/2 nav=3/1 orien=2 layout=34 uiMode=17 seq=60}
09-11 11:38:03.400: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/2 nav=3/1 orien=1 layout=34 uiMode=17 seq=61}
09-11 11:38:05.560: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/1 nav=3/1 orien=2 layout=34 uiMode=17 seq=62}
09-11 11:38:07.650: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/2 nav=3/1 orien=2 layout=34 uiMode=17 seq=63}
09-11 11:38:08.080: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/2 nav=3/1 orien=1 layout=34 uiMode=17 seq=64}
09-11 11:38:10.350: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/1 nav=3/1 orien=2 layout=34 uiMode=17 seq=65}
09-11 11:38:12.880: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/2 nav=3/1 orien=2 layout=34 uiMode=17 seq=66}
09-11 11:38:13.310: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/2 nav=3/1 orien=1 layout=34 uiMode=17 seq=67}
09-11 11:41:40.191: INFO/ActivityManager(58): Config changed: { scale=1.0 imsi=310/260 loc=nl_BE touch=3 keys=2/1/1 nav=3/1 orien=2 layout=34 uiMode=17 seq=68}

Have a close look at all those logging lines and you’ll see why we added the keyboard hiding to the list. The value of orien changes (1 or 2) but also the keys value changes (2/1/1 or 2/1/2). Probably this is because a different keyboard has to be shown when in landscape or portrait mode.

Save the Activity state
The second solution is a little harder to implement but fixes the problem as well. The advantage of this solution compared to the first one is that you have full control on the reloading process, although the re-creation of the activity isn’t skipped this way.

The Activity class you have to inherit from every time you create an Activity has some useful methods to override.

• The onSaveInstanceState(Bundle outState) will store the current state of your activity somewhere on the device. In case the activity needs to be recreated (so on an orientation switch for example) this saved state will be used.
• The onDestroy() method will be called when the activity is about to recreated. First the state will be saved, afterwards the activity will be destroyed and finally it will created again.

So now we now this we could implement it this way:

public class MyActivity extends Activity {
    private List myData;

    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.myLayout);

        Object s1 = savedInstance.getSerializable("myData");
        if(s1 == null) {
            //Now data found so get it yourself
            //Some call to a webservice or somthing to retrieve your data
            loadDataAndShowLoadingDialog();
        } else {
            //Data found on the savedInstance
            myData = (ArrayList) s1;
        }
    }

    public void loadDataAndShowLoadingDialog() {
        //Show loading dialog
        //Load data
        //Hide loading dialog
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        ArrayList data = (ArrayList)myData;
        outState.putSerializable("myData", data);
        super.onSaveInstanceState(outState);
    }

    @Override
    protected void onDestroy() {
        dismissDialog(LOADING_DIALOG);
        super.onDestroy();
    }
}

In the onDestroy() method the loading dialog is dismissed just to be sure there is only one loading dialog of this kind available on the UI thread. Otherwise the issue could still remain!

Conclusion
Which of both methods is best to be used? In fact there is no correct answer. Both will work, and both have there advantages and disadvantages so it’s up to you. What do you want? Keep your code clean and solve the issue more globally then go for solution one. Are you willing to get your hands dirty and have more control on the issue (what data should be reloaded and what data shouldn’t then go for solution 2.

Threading in an Android application? Indeed, and here’s why. In Android if you want to show a loading dialog while you are loading some data from let’s say a web service (which can take some time to finish as you are not entirely sure what kind of internet connection is available on the device) you have to start using threading. The reason why you have to use threading for it is because the loading dialog needs to be updated all the time (with a percentage, some graphical circle that goes around etc) and at the exact same time you want to get your data from your service.So here is how I originally implemented it in the MyEpisodes Manager project:

public class EpisodesWatchListActivity extends Activity {
        private Runnable viewEpisodes;

        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.watchlist);
            //Do some other stuff on creation
            reloadEpisodes();
            //Do some other stuff on creation
        }

        private void reloadEpisodes() {
		showDialog(EPISODE_LOADING_DIALOG);
		viewEpisodes = new Runnable() {
			@Override
			public void run() {
				getEpisodes();
			}
		};

		Thread thread =  new Thread(null, viewEpisodes, "EpisodeRetrievalBackground");
		thread.start();
        }

	private void getEpisodes() {
		try {
			episodes = myEpisodesService.retrieveEpisodes(episodesType, user);
		} catch (InternetConnectivityException e) {
			String message = "Could not connect to host";
			Log.e(LOG_TAG, message, e);
			exceptionMessageResId = R.string.internetConnectionFailureReload;
		} catch(FeedUrlParsingException e) {
			String message = "Exception occured:";
			Log.e(LOG_TAG, message, e);
			exceptionMessageResId = R.string.watchListUnableToReadFeed;
		} catch (Exception e) {
			String message = "Exception occured:";
			Log.e(LOG_TAG, message, e);
			exceptionMessageResId = R.string.defaultExceptionMessage;
		}
		runOnUiThread(returnEpisodes);
	}

	private Runnable returnEpisodes = new Runnable() {
            //Update the view (input fields, lists,...)
            dismissDialog(EPISODE_LOADING_DIALOG);
        }
}

A little explanation of what will happen and why:

• On creation of the activity the method to (re)load the data is called.
• Next the dialog is started on the current thread (which is also known as the UI-thread).
• Now we’ll create a Thread in which the actual data will be retrieved, to make things a bit more understandable we created a separate method for purpose.
• After the data is loaded in the application we still have two things left to do, first of all the view must be updated with the new data loaded, next the loading dialog should be hidden. And here happens a little magic.  In your entire application there will be only one thread which you can use to update the view, this thread we call the UI-thread. Therefore we can use the runOnUiThread(Runnable runnable) method available in the Activity super class.
• In this runnable-instance we should first update the view and when it’s all done we should dismiss the dialog (or in other words just close the dialog)

Now because this looks like one big mess Android came up with a simple solution, called AsyncTasks. I’ve re-written the previous example to fit in with the AsyncTasks and suddenly it looks a lot more clean. See the example here:

public class EpisodesWatchListActivity extends Activity {
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.watchlist);
            //Do some other stuff on creation
            reloadEpisodes();
            //Do some other stuff on creation
        }

        private void reloadEpisodes() {
            AsyncTask asyncTask = new AsyncTask() {
                @Override
                protected void onPreExecute() {
                    showDialog(EPISODE_LOADING_DIALOG);
                }

                @Override
                protected Object doInBackground(Object... objects) {
                    getEpisodes();
                    return 100L; //In my case I do not need a return value so I return some default value!
                }

                @Override
                protected void onPostExecute(Object o) {
                    updateView();
                    dismissDialog(EPISODE_LOADING_DIALOG);
                }
            };
            asyncTask.execute();
        }

	private void getEpisodes() {
		try {
			episodes = myEpisodesService.retrieveEpisodes(episodesType, user);
		} catch (InternetConnectivityException e) {
			String message = "Could not connect to host";
			Log.e(LOG_TAG, message, e);
			exceptionMessageResId = R.string.internetConnectionFailureReload;
		} catch(FeedUrlParsingException e) {
			String message = "Exception occured:";
			Log.e(LOG_TAG, message, e);
			exceptionMessageResId = R.string.watchListUnableToReadFeed;
		} catch (Exception e) {
			String message = "Exception occured:";
			Log.e(LOG_TAG, message, e);
			exceptionMessageResId = R.string.defaultExceptionMessage;
		}
	}

	private void updateView() {
            //Update the view (input fields, lists,...)
        }
}

I hope you notice that this code is a lot more easier to read than the previous. What it does:

• First of all a new AsyncTask gets instantiated and implemented.
• The method doInBackground(Object… objects) is the only that must be implemented. So the name already tells you that this is the method that will start a new thread and execute some stuff you define in that thread. In our case the data gets loaded from a web service.
• Next we also have to implement the onPreExecute() method in order to be able to start the loading dialog.
• And off course the onPostExecute(Object e) method which will hide the loading dialog when the data is loaded.
• As you see the runOnUiThread(Runnable runnable) has been removed from the getEpisodes() method but everything done in this method has been moved the onPostExecute(Object e) method as this last mentioned method will not run in a seperate thread but on the UI-thread itself!

I also created a sample Android project called ‘LoadingDialogsAndThreading’ which you can find it on Google Code in the my-android-samples project.
It’s easy, not a lot of work to change your code and it makes it lot more readable for other developers. So definitely something to look into!

Whether or not to update a widget

So what are the riks… For defining the risks of a widget we first have to dive a little into widget development. Upon creating the widget you probably first start the designing of the widget. When that’s finished two files need to be created. One XML file containing the appwidget-provider-tag and one Java file extending the AppWidgetProvider class, we’ll just call this the widget provider class.
In the XML file you have to define android:updatePeriodMillis.
The Java file for the widget provider needs to override some methods from it’s super class. One of the methods is the onUpdate(…) method. Now what we need to know right here is that the update triggered from the XML configuration always triggers the onUpdate(…) method from it’s widget provider class.
Now we know enough to get into troubles. Let’s say you are creating a very simple widget which just displays the current date and time. For the time we will only show the minutes, not the seconds. At first sight you would set the updatePeriodMilis for the widget to update every minute, so set it to 60.000 milliseconds. The update method from the widget provider class will be called and you will be able to update what the user can see. Although this is where it all goes wrong and lot’s of unnecessary battery life will be lost. One of the reasons why battery life gets lost is because the updatePeriodMilis will always trigger the display of the device to light up. Not really a good idea if you know that the display is one of the most battery consuming parts of a device. Another reason not to do so is because there will be constantly code being running in the background of the device, imagine that you also want to show the seconds on your simplistic clock? That would almost kill the battery as the devices will never know any rest!

There are better ways to decide to update the widget. In some cases you can just use a button. If the user presses a button, you update the widget, otherwise nothing happens. Off course that’s not always the use-case you want as you sometimes may want to display let’s system information. Updates on the wifi status for example. Well there is a solution for these use-cases also! Android provides system updates on the GPS, wifi, clock,… An application or better an activity can register for updates on those system-services. As soon as there is an update your activity will be warned and you can start updating the widget.

Updating the content

So far so good, but there is still something I want to warn you about when it comes to updating the GUI of a widget from within an activity or a service. First off all let’s have a look at the code to update the layout. Let’s say we have on the widget three labels available, with the according id’s of label1, label2 and label3. Not that hard
RemoteViews rv = new RemoteViews(context.getPackageName(), WIDGET);
rv.setTextViewText(R.id.label1, "the new text");
ComponentName cn = new ComponentName(context, YourActivity.class);
AppWidgetManager mgr = AppWidgetManager.getInstance(context);
mgr.updateAppWidget(cn, rv);
Now this should work right out of the box. But what if you want to update more than one label (or button or image or whatever you want to update) at once? You could easily just run the above block of code for 2, 3 or even 4 times. Not a big deal. Although when doing so you might run into problems. Buttons available on the widget might stop working suddenly, just because of using different RemoteViews! The best thing is to do it all in one block of code just like this:
RemoteViews rv = new RemoteViews(context.getPackageName(), WIDGET);
rv.setTextViewText(R.id.label1, "text for label1");
rv.setTextViewText(R.id.label2, "text for label2");
rv.setTextViewText(R.id.label3, "text for label3");
ComponentName cn = new ComponentName(context, YourActivity.class);
AppWidgetManager mgr = AppWidgetManager.getInstance(context);
mgr.updateAppWidget(cn, rv);
This block of code shouldn’t cause any troubles. So remember each time that you want to update your widget to do it all at once, and not in different blocks of code!

What SQL is…

SQL means Structured Query Language and is used to query databases. Using this language it is possible to create, read, update and delete data (also known as the CRUD-operations) in a database and to retrieve data from it. This language is used to query the most common databases such as Microsoft SQL Server, MySQL, SQLite, DB2,… (all relational databases). In relational databases, I assume you all know what that is, you can easily query data from different tables in the same SQL-statement (one CRUD operation). Therefor you will mostlikely use JOIN or WHERE clauses.

I’ve prepared some easy examples which you should understand before continue to read this article:
A simple insert statement:
INSERT INTO mySimpleTable (column1, column2) VALUES ('1', 'test');
Then the syntax of an INSERT-SELECT is:
INSERT INTO mySimpleTable (column1, column2) SELECT mst.column1, mst.column2 FROM mySourceTable mst;

About my problem…

Those queries all go nice and smooth but the problems started for me when using JOINS in the FROM-clause. What I always did was something like this:
INSERT INTO mySimpleTable (column1, column2, column3) SELECT FROM sourceTableOne sto LEFT OUTER JOIN sourceTableTwo stt ON sto.id LIKE stt.stoID;
At first this doesn’t seem to be a very bad query (maybe DB admins already see the problem but I, as a software engineer, didn’t). What happens here is that this query selects some records from sourceTableOne and the according data from sourceTableTwo. The linkage between two tables is based on the ID of sourceTableOne which is of datatype int or bigint. And there the problems begin. To compare the id and reference ID (FK) with each other I used LIKE all the time. Why? Because like just works for comparing everything (int, bigint, text, ntext, varchar, nvarchar,…). In my case (with the 18.000 records to query) this statement took more than 30 minutes to execute which slowed down my entire migration process. I had to find a solution to get around this, so why not find the problem first.

The solution…

I just have to admit, altough I don’t like to praise Microsoft, that SQL Server 2005 Express Edition has a pretty good Query analyzer (or whatever it is officially named). That learned me that it was the JOIN with sourceTableTwo that took this long. So I started playing a bit with the query and noticed that the problem is the LIKE comparator. I used because I wouldn’t have troubles comparing different data types (integer, varchar, nvarchar,…) so also in case that the columns had to match exactly I used the LIKE comparator.

Little sidenote: The LIKE comparator has been added to SQL so that filtering on a column of which you don’t exactly know what values it should contain got a lot easier. You could do this with a SQL statement like this: select * from A where myColumn LIKE 'ABC%'. This selects all data from table A where the values in column myColumn start with ‘ABC‘.

Altough in SQL the LIKE comparator is much more slower than the equals (=) comparator. Replacing LIKE with the equals (=) symbol it only takes me 3 seconds to execute that exact same query.

And yet another problem… and solution!

Now let’s extend the query which runs in about 3 seconds with a subquery:
INSERT INTO mySimpleTable (column1, column2, column3) SELECT  FROM sourceTableOne sto LEFT OUTER JOIN sourceTableTwo stt ON sto.id = stt.stoID WHERE sto.id IN (SELECT id FROM sourceTableOne WHERE value1 > 10);

Again this query runs way much longer than 3 seconds just by adding an extra subselect.  You could replace this query with a HAVING subquery, which would seriously improve performance.
INSERT INTO mySimpleTable (column1, column2, column3) SELECT  FROM sourceTableOne sto LEFT OUTER JOIN sourceTableTwo stt ON sto.id LIKE stt.stoID WHERE sto.id HAVING (SELECT * FROM sourceTableOne WHERE value1 > 10 AND id LIKE sto.id);

Conclusion

So pay attention to following two points in writing queries that handle a massive load of data:

• For an exact match in a JOIN or WHERE clause always use the equals symbol (=) and not LIKE
• Searching for a value in a list don’t use IN but instead try HAVING

But also know the equals symbol (=) can be used for comparing most fields, even with different data types, for example integer and varchar. , but not for all. Not for text and ntext!

Applicatie ontwikkeling op Android staat nog min of meer in zijn kinderschoenen gezien de jonge leeftijd van Android maar wordt wel perfect ondersteund door Google. Zo ben ik zelf aan de slag gegaan om in Java een eigen applicatie te bouwen. ‘MyEpisode Watch List’ is de naam van de applicatie en is sinds een week gratis te verkrijgen op de Android Market. MyEpisodes.com is een website waar je gratis kan registreren en zo een lijst bijhouden van welke afleveringen van bepaalde series je nog moet downloaden/bekijken. Deze mobiele applicatie haalt een lijst op van alle nog te bekijken afleveringen en als je één van bekeken hebt kan je ze meteen markeren als ‘bekeken’. De status van elke episode wordt geupdated op MyEpisodes.com telkens bij het veranderen van een status naar ‘bekeken’. De applicatie is momenteel enkel beschikbaar met een Engelstalige layout maar in de toekomst komt daar zeker nog een Nederlandstalige layout voor!

Een super groot success kan je applicatie niet noemen (en dat had ik persoonlijk ook nooit verwacht). Maar als geregistreerd Android developper kan je nagaan hoeveel mensen je applicatie ooit geïnstalleerd hebben en hoeveel mensen er actief gebruik van maken. Tot mijn grote verbazing (ik had al blij geweest had ik er op één week tijd 100 downloads en wat minder actieve gebruikers gehad) hebben reeds 199 mensen de applicatie gedownload en heb ik momenteel 102 actieve gebruikers van de applicatie.

Mobile development is the future of application development. Dat is mijn standpunt tegenover applicatie ontwikkeling. Smartphones zoals de iPhones, Palm, Android,Symbian,… krijgen steeds een groter marktaandeel in de mobiele communicatie markt. Dat grotere aandeel in combinatie met de steeds groter wordende mogelijkheden op zo’n toestel maakt dat we er binnenkort alles kunnen op doen en dat bedrijven Smartphones ook kunnen gaan gebruiken om bepaalde van hun business problemen op te lossen.
But no mobile development without the good-old application development. Computers zullen echter nooit te vervangen zijn door Smartphones en application development is daarom zeker en vast niet dood. Er is al lang een markt voor mobile development maar deze markt wordt nu steeds sneller groter en groter en dat maakt dat het nu het ogenblik is dat er moet ingespeeld worden op een extra markt.

Om makkelijker te werken en gebruik te kunnen maken van alle tien je vingers komt 10/GUI met het idee af om niet enkel de muis in de vuilbak te smijten maar zelfs volledig af te stappen van het werken met venster die elkaar kunnen overlappen, kunnen worden versleept,… Wat 10/GUI in zijn video voorstelt is om te werken met een soort van touch plate waar je handen opliggen en waarmee je de computer bedient. De vingertoppen die het oppervlak raken worden dan op het scherm als kleine cirkels. Zo win je qua zichtbaarheid de oppervlakte die anders door de handpalmen wordt bedekt en heb je meer bereik op het scherm dan met een muis. Daarnaast werkt 10/GUI niet met de venster zoals deze gekend zijn in onze huidige besturingssystemen maar met venster die altijd de volledige hoogte van je scherm bedeken, en slecht een gedeelte van de breedte. Bij het openen van een tweede scherm komt dit er niet over te staan maar ernaast. Door gebruik te maken van al je vingers kan je dan door de horizontale lijst scrollen, vensters selecteren en vensters verplaatsen. Voor het werken in een programma maakt het ook niet uit welke vinger(s) je gebruikt om bijvoorbeeld een menu te openen. De vinger die het dichtste bij is gebruik je gewoon om naar de plaats op het scherm te gaan waar dit nodig is. Het demo filmpje is zeker de moeite waard om een te bekijken. Ik geloof zelfs dat hier potentieel in zit.

Of de muis door deze nieuwe technologie volledig afgedaan zou hebben is maar zeer de vraag. Het gebruik van een 10/GUI systeem lijkt op het eerste zicht heel handig en ik geloof er ook in dat dit ook zo is. Maar stel je voor met een laptop dat je (ipv van je muis) steeds een soort van touch plate moet meeslepen zoals het voorbeeld ook wordt gegeven in de video. Makkelijk is zeker anders. Stel dat deze technologie ooit aanslaat zal de muis wel blijven bestaan. 10/GUI zal zich vooral focussen op desktop gebruikers in plaats van laptop gebruikers.