So, the problem was thus: I have my main activity that checks for the existence of a location provider before it transfers the user to a different activity. After it is satisfied that the GPS is in fact enabled, it continuously grabs a location from it until the accuracy is less than or equal to ten feet. Once both of these conditions are met, it passes control to the next activity. Overall, its a very simple task, but I wanted to keep my main activity from having to implement the LocationListener interface to accomplish it. Not only do I feel its a good separation of concerns to put the LocationListener onto its own class, but it also keeps the code for the main activity much more simple. Which is always good.

So, I created a new class that I called LocationProvider. It implemented the LocationListener interface, and in the constructor set up a new LocationManager, told it to start updating itself, and the created a new Location from the updates. I also added a few methods to the class to cycle the location updates until the given accuracy was achieved. Simple enough. But, a problem arose. I could not call the method getSystemService() without an activity context, meaning my entire class scheme would not work.

But, a simple problem in this case, luckily required a very simple solution: pass the context from the main activity into the LocatoinProvider object in the constructor, and then call context.getSystemService(). Beautiful, works like a charm. My class now knows just enough to initialize the GPS, refine the accuracy, and then spit the latitude and longitude back to the main activity.

For the curious, and to further illustrate my point, heres the relevant code from my project:

// Make sure the GPS fix is sufficiently accurate
// Set up a progress spinner to display while an
// accurate fix is achieved.
spinnerDialog = ProgressDialog.show(Pinpoint.this, "",
		"Waiting for accurate (> 10 meters)" +
                "GPS coordinates...Please wait. ", true);

//Create a new instance of LocationProvider,
//which implements LocationListener
//Pass in the current activity context, so
//LocationProvider can access system services
locProvider = new LocationProvider(Pinpoint.this);

// Thread handles refreshing the GPS until desired
// accuracy is achieved
new Thread(new Runnable() {
          public void run() {
          locProvider.getCurrentLocation();
          spinnerDialog.dismiss();
          return;
     }
}).start();

//Once the GPS has sufficient accuracy,
//Create an intent to launch the new location activity
Intent createLocationIntent = new Intent(
     Pinpoint.this, CreateLocation.class);
startActivity(createLocationIntent);

So, there you have it, a dead simple approach to separate concerns in your Android project.

After some thought on how best to accomplish this without pissing off the user (nobody likes an application that seems to hang, even if there is something ticking in the background), I settled on displaying a ProgressDialog to let the user that something is indeed happening, and they can continue once its done.

So, after reading up on this particular dialog, I found that there are two flavors: indeterminate and non-indeterminate. The non-indeterminate variety shows a progress bar, and can be handy when you have something measurable to load. The indeterminate variety simply shows a spinner with a message, and is therefore good for non-measurable load times. For my situation, the indeterminate variety is fine.

So, choice in hand, I set out to write some code. My first draft looked like this:

ProgressDialog spinnerDialog = ProgressDialog.show(
	Placeholder.this, "",
	"Waiting for accurate (> 10 meters) GPS coordinates...Please wait. ", true);
refineGPSAccuracy();
spinnerDialog.dismiss();

The ProgressDialog takes four arguments: a context, a title (which Ive left blank), the message to be displayed, and whether or not the spinner is indeterminate. After creating one of these, I call my method, and once thats done, dismiss the spinner. Pretty simple, right? Well, yes, but the problem is that the code as we have it won’t work. If you tried to run this, your method would fire off, the app would hang until the method returned, and your spinner would be nowhere to be seen.

Why is this? Well, the quick answer is, calling the method is blocking the UI thread, meaning that your nice dialog will not show up until the method has returned, at which point we dismiss the dialog. So, how do we get around this? Create a thread for the method to run in. This way, it won’t block the main UI thread, and our spinner will be displayed in all its glory.

Version 2 of my code looked like this:

ProgressDialog spinnerDialog = ProgressDialog.show(
	Placeholder.this, "",
	"Waiting for accurate (> 10 meters) GPS coordinates...Please wait. ", true);
new Thread(new Runnable() {
	public void run() {
		refineGPSAccuracy();
		spinnerDialog.dismiss();
		return;
	}
}).start();

