annema.me

OWE on the GL.iNet Flint 3

2026-04-02T00:00:00Z

For my work at IPinfo I needed an open Wi-Fi network to test against. Having learned of the existence of Opportunistic Wireless Encryption (OWE) and that OpenWrt supports it, I wanted to have one.

OWE encrypts traffic on open networks without requiring a password. Clients (Apple, Android) that support OWE encrypt their traffic. Lack of encryption was always the big drawback of open networks. For my use case it didn't really matter (I don't expect anyone to join), but now I get to say I have an encrypted guest Wi-Fi network that doesn't need a password.

Setting it up on the Flint 3 was straightforward following the OpenWrt guest Wi-Fi and OWE guides. But it didn't work. There were two separate issues.

GL.iNet firmware bug

The OpenWrt guides tell you to set encryption='owe' on the wireless interface. Presumably this works in the normal version of OpenWrt, but there's a bug in the modified variant that ships with the Flint 3's firmware. On firmware 4.8.4 it silently creates an open network with no encryption. Technical details.

The workaround is to use the encryption and OWE flag separately:

uci set wireless.<iface>.encryption='ccmp'
uci set wireless.<iface>.owe='1'
uci commit wireless
wifi

CoreWLAN bug

After getting OWE working I noticed that macOS and iOS report the network as "Security: None". At first I thought OWE wasn't working, but checking on the router confirmed it was.

The bug is in Apple's CoreWLAN framework. CWInterface.security() returns kCWSecurityNone (0) for an active OWE connection when it should return kCWSecurityOWE (14). The scan API gets it right: CWNetwork.strongestSupportedSecurity correctly returns kCWSecurityOWE.

Maybe because of this bug the UI also doesn't distinguish OWE from open networks at all. Same appearance and security warning. Anyone who went through the trouble of setting up OWE gets flagged as insecure anyway. That's wrong.

Apple feedback ID: FB22250575

Free Wi-Fi for all

It took a lot of fiddling and going back and forth with Claude but ultimately I was able to come up with a solution that I understood and could report issues for. Finding issues with iOS and macOS was an unexpected bonus. I guess.

If you're ever near my house be sure to join my open but encrypted Wi-Fi.

Configure GL.iNet GL-BE9300 (Flint 3) on KPN fiber

2026-03-17T00:00:00Z

Backstory

Up until a few days ago my main Wi-Fi router was an Apple Time Capsule. It's one of the latest models but still this thing is old. Apple discontinued the product line in 2018 but I probably bought it in 2013, maybe 2014. That makes it over 10 years old. It survived 3 NYC apartments, a move back to The Netherlands, being stored in an attic for a while, dusted off and then 2 more houses. The longevity of this thing is honestly amazing (granted I haven't used it for backups for a few years but when I stopped even the hard drive still worked).

I didn't even replace it because it was broken but because I need more configurability for my work at IPinfo. To test I occasionally need uncommon network configurations like an IPv6-only network, an open Wi-Fi network or just a separate Wi-Fi network to begin with. None of these were easy to set up on my Time Capsule or the router that came for free with my KPN subscription.

UniFi vs GL.iNet

For years I thought I would upgrade to UniFi but I decided against it. The fact that it's an American company didn't work in its favor but ultimately I realized I didn't need their ecosystem. I run Home Assistant so anything I can get through their ecosystem I can also connect to my current network and have Home Assistant handle it.

Instead I went for a Flint 3 (GL-BE9300). It was recommended by a coworker, it's well reviewed by rthings.com but most importantly it runs a modified OpenWrt firmware. I don't have to set up OpenWrt from scratch but I can still use it to configure unusual network configurations.

KPN setup

After I received my new router I needed to make it work on my KPN Fiber connection. Initially I followed this guide. In case the guide ever disappears here's a quick summary of its setup:

Under “Ethernet 1” click “Modify” then use the following settings:

Setting	Value
Protocol	`PPPoE`
Username	`internet` (can be anything)
Password	`internet` (can be anything)
VLAN ID	6
MTU	1500

Then click “Apply”

IPv6 support

The guide worked, but left me without IPv6 support. After some digging I found it's something I need to enable by going to “Network” -> “IPv6” and then enable it with the following settings:

Setting	Value
Mode	Native
DNS Acquisition method	Automatic

Finally go to “Network” -> “Multi-WAN”, Click the settings gear next to “Ethernet 1” and change “Protocol” from “IPv4” to “Both”

That's it. A quick way to test if it worked is to see if v6.ipinfo.io loads. Next I'm going to set up an open but encrypted (OWE) Wi-Fi network for testing.

Get notified when a GitHub action completes

2026-02-12T00:00:00Z

Often I’m waiting to merge a PR until all of its checks have passed. While I do my best to keep checks as fast as possible they still take long enough that I’m not going to wait for them to finish. I start something new while I wait. Frequently I then forget to merge the PR because I’m completely caught up in the next thing. This is even worse for PRs where I’m testing changes to the GitHub actions. I have to wait for feedback but then forget to check when it’s finally there.

To avoid this, I want to get notified when a GitHub action completes. I know I can enable notifications for workflow runs. GitHub gives me two options; email and/or web. I manage all my GitHub notifications through the web UI, so email is out of the question. Enabling workflow notifications for web just means workflow runs will end up in the GitHub UI. I still have to remember to check which brings me back to the original problem.

Luckily the command line and GitHub's command line interface can help. Now, whenever I need to be notified of a workflow run I use:

gh run watch ; terminal-notifier title "CI" -message "Run completed"

gh run watch prompts for what run to watch and ; will run terminal-notifier after gh finishes regardless of whether it succeeds or not.

You can also use && if you only want to be notified on success or || for failures.

Converting ISO country codes to country names using Locale

2025-10-31T00:00:00Z

Because IPinfo's open API always returns country codes, I needed to convert them to country names for better address formatting. For example, 1.1.1.1 returns AU for Australia. The authenticated tiers (free Lite and paid Core/Plus) have both codes and names, but the open API doesn't.

At first I hoped this would do the trick:

let postalAddress = CNMutablePostalAddress()
postalAddress.isoCountryCode = ipInfoResponse.country
print(postalAddress.country) // ""

Sadly CNPostalAddress and CNPostalAddressFormatter don’t map country codes to country names. While looking for alternatives, I found this gist. It uses Locale’s localizedString(forRegionCode:) to init a Locale using just the country code. What an incredibly elegant idea! No external dependencies and just platform native APIs which are much more likely to return similar results as people would see in Apple’s own apps. Since I only need country names (not a full locale), the code is even shorter:

Locale.autoupdatingCurrent.localizedString(forRegionCode: "NL") // Netherlands

That’s it.

This almost felt too easy. I was looking forward to building a solution: importing mapping data, handling translations, dealing with edge cases. Instead, one line of platform API code solved it better than anything I could build. Feeling robbed of a good engineering challenge, I decided to verify this simple solution actually works. I tested this against all ISO-3166 country codes to see what happens.

The setup:

let json = // https://github.com/lukes/ISO-3166-Countries-with-Regional-Codes/blob/145f1ad3caff212ed25f42b0ee2c8b92a75af895/slim-2/slim-2.json

struct Country: Decodable {
  private enum CodingKeys : String, CodingKey {
    case name
    case alpha2 = "alpha-2"
    case countryCode = "country-code"
  }

  let name: String
  let alpha2: String
  let countryCode: String
}

let decoder = JSONDecoder()
let countries = try! decoder.decode(
  [Country].self,
  from: json.data(using: .utf8)!
)

struct LocaleCountry {
  let name: String
  let code: String

  let originalName: String
}

let locale = Locale.current
let localeCountries: [LocaleCountry] = countries.compactMap {
  guard let countryName = locale.localizedString(forRegionCode: $0.alpha2) else {
    return nil
  }

  return LocaleCountry(
    name: countryName,
    code: $0.alpha2,
    originalName: $0.name
  )
}

Starting with the basics, let’s confirm no countries are missing:

localeCountries.count == countries.count // true

Then let’s confirm every country has a name:

localeCountries.count(where: { $0.name.isEmpty }) // 0

Finally, let’s check if all the names match:

localeCountries.count(where: { $0.name != $0.originalName }) // 49

I knew this was too easy; I found 49 mismatches. On closer inspection however, the simple solution actually works better than expected. These were mostly stylistic mismatches. For example “BQ” in the original data is “Bonaire, Sint Eustatius and Saba” whereas Apple uses “Caribbean Netherlands”. Similarly the original data uses the awkward “Netherlands, Kingdom of the” whereas Apple returns just “Netherlands” which is better. Apple also makes other stylistic choices (like using “&” instead of “and” in Antigua & Barbuda) that feel more natural. By using platform native APIs, we get the same values Apple uses. Which is what users from, for example, the Caribbean Netherlands, Côte d’Ivoire and Netherlands will expect. Although as someone from The Netherlands, I do miss the The in The Netherlands.

For reference here’s the full list of mismatches:

AG: Antigua & Barbuda != Antigua and Barbuda
BO: Bolivia != Bolivia, Plurinational State of
BQ: Caribbean Netherlands != Bonaire, Sint Eustatius and Saba
BA: Bosnia & Herzegovina != Bosnia and Herzegovina
IO: Chagos Archipelago != British Indian Ocean Territory
BN: Brunei != Brunei Darussalam
CV: Cape Verde != Cabo Verde
CN: China mainland != China
CG: Congo - Brazzaville != Congo
CD: Congo - Kinshasa != Congo, Democratic Republic of the
CI: Côte d’Ivoire != Côte d’Ivoire
FK: Falkland Islands != Falkland Islands (Malvinas)
HM: Heard & McDonald Islands != Heard Island and McDonald Islands
VA: Vatican City != Holy See
IR: Iran != Iran, Islamic Republic of
KP: North Korea != Korea, Democratic People’s Republic of
KR: South Korea != Korea, Republic of
LA: Laos != Lao People’s Democratic Republic
FM: Micronesia != Micronesia, Federated States of
MD: Moldova != Moldova, Republic of
MM: Myanmar (Burma) != Myanmar
NL: Netherlands != Netherlands, Kingdom of the
PS: Palestinian Territories != Palestine, State of
PN: Pitcairn Islands != Pitcairn
RU: Russia != Russian Federation
BL: St. Barthélemy != Saint Barthélemy
SH: St. Helena != Saint Helena, Ascension and Tristan da Cunha
KN: St. Kitts & Nevis != Saint Kitts and Nevis
LC: St. Lucia != Saint Lucia
MF: St. Martin != Saint Martin (French part)
PM: St. Pierre & Miquelon != Saint Pierre and Miquelon
VC: St. Vincent & Grenadines != Saint Vincent and the Grenadines
ST: São Tomé & Príncipe != Sao Tome and Principe
SX: Sint Maarten != Sint Maarten (Dutch part)
GS: So. Georgia & So. Sandwich Isl. != South Georgia and the South Sandwich Islands
SJ: Svalbard & Jan Mayen != Svalbard and Jan Mayen
SY: Syria != Syrian Arab Republic
TW: Taiwan != Taiwan, Province of China
TZ: Tanzania != Tanzania, United Republic of
TT: Trinidad & Tobago != Trinidad and Tobago
TC: Turks & Caicos Islands != Turks and Caicos Islands
GB: United Kingdom != United Kingdom of Great Britain and Northern Ireland
US: United States != United States of America
UM: U.S. Outlying Islands != United States Minor Outlying Islands
VE: Venezuela != Venezuela, Bolivarian Republic of
VN: Vietnam != Viet Nam
VG: British Virgin Islands != Virgin Islands (British)
VI: U.S. Virgin Islands != Virgin Islands (U.S.)
WF: Wallis & Futuna != Wallis and Futuna

What is bad behavior?

2025-10-30T00:00:00Z

During my run I had a discussion in my head about bad behavior. What makes a behavior bad? Why is it bad?

The discussion in my head started when I ran by an elephant path made by people, mostly kids, biking across the grass to get to the main bicycle path. I was annoyed by this because my community has asked people to stop doing it and I talk to my kids about it every time I see them do it. Even though I know they will probably do it anyway if I'm not watching.

I imagined myself being in the meeting with Staatsbosbeheer (the Dutch forestry service who owns this area) where the discussion was about potential solutions. The first argument I made in my head was to put up some sort of barrier to prevent the behavior but then I remembered an example from a university. After they renovated the lawn, they purposely didn't add any paths. Instead they waited a year to see where paths would naturally emerge and added them there.

That example in mind I began arguing for doing the same. In my head someone else would argue "but that's rewarding the wrong behavior". At this point I began questioning what is bad behavior? Why is it bad? I remembered what happened with my oldest after I discovered he had been playing Roblox even though we told him not to. We'd banned it because we worried he wouldn't come to us if things in the game troubled him.

He explained that he'd been doing it in secret for some time with his friends. All of his friends are allowed to play Roblox. He was playing games together with them and he was the only one not allowed to play it himself. Is this bad behavior? Was this a child's form of civil disobedience? Was he challenging a rule that didn't make sense to him? We eventually decided to let him keep playing Roblox after we explained our fears to him.

That university asked "what are people trying to tell us?" instead of "how do we stop them?" Maybe that's the better question.

Is that condoning his disobedience? Or is it recognizing that the traits that frustrate us now — standing up for himself and questioning authority — are exactly what we want him to have as an adult? What about the university example? Was it bad behavior for people to walk on the grass or was it okay there because there was no other option?

And finally, what about my initial example? Is putting a path where people obviously want one the same: rewarding rule-breaking? Or is it listening to what people are trying to tell us?

I don't know. But I think I'd rather err on the side of flexibility and meet people where they are. Even when it feels like giving in.

Accessing Swift Package Manager dependency versions at runtime

2025-09-28T00:00:00Z

I was building a debug screen for an iOS/Mac app and wanted to display the version of a third-party dependencies managed by Swift Package Manager.

My first instinct was to use an Xcode run script build phase to extract version information at build time, but I quickly ran into various code signing errors that made this approach unreliable. Especially because building for macOS triggered code signing errors for different configurations than iOS did. I didn't look very hard, but I wasn't able to find a configuration that worked for both platforms.

After some experimentation, I found a solution that works reliably: copying the Package.resolved file at build time and parsing it at runtime. The Package.resolved file contains the exact commit hashes and versions of all your dependencies, so it's perfect for this use case.

Here's how to set it up. First, create a run script build phase that copies the file into your project directory:

cp ${PROJECT_FILE_PATH}/project.xcworkspace/xcshareddata/swiftpm/Package.resolved ${PROJECT_DIR}/Package.resolved

Make sure to add ${PROJECT_DIR}/Package.resolved under Output Files in your run script build phase. This tells Xcode that this file is generated by the script. I don't know since when but at least in Xcode 26 build scripts run in a sandbox. If you forget to add input and output files Xcode will complain.

Next, add the copied file to your Xcode project (you can drag it into the project navigator or right-click and select "Add Files to [project name]"). Ensure the file is included in "Copy Bundle Resources" and that your run script build phase runs before the copy resources phase.

Package.resolved is just JSON, so we can decode it with a simple struct:

// SPM.swift

import Foundation

struct SPM: Codable {
 let pins: [Package]

 struct Package: Codable {
  struct State: Codable {
   let revision: String
  }

  let identity: String
  let state: State
 }

 static func allPackages() -> [Package] {
  guard let packagesPath = Bundle.main.path(forResource: "Package", ofType: "resolved"),
     let data = try? Data(contentsOf: URL(fileURLWithPath: packagesPath)) ,
     let resolved = try? JSONDecoder().decode(SPM.self, from: data)
  else {
   return []
  }

  return resolved.pins
 }
}

The allPackages() method loads the bundled Package.resolved file and decodes it into an array of packages. Each package includes its identity (name) and the exact commit revision. If you need other fields, take a look at your Package.resolved file to see what's available and add it to the SPM hierarchy.

I don't yet know how reliable this is, but it works fine so far. I later realized it's the same technique used by SPM-Acknowledgments to auto-generate acknowledgments screens. At the time of writing SPM-Acknowledgments was last updated in 2020 which suggests that this approach is stable enough. For me it's for debug information so it's okay if it stops working.

Moving DNS from Cloudflare to Gandi using DNSControl

2025-09-24T00:00:00Z

Current setup

I'm in the process of moving this site to Europe. For the past couple of years annema.me was hosted on GitHub Pages. My domain registrar was dotster.com and DNS was done by Cloudflare.

Historical context

I registered annema.me with Dotster in 2011 because I worked at Sofa and they used Dotster. I later moved to Cloudflare for DNS since it made HTTPS easy.

For years all I heard from Dotster was the occasional renewal email, but then they rebranded to web.com, then Network Solutions, triggering excessive emails with each change. Combined with wanting to use European providers, this prompted me to move all my domains.

The migration challenge

At the moment annema.me is rented through gandi.net but the DNS is still controlled by Cloudflare. Unfortunately, moving DNS to Gandi without interruption requires switching to Gandi's LiveDNS, which provides only a bare text box for entering existing DNS records. It doesn't even tell me, a DNS novice, what format it expects.

My first attempt was to use Cloudflare's export and paste the result of that into the box. It gave a ton of cryptic errors. I tried editing the file because it complained about Cloudflare's magic TTL of 1 (which just means Cloudflare handles TTL automagically). Even changing it to 300, Gandi's minimum, but none of that worked.

Besides this all feels fragile. I honestly don't care too much if everything goes down but I at least want to try to keep things up.

I don't remember how I found it, but I ended up using DNSControl to automate the migration.

Exporting existing records

After setting up my credentials I needed a dnsconfig.js with my own DNS configuration. Again it felt error prone to do this manually so I used dnscontrol get-zones instead:

dnscontrol get-zones --out=dnsconfig.js --format=djs cloudflare - all

Which gives a good starting point:

var DSP_CLOUDFLARE = NewDnsProvider("cloudflare");
var REG_CHANGEME = NewRegistrar("none");

D(
  "annema.me",
  REG_CHANGEME,
  DnsProvider(DSP_CLOUDFLARE),
  DefaultTTL(1),
  A("@", "185.199.111.153", CF_PROXY_ON),
  A("@", "185.199.110.153", CF_PROXY_ON),
  A("@", "185.199.109.153", CF_PROXY_ON),
  A("@", "185.199.108.153", CF_PROXY_ON),
  // etc
);

The 404 roadblock

With that in place I added DSP_GANDI = NewDnsProvider("gandi") and, with the credentials already configured, ran dnscontrol preview:

$ dnscontrol preview
**\*\*\*\***\*\*\*\***\*\*\*\*** Domain: annema.me
INFO#1: Domain "annema.me" provider gandi Error: StatusCode: 404 ; Err: 404: Unknown domain
INFO#2: DetermineNS: zone "annema.me"; Error: error while getting
Nameservers for zone="annema.me" with provider="gandi": StatusCode: 404 ;
Err: 404: Unknown domain

This confused me for a while because https://api.gandi.net/v5/domain/domains/annema.me/nameservers definitely returned information for annema.me. I had read in the Gandi provider documentation that:

It is only able to work with domains migrated to the new LiveDNS API

It wasn't until I read the Debugging section that I realized the Gandi provider is calling:

https://api.gandi.net/v5/livedns/domains/annema.me/nameservers

Which, of course, did 404, because, to avoid interruption, my domains are using Cloudflare instead of Gandi's LiveDNS.

Classic. I was trying to automate moving my DNS from Cloudflare to Gandi, only to end up back at that same text box. However, playing with DNSControl reacquainted me with DNS zone files. I figured that might be what the text box was silently asking for.

The zone file workaround

So I could not go from Cloudflare to Gandi, but perhaps I could go from Cloudflare → DNS zone (BIND) → Gandi. Out of an abundance of caution, I tested this process with another domain first, and it worked perfectly.

I updated my dnsconfig.js to include DnsProvider(DSP_BIND). After confirming with dnscontrol preview that nothing strange would happen, I ran dnscontrol push and got a zone file in ./zones/annema.me.zone.

I pasted the zone file content into Gandi's text box and switched the nameservers. To verify everything was working, I checked the DNS propagation:

dig ns annema.me

;; ANSWER SECTION:
annema.me.              86351   IN      NS      mona.ns.cloudflare.com.
annema.me.              86351   IN      NS      yichun.ns.cloudflare.com.

Ugh. DNS in a nutshell. Of course the TTL had just rolled over and would take almost a full day to propagate.

But querying Gandi's nameserver directly confirmed that my records had migrated successfully:

dig @ns-7-a.gandi.net a annema.me

;; ANSWER SECTION:
annema.me.              300     IN      A       185.199.108.153
annema.me.              300     IN      A       185.199.109.153
annema.me.              300     IN      A       185.199.110.153
annema.me.              300     IN      A       185.199.111.153

Verifying the migration

The migration worked perfectly. DNSControl's zone file export provided what Gandi's LiveDNS import expected. What started as a frustrating manual process became an automated, repeatable solution. Open source and available on GitHub.

All that done, my domain names and DNS are now handled by European companies. Part of my motivation for this move was reducing dependence on American services given the unpredictability of US politics.

I have no particular strong feelings about the US, but I do think their electoral system is problematic. I think it's an antiquated system invented to account for horse travel that both parties have kept in place because at one point or another it favored them. At least that's the only logical explanation I can come up with to keep the system in place. Trump is a democratically elected president under this system, which I believe unfairly gives more power to less populous states (I know he won the popular vote this time, my point still stands) and creates exactly the kind of uncertainty that France's Europe Minister Benjamin Haddad was referring to:

We cannot leave the security of Europe in the hands of voters in Wisconsin every four years.

The same principle applies to digital infrastructure. By using European providers I am supporting local infrastructure, reducing dependence on distant political decisions, and as an EU citizen, having some democratic input into the regulations that govern my digital rights.

Next up: moving from GitHub Pages to my Hetzner server.

Dynamic bundle identifiers in Xcode: Using xcconfig for different configurations

2025-07-17T00:00:00Z

Generally in Xcode you have two configurations: Debug and Release. It's often a good idea to have a different bundle identifier for each configuration so that your debug builds don't replace the release builds on your device.

Normal setup

For a single target I usually start with three xcconfig files: Base.xcconfig, Debug.xcconfig and Release.xcconfig. Base.xcconfig is for build settings shared by both configurations. Versions for each app/extension need to match so that's a good thing to place in your Base.xcconfig:

// Base.xcconfig
MARKETING_VERSION = 1.0
CURRENT_PROJECT_VERSION = 1

Debug.xcconfig and Release.xcconfig then look like this:

// Debug.xcconfig
#include "Base.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = "me.annema.app-name.ios.dev"

// Release.xcconfig
#include "Base.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = "me.annema.app-name.ios"

See Map build settings to a build configuration for instructions on how to configure your project to use the xcconfig files.

Safari extension

I'm working on a Safari extension which comes with 4 different targets: iOS app, iOS extension, macOS app and macOS extension. With the above approach that would mean 8 separate xcconfig files that are almost identical. The odds of a typo or copy-paste error are high. I want a single xcconfig file per target that has the dev suffix for Debug builds and no suffix for Release builds.

Conditional values

The first obvious thing I tried was to define conditional Debug and Release values:

// Base.xcconfig
PRODUCT_BUNDLE_IDENTIFIER_PREFIX = me.annema.safari-extension
PRODUCT_BUNDLE_IDENTIFIER_SUFFIX[config=Debug] = .dev

// iOS (App).xcconfig
#include "Base.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = $(PRODUCT_BUNDLE_IDENTIFIER_PREFIX)$(PRODUCT_BUNDLE_IDENTIFIER_SUFFIX)

I expected this to resolve to:

Debug: me.annema.annema.safari-extension.dev
Release: me.annema.safari-extension

But each configuration resolves to me.annema.safari-extension instead.

The trick

It's then I realized references can be nested:

// Base.xcconfig
BUNDLE_ID_SUFFIX_Debug = dev
BUNDLE_ID_SUFFIX_Release =

PRODUCT_BUNDLE_IDENTIFIER_SUFFIX = $(BUNDLE_ID_SUFFIX_$(CONFIGURATION))

Xcode sees the $(CONFIGURATION) and replaces it with Debug or Release. The outer $() then becomes $(BUNDLE_ID_SUFFIX_Debug) or $(BUNDLE_ID_SUFFIX_Release) which Xcode replaces with one of the values we've defined on the first two lines: dev for BUNDLE_ID_SUFFIX_Debug and nothing for BUNDLE_ID_SUFFIX_Release.

The result

To get the final bundle identifier we need to combine the prefix with the suffix and make the value unique for each target. The final Base.xcconfig therefor defines both a prefix and a suffix:

// Base.xcconfig
BUNDLE_ID_SUFFIX_Debug = .dev
BUNDLE_ID_SUFFIX_Release =

PRODUCT_BUNDLE_IDENTIFIER_PREFIX = me.annema.safari-extension
PRODUCT_BUNDLE_IDENTIFIER_SUFFIX = $(BUNDLE_ID_SUFFIX_$(CONFIGURATION))

The app specific xcconfigs combine the prefix and suffix:

// iOS (App).xcconfig
#include "Base.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = $(PRODUCT_BUNDLE_IDENTIFIER_PREFIX).ios$(PRODUCT_BUNDLE_IDENTIFIER_SUFFIX)

// iOS (Extension).xcconfig
#include "Base.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = $(PRODUCT_BUNDLE_IDENTIFIER_PREFIX).ios$(PRODUCT_BUNDLE_IDENTIFIER_SUFFIX).web-extension

// macOS (App).xcconfig
#include "Base.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = $(PRODUCT_BUNDLE_IDENTIFIER_PREFIX).macos$(PRODUCT_BUNDLE_IDENTIFIER_SUFFIX)

// macOS (Extension).xcconfig
#include "Base.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = $(PRODUCT_BUNDLE_IDENTIFIER_PREFIX).macos$(PRODUCT_BUNDLE_IDENTIFIER_SUFFIX).web-extension

The final bundle identifiers resolve to the following. Note that web-extension is a suffix, this is required because an extension's bundle identifier needs to be prefixed by the bundle identifier of the containing app.

Target	Debug	Release
iOS (App)	me.annema.safari-extension.ios.dev	me.annema.safari-extension.ios
iOS (Extension)	me.annema.safari-extension.ios.dev.web-extension	me.annema.safari-extension.ios.web-extension
macOS (App)	me.annema.safari-extension.macos.dev	me.annema.safari-extension.macos
macOS (Extension)	me.annema.safari-extension.macos.dev.web-extension	me.annema.safari-extension.macos.web-extension

Detecting when an Android permission can only be granted via Settings

2025-06-19T00:00:00Z

I was surprised to discover how easy it is, even when following the official Android permissions guide, to end up with a button that does nothing.

Setting the stage: how it works on iOS

On iOS CLAuthorizationStatus has 6 possible states to indicate what level of access a user has granted to their location:

public enum CLAuthorizationStatus {
case notDetermined
case restricted
case denied
static var authorized: CLAuthorizationStatus // deprecated
case authorizedAlways
case authorizedWhenInUse
}

The denied and notDetermined cases are crucial because they allow us to differentiate between a user who has been asked for access and rejected it, and a user who has not yet been asked. We know the system shows the permission request UI when CLAuthorizationStatus is notDetermined, but does nothing if the status is denied.

As a result, we can create buttons and interfaces that respond appropriately to each state. For example:

.notDetermined
We need location authorization
[Request authorization]

.denied
We need location authorization
[Open Settings]

Taking the stage: how it works on Android

Consider my surprise when I learned the equivalent Android type is:

public sealed interface PermissionStatus {
    public object Granted : PermissionStatus
    public data class Denied(
        val shouldShowRationale: Boolean
    ) : PermissionStatus
}

This type is defined by Google's Accompanist which builds on top of existing Android APIs for easier access from Jetpack Compose. In truth, Android requires separate APIs to determine whether a permission is granted or denied and if an additional rationale may be shown or not.

Android does not have an official API for detecting the difference between notDetermined and denied. As a result, there’s no standard method to send users to the settings app if they mistakenly reject a permission or want to grant it later. If implemented the official Android way, they will get a button that simply does nothing.

The maintainer of Accompanist admits as much and agrees it's terrible UX. Luckily someone in the comments provided a partial solution. It's partial because it only supports asking for a single permission, but precise location access on Android requires two separate permissions: android.permission.ACCESS_COARSE_LOCATION and android.permission.ACCESS_FINE_LOCATION. It works by remembering the original state of the permission and directing the user to Settings if the permission changed from Denied(shouldShowRationale=true) to Denied(shouldShowRationale=false).

Intermission: understanding how permissions change

Before we can understand the final solution we need to understand how permissions change as the user rejects all or partial permissions:

Rejecting all permissions

The flow for rejecting all permissions is the same as for rejecting a single permission, meaning we can use the same approach as the original implementation but looking at all the requested permissions instead.

Initial state

The state of permissions when the user first launches the app or has previously rejected all permissions.

Permission	PermissionStatus
`ACCESS_COARSE_LOCATION`	`Denied(shouldShowRationale=false)`
`ACCESS_FINE_LOCATION`	`Denied(shouldShowRationale=false)`

First rejection

After the user first rejects permissions Android gives us the opportunity to provide an additional rationale for why it's necessary:

