Tagged: iPhone development Toggle Comment Threads | Keyboard Shortcuts

  • intern 3:32 pm on July 9, 2009 Permalink |
    Tags: Formula Sensei, interface design, intuition, iPhone development, standards   

    Thinking about interface design. One of… 

    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.

     
  • intern 3:24 pm on July 9, 2009 Permalink |
    Tags: certificates, code signing, iPhone development, private key, public key   

    So one of the things you run into when y… 

    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.

    1. An appropriate certificate
    2. A public key that matches this certificate
    3. A private key that matches the certificate and the public key
    4. A provisioning profile that matches all of the above, AND is correct for your build.
      1. So what does each of these things do, and how do I get them?

        1. Certificates:
          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.

        2. 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.

        3. 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.

        4. 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.

        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 3:15 pm on August 31, 2009 Permalink

      thanks for the explaining everything in detail. I have a problem “matching certificate identify with private key no found in login keychain” when I tried to add provisioning profile. I have a development certificate, public key, and private key. Is there a way to verify these three items before I generate Provisioning profile? Thanks in advance.

  • intern 7:09 pm on July 1, 2009 Permalink |
    Tags: , decimal separators, iPhone development, localization   

    On Monday, I spent some time in the morn… 

    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;
    decimalChar is 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:@"."];

    Takehome lessons:

    1. doubleValue doesn’t know about commas or localisation
    2. x-code’s documentation feature is my friend
    3. spend time figuring out exactly where your bug is happening in the code
    4. use debugging tools to do this
    5. once you know where it’s all going wrong, the hard part might well be over
     
    • intern 11:33 am on July 9, 2009 Permalink

      Konstantin, if there’s something specific you’re looking for, let me know and I’ll do my best to answer your question.

    • KonstantinMiller 11:45 pm on July 6, 2009 Permalink

      Hi! I like your srticle and I would like very much to read some more information on this issue. Will you post some more?

  • intern 6:46 pm on June 23, 2009 Permalink |
    Tags: audio codecs, , iPhone development, Kerching!   

    iPhone development Tuesdays: Today bega… 

    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[487] : [14:31:04.568 ] AudioQueue codec policy 1: failed to find a codec of the requested type

    YUCK.

    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.

     
  • intern 6:11 pm on June 22, 2009 Permalink |
    Tags: , iPhone development, Monday   

    Today, after spending some time in the m… 

    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.

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel