There’s the option of using Three20 to get good looking buttons. Its an option, but frankly, it feels a bit like using a sledgehammer to crack a nut. You end up with a large addition to your code, just for nice buttons. OK, you could go to the trouble of stripping out what you don’t need, but that again is more work.

All iPhone developers know about UIGlassButton – Its an undocumented API for making nice looking buttons, that exists only on the simulator and not on the iPhone itself. Why couldn’t we just have that for iPhone OS? I dunno, but its not there.

At some point in the past, I came across a nice snippet of code that used undocumented techniques for creating a glass button, and then saving the image to disk. This could then be used as a background to a “custom button”, producing the nice glass buttons I’ve been looking for. I think it was schwa on twitter; Nice. Full credit where it’s due.

So, building upon this, I’ve thrown together a simple single-screen app for creating the images for glass buttons using that technique. Basically, it allows you set the RGB values, and the size. Hitting “Save” writes the pngs to the application’s documents directory.
Now, you’ll have two png files, which you can use as images in custom buttons. Hey presto. Very simple UIGlassButtons.
Here’s a screen shot:

Our very simple button maker

Full source is available on github. Comments welcome.

You’re reading the tapadoo blog. Did you know that as well as publishing our own applications, we offer iPhone development services and consultancy? If you have an idea, project or something you think we can help you with, please get in touch through our contact page.

That project is Firepit.

What is Firepit?
Firepit is

1. A web based framework
2. For bands going on tour…
3. ..which allows them to produce iPhone applications..
4. ..that are “virtual tour programmes”

We just got out the first Firepit release today: The App is “Ultravox – Return to Eden II“, and it is on release on the app store worldwide.

We’re delighted that Ultravox are on board. They’ve been an avid supporter of the project for some weeks, getting behind the idea, and supplying some great exclusive content. A quick look over Midge Ure’s Twitter stream shows he’s being doing some beta testing, and bigging up the app.

Hope y’all like it.

1. A senior developer decides that for the new project, the entire team should use a single style. This will mean that the code is consistent across the project and make it easier for developers to work on each other’s code. It also means there will be a level of consistency on commenting etc.
2. A sub-group is put together to decide the guidelines.
3. The guidelines are issued
4. The team fight over them
5. A manager steps in and tells them to use the ones laid down.
6. There’s huffing and puffing but eventually everyone uses it.

Well, that’s been my experience anyway.
But, its always the fight that interesting. People fighting over where its a newline before an curly brace or not, hungarian notation or not, tabs versus spaces always makes me think that people are missing the point somewhat.
The point is about consistency. The arguments are usually about some people consider more whitespace more readable, whilst others think that the more code on the page, gives you a better understanding of what the code does, without having to always page up and down.

So…when you have a few years under your belt, you realise this, and you sit back, enjoy the fireworks knowing that the manager will step in, put an end to the arguing, and we’ll get our consistency mojo.

But….every now and then I do feel that some rules are just stoopid. I was reading the excellent google style guidelines for Objective-C tonight and saw my personal pet peeve stupid styleguide rule:

Each line of text in your code should be at most 80 characters long.

Why?
Why?
Why not 79 characters? Why not 81? Why not more?
I know why.
Before we had GUIs, your typical PC, or VAX Terminal, etc had a width of 80 characters. Printers too. Typically printed 80 characters per line.
But c’mon. We’ve not used text terminals for years, and a typical monitor can show much wider than 80 characters. And…we never print code anymore; If we did, the printer can handle more than 80 characters wide anyway.

I think its silly to have a style guide that was relevant in 1990, but has no relevance to the real world apart from “that’s how gran did it”.

There’s an excellent couple of books by a guy called Steve Maguire. One is called “Writing Solid Code” and another is called “Debugging the development process”. They are more relevant to writing C code, but the sentiments in them are excellent, and I still think all developers should at least read “Writing Solid Code”. There’s a great anecdote in “Debugging the development process” that as I remember it, is about Steve’s wife and her pot roast. It went like this (I hope Steve doesn’t mind me quoting it):

“A boy asked his mother how come she cuts off the edges of a pot roast when putting it into the pot. Mother told him that that’s how her mother taught her to do. So, boy went to his grandmother and he got the same answer. Then he went to his grand-grandmother and ask her the same question. The answer was: Well, back then my pot was to small and the meat didn’t fit inside.”

80 Characters per line when writing code: Pot roast rules for developers.

You’re reading the tapadoo blog. Did you know that as well as publishing our own applications, we offer iPhone development services and consultancy? If you have an idea, project or something you think we can help you with, please get in touch through our contact page.