If you own a mobile device such as a google android phone, or an iPod touch (like the one I am using to write this post) you should find the this blog looks a little prettier and is easier to navigate on your mobile device thanks to a nifty plugin called wp-touch. If you’re Reading this the old fashioned way, on a gloriously large screen, you’ll notice no difference whatsoever.
Recent Updates Toggle Comment Threads | Keyboard Shortcuts
Thinking about interface design.
One of my projects this week is to think through a very specific design problem.
One of our iPhone applications, Formula Sensei solves scientific formulae. The concept is simple, but the application very useful. For our next release, we want to add the ability to solve for resistors in series or parallel. Both of these equations pose a new interface problem that didn’t exist for the formulae already present in the application: to add and remove variables in the equation. All of the other formulae have fixed numbers of variables. As such, I have spent a great deal of time thinking, writing about, and sketching ways to add and remove members from a list of input values in a way that feels intuitive to the user, and fits with the flow of the existing interface.
Expect a more full writeup, with pictures at some point in the next couple of days.
So one of the things you run into when you develop for the iPhone or iPod Touch is code-signing, and the various things that come with this. After a crash-course in certificate signing from Senior Engineer, Steve, and many days of fiddling around with Apple’s developer portal trying to figure out how to get it all working, I think that a full writeup is called for.
One of the first ways that you’ll know you need to spend more time fiddling around with this stuff is the classic ‘codesigning’ error when you try to build your project and test it on your ipod. It can take a while to figure out where the issue lies when the code-signing error pops up, but after working quite extensively figuring out how to run and test applications, and subsequently how to build and upload them to the app-store, I have a little check-list of code signing things that I go to now when things go wrong. I’ll go into each item in detail a little later on.
- An appropriate certificate
- A public key that matches this certificate
- A private key that matches the certificate and the public key
- A provisioning profile that matches all of the above, AND is correct for your build.
A certificate is a data file, signed by a certificate signing agency. You don’t need to interact with the signing agency directly, Apple will take care of that for you. To get your certificate, you send a certificate signing request to Apple. More on that in a moment. First lets look at exactly what a certificate does, and how it works.
A certificate gets rolled into your code when you build your application. It provides an end user’s computer with information about where the app came from and who built it. In order to verify that what the certificate says is true, certificates are ‘signed’ by an agency. One can self-sign a certificate, but this provides the user no guarantees that you are who you say you are. A signed certificate matches information stored in your public and private keys, and adds a layer of authority that comes from an external signing service. When you build your app X-Code checks for all three of these things. This can be misleading if you have downloaded a certificate that somebody else generated (say you are working as part of a development team and somebody else generated all of your certificates). You may see Keychain entries for the correct certificate, and items called public key and private key. It does not necessarily follow that these three items match one another.
There are two ways to get matching certificates and keys. Firstly, one generates the certificate signing request oneself, and submits it to Apple. When a certificate signing request is generated, matching keys are also created. For more details on this, see the walk-throughs in the apple developer portal. Alternatively one downloads the correct certificate from the developer portal, and crucially obtains the matching keys from whoever created the certificate. This might be good things to keep in a development repository of one is working as part of even a small team doing iPhone development. That way, each time somebody wants to install an app, they don’t have to go about creating certificates from scratch. This is particularly sensitive when it comes to distribution certificates. Each development account can have a number of development certificates attached, but only one development certificate. If your boss is on vacation, and he created the certificate, but didn’t share the private and public key before leaving, you will need to create the certificate anew for yourself. Only the owner of the development account can create distribution certificates; registered team members cannot.
In order to deploy an application to the app-store, it must be signed with the distribution certificate.
- Public key
In order to get a public key, you create a certificate signing request according to the process outlined by apple, or import one created by somebody else when they generated the code-signing certificate.
The public key states the identity of the signing authority, and contains all of the public information that verifies that you are who you say your are.
- Private Key
The private key contains information about the machine that compiles the code (in theory). As such it’s actually not very good practice to share private keys around the development team, and is probably better practice to generate new signing certificates each time a team-member submits code to the app store.
However, if you find Apple’s certificate and provisioning system cumbersome, then particularly for development certificates, it’s an option.
- Privisioning Profile
The final puzzle piece is the provisioning profile. Getting this right can be quite a balancing act, given that the provisioning profile takes into account not only public and private keys, and the certificate needed for code-signing, but also the purpose of the build. Development profiles are locked to individual device ID’s, and are distinct from distribution profiles. I have found that if in doubt, it has been best to generate a new profile.
There is an important reason that I list this item last: it needs to be the very last thing you create on the developer portal before you try to build your app. When you generate a provisioning profile, Apple locks it to a particular certificate. If you haven’t generated the certificate your program is going to use yet, you can’t download a provisioning profile that will work for that certificate. Furthermore, if you re-generate a particular certificate, you will have to open your provisioning profile on the apple site, and hit save, to update it for the new certificate, then re-download and feed it to x-code. I repeat, do this last.
So what does each of these things do, and how do I get them?
If you want to know a little bit more about the mechanics behind all of this, check out the Wikipeda page on code signing.
Also Jeff Crouse spends some time walking through this process in his excellent tutorial on getting openFrameworks running on the iPhone.
If you have specific questions please comment and I’ll do my best to answer them!
Dali Tao is discussing. Toggle Comments
On Monday, I spent some time in the morning polishing up the photoshop comps I’d been working on. There’ll be a more detailed full writeup on the process I went through with those once they’re totally finished. In the afternoon I turned my attentions back to the Cheapest app. My mission: to locate and fix a bug that prevented use of numbers after the decimal point when an iPhone’s localization settings dictate a comma instead of a period as the decimal separator.
There was already some cleverness going on in terms of localization: the following line of code made sure that where appropriate, the comma was used instead of the period:
decimalChar = field.formatter.decimalSeparator;
decimalCharis then appended to the current digits in the field. This is all well and good: people get a familiar decimal separator. The problem was that when they moved on to the next field, digits after the decimal were lost.
What a mystery. I should mention that these are really my first forays into objective-c, so I’m very much learning to read the syntax as I go. After some time spent reading documentation, and hunting through different parts of the program, including an introduction by Steve to the debugging features in x-code, I figured out the process the application went through each time a field lost focus.
When the user presses a key on the calculator keyboard built into the app, that digit is appended to a string variable (string of text). Only when the field loses focus, is that value mined for its numbers, and passed to a different variable in the local currency format. The problem was, the part of the program that stripped the numbers out of the text didn’t know what to do with a comma, and so digits after the comma were lost.
The fix was quite simple: change commas to periods, before parsing the string for its numbers. I didn’t need to worry about putting commas back in, because the currency-formatted variable that reads those numbers already knows about localisation.
So the problem was fixed with a single line of code, incidentally, my very first line of code to go into a published application.
And here it is:
title = [title stringByReplacingOccurrencesOfString:@"," withString:@"."];
doubleValuedoesn’t know about commas or localisation
- x-code’s documentation feature is my friend
- spend time figuring out exactly where your bug is happening in the code
- use debugging tools to do this
- once you know where it’s all going wrong, the hard part might well be over
iPhone development Tuesdays:
Today began by testing Cheapest, a nifty little calculator app that finds price differences per unit for items sold in bulk at the grocery store. The handy ‘kerching’ noise that indicates successful completion of the calculation did not play under new iPhone OS. time for some bug-hunting.
I spent some time reading through changes to the audio codecs that run in the new iPhone OS, and thinking about ways to bring those in without destroying backward compatibility. The error that the application was throwing out looked a little bit like this:
Tue Jun 23 14:31:04 unknown mediaserverd : [14:31:04.568 ] AudioQueue codec policy 1: failed to find a codec of the requested type
Then, senior studio developer, Steve, suggested that perhaps this might be a format issue. Good thinking Steve. Three minutes of google searching, and one creative commons licensed new sound effect in a more compatible format later, and my professional iPhone developer testing device (ipod touch) was making happy cash register noises at the touch of a button. Successful afternoon I’d say.
Next challenge: making the iPhone 2.2.1 simulator run happily to check for backward compatibility.
Today, after spending some time in the morning tweaking my three photoshop comps, I began work getting an iPhone development environment set up on mine and another laptop. The SDK includes a new version of apple’s development environment, xcode. With this up and running, I used my new-found knowledge of the subversion version tracking system to check out code to my local machine for the first application that I’ll be working on.
My task is to go through the application, checking for compatibility issues with the new iPhone operating system. The development environment allows me to simulate different iPhone hardware and software combination. Additionally, once I am authorised, I’ll be able to build and install applications on my ipod touch.
New blocky background: colour is taken from my coffeeshop surroundings.
Also, the coffee here is excellent.
MichaellaS is discussing. Toggle Comments
PHP was a somewhat complicated install.
I first had to download and install the inconv library, and the mcrypt library, and tell the PHP configure script about them. Furthermore I had to point the configure script at my existing mySQL installation (an easy osx package double clickey type installation) and apache installation. Only after carefully balancing the conflicting forces of each of these configure options would the make script run correctly. Notably, libmycrypt is the part of mcrypt that PHP needs. The actual mcrypt program has dependencies on some hashing algorithms that I had trouble finding, but is not actually needed. Both of these projects are available here.
to test my php installation, I wrote a short PHP file that invoked phpinfo command, which brings up a screen detailing the configuration options set for PHP.
Once php was installed I restarted apache and tested.