Permission	PermissionStatus
`ACCESS_COARSE_LOCATION`	`Denied(shouldShowRationale=true)`
`ACCESS_FINE_LOCATION`	`Denied(shouldShowRationale=true)`

Second rejection

Because the user rejects the permission again we're no longer allowed to show a rationale. The system will no longer show system UI when asked.

Permission	PermissionStatus
`ACCESS_COARSE_LOCATION`	`Denied(shouldShowRationale=false)`
`ACCESS_FINE_LOCATION`	`Denied(shouldShowRationale=false)`

The important state change

Because the permission state changes from Denied(shouldShowRationale=true) to Denied(shouldShowRationale=false), we know that the user has denied us for the final time and can instead open the Settings app.

In code:

currentState is PermissionStatus.Denied && currentState.shouldShowRationale &&
newState is PermissionStatus.Denied && !newState.shouldShowRationale

Rejecting partial permissions

The flow for partial permissions is slightly different:

Initial state

The state of permissions when the user first launches the app or has previously rejected all permissions.

Permission	PermissionStatus
`ACCESS_COARSE_LOCATION`	`Denied(shouldShowRationale=false)`
`ACCESS_FINE_LOCATION`	`Denied(shouldShowRationale=false)`

Partial approval

The user allowed coarse location, but not fine.

Permission	PermissionStatus
`ACCESS_COARSE_LOCATION`	`Granted`
`ACCESS_FINE_LOCATION`	`Denied(shouldShowRationale=false)`

Second partial approval

The user is asked to change location access from coarse to fine but rejects it.

Permission	PermissionStatus
`ACCESS_COARSE_LOCATION`	`Granted`
`ACCESS_FINE_LOCATION`	`Denied(shouldShowRationale=false)`

The important state change

In this case we see that with the first and second partial approvals the permission state doesn't change at all. We can detect this specific state by making sure that at least one permission was granted and the permission state didn't change:

if (newPermissionStates.any { !it.value.isGranted } && currentPermissionsStates == newPermissionStates)

Unfortunately, there is still an issue with this approach. After rejecting the change from approximate to precise location, the system UI dismisses and the Settings app opens immediately. Ideally this would happen the next time they tap the button, like it does when all permissions are rejected. I decided that this is good enough for me. It should be relatively rare and I've already spend more time on this than I wanted.

Applause: the full solution

package io.ipinfo.android.extensions

import android.app.Activity
import android.content.Context
import android.content.ContextWrapper
import android.content.pm.PackageManager
import android.util.Log
import androidx.compose.runtime.Composable
import androidx.compose.runtime.Stable
import androidx.compose.runtime.derivedStateOf
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.platform.LocalContext
import androidx.core.app.ActivityCompat
import androidx.core.content.ContextCompat
import com.google.accompanist.permissions.ExperimentalPermissionsApi
import com.google.accompanist.permissions.MultiplePermissionsState
import com.google.accompanist.permissions.PermissionState
import com.google.accompanist.permissions.PermissionStatus
import com.google.accompanist.permissions.isGranted
import com.google.accompanist.permissions.rememberMultiplePermissionsState
import com.google.accompanist.permissions.rememberPermissionState
import com.google.accompanist.permissions.shouldShowRationale

// Extend Accompanist to detect when a permission needs to be granted through the Settings app.
// Inspired by: https://github.com/google/accompanist/issues/1363#issuecomment-1326516265

/** Find the closest Activity in a given Context. */
internal fun Context.findActivity(): Activity {
    var context = this
    while (context is ContextWrapper) {
        if (context is Activity) return context
        context = context.baseContext
    }
    throw IllegalStateException("Permissions should be called in the context of an Activity")
}

internal fun Context.checkPermission(permission: String): Boolean {
    return ContextCompat.checkSelfPermission(this, permission) ==
        PackageManager.PERMISSION_GRANTED
}

internal fun Activity.shouldShowRationale(permission: String): Boolean {
    return ActivityCompat.shouldShowRequestPermissionRationale(this, permission)
}

private val TAG = "ExtendedAccompanist"

/** `true` if a rationale should be presented to the user. */
@ExperimentalPermissionsApi
internal val PermissionStatus.shouldShowRationale: Boolean
    get() =
            when (this) {
                PermissionStatus.Granted -> false
                is PermissionStatus.Denied -> shouldShowRationale
            }

@ExperimentalPermissionsApi
@Composable
fun rememberPermissionState(
        permission: String,
        onCannotRequestPermission: () -> Unit = {},
        onPermissionResult: (Boolean) -> Unit = {},
): ExtendedPermissionState {
    val context = LocalContext.current

    var currentShouldShowRationale by remember {
        mutableStateOf(context.findActivity().shouldShowRationale(permission))
    }

    var atDoubleDenialForPermission by remember { mutableStateOf(false) }

    val mutablePermissionState =
            rememberPermissionState(permission) { isGranted ->
                if (!isGranted) {
                    val updatedShouldShowRationale =
                            context.findActivity().shouldShowRationale(permission)
                    if (!currentShouldShowRationale && !updatedShouldShowRationale)
                            onCannotRequestPermission()
                    else if (currentShouldShowRationale && !updatedShouldShowRationale)
                            atDoubleDenialForPermission = false
                }
                onPermissionResult(isGranted)
            }

    return remember(permission) {
        ExtendedPermissionState(
                permission = permission,
                mutablePermissionState = mutablePermissionState,
                onCannotRequestPermission = onCannotRequestPermission,
                atDoubleDenial = atDoubleDenialForPermission,
                onLaunchedPermissionRequest = { currentShouldShowRationale = it }
        )
    }
}

@OptIn(ExperimentalPermissionsApi::class)
private fun permissionStates(context: Context, permissions: List<String>): Map<String, PermissionStatus> {
    return permissions.associate {
        if (context.checkPermission(it)) {
            it to PermissionStatus.Granted
        } else {
            it to PermissionStatus.Denied(
                shouldShowRationale = context.findActivity().shouldShowRationale(it)
            )
        }
    }
}

@OptIn(ExperimentalPermissionsApi::class)
@Composable
fun rememberMultiplePermissionsState(
        permissions: List<String>,
        onPermissionsResult: (Map<String, Boolean>) -> Unit = {},
        onCannotRequestPermission: () -> Unit = {}
): ExtendedMultiplePermissionState {
    val context = LocalContext.current
    var currentPermissionsStates by remember {
        mutableStateOf(permissionStates(context, permissions))
    }

    var atDoubleDenialForPermission by remember { mutableStateOf(false) }

    val mutablePermissionState =
            rememberMultiplePermissionsState(
                    permissions,
                    onPermissionsResult = { newPermissions ->
                        val newPermissionStates = newPermissions.mapValues {
                            if (it.value) {
                                PermissionStatus.Granted
                            } else {
                                PermissionStatus.Denied(
                                    shouldShowRationale = context.findActivity().shouldShowRationale(it.key)
                                )
                            }
                        }

                        Log.d(
                            TAG,
                            """
                               ------------
                               onPermissionResult
                               current: $currentPermissionsStates
                               new: $newPermissionStates
                               --------------
                            """.trimIndent()
                        )

                        // show settings when at least one permission is denied and the current and new permissions haven't changed.
                        if (newPermissionStates.any { !it.value.isGranted } && currentPermissionsStates == newPermissionStates) {
                            onCannotRequestPermission()
                        } else {
                            for (permission in permissions) {
                                val currentState = currentPermissionsStates[permission]
                                val newState = newPermissionStates[permission]
                                if (
                                    currentState is PermissionStatus.Denied && currentState.shouldShowRationale &&
                                    newState is PermissionStatus.Denied && !newState.shouldShowRationale
                                ) {
                                    onCannotRequestPermission()
                                    break
                                }
                            }
                        }

                        onPermissionsResult(newPermissions)
                    }
            )

    return remember(permissions) {
        ExtendedMultiplePermissionState(
                permissions = mutablePermissionState.permissions,
                mutablePermissionState = mutablePermissionState,
                onCannotRequestPermission = onCannotRequestPermission,
                atDoubleDenial = atDoubleDenialForPermission,
                onLaunchedPermissionRequest = {
                    currentPermissionsStates = permissionStates(context, permissions)

                    Log.d(
                        TAG,
                        """
                            onLaunchedPermissionRequest
                            current: $currentPermissionsStates
                        """.trimIndent()
                    )
                },
        )
    }
}

@OptIn(ExperimentalPermissionsApi::class)
@Stable
class ExtendedPermissionState(
        override val permission: String,
        private val mutablePermissionState: PermissionState,
        private val atDoubleDenial: Boolean,
        private val onLaunchedPermissionRequest: (shouldShowRationale: Boolean) -> Unit,
        private val onCannotRequestPermission: () -> Unit
) : PermissionState {
    override val status: PermissionStatus
        get() = mutablePermissionState.status

    override fun launchPermissionRequest() {
        onLaunchedPermissionRequest(mutablePermissionState.status.shouldShowRationale)
        if (atDoubleDenial) onCannotRequestPermission()
        else mutablePermissionState.launchPermissionRequest()
    }
}

@OptIn(ExperimentalPermissionsApi::class)
@Stable
class ExtendedMultiplePermissionState(
        override val permissions: List<PermissionState>,
        private val mutablePermissionState: MultiplePermissionsState,
        private val atDoubleDenial: Boolean,
        private val onLaunchedPermissionRequest: (shouldShowRationale: Boolean) -> Unit,
        private val onCannotRequestPermission: () -> Unit
) : MultiplePermissionsState {
    override val revokedPermissions: List<PermissionState> by derivedStateOf {
        permissions.filter { it.status != PermissionStatus.Granted }
    }

    override val allPermissionsGranted: Boolean by derivedStateOf {
        permissions.all { it.status.isGranted } || // Up to date when the lifecycle is resumed
        revokedPermissions.isEmpty() // Up to date when the user launches the action
    }

    override val shouldShowRationale: Boolean by derivedStateOf {
        permissions.any { it.status.shouldShowRationale } &&
                permissions.none { !it.status.isGranted && !it.status.shouldShowRationale }
    }

    override fun launchMultiplePermissionRequest() {
        onLaunchedPermissionRequest(mutablePermissionState.shouldShowRationale)
        if (atDoubleDenial) onCannotRequestPermission()
        else mutablePermissionState.launchMultiplePermissionRequest()
    }
}

New website

2025-06-09T00:00:00Z

I wrote my last blog post in 2016. Ever since I felt like I wasn't doing anything worth writing about. I was no longer enjoying myself as a software developer. I burned out. There were a lot of factors that contributed to my burnout but one of them was definitely that I no longer enjoyed the way I built software. Unfortunately it took years to gain the insight that I still enjoyed making products, but not the way I was making them.

There were many ideas and inspirations that contributed to my recovery. On a personal level raising my kids taught me valuable lessons in recognizing, feeling and dealing with my own emotions. Through the raising humans kind podcast, The explosive child and How to talk so kids will listen & listen so kids will talk I discovered a different way to raise my kids while simultaneously learning how to better recognize my own emotions. It's hard to summarize but if I had to it's: Respect feelings; limit behavior. It's okay to be sad; it's not okay to hit your siblings.

As a way to remind ourselves that all feelings are okay we have this Inside out poster framed on a wall in our living room:

Professionally I learned about the term Product developer from PostHog which gave name to my professional identity. I've always known I'm not a typical software developer but it wasn't until I learned of the concept product developer that I was able to truly understand and articulate the difference.

I skipped a lot of things that contributed to my burnout; heck I probably haven't discovered a lot of the reasons. All the insights I did gain brought me to a simple conclusion: I lost the joy of creation.

Recovering from burnout was finding that joy again and I did.

I found it in Health shortcuts and brb. I started building iOS apps in 2007 (yes, before there was an official SDK) but these are the first apps I published myself. I'm incredible proud of my apps but simultaneously I tire of their uniformity. iOS and Android are optimized to make apps that look and feel like any other app. While it means someone with little visual design talent, me, can ship something by myself, it also means every app looks and feels the same. I scratched my creative itch, but I was still itching.

It's then I found a new community. A community that has existed since the early days of the internet. A community that has persisted through the uniformity of Bootstrap and Tailwind. A community that articulated some of my feelings about React. A community that exists outside of walled gardens. A community that is accessible to anyone (with a computer and an internet connection). A community that believes in owning our part of the internet.

I started following Piccalily and Andy Bell. I began learning about Modern CSS. I noticed the similarities between mobile and web development, accepted that modern software development is different than when I started and realized the web has always been better at non-uniform responsive and inclusive design than even SwiftUI and Jetpack Compose are today.

Most importantly I found myself using view source to see how Lea Verou made the sun in the blog header animate. To get inspiration for naming my variables. To learn how Stuart made his customizable background pattern work. Dreamed about one day having a site so cool that it's vibe changes based on the time off day. I appreciated all this for what it was: art. Accessible to anyone.

I left all the walled gardens but I didn't replace it with anything. This gestures to the surroundings is my replacement. My own humble space on the internet. Outside of any walled gardens and accessible to anyone. Welcome.

Find time zones where it's currently a certain time

2016-05-05T08:18:00Z

For a project I'm working I needed a function that returns the time zones where it's currently 9am. I generalized the function to be able to find time zones where it's currently any time. My Swift implementation was inspired by this stackoverflow answer, providing code for the same problem in Ruby.

func timeZonesWhereItIs(hour: Int, _ minute: Int = 0) -> [NSTimeZone] {
  let calendar = NSCalendar.init(calendarIdentifier: NSCalendarIdentifierGregorian)!
  calendar.timeZone = NSTimeZone(name: "UTC")!
  let currentUTCTime = NSDate()

  return NSTimeZone.knownTimeZoneNames().flatMap(NSTimeZone.init).filter { timeZone in
      let components = calendar.componentsInTimeZone(timeZone, fromDate: NSDate())
      components.hour = hour
      components.minute = minute
      let date = calendar.dateFromComponents(components)!

      return calendar.isDate(date, equalToDate: currentUTCTime, toUnitGranularity: .Hour)
  }
}

Usage:

timeZonesWhereItIs(12, 14)

To find a time zone at each hour offset use it as follows:

func timesZonesForEveryHour() -> [NSTimeZone] {
  return (0..<24).flatMap { timeZonesWhereItIs($0).first }
}

Note that there are time zones that are offset by 30 and 15 minutes. This function won't return those.

Have fun.

Gesture Recognizers in Swift

2015-07-08T22:52:00Z

I wrote about using Gesture Recognizers in Swift for thatthinginswift.com.

I ran into a couple of surprises using gesture recognizers in Swift. Nothing major, but definitely things to look out for. Head over to the article to read more about it.

Nick is also looking for more contributors. If you're interested send a PR. If you need inspiration for topics take a look at issues 8.

