Java Adventures

So, this is where I've hit the problem that Java is not a language I'm familiar with.

So that's why this post is a bit late - I've had to delve into some Java resources to figure out how to distinguish my arse from my elbow.

Anyway, I already had:

public class WeddingLogisticsActivity extends Activity {


/** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
}

I'm fairly sure I need to declare a DatePicker (tell the app to expect a DatePicker, and what to call it), so I added

DatePicker WeddingDate;

This means when I refer to WeddingDate, the app knows what I'm talking about.
Then, from looking at example code, (mostly from hackaday which I mentioned before), I need to tell the app what to do with WeddingDate. And...I can't quite figure that bit out yet. More reading required!

Code: Import, Activity, Extend

This next bit is focussed in the source-code folder (src), in a section named WeddingLogisticActivity.java

Eclipse has automatically added in what you see on the left here.

First of all we have the name of the package, which will eventually uniquely identify Wedding Logistics on Google Play.

Then we have the import statements. One analogy for these is academic references - if you write an essay which doesn't show the sources for your statements of fact then your readers will think you're making it up. Well, think of your app as a very sceptical reader - unless every statement is ultimately backed up in a reference [unless every method is in an imported library], it won't believe you [won't be able to execute that method].

The import statements I have already just cover me for the basic operation of the Android Operating System, and for the initial Activity that I'll get to in a moment, so I'll be adding a few, to deal with the Context (the situation on your Android), the View (what's on screen), an OnClickListener (to notice when, say, the user clicks on a button), deal with Buttons, Toast (messages that appear temporarily on screen. So called because they pop-up, I think), and a DatePicker, &c.

I've got the outline of my list from the excellent hackaday.com Android Tutorial and then added one for the DatePicker. Eclipse helpfully highlights all of the import statements I'm not using at the moment

(see the little row of symbols on the left?) so I can remove any unnecessary imports once the code is finished. Equally, as I expand the app, I'm likely to need to add more imports to cover new features.

Then we declare a public class called WeddingLogisticsActivity (henceforth abbreviated to WLA), and that it extends the core Activity.

Just to unpack that a bit - public means that other processes can refer to WLA; class - well, for a full definition of that I'll give you the wikipedia article, but the short version is that it means I could have several examples of WLA, based on the definition of it given here.

As to the bit about extending Activity, well, the Activity is a core Android class which handles some basic stuff for me - saying WLA extends Activity is a way of telling the system I want WLA to start with all the attributes of Activity, and then I want to give it some more.

At present, all WLA does which is apparent to the user is load the screen from last time; however, if the user attempts to enter the date, nothing will happen. If they click Done, nothing will happen. Unfortunately, I'm out of time, so I'll get to rectifying that next time!

Projecting in Eclipse

Starting with Eclipse, we have to start a new project, which is pretty simple:
File > New > Android Project.
I am calling this project Wedding Logistics, though in places where I feel the need to abbreviate that will be WedLog.

Then I have a decision to make; there are various versions of the Android Operating System out there in the wild. The earlier the version I opt for, the more phones will be able to successfully run my app - but the fewer features I'll be able to use.

This calls for a little research; a quick google gets me this graph from Wikipedia.
The figures are a year out of date, and show 90% of users on Android 2.2 and above. Given that new Android phones are on Ice Cream Sandwich (4.0 and up), working in Android 2.2 is ample.
Now, for Eclipse purposes, we need to translate that version number into an Application Programming Interface (API) number. Android 2.2, aka Froyo, is API 8. This means anyone trying to operate my app on APIs 1-7 is out of luck, but I should be okay for 8 and up.

Next thing I have to do is name the package; this is something for when [eventually] I get this thing onto the App store. Every app needs a unique package name, and to guarantee that, the convention is to use your website url followed by the app name. So for me, that is uk.co.blogger.becomingandroid.weddinglogistics for this app. Ungainly, but it'll do.

Now Eclipse will do its magic - it has created a raft of files that I will need as part of the app, and populated them with bits of generic code. This is part of where an IDE saves hassle. Now, as I mentioned last time, the output from Droid Draw can come straight into Eclipse - specifically, under the folder res (for Resources), layout, main.xml
Now here, I'm following the advice from a tutorial I used; I may need to alter it later, but it will do for now.
I go and have a look at the results in Eclipse, and...ah. Oh dear.

There are two errors; and it doesn't look like it did in Droid Draw. I think the problem is that I used an Absolute Layout - it looked neater. I'll try it with a Relative Layout, remembering that this is meant to be fast-and-dirty!

 Now, calendar appearance aside, that's a bit more like it. Also, there not being any major errors, I can go ahead.
There are however some warnings, highlighting possible problems. On this occasion, they're reminding me that I don't need to hard-code the text (like "Welcome to Wedding Logistics 0.1") - it can go in strings instead. I'm going to ignore that this time, because this text is only appearing on this screen, so I don't see any real advantage to putting it in strings for easy re-use.

You'll also notice that I got rid of the second option for entering the date - firstly, this date-selector looks more like what I had in mind for that, and secondly I have changed the note at the end. This will make the code simpler, though I may return to giving users an approximate option on the front screen later.

So, with the extra faff I had to go through with this, I'll be coming back to the actual code in the src folder next time. There will be import statements!