GitHub love

I imported some of my open source code over to GitHub. I have to say I was surprised how easy and smooth the import went from my old svn repository. The whole history seems to have been imported nicely.

Beside importing SimpleTimer (my first Cocoa app: beware, its code might not be the prettiest!), this is the first release of CLutils, my collection of C/C++/Objective-C functions built over the years. There’s not much structure in it, beside subdividing it by deployment platforms (Mac OS X, iOS and cross-platform code) and OS X APIs (Carbon, Cocoa).

http://github.com/ettore/SimpleTimer/
http://github.com/ettore/CLutils/

FlashBuilder quirks

I ran into the following weird compile error recently:

compile error:
1071: Syntax error: expected a definition keyword (such as function) after attribute override, not protected.

in relation to the following code:


override 
protected function createChildren():void {}

The solution?


override protected function createChildren():void {}

Don’t even get me started.

Updating your Apple Push Notification Service certificates

Just a quick checklist to get up to speed when your APN certificates expire.

  1. Login into the Provisioning Portal, click “App IDs” on the left side column
  2. Click “Configure” on the App ID of your app
  3. Click Revoke for the expired Push SSL certificate
  4. Open Keychain Access on your Mac. Click the “My Certificates”, find the expired cert and just delete it.
  5. From the Provisioning Portal, start creating a brand new Push SSL certificate. Just follow the instructions.
  6. Don’t forget to download the signed cert and double-click it to install it (aps_developer_identity.cer) in your default keychain.
  7. Select My Certificates, find the newly created cert, click the disclose triangle. Then:
    • Right-click on the private key entry without selecting the parent, and select Export. A .p12 file will be saved.
    • Right-click on the actual certificate without selecting the child key, and select Export. Another .p12 file will be saved. UPDATE 2017: it looks like you don’t need to do this anymore. The cert file includes a bag with both cert and key, so deploying that should work.
  8. If your server requires .pem style certificates, run this:
    $ openssl pkcs12 -in apn_cert.p12 -out apn_cert.pem -nodes
    $ openssl pkcs12 -in apn_key.p12 -out apn_key.pem -nodes
  9. Deploy the .pem files in the right location accessible by your application server that will be sending the Push notifications.
  10. UPDATE (2015): it seems like each exported files contains both key and certificate now and therefore are identical. I don’t recall that being the case at the time of this writing.

Now push notifications should be up and running once again.

Quickly rebuild your iOS app when Provisioning Profile expires

  1. Login into the Provisioning Portal, click “Provisioning” on the left side column
  2. Renew your expired profile (or create new one) and download it
  3. Drag it over the Xcode dock icon (or add it into the Organizer)
  4. Remove old profiles from Xcode Organizer
  5. Open your Device target. Select the Build tab -> Code Signing Identity, and make sure the new profile is the one in use.
    Xcode has the habit of not automatically updating its targets to use the newly installed provisioning profile. (Even if you physically removed the old one.)

At this point you should be able to rebuild the app.

Bitstrings and Binaries (Erlang bit syntax minihowto part 2)

What’s the difference between the Binary and Bitstring types in Erlang? Well, a bitstring is a sequence of bits of any length; a binary is a sequence of bits where the number of bits is evenly divisible by 8. (So any binary is also a bitstring.)

Some examples:

1> <<2#11110000:5>>.
>
2> <<2#11110000:6>>.
>
3> erlang:is_bitstring(<<2#11110000:6>>).
true
4> erlang:is_binary(<<2#11110000:6>>).
false
5> erlang:is_bitstring(<<2#11110000:8>>).
true
6> erlang:is_binary(<<2#11110000:8>>).
true

In the Erlang bit syntax there are 2 clarifying (?) type synonyms:

bytes == binary
bits  == bitstring

which are basically telling you to think of binaries as sequence of bytes, and bitstrings as sequence of bits. Quite obvious right? Well, it wasn’t for me at first.

It’s also worth noting how binaries and bitstrings are converted into text strings. Given the binary <<16#50>> storing the letter ‘P’,

7> <<16#50>>
<<"P">>
8>erlang:bitstring_to_list(<<16#50>>). #I could've used binary_to_list()
"P"          %great!
9>erlang:bitstring_to_list(<<16#50:5>>).
[<<16:5>>]  %mmh...

The result of command #9 is not exactly what I had imagined. Yes, it’s a list, but it’s certainly not a text string, and I was expecting a text string. Why was I expecting a text string if the API is named bitstring_to_list() ? Because if I was in the middle of coding a text manipulation algorithm and called bitstring_to_list(), I would probably (wrongly) assume that it would do some magic and transform any bitstring in a usable text string. Why? Because we are used to treat text strings as lists. Why? Because we don’t have APIs that mention “strings”: all the builtin APIs only mention lists. That’s the problem. We are using a list API as if it was a string API, when a generic list is not necessarily a string.

Changing a UIButton title and dealing with button States

If you are changing the title of a UIButton programmatically, you will naturally use the method setTitle:forState:. Easy enough… well, sort of. What do you put in the state parameter?

My first reaction was “I’m going to put all possible states since I just want the button title to change no matter what.” So I blindly bit-OR‘ed all the possible values defined in the docs.


[myButton setTitle:@"New Title" 
          forState:UIControlStateNormal | UIControlStateHighlighted | UIControlStateDisabled | UIControlStateSelected];

Sound reasonable right? Wrong. If you do that here, your button title is probably not going to change at all. The problem is that the “normal” state (per Apple docs that’s “enabled, not selected, not highlighted”) is defined as such:

enum {
    UIControlStateNormal   = 0,
    UIControlStateHighlighted  = 1 << 0,
    UIControlStateDisabled     = 1 << 1,
    UIControlStateSelected     = 1 << 2,
    ...
}

so if you bit-OR all of them you are actually going to set the title for ALL states EXCEPT the “normal” (most common) state!

Sigh…

Erlang bit syntax mini How-To

I don’t know why but Erlang bit syntax always confused me. I always skipped it while reading the docs, until, well, now that I need it. I should say this is not meant to be an exhaustive how-to by any means. It’s just a collection of notes, but howto sounded better. 🙂 There are better guides out there. [Reference docs too.]

Anyway. Here’s some binary data in Erlang:

<<16#1192c05a:32>>

What does all this mean? Let’s analyze it, left to right.

  1. 16# This specifies we want to express the number in base 16.
  2. We have an eight digits hex number.
  3. No type specification is provided: default is unsigned integer.
  4. No unit specification is provided: default for integer is 1, which means ‘bits’.
  5. :32 Size specification: this tells erlang to consider 32 units, which in our case means 32 bits, since we are dealing with bits.

Let’s evaluate it:

86> <<16#2092105a:32>>.
<<32,146,16,90>>

What if we forget to specify the size spec? In that case the default will apply and since we’re dealing with an integer type, the default is 8 (bits). For Erlang this means we are going to return the least significant byte:

87> <<16#2092105a>>.
<<90>>

Now that we know that, we can get a subset of bits by setting the size accordingly:

88> <<16#2092105a:16>>.
<<16,90>>     %two least significant bytes

We don’t need to specify a size multiple of 8:

89> <<16#1192FFFF:15>>.
<<255,127:7>>

It’s pretty cool how easy it is to slice bytes apart at the bit level. I was sort of surprised that if we slice some internal bits it looks like the bits at the right are moved to the left. E.g. here we take the 4 least significant bits of the first 0xFF:

90> <<16#FF:4,0,16#FF,0>>.

but instead of obtaining:

<<16:4,0,255,0>>
F 00 FF 00

we get:

<<240,15,240,0:4>>
F0 0F F0 0          [240 == F0]

Also, the value doesn’t need to be a literal, it can be an expression:

91> N = 16#FF00FF01.
4278255361
92> <<N:32>>.
<<255,0,255,1>>

And therefore, given some binary data, we can also pattern-match it super easily:

<SourcePort:16, DestinationPort:16, CheckSum:16, Payload/binary>> = SomeBinary.

There’s more to Erlang bit syntax than this, but I’ll stop here for now.