Ruby's tap method in Swift

2015-03-18T12:38:00Z

Ruby has a nice method called tap, which I wanted to try and port to Swift. To learn what it does, let's take a look at Ruby's documentation:

Yields self to the block, and then returns self. The primary purpose of this method is to "tap into" a method chain, in order to perform operations on intermediate results within the chain.

Yeah, right. I don't really know what that means. Googling yields (no pun intended) many contrived examples like these:

[1, 2, 3, 4].tap &:reverse! # [4, 3, 2, 1]

In Swift the same can be written as:

tap([1, 2, 3, 4], reverse) // [4, 3, 2, 1]

A less contrived example would be:

User.new.tap do |user|
    user.name = "Yukihiro Matsumoto"
    user.known_for = "Ruby"
end

In the latter case tap is acting as a sort of improptu builder. In Swift:

tap(user) {
    $0.name = "Chris Lattner"
    $0.knownFor = "Swift"
}

Note that the previous example requires every property of the user to be mutable (var). This example should only be seen as a comparison to Ruby. Please don't do this in your actual code unless you absolutely have to.

That said, we've established a public API, it's time to start implementing. If you want to follow along; I've made a playground available.

In the Ruby source tap is implemented like so:

VALUE
rb_obj_tap(VALUE obj)
{
    rb_yield(obj);
    return obj;
}

Translating that to actual Ruby:

class Object
  def tap
    yield self
    self
  end
end

My first attempt was a copy of Ruby's implementation, but in a global function. I'm not a huge fan of the global functions in Swift, but it works out nicely because we won't have to extend any existing objects.

func tap(object: AnyObject, block: (AnyObject) -> ()) -> AnyObject {
    block(object)
    return object
}

Great, we threw out all type safety in an attempt to be as dynamic as Ruby. It also doesn't compile.

Let's introduce some generics:

func tap<A>(var object: A, block: (inout A) -> ()) -> A {
    block(&object)
    return object
}

This does compile, and it's type safe to boot:

tap([1, 2, 3], reverseInPlace)

Note that Swift doesn't have a built-in reverse in place method like Ruby does. If you're interested in what that looks like; take a look at the gist.

A less contrived example would be:

tap(NSDateComponents()) {
    $0.day = 18
    $0.month = 06
    $0.year = 1986
    $0.calendar = NSCalendar.currentCalendar()
}.date

If you got this far, you might be wondering: do we need a tap function? The answer is: maybe. In Objective-C we could use GCC code block evaluation to similar effect. In Swift we should be able to write:

let date = {
    let c = NSDateComponents()
    c.day = 18
    c.month = 06
    c.year = 1986
    c.calendar = NSCalendar.currentCalendar()
    return c
}().date

Unfortunately this confuses the type system. It is unable to infer the return type of the block. Instead we have to write:

let date = { () -> NSDateComponents in
    let c = NSDateComponents()
    c.day = 18
    c.month = 06
    c.year = 1986
    c.calendar = NSCalendar.currentCalendar()
    return c
}().date

For now, tap is a safer and arguably more readable alternative but it's likely that the Swift compiler will solve the entire issue more elegantly in the future.

Update: Several people on Twitter have pointed out to me that my implementation wasn't an exact reproduction. The post has been updated with a better implementation. If you're interested in my incorrect implementations take a look at the revision history of the gist.

The Builder Pattern in Swift

2015-02-02T19:51:00Z

A while ago I wrote a post about implementing the builder pattern in Objective-C. Today we're going to do the same for Swift.

In the previous post the end result was:

Pizza *pizza = [Pizza pizzaWithBlock:^(PizzaBuilder *builder]) {
    builder.size = 12;
    builder.pepperoni = YES;
    builder.mushrooms = YES;
}];

There is a couple of things that can be improved here:

The syntax. I don't mind Objective-C, but there are definitely some superfluous characters.
Failability. A pizza without a size doesn't make sense. Adding this to Objective-C is not impossible, but a decision has to be made on how to represent failures. Do we throw an exception when a size isn't set? Return nil from an initializer? Maybe even have an isValid method with an error parameters that is returned by reference?

In turns out, builder can be done better in Swift. This is what it looks like when using the same Pizza example from the previous post:

Pizza() { builder in
    builder.size = 12
    builder.cheese = .Mozzarella
    builder.pepperoni = true
}

The Pizza initializer takes a block, with the builder as it's parameter. In the trailing closure we set the properties of the pizza. So far it's exactly the same as Objective-C with slightly better syntax. From this point on things are different. After the block is executed we have an optional Pizza, whereas in Objective-C we had a potentially invalid Pizza. As mentioned before, preventing this in Objective-C is possible, but a decision has to be made on how to present the error. In my experience these kinds of errors usually end up being ignored, becoming a hard to find bug at some point in the future.

Back to Swift; we ended with an optional Pizza. By making the result an optional we make it easier to deal with physical impossibilities; like a Pizza without a size. To see how this works, take a look at the initializers:

init?(block: (PizzaBuilder -> Void)) {
    let builder = PizzaBuilder()
    block(builder)
    self.init(builder: builder)
}

init?(builder: PizzaBuilder) {
    if contains([12, 14, 16], builder.size) {
        self.size = builder.size
        self.cheese = builder.cheese
        self.pepperoni = builder.pepperoni
        self.mushrooms = builder.mushrooms
    } else {
        return nil
    }
}

Both initializers are what are called failable initializers. They either return an optional Pizza or nil. In our example the only way the initializer fails is when the size isn't 12, 14, or 16 inch.

Check out my entire Pizza implementation in this gist.

Swift arguably makes the syntax for a builder nicer. It also makes modeling failure easier by making it a core part of the language. After the Pizza is initialized from the builder there is only one question left: Is the Pizza a lie?

Configure your iOS app for multiple environments

2014-11-20T18:50:00Z

Two weeks ago I wrote a post about cleaning up your application delegate with initializers. I eluded to a Configuration object in that post. I decided to make this two separate posts because they're different concepts that happen to work together.

The Karma app has to run in 3 environments: Development, Pre-release and Production. We also have some secondary environments, like Test and Device, which are subsets of respectively Development and Production.

Each environment is different. In Development crashes are not reported and Facebook's development environment is used for authentication. In production (read: App Store) crashes are reported and the app communicates with our production APIs. This requires connecting to different URLs and authenticating with different keys.

One solution, unfortunately used frequently, is preprocessor macros. When you create a project, Xcode automatically configures a DEBUG=1 preprocessor macro for Debug builds. The macro is not defined for release builds so it's possible to target different environments:

#if DEBUG
NSString *const KPAThirdPartyServiceKey = @"debug123";
#else
NSString *const KPAThirdPartyServiceKey = @"release123";
#endif

This is known as conditional compilation. The code in the DEBUG block will not be part of a Release build and vice versa. Meaning both environments run different code. This is great if you're targeting different architectures, say ARM and Intel, because doing the same thing requires different APIs.