So, essentially, all we’re doing is setting the actual logic aside into its own thread, and once that method returns, dismissing the spinner (as the work is done, and the user should be able to interact with the app again), and killing the thread. Simple as that.

The first obvious thing we need is an idea of what our widget is going to do. In my case, my app widget toggles on the camera LEDs (on the Moto Droid/Milestone).  Not too complicated. So, what do we want to happen when we push the widget? Well, the LED’s need to either come on or turn off, and also the little flashlight icon should switch between lit and unlit respectively.

So, with this in mind, now we need to actually set up our application to use a widget. For brevitys sake, Ill let the good folks over at google cover this topic, as they already have a good write-up/tutorial on how its all done (written much better than I could too). The link to the Widget tutorial is here.

Once you have your application set up to support a widget, the next step we need to do is to hook our widget up to our existing code to allow the user to interact with our main application from their home screen. Lets first focus on calling our method to toggle the lights on and off. We need to somehow get our widget to register when the user clicks on it. Since app widgets are slightly different than other widgets within Android, we cannot just attach an onClickListener to our widget and go. We need to instead use a RemoteViews object. The Android documentation defines a RemoteViews as a “class that describes a view hierarchy that can be displayed in another process”.

private RemoteViews views = new RemoteViews("com.test.widgetTest", R.layout.widget);

Our RemoteViews object takes two arguments, the package name, and the layout to use in the object. This object will allow us to connect an onClickListener to our widget. Before we do that however, we need to specify a new intent for our onClickListener to start. We will also need to create a PendingIntent to store our new intent.

Intent intent = new Intent(context, Widget.class);
intent.setAction(ACTION_WIDGET_RECEIVER);
PendingIntent pendingIntent = PendingIntent.getBroadcast(context,
					0, intent, 0);

For our intent, we need to supply a context and a target activity. In this case, the target activity is the widget class, the same class we are currently working in. Why we are doing this will be explained in a moment. We also need to set an action for the intent, and in this case we have chosen ACTION_WIDGET_RECEIVER, which we will use in the onReceive() method when a user clicks on the widget. Finally, we set up our pending intent with the intent we just created, but we set it to broadcast, rather than start a new activity.

The next step we need to take is to set up our onClickReceiver using our RemoteViews object.

views.setOnClickPendingIntent(R.id.toggle_button_widget, pendingIntent);

We use the setOnClickPendingIntent() method to set our widget to use our pending intent whenever the user clicks on it. For the purposes of this tutorial, I have used an ImageView in my widget layout called toggle_button_widget.

So, now that we have our onClick all set up, lets make it do something when a user clicks on it. As I mentioned earlier, our intent broadcasts to our widget class. What this means is that whenever the widget is clicked on, it sends a broadcast to itself, which automatically triggers the widgets onReceive() method. It is in the onReceive() method where we will do the appropriate action (in this case toggle the lights on or off).

Earlier, we set the action of our intent to ACTION_WIDGET_RECEIVER. One of the first things we want to do is check to see which action was broadcast in our intent. This can be accomplished using a simple if statement (or possibly a switch if you have multiple cases):

if (intent.getAction().equals(ACTION_WIDGET_RECEIVER)) {
}

By using this sort of check at the start of our method, we can handle multiple types of broadcasts if need be, but for our example we’ll only be using one. Once we are sure that the action that was sent is the action we want, we can then set up our logic to flip the lights on or off. This might look something like this:

@Override
public void onReceive(Context context, Intent intent) {
     if (intent.getAction().equals(ACTION_WIDGET_RECEIVER)) {
          try {
               led = new FlashlightLED();
               led.toggleLight();
          }
     }
     super.onReceive(context, intent);
}

Thats all we need to do to get our widget to toggle a value in our main application! Pretty simple, whenever the widget is clicked, it calls its own onReceive() and then runs the appropriate logic. But while thats all well and good, when our light is on, the image on the widget is the same as if it were off, which can be confusing. The next thing we want to do is to change the image on the widget according to the state of our light.

I’m going to put a disclaimer in at this point: The following method, while it will work fine, is probably not the best way to go about this, but it is, at the time of this writing, the only way I have found to accomplish this. Please chime in in the comments if you know of a better way.

What we basically need to do is to change the image that is stored in our ImageView, toggle_button_widget, and then update the widget to reflect our new changes. Since we have our widget layout stored in a RemoteViews object, the first step, physically changing the image, is fairly easy:

views.setImageViewResource(R.id.toggle_button_widget, R.drawable.flashlight_lit);

All we are doing here is finding the ImageView in our RemoteViews object and updating its value. Next, we need to update the widget to reflect our changes. To do this, we create a ComponentName object, which takes the context, and the class, in our case our widget class. We can then use this ComponentName object, along with our RemoteViews object to update the widget:

ComponentName cn = new ComponentName(context, Widget.class);
AppWidgetManager.getInstance(context).updateAppWidget(cn, views);

It should be noted here that if the user has more than one instance of the widget active on their screen, this will update all of them simultaneously. This makes sense for my widget, as if the light is on, all the instances of the widget should reflect this fact.

So, now that we can update the image each time the light is toggled, our onReceive() method could look something like this:

@Override
public void onReceive(Context context, Intent intent) {
     if (intent.getAction().equals(ACTION_WIDGET_RECEIVER)) {
          try {
               led = new FlashlightLED();
               led.toggleLight();
               if (led.isEnabled()){
                    views.setImageViewResource(R.id.toggle_button_widget, R.drawable.flashlight_lit);
                    ComponentName cn = new ComponentName(context, Widget.class);
                    AppWidgetManager.getInstance(context).updateAppWidget(cn, views);
               }else{
                    views.setImageViewResource(R.id.toggle_button_widget, R.drawable.flashlight_off);
                    ComponentName cn = new ComponentName(context, Widget.class);
                    AppWidgetManager.getInstance(context).updateAppWidget(cn, views);
               }
          }
     }
     super.onReceive(context, intent);
}

And the full code for our widget might look something like this:

public class Widget extends AppWidgetProvider {
     private static final String ACTION_WIDGET_RECEIVER = "ActionRecieverWidget";
     private RemoteViews views = new RemoteViews("com.test.widgetTest",
			R.layout.widget);

     public void onUpdate(Context context, AppWidgetManager appWidgetManager,
			int[] appWidgetIds) {
		final int N = appWidgetIds.length;

		// Perform this loop procedure for each App Widget that belongs to this
		// provider
		for (int i = 0; i < N; i++) {
            int appWidgetId = appWidgetIds[i];
            Intent intent = new Intent(context, Widget.class);
            intent.setAction(ACTION_WIDGET_RECEIVER);
            PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

            views.setOnClickPendingIntent(R.id.toggle_button_widget, pendingIntent);

            // Tell the AppWidgetManager to perform an update on the current App
           // Widget
			appWidgetManager.updateAppWidget(appWidgetId, views);
     }

     @Override
     public void onReceive(Context context, Intent intent) {
          if (intent.getAction().equals(ACTION_WIDGET_RECEIVER)) {
               try {
                    led = new FlashlightLED();
                    led.toggleLight();
                    if (led.isEnabled()){
                         views.setImageViewResource(R.id.toggle_button_widget, R.drawable.flashlight_lit);
                         ComponentName cn = new ComponentName(context, Widget.class);
                         AppWidgetManager.getInstance(context).updateAppWidget(cn, views);
                    }else{
                         views.setImageViewResource(R.id.toggle_button_widget, R.drawable.flashlight_off);
                         ComponentName cn = new ComponentName(context, Widget.class);
                         AppWidgetManager.getInstance(context).updateAppWidget(cn, views);
                    }
               }
          }
          super.onReceive(context, intent);
     }
}

And there you have it! A simple, lightly interactive homescreen app widget for Android.

The set up: I was trying to include into my application a ListPreference object, which basically just creates a dialog with a list of selectable items in it for use with a PreferenceActivity. Quite handy, particularly if you need to let the user select from more than one option, say, for an update timer or similar.

So, I set up my preferences page thusly:

Nothing fancy here, except to note that the ListPreference takes a couple additional arguments, namely entries, which is an array of human readable values, and entryValues, which is an array of data values that each correspond to the values in entries.

Next, I set up a PreferenceActivity to create my preferences page:

public class Prefs extends PreferenceActivity {

