Slow Improvement

Aha! It gets better - I have not only discovered that it is possible to make the calendar appear, not just the day/month/year spinners; I have also discovered a method called onDateSetListener. I've even found out how to make a value (like "Yes, a date has been picked") persist from one session to the next.

The calendar thing I'm going to just make note of for now - remembering as I said back here that as long as it works, prettiness comes later.

The method onDateSetListener might explain some of the problems I've had with onClickSetListener - it wasn't quite the right method for what I was doing. I'll try replacing it based on what I've found at the Android Developers' forum and Stack Overflow.

So from

WeddingDate = (DatePicker)findViewById(R.id.datepicker) 

WeddingDate.setOnClickListener(this);

I now have:

WeddingDate = (DatePicker)findViewById(R.id.datepicker);
        mDatePicked = new DatePickerDialog.OnDateSetListener() {
@Override
public void onDateSet(DatePicker view, int year, int monthOfYear,
int dayOfMonth) {
// TODO Auto-generated method stub } 

I think that's progress, of a sort? At least, Eclipse isn't flagging any major errors, and I can put something into the method stub to cover the last point I mentioned up top - making sure that once a date is picked, the user doesn't have to do it again.

That's where this comes in. Now, the example given isn't quite right - it's for a setting that the user might change at any time, so the setting is re-saved every time the application closes. I want mine to save the setting solely when the user finishes with SSA - if they ever say they want to change the date, I'll get the app to just bring them back to SSA.

So, in WLA I have put

        SharedPreferences settings = getSharedPreferences(WedPrefs,0);

        String WedDate = settings.getString("WedDate", "");

which is aimed at getting together an object called "settings", which in addition to knowing the Wedding Date can also hold other information in future. I've picked my variable names and properties such that they match up with the if block I created here.
Coming back to SSA, where it said //TODO above, I've now got

SharedPreferences settings = getSharedPreferences(WedPrefs,0);

SharedPreferences.Editor editor = settings.edit();

WedDate = String.valueOf(year) + String.valueOf(monthOfYear) + String.valueOf(dayOfMonth);

editor.putString(WedDate);

This still isn't quite right - the string WedDate operates, and becomes year + monthOfYear + dayOfMonth [for example the 19th May 2012 would appear as 2012419* which I think is the easiest way to grab it back out afterwards] but then Eclipse isn't keen on editor.putString(WedDate); and I'm not sure why.

Well, I wasn't. I tried typing it again, and when the tips popped up:

I saw that the putString method requires two separate arguments.
By analogy with the method in WLA, the first argument has to be "WedDate".
Because of the name I've given in SSA, the second argument has to be WedDate. Fortunately one is in "" and the other is not, so that isn't confusing at all!
May want to change one of those names, I'll think about it.


In any case, this has taken a while, but I've nearly finished the initial stage. There are two immediate steps remaining - one, a message to inform the user whether the date is entered successfully, and two, something on the WLA to state whether a date already exists.
Then to build this into the full app, I'll need something to direct the app back from SSA to WLA - if I understand Android convention correctly, that will be automatic as long as I close down SSA correctly.
Then I can start testing it.

*2012419, you say? Yes. 2012 for the year; then Java counts months from 0 to 11, so in spite of being the fifth month May comes out as 4; then 19 for the 19th. I think that the month will show as 4, not 04...
Some systems counting from 0 and others from 1 is the reason for fence-post errors!