Testing Test...

Spent much of the day going around and around and around in circles. The word is argh.

I begin to wonder whether I should try condensing the app into one view for now, then trying to figure out how to add a second view separately...might be a way to separate out the issues enough to attack them productively.

Source Not Found

I haven't yet found any useful suggestions on dealing with Source Not Found; so, I'm going to take some stabs in the dark and see if any of them result in a scream.

First off, I know that I have said that the warnings aren't that important, as long as there aren't any actual errors. How about I just test that; I comment out the unnecessary import statements [a simple /* on one side and */ on the other does the trick. Alternatively for single lines // works.]

Commenting in this way is a great method to quickly change code around - because if I decide that removing something was a mistake, I just have to uncomment it, not remember how it went and re-type it.

Then the remaining warning is around

private DatePickerDialog.OnDateSetListener mDatePicked;

and how I use it in

mDatePicked = new DatePickerDialog.OnDateSetListener() {

In that Eclipse is telling me that mDatePicked is not used! Um, oops...what's gone wrong here then? I declare mDatePicked, as you see above, then I do some stuff onDateSet.
Now, I have a sneaking suspicion that there's some duplication between these two lines, so let's see what happens if I take one out, leaving

mDatePicked {

 Nope, that errors. Badly. Howabout taking out the first one? Also makes things worse, in that the warning has upgraded to an error.
Aha! Stack Overflow to the rescue! Looks like the whole thing is redundant now I've got

public void onDateSet(DatePicker view, int year, int monthOfYear, int dayOfMonth) {

So I'll just try cutting out the lot, see what I get. No...that causes even more problems. I'm going around in circles here. I believe the technical term is GAH!

Testing, Testing, 1-2-1-2

To test an app, first thing you need is for Eclipse to not report any errors.

Then you need to feel that there is enough of your app complete to be worth testing. For instance, I don't really-truly care about whether the home screen looks right, if all I can do is look at it. I want to know whether it works when I press buttons.

Then you Save All (Ctrl+Shift+S), and finally you go to the green and white Button for "Run Wedding Logistics".

Having already specified a test machine (in my case using the specs for my own Android phone), it should just load up. Be aware though, this step can be veeeery slow.

And...ah. Oh dear:

Well, at least you can see what Toast looks like! As well, of course, as the appearance of the testing software [which is included in Eclipse].

It does occur to me that most programming I've done will talk about de-bugging, and this seemed to be more of a 'run program' option. Hmmm. *Looks around* Aha!

I clicked on this:

I should have gone for this:

The Debug button. Debugging is one of those terms that is more literal than you think - while the origins are obscure, it was popularised in the days of the first computers, vast buildings full of valves such as Colossus or ENIAC. - when it was possible for a bug like a moth to get into the works and cause the machine to behave in unexpected ways. The archetypal bug is pictured here.

I believe my error is linked to the fact that the tutorials from hackaday were with already completed and tested code - so the bit of seeing it work at the end was just the reward. Anyway, now I hit Debug, so I'll see what pops out:

Source not found.

Ah. I have no idea. Will have to come back to this once I've done some more reading.

Finishing touches

As I said last time, I reckon there are two things left to do before I have a module that is worth testing.

First - I want to notify the user when a date is entered successfully. Now, this is not essential in the grand scheme of things, because when the whole app is complete, closing SSA will lead the user to a screen which shows the date (among other things). Whether or not I decide to retain it then, I want to have it now, just so that I know it's working when I test it!

The easiest way to do that is with what is called Toast - I imagine because when it is ready, it pops up! Toast is a kind of message that appears in a little box floating on the screen for a set duration.
Toast has three key components (or 'arguments', in this instance). The Context, being the current state of the application; the Text, being what you want your Toast to display; and the Duration, being how long to display it for.

As usual with Android's imaginative variable names, we get something like this:

Context context = getApplicationContext();

        CharSequence text = "You are getting married on " + WedDate + "!";

        int duration = Toast.LENGTH_LONG;

        Toast toast = Toast.makeText(context, text, duration);

        toast.show();

As you can see, here we will tell people "You are getting married on []!", for a duration of Toast.LENGTH_LONG. I don't know exactly how long that is, but it's a few seconds; certainly long enough to read this message.

Alright, so on to the second thing I wanted to add - and this is probably entirely temporary: a message on WLA to confirm that the app knows the user's wedding date.
I've put exactly the same Toast, just replacing "You are getting married on " with "Your wedding date is ", so that if I close SSA and get back to WLA at the same time as a Toast appears, I will know which Activity is responsible for it.

In both these cases, I already had the import statement - import android.widget.Toast - otherwise I would have to add it before Eclipse would be happy.

Now, bearing in mind that 1) This is one small corner of the planned app, and 2) That it may not even begin to work when tested - it's time to start testing this thing, and see what breaks!