	private static final String OPT_TIMER = "set_timer";
	private static final String OPT_TIMER_DEF = "5";

	@Override
	protected void onCreate(Bundle savedInstanceState){
		super.onCreate(savedInstanceState);
		addPreferencesFromResource(R.xml.settings);
	}

	public static String getTimer(Context context) {
		return PreferenceManager.getDefaultSharedPreferences(context)
		.getString(OPT_TIMER, OPT_TIMER_DEF);
	}

}

Okay, at this point, we should be all set up to start using our preferences…or at least we would be if there weren’t a bit of bug with the current release of Android. If you were to run this code right now, with your two arrays, entries and entryValues set up in a resource file, chances are you would get a null pointer exception. How can that be possible though, since technically, nothing we’ve written is even doing anything? Its all relying on the underlying Android framework at this point…

Well, as it turns out, we can track this issue back the arrays we are using. When I first set up my preferences page, I built two arrays that looked like the following:

	
		1 minute
		2 minutes
		5 minute
		10 minutes
	
	
		1
		2
		5
		10
	

As you can see, one is an array of String, while the other is an array of int. This is where the bug lies. The ListPreference object does not support type mismatches on the two arrays it needs. If we were to change the above code to:

	
		1 minute
		2 minutes
		5 minute
		10 minutes
	
	
		1
		2
		5
		10
	

...Where both arrays are of type String, the null pointer exception goes away, and everything chugs along just fine. This really is only a minor, if not perplexing bug, as it is not a big deal to cast a string into an int. But, as I stated earlier, I felt it was worth bringing up, if only to save some fellow programmers some of the headaches I endured trying to figure it out.

The official bug report can be found here.

Lets say you have two activities. The first one, A, has a button that opens up the second activity, B. B, in turn has a button that returns the user to activity A. So, if you were to push the button in activity A, you would end up in activity B and vice versa. Pretty straight forward.

Now, lets say you just pushed the button in activity A, and ended up in activity B. You now want to go back to activity A. Pretty simple, just push the button in B, right? While if we push the button, we do in fact end up looking at activity A again, but it is not, in fact, the same instance of activity A that brought us to B in the first place.

If we think about this from an object oriented standpoint, this makes sense. When we create a new intent to change the activity from A to B and back, Android creates a new instance of the class for each intent. This means that every time we push the button, we are pushing a new instance of either A or B (depending on where we are) onto the stack, rather than re-using the already existing instance that we created previously. For our little sample application detailed here, this really doesn’t matter too much, as there is no difference between a new instance of A and one that has been around for a while.

Say though, that activity A changes state based off of user interaction, for example, the background on the button changes when pressed. If we pressed the button to go to activity B, and from B pressed the button to activity A, we would see no change on our button, even though we pressed it to get to B. This is because, as described above, when we press the button in B to go to A, a new instance of A is created, meaning that our original A is pushed deeper into the stack by the new A, and all state changes in the original A are not reflected in the new A.

This problem is easily solved through the use of a “launchmode” for the desired activity. A launchmode dictates what happens when an activity is launched. In this case, this means when we create a new intent and call startActivity() on said intent. There are four types of launchmodes: standard, singletop, singletask, singleinstance. For simplicities sake, Im going to ignore the last two and focus on the first two.

The default launchmode for an activity is standard (makes sense). Standard means that when a new intent for the activity is created, a new instance is created of the activity, even if one already exists on the activity stack. This is what creates the behavior outlined above when transferring between activity A and B. Even though we already have an instance of A on the top of the stack, when we use B to return, Android creates a new instance of A.

The second launchmode is singletop. This launchmode first looks to see if there is already an instance of a matching activity on the top of the stack, and if so, it uses the exsiting instance in the new intent rather than create a new instance. This is exactly what we would need if we wanted A to reflect state changes upon returning from B, as we would be recycling the original instance, rather than creating a new one each time.

All of this launchmode goodness happens in the applications AndroidManifest.xml file, within each individual activity declaration. The code would look like this:

You can read more about launchmodes here.

Thankfully, there is a much simpler way to figure out distances between two points on a map: the distanceTo() method in the Location class. Using this handy little method, we can quickly find out the distance between two locations:

double distance;

Location locationA = new Location("point A");

locationA.setLatitude(latA);
locationA.setLongitude(lngA);

Location locationB = new Location("point B");

locationB.setLatitude(latB);
LocationB.setLongitude(lngB);

distance = locationA.distanceTo(locationB);

One thing to note is that the distanceTo() method returns the distance in meters, so you will need to do the appropriate calculations if you want your distances in other units.

To start with, we need a locationManager object:

LocationManager locManager = (LocationManager) getSystemService(LOCATION_SERVICE);

Now that we have a location manager, its a simple process to check to see if the GPS is enabled or not:

if (!locManager.isProviderEnabled(LocationManager.GPS_PROVIDER)){
      createGpsDisabledAlert();
}

This just checks to see if GPS is on, and if not, it calls a method, createGpsDisabledAlert(), which will build an alert dialog to warn the user that their GPS is off:

private void createGpsDisabledAlert(){
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Your GPS is disabled! Would you like to enable it?")
     .setCancelable(false)
     .setPositiveButton("Enable GPS",
          new DialogInterface.OnClickListener(){
          public void onClick(DialogInterface dialog, int id){
               showGpsOptions();
          }
     });
     builder.setNegativeButton("Do nothing",
          new DialogInterface.OnClickListener(){
          public void onClick(DialogInterface dialog, int id){
               dialog.cancel();
          }
     });
AlertDialog alert = builder.create();
alert.show();
}

If the user decides they want to turn their GPS on, and they select the positive action of the dialog, showGpsOptions() is called. All this method does is to show the “Locations and Security” page from the Android settings menu. As a small sidenote, as of Android 1.5, there is no way to directly toggle the location settings through code, so we have to assume the user can figure it out if shown the proper screen. The code for showGpsOptions() is very simple:

private void showGpsOptions(){
		Intent gpsOptionsIntent = new Intent(
				android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS);
		startActivity(gpsOptionsIntent);
	}

And thats it! When the user starts the activity, if the GPS is off, the dialog will pop up asking them what they want to do. If the GPS is already on, nothing will happen. Sweet. The full code looks like the following:

protected void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     setContentView(R.layout.main);
     LocationManager locManager = (LocationManager) getSystemService(LOCATION_SERVICE);

