There’s a number of places where you could have made a mistake. You developer cert could have been incorrect.
You may have added their UDID to the portal, but forgot to add it to the provisioning certificate.
You may have added it, but not used the correct profile when making the build.
You may have done all this right, but not put the correct binary on the webserver

..and so on. We’ve all been there.

So, how can you tell if an ipa is actually signed for a client’s UDID. Well you could download/extract/find the provisioning file, etc.

Or you could use a handy command line script we’ve thrown together and put on github which does all this for you.

Hope you find it useful
https://github.com/dermdaly/listdevs

• When an array has more than 1 entry, it is serialized correctly
• When the array has only 1 entry, it is serialized not as an array, but as a single dictionary.

Firstly, lets explain why this has occurred
If you consider the following XML:

<team>
    <employee>
      <name>Joe</name>
      <surname>Bloggs</surname>
  </employee>
  <employee>
    <name>Jane</name>
    <surname>Doe</surname>
  </employee>
</team>

A typical XML to JSON converter will convert this as follows:

{
  team:{
    employee:[
      {
        name:'Joe',
        surname:'Bloggs'
      },
      {
        name:'Jane',
        surname:'Doe'
      }
    ]
  }
}

I.e It is converted to a Dictionary, with a key called ‘team’ whose value is a Dictionary, with a key called ‘employee’ which is an array of Dictionaries (with keys of ‘name’ and ‘surname’).

Great.
However if the XML was a team with a single entry:

<team>
    <employee>
      <name>Joe</name>
      <surname>Bloggs</surname>
  </employee>
</team>

The XML to JSON converter has no context on Employee. It has now way of knowing that this is potentially a repeating group (especially if it has no XSD to consult), so it converts the XML to the following JSON:

{
  team:{
    employee:{
      name:'Joe',
      surname:'Bloggs'
    }
  }
}

So, this is now a Dictionary, with a key called ‘team’ whose value is a dictionary with a key called ‘employee’ whose value is a Dictionary.

The problem here is when we go to parse, we expect the value of ‘employee’ to be an array (which it isn’t), and this can lead to problems in the code.

And..due to Objective-C loose approach to type, the following code will run:

NSArray *array = [teamDict objectForKey:@"employee"];


In those cases where there team has a number of employees, the above code works fine, and the pointer, array stores an array. In those cases where a team as a single employee, the above code runs, however the pointer, array will actually point to a NSDictionary. So the following code (for example)

int numEntries = [array count];

Will sometimes work, and sometimes lead to a runtime error, which on iPhone will manifest itself as a crash.

So how do we fix this?
Well, if you have control over the server side, the simple question is to fix it in the first place. Note: This is a common problem with JAXB, a popular java XML binding mechanism often used in REST services written in Java. We’ve come across some examples on how to work around it here and here.

If you have no control over this, you may be able to handle this in your Objective-C code. Here’s some sample code we’ve started to use; It checks the data type at runtime, and if necessary, converts it to a single element array

+(NSArray *) getArrayFromJSONDictionary:(NSDictionary *)parent
               forKey:(NSString *)key {
  id obj = [parent objectForKey:key];
  if([obj isKindOfClass:[NSArray class]]) {
    return obj;
  }
  if([obj isEqual:[NSNull null]]) {
    NSLog(@"Warning: object for key %@ is null", key);
    // Return an empty array
    return [[[NSArray alloc] init] autorelease];
  }
  NSLog(@"Warning object for key %@ is of type %@",
        key, [[obj class] description]);
  NSArray *ret = [NSArray arrayWithObject:obj];
  return ret;
}

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.