It's awful for configuring environment, because 1) it's an unnecessary conditional (that doesn't indent in Xcode) 2) you're literally shipping code that's different from what you use to debug. In this simple example it will likely never cause problems, but it'll become more complicated over time. Consider what happens when introducing a third environment. As mentioned before, the Karma app has 3 primary environments and several subsets of those. Using conditional compilations, we would need several levels of nested conditionals to support every environment.

What we want is a way to automatically load different configurations for different environments. We'll need 3 things to make this work:

An object to hold the configuration values
A way of differentiating between environments (without using conditional compilation and preferably no other type of conditional)
A system to load different configuration values for each environment

I've made an example project available on Github that has these 3 things. Let's go over them one by one.

The Configuration Object

The Configuration object solves requirement one. It holds configuration values in a dictionary and makes them available through a settingForKey: method. The object also partially solves requirement 3 because it can populate itself by loading a plist. More on that later.

Differentiating between environments

Before we can fully solve requirement 3 we first need a way of differentiating between environments. I've done this in the example project by creating different build configurations. In Xcode 6.1 you can find build configurations by clicking on the project in the Project Navigator then selecting the project again under "PROJECT" in the editor. From there go to the "Info" tab. You should see a "Configurations" section, which by default, has a Debug and Release configuration. In the example project I called them: Development, Staging and Production. You can create as many as needed and give them any name you see fit.

For convenience I also created a scheme for each build configuration. This makes it easy to build for a certain environment by simply selecting it's corresponding scheme.

Loading different configurations per environment

Now that we have a way to differentiate between environments it's time to discover how we can load a configuration for each. This is already partially solved by the Configuration object. In the loadDefaults method it will search for the ConfigurationPlist key in the Info.plist. In other words: all we need is a way to make this key have a different value for each environment.

When a value in the Info.plist is enclosed in $(), the key between () will be looked up in your build settings (I searched for documentation on this, but couldn't find any). In the example project the ConfigurationPlist value is $(CONFIGURATION_PLIST). To make it work, we need to add a build setting called "CONFIGURATION_PLIST" and give it a different value for each build configuration.

To add a build setting, select the project in the Project Navigator, select the target (in the Example app it's called "Configuration") under "PROJECTS" and switch to the "Build Settings" tab. In this tab you can add more build settings by clicking the plus icon and selecting "Add User-Defined Setting" from the popup menu. Name it "CONFIGURATION_PLIST". Now click the arrow on the left side, you'll see that Xcode allows you to change the value for each build configuration. How you name these is up to you. I follow [Environment]-Config as a naming pattern.

The final step is to create the plists. If you look at the example project you'll see there is one plist for each environment: Development-Config.plist, Staging-Config.plist and Production-Config.plist. I also added two keys: environment and report_crashes. These are just two examples, you can add any configuration options in these plists.

All that's left is to access your settings at runtime:

[[Configuration defaultConfiguration] settingForKey:@"report_crashes"];

Wrapping up

In the Karma app I combine this approach with the Initializer pattern I explained in my previous blog post. Each initializer is passed a Configuration object, allowing it to grab the settings it needs to initialize the portion of the app it's responsible for.

It takes some setup, but you end up with an easy way of loading distinct settings per environment. Adding more environments takes a couple of steps, but it's a lot easier than having to go through your code and update conditionals and hardcoded strings everywhere.

While writing this post I discovered KZBootstrap attempts to solve the same problem. I haven't looked at it in detail, but being able to change configurations at runtime is one thing it has over my solution. When it comes to using it I have to agree with Dave Verwer who had this to say about it in issue 168:

However, before you jump in with both feet I'm not completely convinced that iOS projects actually need a bootstrap. There are some good recommendations here though so what I would recommend is to take a look at this, spend some time understanding it and then pick bits that work for you. Blindly using someone else's defaults is only going to lead to surprises down the line.

I've thought about open sourcing my approach, but haven't figured out how to automate the Xcode setup. There is promise in some of the tools that power CocoaPods, but haven't had the time yet to look into it.

I'm happy to see that more developer are trying to solve this problem. From my experience it's something most of us run into at some point. When I wrote my solution I couldn't find anyone who'd shared their solution, forcing me to come up with my own.

Clean up the application delegate with initializers

2014-10-30T16:48:00Z

The application delegate has a tendency to become unwieldy. It provides a ton of callbacks to respond to about every possible state change of your app. The method that grows quickest is usually applicationDidFinishLaunching:withOptions:^{[citation needed]}. From preloading content for a better experience, to configuration third party services, it all tends to end up in that same method.

I've been using the concepts of initializers recently. An initializer is an object that conforms to the Initializer protocol with just one required method: performWithConfiguration:.

You might wonder what the configuration argument is, but for now I want to focus on the concept of initializers. For the purpose of this blog post it is sufficient to think of the configuration object as a dictionary that contains configuration options. For example: keys for third party services, or the log level.

Let's take a look at an initializer implementation. This is the initializer I use to configure HockeyApp in the Karma app.

  - (void)performWithConfiguration:(id<Configuration>)configuration;
{
    if (![configuration settingForKey:HockeyAppIdentifierKey]) {
        DDLogWarn(@"No Hockey Identifier in configuration: %@", configuration);
        return;
    }

    BITHockeyManager *manager = [BITHockeyManager sharedHockeyManager];
    id delegate = [UIApplication sharedApplication].delegate;
    [manager configureWithIdentifier:[configuration settingForKey:HockeyAppIdentifierKey] delegate:delegate];
    manager.disableCrashManager = [[configuration settingForKey:HockeyAppCrashesDisabledKey] boolValue];
    manager.crashManager.crashManagerStatus = BITCrashManagerStatusAutoSend;
    [manager.authenticator authenticateInstallation];
    [manager startManager];
}

Initializers aren't always about third party services. The following initializer preloads the store whenever the app launches. Notice that it completely ignores the configuration argument:

@implementation StoreInitializer

- (void)performWithConfiguration:(id<Configuration>)configuration;
{
    [[ProductFetcher sharedFetcher] fetch];
}

- (BOOL)shouldPerformWhenApplicationEntersForeground;
{
    return YES;
}

@end

This initializer also implements the shouldPerformWhenApplicationEntersForeground optional method. This method allows initializers to let the application delegate know they should also be run when the application enters the foreground.

Now all that is left is running the initializers every time the app launches. In your app delegate simply add the following to application:didFinishLaunchingWithOptions::

[self.initializers makeObjectsPerformSelector:@selector(performWithConfiguration:) withObject:[Configuration defaultConfiguration]];

You can run initializers when the application enters the foreground by adding this to the applicationWillEnterForeground: method:

[self.initializers enumerateObjectsUsingBlock:^(id<Initializer> initializer, NSUInteger idx, BOOL *stop) {
    if ([initializer respondsToSelector:@selector(shouldPerformWhenApplicationEntersForeground)]
        && [initializer shouldPerformWhenApplicationEntersForeground]) {
        [initializer performWithConfiguration:[Configuration defaultConfiguration]];
    }
}];

In both examples self.initializers is an array of initializers. In the Karma app the property is implemented like this:

  - (NSArray *)initializers;
{
    if (!_initializers) {
        _initializers = @[
            [[LoggingInitializer alloc] init],
            [[HockeyInitializer alloc] init],
            [[WontonInitializer alloc] init],
            [[FacebookInitializer alloc] init],
            [[StoryboardInitializer alloc] init],
            [[StoreInitializer alloc] init],,
            [[APNInitializer alloc] init]
        ];
    }

    return _initializers;
}

By encapsulating initialization logic into it's own object you can keep the application delegate just that much cleaner. If by this point you're wondering what that configuration argument really is. Be patient. That will be the subject of a next post.

Adopting a new programming language

2014-07-02T17:33:00Z

Over the course of my short career I've had the opportunity to build production-quality software in many new languages. I like learning new languages. I think it makes me a better developer. My skill level is probably average in most of the languages I’ve worked with, but I've learned something useful from each and every one.

Here's my approach to adopting a new language.

Commit!

There’s no use in trying to adopt something if the language you’re comfortable with is looming nearby: have a specific goal in mind and commit to it. Write a program, write a single class, do a beginners tutorial. Anything, as long as it commits you to writing the new language and nothing else.

Stay idiomatic

Most programmers I know, including myself, will come to a new language and start complaining about what it lacks. Most of us will also immediately start looking for ways to incorporate the favorite features from our language of choice.

Avoid this at all costs. People are productive in the language every day. It is very likely they have a better, more idiomatic, solution for the problem you're trying solve. Don't try to get back into your comfort zone by turning a language into something it's not. You want to learn something new, not force your old knowledge into another context.

Learn when you have a better solution

Eventually you'll become comfortable in a language. You'll know which solutions have been tried and which don't work for you. This is the point to start incorporating past experiences, never earlier. Note that it can take months, if not years, to get to this level of proficiency. If you're not sure, you're not ready yet.

Side note: I'm talking about language patterns that apply to specific languages. You should always try to follow good software practices. Regardless of language you should always be on the lookout for Law of Demeter and Lyskov violations.

Learn the frameworks

Programming languages are born, evolve and are discarded. Knowing the big concepts will help you transition to any new language. — Saul Mora

Most programming languages have similar syntax, so learning the syntax usually isn't the hardest part. Unless you're designing a language, it doesn't really matter how a method is called. It's the frameworks where you have the most opportunity to learn about new patterns, or novel ways to use them.

One trick I picked up to learn is to take warnings seriously. It's easy to ignore warnings when learning a new language. Especially early on, you might not yet really know what is going on, and the warnings might be very cryptic and hard to understand. Don't ignore them. Warnings are meant to tell you about a potential problem, an issue that is likely to cause a bug at some point. Only ignore them if you truly know what you're doing.

Warnings give you an opportunity to learn something new. Frameworks often warn about using it in ways that might become problematic. By exploring these warnings, you learn a little about the assumptions and inner workings of the framework. Only after learning what the warning means should you decide to ignore the warning.

Become part of the community

When you first get started, you might not know anybody in that community. That means there’s no one to reach out to when you get stuck. It's important to find people that can help you learn.

Try to go to meetups. If you're in a hub like New York, there's probably a ton. If not try, to at least go to a conference. Regardless of where you are in the world you’ll want to engage with the community online.

The best way to get yourself known is speaking. It might be hard to get in, because organisers don't know you, but you do have a unique perspective now. You've learned their language coming from a different background, and should be able to give an interesting talk about it. Talk about the challenges of adopting the language. Talk about things you find good/bad in the community. You have an unbiased view of what it's like to get started and the community can learn from that.

Learn how to navigate the docs

The documentation is your number one go-to for problems and discovery. Learning to navigate the documentation means you can find things faster. Most community-maintained frameworks also adopt the documentation style and design of the language. For example, most Ruby documentation looks like, well, ruby doc. By just learning to navigate the language's docs, you're simultaneously getting familiar with how most of the community documents their code.

Embrace the change

Initially you will literally feel overwhelmed. Programming is making choices and for the first couple of weeks you will feel like every choice you make is stupid and wrong. In short, you will have no clue what you're doing. At some point or another you probably have to suppress the urge to find whoever wrote the documentation and have a good chat with him. Don't let this feeling discourage you. You're outside of your comfort zone; you should, by definition, feel uncomfortable.

Edit: I made a bad joke about PHP. I probably thought it was funny at the time, but reading it now; it does not fit this post nor my blog. This is about encouraging everyone to learn new things and the comment detracts from that. PHP is used succesfuly every day and joking about it only disrespects its community. Linking to Buffer, a company advocating positivity and succesfully using PHP, in the same paragraph makes it even worse. I apologize. I left the comment in for posterity.

We're all software developers. You're not just a Ruby developer, I'm not just an Objective-C developer, ~~and in some circles you don't want to identify yourself as a PHP developer~~. More diversity in your knowledge and your experiences means you'll be able to build more interesting things. Or as the Buffer Blog said it:

The more of these building blocks we have, and the more diverse their shapes and colors, the more interesting our castles will become.

Hour formatting with NSDateFormatter dateFormatFromTemplate

2014-05-27T17:00:00Z

TLDR; Using NSDateFormatter's dateFormatFromTemplate:options:locale: for 12/24 hours? Use "j" instead of "h" or "H" for the hour format.

Last week I started a fight with NSDateFormatter. I needed to format just the hour of an NSDate. Formatting hours is especially tricking because unlike any other date component, the same hour can be shown in two different formats, 12 hour with am/pm designator or 24 hour.

To generate the date format I'm using NSDateFormatter's dateFormatFromTemplate:options:locale: class method. This was my first try:

[NSDateFormatter dateFormatFromTemplate:@"HH a" options:0 locale:[NSLocale currentLocale];

The template string uses 24 hour format but also includes the am/pm designator 'a'. HH stands for 0 prefixed 0-23 hours. I wasn't exactly sure how to use this method but my expectation was that it would be rewritten to "hh a" and "HH" for 12 and 24 hours respectively.

This appears works. On my phone (set to nl_NL and 24 hour time format), toggling the 12/24 hour setting would correctly change the generated format. In the simulator and on one of our test phones it did not. The test phone was set to 12 hour clock and it's locale was set to en_US, but dateFromTemplate:options:locale: always returned "HH" as the date format.

I changed the template to read hh a. This again appeared to work except on my phone. Which would now always format 12 hour time. I reversed the problem.

NSDateFormatter is documented to try to rewrite the format to match the 12/24 hour preference in the Settings app. My guess is that this is why toggling the preference appeared to work for phones that were set to the same locale as the template string I was passing in.

After googling and trying to comprehend the Unicode Technical Standard it finally clicked. I kept glossing over the last hour designator of which the first line of the description says:

This is a special-purpose symbol. It must not occur in pattern or skeleton data.

My mind would read that it shouldn't be used in pattern data and move on. Unfortunately the next line says:

Instead, it is reserved for use in skeletons passed to APIs doing flexible date pattern generation

Which is exactly the purpose of this NSDateFormatter API, just worded somewhat confusingly. Eventually the fix was to change the template line to:

[NSDateFormatter dateFormatFromTemplate:@"jj" options:0 locale:[NSLocale currentLocale];

and all was good in the world.

Builder and GCC Code Block Evaluation

2014-05-19T16:04:00Z

My post about the builder pattern got great responses and a lot of people offered alternative solutions to the same problem. The most popular suggestion was to use GCC Code Block Evaluation without the separate builder object. Using the pizza example from the previous post it looks like this:

Pizza *pizza = ({
    Pizza *builder = [[Pizza alloc] init];
    builder.size = 10.0;
    builder.pepperoni = YES;
    builder.mushrooms = YES;
    builder;
});

While this gives the same advantages to code organization there is nothing stopping me from modifying the pizza after it's created. One of the advantages of builder is that the created object is immutable. Immutable objects are great because they can be safely used in caches or passed around between threads.

But, we can improve this by combining the approach from my first post and this one. Let's take a look at an example using Foundation:

NSURL *url = ({
    NSURLComponents *components = [[NSURLComponents alloc] init];
    components.scheme = @"http";
    components.host = @"annema.me";
    components.path = @"the-builder-pattern-in-objective-c";
    [components URL];
)};
// URL = http://annema.me/the-builder-pattern-in-objective-c

In this example NSURLComponents is the builder object and NSURL is the immutable result. The url components are nicely enclosed in their own scope making it impossible to accidentally re-use the same instance. The created URL is immutable, giving us the same advantages of builder without having to add a special constructor to the class.

Even better is that this also works for any object that has a mutable counterpart (hat tip to Hannes Verlinde). For example NSAttributedString:

 NSAttributedString *text = ({
    NSMutableAttributedString *mutableText = [[NSMutableAttributedString alloc] init];
    [mutableText appendAttributedString:[[NSAttributedString alloc] initWithString:paragraph1]];
    [mutableText appendAttributedString:[[NSAttributedString alloc] initWithString:paragraph2]];
    [mutableText appendAttributedString:[[NSAttributedString alloc] initWithString:paragraph3]];
    [mutableText copy];
});

Before writing my post I had forgotten about GCC Code Block Evaluation. After the responses made me aware of the pattern I not only found it works great with builder, it's a great aide in code organization as well. Mattt Thompson summarized it better than I can:

If code craftsmanship is important to you, strongly consider making this standard practice in your work. It may look a bit weird at first, but this will very likely become common convention by the end of 2014.

I guess my adopting this practice in 2014 is one more step towards proving Mattt's statement.

TDD - Classicists vs Mockists

2014-04-09T15:26:00Z

A while ago I reread Martin Fowler's classic mocks aren't stubs essay. He does a great job of explaining the different schools of TDD. In summary it basically comes down to classicists, those that build the system from business models up and mockists who build the system from the UI down mocking lower level components that haven't been build yet.

The essay got me thinking about which school I belong too. I lean to the mockist side of things, but I think it's dangerous to separate ourselves between being purely mockist or purely classicist. You probably prefer one over the other but you should use whichever best solves your problem.

For example in the Karma apps we have a store where customers can buy gigabytes. When the store loads I want to verify that the buy button is displaying the price formatted as US dollars. One way of verifying this behavior is by stubbing the formatter to return a static response. In this case I consider that an implementation detail. Instead I verify that the button title is what I expect. For example the button title for a product costing $14 should be formatted as $14.00 if the locale is en-US and the currency is dollars. It should read $ 14,00 when the locale is nl-NL and the currency is dollars. This way I not only verify that the formatter is called, but also that the formatter is configured correctly.

When testing what happens after products load I would use a mock (actually I would use a fake, more on that later). I don't want my tests to hit the actual API because it can randomly fail and makes it complicated to test both success and failure cases. Instead I'd rather stub out the API abstraction and have it return what I expect.

The problem with stubbing asynchronous code is that you need to use a spy to get access to the success and error callbacks. I haven't seen any framework, in any language, that doesn't make this process convoluted. In reality I'm much more likely to use a fake implementation of the API abstraction. A fake will save the callbacks internally when products are requested. After my expectations are set up, I tell the fake to either fail or succeed.

With this approach the tests never need access to the callbacks. Fakes do introduce more, potentially buggy, code in your test suite. As long as you keep your fakes as simple as possible this should never become a major problem. Furthermore fakes, unlike real APIs, will never randomly feel (unless you use threading, luck that with good).

I like Martin's essay (seriously, read it, now!) but I think it should be made more apparent that there is no one size fits all solution. You're not a classicist or a mockist. You might prefer one over the other, but you have to assess the problem and pick the right solution.

The Builder pattern in Objective-C

2014-04-04T15:43:00Z

Learning Android and by extension Java has given me some new patterns to apply in my Objective-C code. The one that I'm most excited about is the builder pattern.

The builder pattern is an object creation pattern that fits well with Java's syntax. I've seen some adaptions to Objective-C but they all directly copy Java's implementation directly and are not very idiomatic.

Let's start off with what it looks like in Java. For my talk about applying patterns from other languages I used a Pizza model as an example, I'll use the same here. This is what it looks like:

Pizza pizza = new Pizza.Builder()
    .size(12)
    .pepperoni(true)
    .mushrooms(true)
    .build();

Think about what this would look like if you had to use a constructor. What would happen to the constructor if the restaurant decides to add more toppings or perhaps different crust types? For these kinds of objects it's easy to end up with an array of possible constructors all covering different permutations of the arguments.

This is the problem the builder pattern solves. It decouples the construction of a complex object from it's representation. The builder pattern is a so called fluent interface; an API that aims to provide more readable code.

A direct port to Objective-C looks something like this:

Pizza *pizza = [[[[[PizzaBuilder alloc] init] setPepperoni:YES] setMushrooms:YES] setSize:12] build];

Not very fluent is it? Unlike others I don't mind Objective-C's square brackets but there's a limit. The following is a more idiomatic approach. It makes use of Objective-C's dot syntax to set the properties:

PizzaBuilder *builder = [[PizzaBuilder alloc] init];
builder.size = 12;
builder.pepperoni = YES;
builder.mushrooms = YES;
Pizza *pizza = [builder build];

This definitely reads better but we're exposing the builder beyond it's minimum scope. It's possible to accidentally re-use the same object somewhere in the same method. In general the scope of variables should always be limited to their absolute minimum.

One of the most common mistakes I see when people are trying to adopt a new language is copy patterns from their favorite language and subsequently complain how bad the adopted language is. Copying the Java implementation has served us well so far but we have to let go now and make the pattern ours. Good artists copy, great artists steal.

In order to make this pattern fit Objective-C we're going to apply another pattern. This one comes from Ruby. I don't know what the official name for it is, I just call it the Ruby configuration block pattern. This is our final idiomatic Objective-C implementation:

Pizza *pizza = [Pizza pizzaWithBlock:^(PizzaBuilder *builder]) {
    builder.size = 12;
    builder.pepperoni = YES;
    builder.mushrooms = YES;
}];

We made the interface fluent, the scope of the builder is limited to within the block and as an added benefit the call to build is now implicit. When the block returns the pizzaWithBlock: method knows that configuration is finished and can call build for us. Not only did we make the pattern idiomatic Objective-C, we also removed one of the Java implementation's major headaches; forgetting to call the sentinel method.

To finish, this is the pizzaWithBlock: method implementation:

+ (instancetype)pizzaWithBlock:(PizzaBuilderBlock)block {
    NSParameterAssert(block);

    PizzaBuilder *builder = [[PizzaBuilder alloc] init];
    block(builder);
    return [builder build];
}

The builder's build method is implemented as:

- (Pizza *)build;
{
    return [[Pizza alloc] initWithBuilder:self];
}

And finally Pizza's initWithBuilder: method:

- (id)initWithBuilder(PizzaBuilder *)builder;
{
    self = [super init];
    if (self) {
        _size = builder.size;
        _pepperoni = builder.pepperoni;
        _mushrooms = builder.mushrooms;
    }

    return self;
}

I use a similar approach in APIClient. Note that I wrote this code before I knew about the builder pattern so it isn't an exact implementation. Having read this post you should now be able to improve my implementation.

I believe we can learn a lot from other languages and their communities. Unfortunately most of us don't have the time to really adopt a new language. This post serves as a shortcut. You just learned a new pattern to apply in your Objective-C code without first having to learn Java or Ruby.

Android adventures #3 - Testing

2014-04-02T15:14:00Z

Due to an injury I had to suspend training for my first half marathon for the remainder of the week. I found myself with some extra time yesterday morning. I decided to spend that time on trying to set up testing for the Karma Android app.

Honestly testing on Android is about the same state as Objective-C when I started 5(?) years ago. At Karma we test most of our code (including our iOS app) but early on we made the decision not to test our Android app. Because of my inexperience with Android learning the platform and learning how to write test for it would've just taken too much time.

I've been doing Android for a couple of months now and felt more confident that I could figure it out. If you, like me this morning, have no idea where to get started I highly recommend this article. Using this article I got it working. I immediately started writing tests for components that most need it.

The first thing I noticed is how slow tests are. Practicing BDD/TDD requires a fast test suite but the gradle build/test step takes quite some time on my state of the art MacBook Pro. This is with just one unit test, I can only imagine how slow it'll get when I get to the level of coverage that our iOS app has. Slow tests, in this case, are better than no tests so I patiently endured.

The second unit test I wrote required a mock. I'm a big fan of OCMockito for iOS and I decided to try Mockito. This is where things got hard. Googling gives me a lot of outdated and conflicting information. I'm assuming all the suggestions worked at some point in Android's Studio lifecycle but they sure as hell don't anymore.

Here are some of the things I tried:

This answer on StackOverflow. It fails with an error that instrumentTestCompile doesn't exist.
The linked documentation suggests using androidTestCompile "org.mockito:mockito-core:1.9.5". This worked but adding the static import for mockito still failed.
I believe this Google Plus post was linked in the last Android Weekly newsletter. It's a variation on the above and also didn't work.
Tried following the Gradle user guide. It constantly refers to things mentioned in previous chapters making it really hard to get just the information I need. I intend to read it at some point, but did not have the time yesterday morning.
More googling found me yet another project from Jake Wharton. Unfortunately it's deprecated. There are successors I believe but I get the feeling that this is already part of Android Studio now?

Trying to combine different solutions from different blogs all stating that theirs is the way to go took me a couple of hours and resulted in nothing.

I only just started Android but I consider the lack of good up-to-date articles a huge problem. This wasn't my first goose chase through Android blogs all recommending different things. I find the official Android documentation thorough in documenting specific APIs, but it often lacks recommended usage and best practices. When starting a new technology you need someone to tell you how it's supposed to be done. I was lucky to have some experienced developers advising me, but not every beginner has that luxury.

On the bright side, I appreciate Apple's very thorough guides a lot more now.

Android adventures #2 - The first crash

2014-03-31T15:12:00Z

Last week we introduced bug fix monday's at Karma. The goal is to have a dedicated day to fix bugs that we usually don't have time for. Because, you know, features are better.

In Android I've had a crasher for a while that falls into this category. With every release I classify it as a nice to have and end up not getting around to it. On the first bug fix monday I decided to tackle it. Problem is I have no clue why it happens.

Luckily the code was also in need of a refactor. Without a reliable way to reproduce I hope the refactor fixed the problem, but if it doesn't I found some useful features in Crashlytics to help with debugging.

First, instead of crashing I catch the NullPointerException causing the crash and use Crashlytics.logException(e); to send it as a non-fatal crash. This gives me the same information as I currently have, but without affecting the user.

I dislike catching unchecked exceptions though because I could be hiding a different problem too. In order to actually fix (instead of hide) the issue I'll need more information.

My assumption is that the crasher is related to the Fragment lifecycle thus I want to know more about it's state when the crash happens. The Fragment class has method called [dump](http://developer.android.com/reference/android/app/Fragment.html#dump(java.lang.String, java.io.FileDescriptor, java.io.PrintWriter, java.lang.String[])) but it's usage is a bit obscure to a beginning Java developer like myself. It took some googling and trial and error but this is the working solution:

ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
dump("", null, new PrintWriter(outputStream, true), null);
Crashlytics.log(Log.INFO, TAG, outputStream.toString());

This writes information about fragment to an output stream which is then logged as a string. Crashlytics will write this to LogCat and also send it with the crash report.

Hopefully the crasher has been fixed but if it isn't I'll definitely have more data to diagnose it.

Android adventures #1 — Perform task on launch

2014-03-27T16:54:00Z

I'm going to try and apply the Brent Simmons approach to Android development. This is the first installment.

I need a way to do something when my Android app is launched. Most Google results I find are about getting notified when another app launches. I'm just interested in when my app launches because I need to load the user's authorization token from disk and create the session.

I realize that most of my readers probably do iOS so let me explain why this is hard. On iOS there is the AppDelegate. Whenever your app launches that's where you do these kinds of common setup. Android apps consists of 1 or more Activities. Every activity is a completely decoupled component that can be launched separately. In other words when the StoreActivity opens there is no guarantee that the MainActivity or any other activity was started before that. In a way you can see Android activities as the AppDelegate and a ViewController merged into the same thing.

Back to the problem at hand. A solution would be to use an abstract superclass for every activity and have that manage creating the session in onCreate:. I dislike this because what to do when I need a ListActivity. I can't dynamically change the superclass of a built-in activity (Technically I probably could, it just sounds like a bad idea). Another reason is that I already have an abstract superclass. Every activity in the Karma app needs to monitor the hotspot status and update the background color accordingly. Now I would need a AbstractHotspotActivity and a AbstractSessionActivity which inherits from that? The other way around wouldn't work because not every activity can be launched without going through the MainActivity first. Mixins where are you when I need you?

Another solution is to subclass Application and setup the session there. Experienced Android developers tell me the Application methods are guaranteed to be called before anything else in your application. I can't explain it, but I also dislike this approach. It might be because when I started doing iOS (a long time ago) it was acceptable to put global state on the AppDelegate so that you can reach it using: UIApplication sharedApplication].delegate.someProperty. In the Android community subclassing Application is an acceptable solution for the same thing. I suspect my iOS attuned nose is just picking up the stale smell of buried corpses.

Unfortunately I haven't found another solution so I'm going to choose the lesser of two evils here. I'm going to subclass Application and deal with it. Chances are future-me will have to write another post about this. Future-me, if you're reading this, deal with it.

The Pomodoro Technique

2014-03-25T17:04:00Z

A while ago I started working with The Pomodoro Technique. I initially had my reservations but after using it semi-consistently for a couple of months I don't see myself going back.

Pomdoro is a time management method named after the kitchen timer. The basic premise is that you decide on a task to work on, set the timer at 25 minutes and exclusively work on that task. When 25 minutes have elapsed you take a short 5 minute break and start the next.

The Pomodoro kitchen timer

Initially I had problems adopting it because I had a wrong definition for a task. For me, a task had to be something I could finish in 25 minutes. Most programming tasks don't fall into that category. Eventually I settled on a different definition: a task is something to work on exclusively for the next 25 minutes. It doesn't matter if I finish it in that time, I just want to commit myself to doing that one thing for a specific amount of time. If I do finish I pick the next task of my todo list and continue with that until the 25 minutes are up.

My average work day now consists of three recurring tasks:

Programming, what I get paid to do, so basically what I do when not doing anything else;
Email, 1 Pomodoro somewhere after lunch;
Write, 1 Pomodoro immediately after lunch;

I keep up to date with what's going on in the world during the 5 minute breaks. The point is to eliminate distractions so I try not to check IM, Twitter or Facebook during the 25 minutes.

It's impossible to measure if using Pomodoro has made me more productive, but I feel more productive. Heck, I literally shipped an Android app with no prior Android development experience in 4 weeks.

Pomodoro also gives me a way to measure my productivity. Honestly I don't really care about how much time I spend on programming. Some days are bad, that's what you get when you're doing creative work. With other tasks like email though it helps me constrain the amount of time I spend on it. Even on a bad day I know I'll never get distracted by email for more than 25 minutes. Also if doing email starts taking more than 25 minutes I know it's time to change something.

Like everything else, it isn't all perfect. It's hard not to get distracted when working in an office. A co-worker can distract you at any moment. The official book says to be strict, because whoever is interrupting you can usually wait. I just don't like blowing people off like that. Besides interacting with co-workers should be fun and an important part of any office culture.

Office culture also prevents me from taking the longer breaks. The technique suggests taking a break every 4 Pomodoros. We do lunch together at the Karma office and our lunch time rarely coincides exactly with 4 Pomodoros. I basically take my first long break during lunch and usually another one somewhere in the afternoon. They're rarely exactly every 2 hours though.

I've been doing Pomodoro consistently for a while now and I'm not going back to my old way of working. I realize now how much time I actually spent being distracted. Programming often requires keeping a complex model in your head and that's gone the second you do something else.

Hopefully by now you're thinking about trying Pomodoro. I highly encourage you to do so. Get the Pomodoro Mac app, commit yourself to work on something for 25 minutes and start the timer.

When you're starting out, don't repeat my mistake. Keep It Simple (Stupid)! According to the book Pomodoro is about much more than just 25 minutes of focused work, but that is what gives me the most value. Don't get bogged down in the details, just get started!

Update: I recommended the Pomodoro Mac app because that's what I use and at the time of writing it was free. Even though it's a paid app now I can still recommend it, but I don't know how it stacks up against other paid Pomodoro apps.

Problems with iOS Push Notifications

2014-02-07T02:34:00Z

Push notifications are a great way to keep users engaged with your iPhone app. The amount of applications that support them led me to conclude that supporting push notification must be trivial. After implementing them myself I'm left with the realization that it is most definitely not.

Consider the Karma iOS app, we have a simple use case, when a push notification is delivered the user needs to be presented the correct screen. For example when a user opens a 'balance' notification, the app should open in the store.

Starting at the beginning let's take a look at the code paths when a push notification is delivered. There are two UIApplicationDelegate methods that need to be implemented. One for when the app is running and one for when it's not.

- (void)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions;
{
    if (options[UIApplicationRemoteNotificationKey]) {
        // Handle the notification
    }
}

The launchOptions dictionary will contain the information about your push notification. This key won't exist if your app was launched in another way.

When your app is already running you need to handle incoming notifications differently:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)options;
{
    // Handle the notification
}

Unfortunately we're not done yet. A running app can be running in 3 different modes: UIApplicationStateActive, UIApplicationStateInactive and UIApplicationStateBackground. When the application state is in UIApplicationStateActive the user is not automatically notified of the push notification and is likely interacting with the app. In the Karma case where we want to show a particular screen we cannot rip a user out of his workflow. The solution:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)options;
{
    if (application.applicationState != UIApplicationStateActive) {
        // Handle the notification
    }
}

That's not 1, not 2, but 3 possible code paths (the conditional technically makes it 4, but we're not using else or doing anything after it) of which 2 have duplicate code. All that and we still haven't really done anything. What boggles my mind is that every iOS developer implementing push notifications has to write this code every time push support is added to an app.

Let's fix the duplicate code by introducing a class named RemoteNotificationHandler:

@interface RemoteNotificationHandler
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)notification;
@end