     if (!locManager.isProviderEnabled(LocationManager.GPS_PROVIDER)){
          createGpsDisabledAlert();
     }
}

private void createGpsDisabledAlert(){
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Your GPS is disabled! Would you like to enable it?")
     .setCancelable(false)
     .setPositiveButton("Enable GPS",
          new DialogInterface.OnClickListener(){
          public void onClick(DialogInterface dialog, int id){
               showGpsOptions();
          }
     });
     builder.setNegativeButton("Do nothing",
          new DialogInterface.OnClickListener(){
          public void onClick(DialogInterface dialog, int id){
               dialog.cancel();
          }
     });
AlertDialog alert = builder.create();
alert.show();
}

private void showGpsOptions(){
		Intent gpsOptionsIntent = new Intent(
				android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS);
		startActivity(gpsOptionsIntent);
}

public class DirectoryTest extends Activity {

     private static final String TAG = "DirTest Output:";

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        File sddir = new File("/sdcard/testDirectory");

        if (sddir.mkdirs()) {
             Toast toast = Toast.makeText(this,
             "Directory successfully created!",
					Toast.LENGTH_SHORT);
	     toast.setGravity(Gravity.CENTER, 0, 0);
	     toast.show();
        }else{
             Log.e(TAG, "Create dir in sdcard failed");
             Toast toast = Toast.makeText(this,
             "Directory creation failed!",
 					Toast.LENGTH_SHORT);
 	     toast.setGravity(Gravity.CENTER, 0, 0);
 	     toast.show();
        }
    }
}

Like I said, pretty simple. We create a new file object with the path to the SD card, which happens to just be /sdcard, and then we call the mkdirs() method, which will create all the directories along the chain we specified in our File object. Nice and easy.