Discipline!

Well, after a rip-roaring stag do (yesh, it was awesome, thank you very much), I need to get back in the groove. I spent most of today reading [yes, on topic reading! Android theory from here mostly], but not a lot of writing.
See if we can't reverse that balance tomorrow.

Further Posting Cancelled

Until Monday, due to the intervention of my stag party.

I'll get back to work (assuming I come home safely!) on Monday, see y'all then.

Making a start

First, a quick reminder of what I decided last time were the core features to aim for:

So some form of calendar function - allowing you to set your date, then keeping track of a countdown; then an ability to enter notes with target completion dates; ability to check back previously created notes; and probably a display with the next few tasks.

Now, there are a variety of ways to approach the next stage. One would be to fire up Droid Draw and plot out the user interface first, then once I'd plotted out how I wanted the thing to look I could work on pulling the back-end together to make it work. Another thing I could do would be to plot out the logical flow of data - where the user enters it, how the app needs to manipulate it, and how it needs to be output.
The third focus which occurs to me is to think in modules of code - a module for note-entering, a module for checking previous notes, a module for displaying priority tasks, a module for the count-down.

Thinking further, however, I realised that working in Droid Draw and with modules of code may be compatible with each other; after all, when you press a button, you want it to do something; so it has to be associated with a bit of code to tell the app "When 'Go!' is pressed, this is what you do," or whatever. Based on the fact that I can combine these two approaches, I think that's the way to go - the disadvantage of working with dataflow is it's less concrete, and so for a (relatively) simple initial app it's probably unnecessary.
My only wariness around starting in Droid Draw is concern I might get too bogged down in making it look pretty before it actually works; then again, I should be able to replace an ugly button in a stupid place with a shiny one placed ergonomically or whatever without actually changing the underlying code. So, as long as you can see all the features on the screen, no complaining if it's ugly!

So we fire up Droid Draw, and it looks something like this:

As you can see, we've got an Android screen on the left, options of things to add top right, and bottom right is currently a blank space.
[The blank space is where the output xml will appear when I hit 'Generate'. The xml will basically be code telling Eclipse how to make the screen look like what I draw on the left. I'll go into that process in more detail later.]

 To me, the obvious place to start is where the user will commence, first time they open the app - the calendar to pick a date.

What you see here is a first stab at that. The explanatory text is done using TextView boxes; a DatePicker gives us our calendar, and at this stage I'm unsure whether the 'Done!' button for that is necessary

I have then put an alternative, for anyone using the software before they have a date booked. This is just using text boxes at the moment; ideally I'd prefer a drop-down list with months, and then the same with years; or I could settle for radio-buttons with Spring/Summer/Autumn/Winter and then a box for years. Something like that, I'm flexible at this stage.

Items are named, so for example the calendar is called @+id/date_picker, the Done button next to it is called @+id/exact to distinguish it from the other Done button being @+id/approx, and so on. You get the idea - everything has a name which is short and to the point, so that when I'm writing code about it I can see what I'm doing more easily.
Once I'm done with this (for now), I hit 'Generate' on Droid Draw, which spits out a load of lovely xml [for anyone interested, that can be found here]. I can paste that directly into res.layout/main.xml [all will be explained!] and have the above appear in my app. Next step is the code.

Oh, one last point - see my little p.s. note to the User at the bottom? Yeah, it isn't just good to remind yourself what's going on by commenting your code - let the User know too!

Next time: Into Eclipse

Beginnings 1: Whys and Wherefores

Who am I, and why am I doing this?

I'm young, highly qualified and unemployed. There's a lot of it about, oddly enough. I want to get a job developing software, and part of the problem is that my formal programming education is slim; so I need pieces of work to point to, an "I did that!" I am learning to write Android apps partly just to improve my skills, and partly to build up a portfolio of work which I can show to prospective employers.

Why blog about it? Self-discipline, primarily. If I know that the results are public, I have more motivation to push on through the debug phases, the design crises, etc. With the added possibility of showing the blog itself to people.

Why Android, not iOS?

1) I have an Android phone, and it's much more appealing to write an app I can use myself.

2) I have an Android phone, so I have a test-bed in my pocket.

3) Getting an app out on the Android Market (or Google Play, as it seems to be now) is a lot easier than getting one onto the Apple Store.

4) I just prefer the Android philosophy of an open platform.

Coming soon: Software and Tools.