Wait, you just moved the method to a different object? Yep! How is that going to solve duplicate code? Well, take a look at the AppDelegate:

- (void)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)options;
{
    if (options[UIApplicationRemoteNotificationKey]) {
        [self.remoteNotificationHandler application:application didReceiveRemoteNotification:options[UIApplicationRemoteNotificationKey];
    }
}

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)options;
{
    [self.remoteNotificationHandler application:application didReceiveRemoteNotification:options[UIApplicationRemoteNotificationKey];
}

There is still some duplicate code, but at least we moved the bulk of handling the notification to an isolated place that can be independently tested. Note that the check for application.applicationState is gone. Now that we have an isolated object dealing with notifications this responsibility belongs there.

Honestly I wish Apple would split the UIApplicationDelegate protocol up into different protocols. That way I don't have to spend so much time keeping my AppDelegate short and readable. Something like application.remoteNotificationDelegate = [[RemoteNotificationHandler alloc] init] would be perfect (Radar #15940986). Splitting the delegate into smaller objects also means classes like the RemoteNotificationHandler aren't needed anymore because the delegate objects can be tested independently from the main AppDelegate.

Back to the topic at hand. Over 600 words and we haven't done anything to solve the initial use case; routing the user to the correct screen in response to a push notification.

To make the problem even more interesting. In the Karma app we didn't simply require the user to be routed to a particular screen. The user needs to be routed to the relevant place in the app as if he had navigated there using the UI. We didn't want to present a modal sheet because it means the same place in the UI can be reached in more than one way. This is not only confusing to the user it also convolutes the code because the same view controller can be presented in different situations.

Enough context, let's begin implementing the RemoteNotificationHandler:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)notification;

Before we do anything else we need to know if the user is currently interacting with the app. If so, we're going to do nothing with the notification. We deemed this sufficient for the Karma app, if you want to simulate the iOS notification bar there are plenty of libraries out there.

Next we'll show the appropriate view controller. The next example is storyboard specific. It also uses storyboard convenience library because, having written it myself, I like using it:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)notification;
{
			// Application state != Active

			NSString *segueIdentifier = [UIStoryboard segueIdentifierForClass:[GuestViewController class]];
			[application.rootViewController performSegue:segueIdentifier];
}

Ok, this works! Sometimes. We ask the rootViewController of the application's key window to present the GuestViewController for us. This works if your storyboard's rootViewController has a segue called GuestViewControllerSegue. If the view controller responsible for presenting the guest screen is deeper down into your view controller stack this approach will quickly turn into a mess of rootViewController.presentedViewController.topViewController. This approach will also break when the rootViewController is already presenting a different view controller.

I dislike this approach because it's a clear Law of Demeter violation. Our RemoteNotificationHelper has to know about the structure of UIApplication, UIWindow and the rootViewController. If you ever decide to move things around in your app this will most definitely break. Our remote notification handler shouldn't know anything about UIWindow or UIViewController, but due to the isolated nature of view controllers this seems the only method that always works.

In my attempts to make this better I tried two other methods with varying success; using the responder chain and NSNotification. These both are conceptually better solutions because the part of the application interested in the remote notification gets a chance to handle it. Unfortunately the responder chain approach doesn't work because there is no guarantee that the responsible part is participating in the responder chain when the push notification is received. The NSNotification approach only works if the handler of the notification is guaranteed to be in memory. If it isn't, the push notification will not be delivered. Another disadvantage of the NSNotification approach is that a component cannot mark a notification as handled. You can easily get into a situation where multiple parts of your app are doing conflicting things in response to the same push notification.

In the Karma app I eventually went with the NSNotification approach. I know that the receiver of the notification is always in memory making this approach viable. It also nicely decouples receiving and handling the push notification, making it trivial to test both.

I've long doubted wether to post this blog post or not. The entire process of supporting push notifications seems too convoluted to be true and even now, while writing this, I feel like I must be missing something. If that is the case than please tell me. If not then this will serve as an indication to others. No, you are not stupid!

Why I prefer testing with Specta, Expecta and OCMockito

2014-01-22T18:20:00Z

Update August 2014: Since writing this article, OCMock has released major version 3. Everything said about OCMock is based on version 2.

If you're testing your Objective-C code (you should) you've probably heard of Kiwi and XCTest. Great! Do you like it? Awesome! You should switch to Specta and Expecta. Why? Keep reading.

Uniform interface

Specta provides one uniform interface that works for every kind of value. For example:

it("equals YES", ^{
    expect(view.isHidden).to.equal(YES);
    // Yes, I'm aware there is a isTruthy matcher but that wouldn't really prove my point...
});

Compare this to the Kiwi alternative:

it(@"equals YES", ^{
    [theValue(view.isHidden) should] equal:theValue(YES)];
});

