Poker? Poke 'er!

Having mostly completed CS 101 (Introduction to Computer Science, aka Build a Search Engine), which was awesome, I just need to wait for a final exam to come out.

So I have moved on to looking at CS 212 (Design of Computer Programs), which has so far focussed on a program to judge winning poker hands, with an added bonus of a procedure to deal the hands. And here I hit a problem, because that procedure is:

def deal(numhands, n = 5, deck = [r+s for r in '23456789TJQKA' for s in 'SHDC']):

"Shuffle the deck and deal out numhands n-card hands"

random.shuffle(deck)

return [deck[n*i:n*(i+1)] for i in range(numhands)]

Just to explain what's going on here:
First it defines (def) a function called 'deal'. Deal can take as inputs the number of hands to deal (numhands), the number of cards per hand (n), and the definition of the pack of cards (where r is the card values, and s is the suits).
Then there's a bit of a description of the function, before shuffling the pack randomly.
Finally the idea is to return an output where:
we get a number of hands (numhands), each containing n cards, by counting out the first n cards, then the next n cards, until the hands are complete.

This is okay for a whole bunch of card games; in fact, considering poker it would work for Five-card Stud, which may be what was intended. But what I've always played is Texas Hold'Em, which has a different structure.
For anyone who hasn't had the pleasure of playing Hold'Em, the basic structure is that each player receives two cards in their own hand, and there are then five cards dealt face up on the table. Each player makes their best hand of five.

So I've tried to put together a function to do that job:

def deal(numhands, n=2, face=5, deck=[r+s for r in '23456789TJQKA' for s in 'SHDC']):

    random.shuffle(deck)

    hands_out = deck[0:face] + deck[(n*i+face):(n*(i+1)+face)] for i in range(numhands)]

    return hands_out

which unfortunately...doesn't work.
I believe the logic is sound; I'm just getting some part of the syntax wrong. I'll come back to it; once this works, I will also have to make an additional function to work out the best hand of five cards from the seven available to each player, and the rest of the code should then follow.

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!

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 3: Early Design Decisions

So, I'm set up with all the tools to write an Android app, give it a pretty interface, and test it. So this seems to open the question - what do I want it to do?

There are thousands of apps already available, to do almost anything imaginable. You can get an app to play The Sims. You can replace your touchscreen keyboard. You can add an archery scoring tool.
According to the might wiki, there are 450,000 apps for Android! How can I do something that's never been done before?
Well, bluntly, I can't. I may not even be able to do something better than it's been done before. That's okay though - it means rather than searching Google Play with ever odder search terms to find something that hasn't been done before, I can just come up with something that seems achievable and get cracking.

I've been spending a lot of time lately helping my fiancée in planning our wedding (for anyone interested in that side of things, her blog as linked there is a good place to start) and the number of lists and pieces of paper to keep track of everything is insane!
Everything has a different timescale; different participants; costs to budget for; and so on.
Basically it is one of the largest events that people are likely to find themselves organising in a non-professional context. Maybe I can do something to help?

Thinking about this, I can think of a lot of things that an 'ideal' version of wedding planning software would do for you. The key thing is to start with a core functionality that's actually useful and then add capabilities once the core is up and running - otherwise it becomes a huge project for one person, I have to learn a lot more before I can get started, and I'm more likely to give up with it incomplete!

Ideal Version:
Keep track of budget - how much things cost and what proportion is paid for.
Keep track of RSVPs - to the main event/reception (if separate), hen and stag.
Replace all the little bitty notes - to-do lists, records, contact details, ideas.
Count-down - knowing what day is W-Day, and being able to categorise tasks by 12 months before, 6 months before, the day before, day of the wedding, whatever.
Tracking primary responsibility for tasks - is the groom handling the music? Is the bride mostly dealing with the caterers?
Be able to synchronise between multiple devices - the bride and groom, and possibly also the best man, maid of honour, ushers, even parents.
With the above, ideally be able to output something (be it a spreadsheet, Google Doc, whatever) to a computer for handling on a larger screen.
BACK UP AUTOMATICALLY - this is a big deal. The more of the critical pieces of paper that are moving onto an Android, the more careful we need to be that one inopportune crash, or getting your phone nicked, won't mess everything up; and relying on busy people to manually backup is going to lead to some failures. I have no idea how easy this is - have to look into it later.

That's quite a lot of features, and different pages within the app, all of which would have to interact smoothly with one another. What's the core of it? I reckon the combination of a to-do list and count-down will do the trick - key reasons being I think it's enough to be useful, but it doesn't require interacting with other phones or linking to PC; it will have easy room for expansion in noting responsibility for tasks; and phones are obviously *already* good for noting contact details, so integrating those into the app aren't the highest priority.

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. That sounds like a pretty good initial feature list to me.

I can start breaking that down into what I'll actually need code-module-wise next time. Then I can give myself a specification - to write code able to perform these functions - and then I can maybe start writing some actual code!