In Kiwi, when working with scalars, both sides need to be wrapped using the theValue(aScalar) macro. Specta hides this complexity by providing one uniform interface for any value. Anything you pass to expect or to a matcher is automatically wrapped for you.

If that doesn't convince you; both Kiwi and Specta are based on RSpec and RSpec switched to the expect approach that Specta is using.

This is their reasoning behind the change, replace RSpec with Kiwi and object with NSObject:

The underlying problem is RSpec's should syntax: for should to work properly, it must be defined on every object in the system… but RSpec does not own every object in the system and cannot ensure that it always works consistently.

Asynchronous Testing

Testing asynchronous code with Specta and Expecta is amazingly well done. It's probably my favorite feature. Both Specta and Expecta support a different use case, which combined will cover all your asynchronous testing needs.

Let's take a look at Specta first:

it(@"does something asynchronously", ^AsyncBlock{
    [object doSomethingAsynchronously:^(BOOL wasDone) {
        expect(wasDone).to.beTruthy();
        done();
    }];
});

AsyncBlock is a macro that provides a block named done. You call this block whenever your test finishes. This can be anywhere between immediately or 10 seconds from now. After 10 seconds it is assumed done will not get called and your test fails. You can use this to test that some sort of callback will be called some time from now.

This also works on before blocks. For example to ensure that a view controller is presented before any expectations run:

before(^AsyncBlock{
    [_mainViewController presentViewController:_viewController animated:YES completion:done];
});

Be careful with this approach. If you're doing TTD or BDD you want your test suite to be fast. A 10 second timeout can significantly slow it down. The Specta approach is often useful in lower levels of the stack. For example imagine AFNetworking using this approach to verify that a completion block is called after a request finishes.

When you test higher up the stack you'll also want to test the outcome of the asynchronous callback. For example that the completion of a network request updates your UI:

it(@"sets the user's name when the user loads", ^{
    [_view.user load];
    expect(_view.nameLabel.text).will.equal(@"Ben Day");
});

This verifies that the nameLabel's text property equals Ben Day within 1 second. The default timeout of 1 second can be changed using [Expecta setAsynchronousTestTimeout:2].

In my experience the combination of these methods of asynchronous testing cover any use case you might have.

Separation of concern

Specta itself is a test runner built on top of XCTest with a BDD-style DSL. Because it nicely separates concerns it does not force a particular matcher framework on you. The authors recommend you use Expecta but if you want you can also use XCTest or OCHamcrest matchers. Of course you can else write your own.

Mocking (and more about separation of concerns)

Initially separation of concern was what I disliked about Specta. Not in the literal sense, who doesn't like nicely separated concerns right? The reason I initially didn't switch from Kiwi to Specta was because Kiwi comes with great mocking built-in. In other words Kiwi mixes multiple concerns into the same framework while Specta doesn't. When I realized I wasn't switching because of something I actually liked about Specta I started looking for a new mocking framework.

My first pick was OCMock. Mostly because it's recommend by Specta's authors. OCMock was sufficient while my test suite was still small, but as it grew it quickly became a burden. It's API doesn't blend very well with Specta's BDD style and it doesn't report test failures properly. OCMock reports test failures by raising exceptions. Exceptions often do not contain enough information for the test reporter to give you accurate line and file information. When you're working with multiple mocks in the same file it becomes very hard to figure out which one is failing.

After a brief search for another mocking framework I settled on OCMockito and I've been using it without complaints ever since. Take a look at the following spec:

it(@"has a dependency that does something", ^{
     _subject.dependency = mock([Dependency class]);
     [_subject doSomethingWithDependency];
     [verify(_subject.dependency) doSomething];
});

OCMockito's clever use of macros make it a very good match with Specta. It also correctly reports errors making it trivial to track down the exact location of a failure.

Wrapping up

Historically Objective-C developers don't have a very good track record when it comes to testing. If you take a look at a language like Ruby where testing is at the core of community you'll find that better tooling, frameworks and education is what drives new rubiests to adopt that mindset.

I think the introduction of tools like Cocoapods and frameworks like Specta and Expecta are the first steps in bringing that mindset to Objective-C. All we need now is more education.

Initializing Objective-C classes with sane initial state

2014-01-14T17:54:00Z

Because Objective-C has the concept of designated initializers, you have to ensure your classes are instantiated using sane initial state. Take for example a fictitious person class with the designated initializer initWithName:

@implementation Person
- (id)initWithName:(NSString *)name;
{
    self = [super init];
    if (self) {
        _name = name;
    }
    return self;
}
@end

Now in a view controller this happens:

- (void)viewWillAppear:(BOOL)animated;
{
    [super viewWillAppear:animated];
    Person *person = [[Person alloc] init];
    self.nameLabel.text = self.person.name;
}

The author accidentally forgot to use the designated initializer and the program now has incorrect state. In this particular situation it results in an empty label that might or might not be visible to the user. This is a simple example but in a complex application this can easily lead to hard to find bugs.

Let's take a look an Foundation class to find a solution. Specifically a possible implementation of the NSNumberFormatter init method:

- (id)init;
{
    return [self initWithLocale:[NSLocale currentLocale]];
}

If possible you should always prefer a sane default over an exception. Unless otherwise specified, an NSNumberFormatter is initialized with the current locale.

However more often than not such a sane default doesn't exist. In the example of our Person class there is no default name that we can fallback on. In this case use NSParameterAssert. Not providing a name is a programmer error. By convention any programmer error should raise an exception. NSParameterAssert will conveniently do this if the passed in parameter evaluates to false.

Let's see what that looks like in our Person class:

@implementation Person
- (id)init;
{
    return [self initWithName:nil];
}

- (id)initWithName:(NSString *)name;
{
    NSParameterAssert(name);
    self = [super init];
    if (self) {
        _name = name;
    }
    return self;
}
@end

This 100% guarantees that your classes initial state is correct. If, like in our previous example, init is accidentally used it will immediately raise an NSInternalInconsistencyException. Furthermore if you remove assertions from your production code this will, apart from the fact the the application now has incorrect state, have no effect on your user's experience.

This also works for classes that already have a designated initializer like UIView:

// In a UIView subclass
- (id)initWithFrame:(CGRect)frame;
{
    return [self initWithText:text];
}

- (id)initWithText:(NSString *)text;
{
    NSParameterAssert(text);
    CGRect textFrame = // Assume this exists
    self = [super initWithFrame:textFrame];
    if (self) {
        _text = text;
    }
    return self;
}

Finally the initialization code paths are trivial to test:

describe(@"Person", ^{
    it(@"cannot be created without a name", ^{
        expect(^{
            Person *person = [[Person alloc] init];
        }).to.raise(NSInternalInconsistencyException);
    }

       it(@"can be created with a name", ^{
        Person *person = [[Person alloc] initWithName:@"Ender"];
        expect(person.name).to.equal(@"Ender");
    });
});

There you have it. A simple and reusable way to make sure your classes are always initialized with sane initial state.

Update:

The initial version of this post included a statement that you should remove assertions from your production code. While I am still off this opinion @__block pointed out an interesting article from Mike Ash explaining proper usage of asserts. Mike also makes a good case on why you shouldn't compile out assertions. Since this discussion is outside of the scope of this article I removed the statement.

Appreciating real world interaction

2013-03-05T07:18:00Z

Moving to New York and having to quickly adept to a completely different culture has really opened up my eyes to a lot of beautiful interactions we encounter during our everyday lives. This inspired me to start realworlddetails.com to celebrate some of the great interactions we tend to overlook because of our busy lives.

As a software user, and developer; I've come to enjoy consuming and creating these fun details. Some of these details truly make our lives easier, while others are just for fun. Regardless, they will all put a smile on your face when you become aware of them. With realworlddetails.com, I hope to make all of us more appreciative of the many things we encounter during our day. Whether waiting in line at the grocery store, shopping at Ikea or any other time we're not looking at a screen. Let's stop and look around for a minute.

If you have any suggestions, be sure to let me know. You can also stay up to date by following our Tumblr blog, Twitter or by simply liking our Facebook page.

Debugging Ember

2013-01-12T14:30:00Z

While building the Karma customer dashboard I discovered several interesting ways to debug Ember apps. Some of these are my own, others I've taken from Tom Dale's excellent debugging Ember talk.

Observers

I don't need explicit observers often in production code but I do use them frequently for debugging. Adding an observer is very similar to a computed property:

propertyObserver: function() {
  // Called when the value of property changes
}.observes('property');

I use this when some computed property down the line has an unexpected value. Add any logging or debugging code in the observer and it will tell you whether the property is changed as expected or not.

toString

Ember does some very cool stuff to give you useful string representations of your objects. However by default modern browsers will show you the object representation. While this is often useful I find myself in situations where I just want to know what kind kind of object I'm looking at.

One option is to call toString on the property like so:

applicationController.toString(); // "<App.ApplicationController:ember2366>"

Another way that is less typing is to append "" like so:

applicationController + ""; // "<App.ApplicationController:ember2366>"

Handlebars

Handlebars has two convenient helpers to aid in debugging. {{log path.to.value}} and {{debugger}} respectively log the value of the path or add a debugger statement at that location in your template.

forEach

It can be quite annoying to have to keep stepping into forEach calls. Set a breakpoint inside your callback function and hit "continue". If the array is not empty the debugger will immediately jump to your callback function. Note that the same works for any other callback as well.

Yehuda adds that in Chrome you can also right click the line number and click "Continue to here".

And that's it. Tom also talks about some more generic javascript debugging techniques so I encourage you to watch it. If you have any debugging techniques I missed let me know.

CSS Markdown mark

2012-03-16T11:05:00Z

I've been impressed with icons created in CSS3 and decided to have a go at it. As an experiment I took Dustin Curtis' markdown mark and made a version using only HTML and CSS. This is the result (separate page):

Unfortunately, due to two issues in current browsers the icon is not pixel perfect.

The M portion of the icon is rendered using the :before pseudo tag with a content attribute. By default text in browsers on a Mac (I haven't tested on Windows) is rendered using sub pixel antialiasing. I was able to make the drawing of the M more accurate by setting -webkit-font-smoothing to antialiased but the end result still has 1 pixel grayish border on both sides of the M. It should be possible to reproduce the M using CSS shapes, but that's outside the scope of my experiment.

Note that -webkit-font-smoothing also allows never but the result is awful:

Ironically, the second issue is the lack of antialiasing on borders. Dustin's original arrow shape is very crisp whereas my version has jacked edges. The most obvious solution is to render a div with a solid background and use :before and :after to overlay two rotated rectangle. This would create the same effect but probably without the jacked edges. I was however unable to get this to work without the rotated rectangles overlapping others parts of the icon.

If you know why browsers don't antialias borders or how to get the arrow more crisp; please mention me on Twitter or comment on the pull request.

Changes to AppEngine's _from_entity

2011-09-08T13:49:00Z

Both my blog and Enstore experienced a serious outage today. This was caused by a recent change to how App Engine initializes entities. The error was:

BadArgumentError: Cannot use key and key_name at the same time with different values

A common trick to detect wether an entity is loaded from datastore or not is to check if kwargs.get('_from_entity') == True: in the models __init__ method. Before today's change _from_entity was a bool argument and this code worked perfectly. Today's change made _from_entity a dictionary containing the entities' properties and values. Because of this the explicit check for True returned False and both Enstore and this blog started returning 500 errors.

The issues were resolved by changing :

`if kwargs.get('_from_entity') == True:`

to:

`if kwargs.get('_from_entity'):`.

My git setup

2011-04-28T15:30:00Z

I have been using git since I started working on Cappuccino. Over time I've found several useful additions to my configuration that made working with it easier.

Bash additions

While working with git it's easy to get lost in branches, tags and commits. The bash completion script included with git helps to keep track. It's core functionality is autocompletion, but it can optionally show the current branch after your prompt. Installation instructions are included in the file, which you can find in the git repository under contrib/completion/. If you change your bash prompt to show the current branch (step 3) consider using PS1='\h:\W'$RED'$(__git_ps1 "@%s")'$NONE'\$ '. It will display the current branch in red, making it much more obvious.

Aliases

Git (since version 1.4) includes support for aliasing commands. For a quick introduction see this tutorial on the git wiki.

These are the aliases I currently use:

[alias]
	co = checkout
    mg = merge
	st = status
	ci = commit
	br = branch
	df = difftool
    lg = log --graph --pretty=format:'%C(bold red)%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold green)<%an>%Creset' --abbrev-commit --date=relative
	lc = log ORIG_HEAD.. --no-merges --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

With the exception of lc and lg all my aliases are shortcuts for git commands. The lg alias is a shortcut for git log with custom formatting. lc is the same, but it only shows the last fetched commits. While you're adding aliases don't forget to alias git itself as well. I've added the following to ~/.bash_login:

alias g='git'
# Make the autocompleton work with the g alias
complete -o bashdefault -o default -o nospace -F _git g 2>/dev/null \
|| complete -o default -o nospace -F _git g

Editor and difftool

I've changed my default git editor to Textmate. This means commands that require text entry, such as commit and tag, will open Textmate. You can change the editor by running: git config --global core.editor 'mate -w' or by setting the GIT_EDITOR environment variable.

Lastly I've also changed my difftool to Kaleidoscope. This is easily done from Kaleidscope itself by going to the Integration in the Kaleidscope menu. If you don't have Kaleidoscope already you can currently buy it for a 50% discount in the Mac app store.

Summary

This is just a summary of how I configured git. If this post has whet your appetite use Google and mix and match several setups to find your perfect git setup.

Announcing autonib2cib

2011-03-05T19:20:00Z

Some time ago I posted a gist for a command line utility that automatically nib2cibs changed nibs. During the weekend I've rewritten the utility, making it more reliable with newly created nibs and nibs containing resources.

I've also moved the code (all 100 lines of it) from the gist to it's own github repo. If you have a feature request or find a bug, please create an issue or even better, a pull request.

Take a look at the README for installation instructions. After installing you can start monitoring your nibs by running autonib2cib <resource directory> in your terminal.

Cappuccino has been very successful at preserving the customary 'code and refresh' workflow for web developers. However, as any developer with more than a handful of cibs knows, having to manually run nib2cib breaks this workflow. Autonib2cib will solve this problem by automating the nib2cib process.

autonib2cib <resource directory>

Improving the Cappuccino Theme System

2010-11-05T20:13:00Z

I've written about the Cappuccino theming system before[^1] and I have a confession to make, I don't like the current system.

Let me clarify. Being able to change every visual aspect of a view is great, but currently it's too complex.

It's complex because a it requires manual building, even during development. I should be able to make a change, refresh the browser and see the difference. Just like developing everything else on the web, including Objective-J.

Objective-J itself is also part of the complexity. setValue:forThemeAttribute:inState works great for small amounts of theme changes. But it becomes unreadable when changing large parts of a theme.

With all the talent in the Cappuccino community I'm sure we can work around these problems with the current system. It will however not fix the biggest issue. Designers won't theme as long as we're using Objective-J as our theming language.

This is a huge step backwards. Designers have been able to style websites for years using CSS. I don't see why that isn't possible for (Cappuccino) web applications.

Now is the time for the skeptics to say that this impossible or to hard to do. Well, as we say in Dutch, watch and shiver[^2].

Obviously this application is a big hack, but it does show what is already possible. Imagine what we could do if we implemented this properly.

In the application I use a Javascript CSS parser. This prevents the need for a separate build phase during development. When the application is ready to be deployed, the CSS can still be build into an optimized format. CSS is also a far more readable theming language and most designers already know and use it.

Now to also get them to use Git.

[^1]: Previous posts are Cappuccino Custom Themes and The Basics of Cappuccino Theming)

[^2]: The source is available here

Cappuccino Custom Themes

2010-09-16T17:17:00Z

A while ago I wrote a blog post about the basics of Cappuccino theming. Since then I've got a lot of questions about how to create fully customized themes.

The first step in building your own custom theme is to create a theme descriptor. If you've built Cappuccino from source you can create one using the following command:

capp gen -t ThemeDescriptor --build -F BlendKit [Theme name]

If you haven't installed Cappuccino from source, you can download a default theme descriptor.

You should now have a folder with the theme descriptor file, a resources directory and a Jakefile. A theme descriptor also includes a handy showcase application which you can use to preview your theme. Running the showcase is simply a matter of opening index.html or index-debug.html.

The showcase by default isn't very helpful, it only has an ugly button. If you open the theme descriptor you'll see the + (CPButton)themedButton class method. You can change the theme properties for a button by setting additional theme values in this method. How to change theme values is described in my previous blog post about Cappuccino theming.

Unfortunately theme-able properties are not documented. You'll have to take a look at Aristo's theme descriptor or check the + (id)themeAttributes method of a class and all of it's superclasses.

Theming another class is done by implementing another +(<Class>)themed<Class> method. If the class is initialized with a frame and some theme values it will automatically show in the theme showcase. Take a look at Aristo's theme descriptor to see what you can do.

The next step is building your theme. You can do this by running jake debug or jake install inside your theme directory. The build process will take the resources and theme descriptor and build it into a theme blend. After the build is done, the theme blend can be found in: Build/[Configuration]/[Theme name].blend>. [Configuration] is either Debug or Release, depending on the jake argument used.

The theme blend is what is needed to actually load the theme in your Cappuccino application. The easiest way to load the theme is by adding the following to your application's Info.plist:

<key>CPDefaultTheme</key>
<string>[Theme name]</string>

This will automatically set the custom theme as the default theme for the application. This will override Aristo (Cappuccino's default theme) and set your theme as the default for the application.

If you load your application, you'll see there's an error; Cappuccino can't find your theme blend. This is because Cappuccino will look inside your application bundle's resource directory for the theme blend and it was built somewhere else. The easiest way to solve this is to symlink the theme blend inside the Resources directory. This also makes sure any changes to your theme are automatically applied in your application when you rebuild the theme.

As mentioned before the previously described method of loading a Theme will completely override Aristo. If you want to use Aristo in addition to your own theme you can load the theme blend manually. The following code shows how this is done:

- (void)applicationDidFinishLaunching:(CPNotification)aNotification
{
	var bundle = [CPBundle mainBundle],
	    blend = [[CPThemeBlend alloc] initWithContentsOfURL:
				 [bundle pathForResource:@"<Theme name>.blend"]];

	[blend loadWithDelegate:self];
}

- (void)blendDidFinishLoading:(CPThemeBlend)theBlend
{
	// Show your application and use your custom theme
}

When using this method it's advisable to show your application after the blend finished loading. This way you'll never have flashes when the custom theme loads.

After the blend is loaded you can apply it to any view:

var customTheme = [CPTheme themeNamed:<Theme name>],
     button = [CPButton buttonWithTitle:@"Custom themed button"];

[button setTheme:customTheme];

I've wrapped up both methods of theming into separate projects. Both can be downloaded here. Please let me know if you have any questions in the comments.

NSConference MINI 2010 Sessions Online

2010-07-22T15:46:00Z

This year, European developers had a hard time attending the WWDC, Apple's developers conference. The announcement was to late, forcing developers to arrange an entire inter continental trip in a relative short amount of time. There was also the pretty steep price and of course it was sold out within just 8 days!

Luckily the community took care of us. The Mac Developer Network hosted a mini NSConference during WWDC. Wanting to help out, I gave a talk about the Cappuccino frameworks.

My session and all the others given during NSConference MINI are now available at the Mac Developer Network website. You can get all of the sessions in one pack for 50 dollars[^1].

[^1]: As far as I'm aware there's no way to buy individual sessions, so if you're only interested in one talk you're still going to have to pay the full sum for all the sessions.

The future

2010-07-19T13:33:00Z

Most of you probably already know, but for those who don’t; the company I work at, Sofa was acquired by Facebook. For reasons I can’t disclose I was not part of the acquisition.

The last couple of weeks have been a very emotional and busy period. Over the course of two weeks I went from having a job I enjoyed, to moving to the Bay Area for a job at Facebook, to having no job at all. In other words my future was destroyed, recreated and destroyed again.

Even though Facebook wasn’t an option, I didn’t want to waste the opportunity to move to the US. I got a ton of job offers during WWDC and I spend most of my time pursuing them trying to find a job in San Francisco.

While I was interviewing at another company I got an email from Sofa’s partner in Checkout, Acclivity. They wanted me to stop by New Jersey on my way back home to talk about my future and offered me an opportunity to continue development on Enstore and Checkout. Although I had set my mind on San Francisco this was an opportunity too good to pass by.

I’ll be part of a newly formed NYC based company responsible for Enstore and Checkout. My wife and I will be moving to New York City as soon as my visa is arranged. Suggestions where to live, eat and spend our spare time are very welcome.

In closing I would like to thank all the companies that offered me a job and all the great people that helped me out trying to find a new job! The last couple of months have been a hard and emotional period, but I’m sure the future will make up for it.

Programmatically Scroll a UIWebView

2010-05-15T04:33:00Z

Ever wanted to scroll a UIWebView programmatically on the iPad or iPhone? Unfortunately Apple doesn't have a public API to do this, but there is a way. A UIWebView can execute any arbitrary javascript with stringByEvaluatingJavaScriptFromString:.

Using this method we can easily scroll a web view like so:

[webView stringByEvaluatingJavaScriptFromString:@"window.scrollTo(0.0, 100.0)"];

It's also possible to save the scroll state of the web view through javascript:

CGFloat xOffset = [[[self webView] stringByEvaluatingJavaScriptFromString:@"pageXOffset"] floatValue];
CGFloat yOffset = [[[self webView] stringByEvaluatingJavaScriptFromString:@"pageYOffset"] floatValue];

I've used and tested both of these methods and haven't found any bugs or weird issues. I've filed radar bug 8184256: No API for programmatically scrolling / zooming a UIWebView. It has been marked as a duplicate of radar bug 5912563.

The Basics of Cappuccino Theming

2010-04-06T06:02:00Z

This is the second post of a series of posts about Cappuccino where I explain the subjects I talked about during my CocoaHeads Amsterdam presentation. The first post can be found here.

Cappuccino and Cocoa have a lot of similarities, but there are some differences. Most prominent is probably Cappuccino's theming engine. Web developers are accustomed to a certain level of customization that Cocoa does not provide. The theming engine provides this freedom to Cappuccino developers.

The theming engine let's you customize any theme-able attribute of CPView. Every subclass of CPView can declare it's own theme-able attributes by implementing the themeAttributes class method and returning a CPDictionary with the attribute names as keys and their default value as values.

Theme states

Before going into theming you'll have to know something about theme states. Basically every Cappuccino view has a theme state. The current theme state can be found by calling the themeState method on any view.

The themeState method itself is not extremely useful since you'll only get a unsigned integer back, it's up to you to find the actual theme state. Far more useful is the currentValueForThemeAttribute: method. This methods takes a string, the name of the theme-attribute, and returns it's current value.

Changing theme states is done through the setThemeState: and unsetThemeState: method. They both take a string with the state name or the CPThemeState itself as their only argument.

Changing theme-attributes

Most (if not all) of the state changing is handled by Cappuccino. Unless you are creating a custom control, you won't need to touch any of the the above methods. Far more important is the setValue:forThemeAttribute:inState: method. Let's take a look at changing the left and right content inset of a CPButton:

[button setValue:CGInsetMake(0.0, 50.0, 0.0, 50.0) forThemeAttribute:@"content-inset"];

Since we don't want the text to jump around when changing states we don't explicitly name the state, this effectively sets a fallback value. When a control is in a state with no defined value, the control will fall back to using this value.

Let's also take a look at setting theme-attributes for different states:

[button setValue:buttonBezel forThemeAttribute:@"bezel-color" inState:CPThemeStateBordered];

[button setValue:highlightedButtonBezel forThemeAttribute:@"bezel-color" inState:CPThemeStateBordered | CPThemeStateHighlighted];

[button setValue:disabledButtonBezel forThemeAttribute:@"bezel-color" inState:CPThemeStateBordered | CPThemeStateDisabled];

Assuming the bezel colors are defined, the above sets the bezel color for the normal, highlighted and disabled state.

During my presentation I used an example of a large button to show how the theming engine works. All the code used in this post came from that example. The project can be downloaded here.

These are the basics of the theming engine. In my own code I often use:

setValue:forThemeAttribute:inState:

to quickly change small details^[1]. I don't recommend creating your own, fully custom, themes this way. It will only result in a lot of clutter in your code. If you want to create your own theme, you should take a look at theme descriptors^[2].

The last thing I talked about during my CocoaHeads presentation is data availability. Cappuccino and Cocoa both assume data to be available when the application launches. I'll discuss this problem in more detail in the next, and last, post of the series.

Like issues with text in a control with odd height, resulting in the text appearing a pixel off center. ↩︎
I tried to find a good post about theme descriptors to link to, but unfortunately I couldn't find one. If you know of one, I'd be happy to link to it. ↩︎

Objective-J Explained: Toll-Free Bridges

2010-03-19T21:34:00Z

Last week I gave a talk on the Cappuccino frameworks during a Cocoaheads Amsterdam meeting. This post is the first in a series in which I'll explain several of the subjects I talked about during my presentation. I didn't have a lot of slides and they won't make much sense without explanation but for those that are interested you can download them here. All of the examples used in this post can be downloaded here.

I'm going to start of this series at the basis of the Cappuccino framework, Javascript. In the end Cappuccino and Objective-J are build on top of this one language and that allows for some pretty cool things. Cool things which will look familiar to Cocoa developers and cool things that can make the transition for Javascript developers easier.

The following code shows an example:

// 1 Declare a javascript array
var array = [];
CPLog.debug(@"Step 1: %@", array);
// >

// 2 Call an Objective-J method on it
[array addObject:@"first object"];
CPLog.debug(@"Step 2: %@", array);
// > first object

// 3 Call a Javascript function
array.push(@"SECOND OBJECT");
CPLog.debug(@"Step 3: %@", array);
// > first object,SECOND OBJECT

// 4 Mix it up
array[0] === [array objectAtIndex:0];
CPLog.debug(@"Step 4: %@", array[0] === [array objectAtIndex:0]);
// > true

// 5 Do something wacky
array[[array indexOfObject:@"SECOND OBJECT"]] = [array objectAtIndex:[array indexOfObject:@"SECOND OBJECT"]].toLowerCase();
CPLog.debug(@"Step 5: %@", array);
// > first object,second object

All of the above code is perfectly valid. This is an example of a toll-free bridge. A toll-free bridged object is both an instance of a regular Javascript and an instance of an Objective-J object. In Objective-J CPArray and CPString are toll-free bridged to their Javascript equivalents.

As you see you can mix and match both syntaxes as you feel fit. A word of caution. The above example (especially step 5) is contrived, I do not recommend mixing syntax like this in production code since it can make your code very hard to read and maintain. Personally I only use Javascript literal array notation to create arrays because it's shorter and more readable than [CPArray array]. I also use regular Javascript objects in stead of CPDictionaries because CPDictionary is not toll-free bridged with the Javascript object.

// 1. Create a regular javascript object using literal notation
var object = {};
// > {}

// 2. Add a key value pair to it using javascript
object['key1'] = 'value1';
// > {"key1": "value1"}

// 3. Attempt to add another key value pair using Objective-J
[object setValue:@"value2" forKey:@"key2"];
// > TypeError: Result of expression 'isa' [undefined] is not an object.

If you prefer using CPDictionaries over Javascript objects you can transform it into a CPDictionary like so:

// 1. Create the object from the previous example
var object = {@"key1":@"value1"}
// > {"key1": "value1"}

// 2. Make a CPDictionary out of it
var dictionary = [CPDictionary dictionaryWithJSObject:object recursively:YES];
// > {"key1": "value1"}

// 3. Attempt to add the key value pair using Objective-J again
[dictionary setValue:@"value2" forKey:@"key2"];
// > {"key1": "value1", "key2": "value2"}

I personally never do this because, to me:

{@"key1":@"value1", @"key2":@"value2"}

is far more readable than:

[CPDictionary dictionaryWithObjectsAndKeys:
    @"value1", @"key1", @"value2", @"key2"]

As you've seen, Objective-J and Javascript differ in syntax a lot, but are still very much the same thing.

As I've said earlier, this post is the start of a series of posts about Cappuccino. The next one will be about Theming, make sure you don't miss it by subscribing to my feed or following me on Twitter.

Welcome!

2010-03-08T19:27:00Z

After some delay it's finally here. Welcome to my blog! I intend to post here whenever I learn something new and interesting. I don't have a specific subject in mind, but it will certainly have to do with usability, design and software.

The reason for me to start this blog is that I like talking about things I learn. Of course it's also kind of mandatory to have a blog nowadays.

I intend to talk about the things I'm currently working on, provided I can talk about them. For now, this post will have to do. Thanks for stopping by and I hope to see you again soon!