Skip to content

Swift – getting the length of a string

In learning Swift, I have found at least 4 different ways of getting the length of a string:

let s = “Hello World”

let l1 = countElements(s)
let l2 = s.utf16count
let l3 = s.lengthOfBytesUsingEncoding(NSUTF8StringEncoding)
let l4 = (s as NSString).length

While countElements may appeal to those coming from Python (len), this feels like a huge step backwards. Based on the name, and the fact that it’s not a method on the string class, it appears to determine the string length every time it’s called. Didn’t we learn anything from strlen in C?

utf16count is a method (good), but I don’t know if the string is encoded in utf16 (bad), nor would I want it to be re-encoded as utf16 if it weren’t already just to get the length of the string.  The whole situation with Unicode is also getting ridiculous, but that’s a topic for another day.

lengthOfBytesUsingEncoding with the specific encoding is just laughable. Really? Trying to give everyone carpal tunnel syndrome?

length on NSString is weird. The length part is good, but first having to essentially cast it to a type from a different language is a bit ‘inelegant’ (and too much typing).

Call me a rebel, but how about something like the following?



Toothpaste in the Nanny State

While staying in California for a business trip, I ran out of toothpaste and needed to buy a new tube of toothpaste. No big deal — I’ll drop in at the local grocery/supermarket and buy some. I found the toothpaste but was dismayed, and highly annoyed, that there was only one kind available. The only toothpaste option was Tom’s toothpaste. Being completely unfamiliar with Tom’s toothpaste, I decided to read the labeling on the package. Surprise #1 — it’s made in Maine! Nothing against Maine, but I was on the western edge of California. Surprise #2 — it contains no fluoride. Now I’m not a toothpaste connoiseur, nor a toothpaste activist, but I don’t like someone else deciding that the only toothpaste that I can buy is made on the opposite end of the country and contains no fluoride. If I were in Maine and in the vicinity of where Tom’s toothpaste is made, I wouldn’t mind as it’s the local product and it’s completely okay to sometimes only find the local product as a purchase option. Regarding fluoride, I really don’t know (or care) whether it’s better to have fluoride in my toothpaste (or water) or not. But, again, I don’t like the idea of others taking away my choices and deciding for me what’s best for me. Do what’s best for yourself according to your own priorities and values, but let me do the same. Tom’s toothpaste may actually be an outstanding toothpaste and better than all the others, but if I want a tube of Colgate, Crest, or whatever else — don’t insist that I can only buy Tom’s.

iOS7 — Not on my Dime, Nor Time

tl;dr iOS7 makes me want to tear out my eyeballs, so I’m moving to Android

There from the beginning

I bought the first iPhone in late July of 2007, about 6 weeks after the debut. I was enthralled — this was the coolest phone I had ever seen, by a long shot. If only I could write my own software to run on it. (And no, Steve, not a web ‘app’!)

Poor Fanboi

This post has all the making of some teary-eyed fanboi, right? Almost, I once was a fanboi, but I gave up fanboyism a long time ago.

Back to the Story

I learned how to develop software for iPhone OS (before it was renamed iOS). I learned to make friends with Xcode and practice black magic every time I tried to install an IPA on a real device. I learned Objective-C and kept learning, and developing, and learning, and so on. All the while, I tinker with Linux and FreeBSD from time to time and occasionally mess around with Android, lest I fall into the all-in trap again. I even transitioned from a hobbyist iPhone developer to a professional one.

Signs of Trouble Emerge

  • WWDC becomes nearly impossible to get into (fashion more than substance?)
  • Battery life on iPhones starts to get bad
  • Usability of iTunes (music player) starts going down
  • Software quality of iOS seems to be getting worse
  • Apple makes it more difficult, if not impossible, to downgrade iOS

And Then iOS7 UI Struck

I saw it during the beta periods, but largely ignored it because surely Apple won’t release something that bad. And then they really DID ship something that bad! So that no accuses me of being completely close-minded, let me start by mentioning a few things about iOS7 UI that I do like, and consider to be improvements over previous versions:

  • narrower switch control (UISwitch)
  • working clock icon on home screen
  • nicer looking app icons for compass, stocks, music/itunes, and phone

That’s it?? That’s it!!

Now for the things that I despise:

  • totally flat design (not a big fan of skeuom… [whatever you call it] either)
  • bright, washed-out transparency EVERYWHERE
  • pastel color scheme (I like bold colors with decent contrast, thank you)
  • silly, gratuitous animations that have no purpose
  • borderless buttons

The UI is a horrible mix of feminine and pre-school color schemes that makes me want to tear out my eyeballs. I’m not going to pay smart phone prices and monthly data plans to have to endure looking at that foolishness and frivolity on my own dime (and time).

And let’s not kid ourselves, these things are here to stay. Other than minor tweaks, there’s too much hubris at Apple, especially after making a fuss about bringing Jony Ive to redesign iOS, to go back on it now.

iOS 7 Under the Hood

To be clear, I’m not saying that ALL of iOS 7 is bad — just the parts that I have to look at when I’m using the device. There are some neat new things that Apple has introduced in iOS 7 such as NSURLSession and I think it’s pretty cool what Apple is doing with timer coalescing and app sandbox security.

My Device Exposure

At $dayjob, I have an iPhone 4S and an iPad mini (Retina/2nd gen) device both running iOS 7. My wife has iOS 7 on her iPhone 5 and on her iPad Air. My personal iPhone is a 4S running 6.1.1 and my personal iPad is an iPad mini (first gen) running 6.1.3. I like the new iPad hardware models and I’m sure I would really like the new iPhone 5S as well. I also regularly make use of an iPhone 3GS running 6.1.3 for testing purposes. Although I have plenty of exposure to the new iPad Air and the new iPad mini, I don’t use them for personal use — at all. Why? I can’t stand looking at iOS 7 UI.

A Fork in the Road

My personal iPhone (4S running iOS 6.1.1) just had its 2-year contract with Verizon expire. I’ve also slowly become more aware of how much money one ends up paying the carriers over that 2 year period. Since I’ve done this continually since 2008 (I paid for my original iPhone in full at time of purchase), that’s a pretty good chunk of change. But, the biggest problem of all is that I despise iOS 7 and refuse to have it on my personal phone (or tablet).

Additionally, I’ve finally concluded that my iPad mini is too small (physically) and has too low screen resolution (ppi) for my old eyes. I nearly always get eye strain (and then a headache) after using it for more than 30 minutes or so. But, if I buy an iPad Air it’ll come the dreaded iOS 7. (Things aren’t looking too good for iOS in my personal stock at this point)

T-Mobile seems to be the easy pick of carriers should I decide to keep any kind of smart phone service. T-Mobile, however, uses a GSM network (like AT&T). My personal iPhone is CDMA (Verizon), so it can’t be used for T-Mobile.

$dayjob has me doing a mix of iOS and Android development. My knowledge and background is heavily slanted towards iOS and I need to become more Android savvy (one way or another). This pushes things heavily in favor of Android, should I decide to keep a smart phone for personal use.

On Android phones, I’m not a huge fan of the Galaxy S4 styling (although I know it’s a very nice device). I looked for other models to choose from and find that the HTC One and Sony Xperia Z seem to be most appealing to me (of those Android devices offered by T-Mobile). It looks like the HTC One is the better phone, but it’s also more expensive, and I plan to buy it outright and not be under contract with a carrier (ever again). If learning more about Android wasn’t such a big priority, and if I were more courageous (or foolish), I might even consider a Blackberry Z10 — but it’s just way too esoteric at this point. An Android phone, along the size and style of the HTC One or Xperia Z seems to be the only practical smart phone choice for me — and, as a bonus, I get to keep my eyeballs!

My iPad mini will likely be sold on eBay, as the hardware doesn’t fit my needs. Both of my personal iOS devices are going away (I’ll keep my iPhone 4S for development and testing purposes). I am about to buy a new MacBook Pro, so I’m not boycotting Apple, just iOS 7. I would consider buying a used full-size iPad (with iOS 6.x) for personal tablet use, but that strikes me as a short-sighted and futile move, as both Apple and developers are always pushing users pretty forcefully to newer versions of iOS.

On Being a Developer

Am I going to be an Android fanboi? Nope! I already know what it’s like to develop for Android, and it ain’t pretty. I’ll still take Objective-C and Xcode over Eclipse and Java any day of the week. And I’ll still be developing for iOS and Android as part of $dayjob (and for hobby projects). But for my personal devices, the stink-eye will be on iOS7.

On Being a Fanboi

Am I an iPhone or iOS fanboi? Nope! “Are you sure about that?”, I hear you thinking. Yes! I’ve been a fanboi before — back in the OS/2 days. I was an OS/2 fanboi. I was all-in on OS/2. It was clearly the superior technology solution (as compared to DOS and Windows), so why not go all in on the best of the lot?, or so went my thinking.

When I eventually accepted the reality that OS/2 was a lost cause, I had some really deep wounds to lick. I had invested enormous amounts of time, money, and energy into the ecosystem. Worse yet, because I was all-in on OS/2, I had ‘none-in’ on Windows. I had a lot of catching up to do — get familiar with Windows, learn Windows development using Win32 and MFC (yuck!). I learned a valuable lesson from this experience — NEVER, ever go all-in on anything (outside of one’s family). I vowed to always have a plan B (and possibly even a plan C) available, in case.

I also began to view all technology vendors through a skeptical and jaundiced eye. This is still how I view all technology vendors — they all suck, just in different levels and at different things. And their level of suckiness shifts over time, as do the things that they suck at.

The same goes for technologies themselves, including programming language. Back in my fanboi days, REXX was my favorite programming language. I used a product called VX-REXX (from Watcom) to whip out OS/2 software with great ease and speed. When OS/2 died, so did VX-REXX and pretty much REXX as a language. Technologies, and programming languages, come and go. I see them all as temporal tools to achieve some greater aim.

Which is better — Ruby or Python? “Who cares?”, is my answer. Pick the one that works for you — and don’t get too attached to it, because it may not even be around tomorrow.

Turning Back the Clock – iOS

I recently was tasked with changing the deployment target of an iOS app from 5.0 to 4.3. What follows are the trials and tribulations of that exercise.


This JSON parser was introduced in iOS 5.0, so it cannot be used in iOS 4.3. I opted to use the tried-and-true SBJSON. Since Objective-C doesn’t have the concept of namespaces (shameful!) and the biggest part of this app is a framework that we make available for others to use, we follow the standard technique of adding our own prefix to all of the SBJSON types to prevent linker collisions.

‘weak’ Properties

If you code your Objective-C like all the cool kids, you’re undoubtedly familiar with ‘strong’ and ‘weak’ identifiers to use as part of a property’s declaration. Although ARC is supported in iOS 4.3, weak references are not supported in iOS versions below 5.0. All weak attributes must be changed to ‘__unsafe_unretained’ instead. Alternatively, you could also change it to ‘assign’ since that’s how we handled unofficial weak references before ARC came along!

iOS Simulator testing with Xcode

My development work was done using the latest Xcode. Unfortunately, the latest Xcode doesn’t have support for iOS 4.3 simulator. (Apple, you irritate me from time to time as a developer) No problem I thought, I’ll just look up the last version of Xcode that is known to support iOS 4.3 simulator and I’ll download that older version of Xcode to do my simulator testing. I downloaded the old Xcode and then attempted to install it (back when Xcode still had to be installed). My laptop is running Mountain Lion and when the installer started up it gave me a message saying that Xcode could not be installed on this newer version of OSX and that I had to use Lion. (Apple, you need to hear that old ‘Developers! Developers! Developers!’ mantra)

I checked with my colleagues and fortunately one of them has a laptop with Lion — great!  I install the older Xcode on Lion and get all my development files installed on it. Now I can test the app in iOS 4.3 simulator.

iOS 4.3 Device Testing

Fortunately, iOS simulators are very good, if not excellent. However, at some point testing needs to be done on a real device to ‘know’ that it really works as intended.  My personal phone (iPhone 4S) is running iOS 6.1.1, my company testing iPhone 5 is running 6.1, my company testing iPhone 4S is running 5.1.1, and my company testing iPad is running 6.0. Oh, and my old iPhone 3GS is running iOS 6.1.3. (Btw Apple, iOS 6.1.3 is horrible with the battery usage on my 3GS)

As you’re probably aware, Apple likes to keep iOS, and even OSX to some extent, on a 1-way direction with regards to upgrades/downgrades. Sorry, did I say ‘downgrade’?  That word does not exist in the iOS dictionary! I discussed the situation with my boss and he starts looking to find a 3GS running iOS 4.3.

After a day or two, my boss tells me that he’s found an iPhone 3GS on Craigslist that’s running iOS 4.3. Great! The guy with the device comes over to our office and the device’s battery is completely drained. (Figures, I thought to myself — it’s Craigslist. Hopefully, the guy doesn’t try to knife us.)  I plug it into one of my iPad chargers to get things moving along more speedily. After having to reassure (a couple of times) boss and dude who owns device that the battery charge must reach a minimal level before the device will actually turn on, the device finally reached the minimum charge level needed to start the device.

The device from Craigslist boots up and I frantically go through Settings->General->About to find out which version of iOS this thing is running. (Dang this screen looks fuzzy!)  Yep, it’s running iOS 4.3. Tell boss and dude that it’s got the version we’re looking for. Boss pays dude $102.00, or similar amount, and dude goes away with some proud new cash. (Thankfully, he didn’t try to knife us.)

I wasted no time getting the app installed on this device to do some ‘real’ testing. My app does not work as expected on the device. (See, I told you that you can’t always rely on the simulator!) Then I notice that some of the built-in software doesn’t seem to work as expected either. Oh-oh, I notice some strange icon on the home screen.  Dang it — this device is jailbroken. Oh well, I’ll just restore the non-jailbroken version of iOS 4.3 and things will be fine.

So, I spend a little time finding (Apple, I think you really are the new Microsoft) the stock restore file (ipsw) for iOS 4.3 running on this device type. Then I download it. Then I fire up the Organizer window in Xcode to get the ipsw file restored to the ‘new-to-us’ iPhone 3GS. Xcode gives me a delightful “This device isn’t eligible for the requested build.” error message. (Apple, I hate you!) Well, maybe iTunes will be more forgiving. I go through the special key sequence to select the ipsw and attempt restore. Ah, looks like iTunes may do the trick. It spends some time grinding away and just when I think I’m home free I get the same “This device isn’t eligible for the requested build.” message.

Either that same day or the next I report in our daily stand-up meeting where we stand (no pun intended) with our ‘new-to-us’ iPhone 3GS. Boss’ boss says “why don’t you just restore it with the original 4.3 software?”  Yay!  After reminding colleagues that I don’t actually have any control over (or special insights into ‘why’ Apple does some things), I decide it’s probably best to show them (in person) the actual steps I take from beginning to end. They see it exactly as I did. (Apple, I’m tempted to never buy another iShiny for the rest of my life!)

And we still don’t have a real device running iOS 4.3 to test on! The saga continues. (And I still hate Apple!)

Turning Back the Clock – Android

I recently was tasked with moving back the API target level (“uses-sdk”) of an Android app from 14 (Ice Cream Sandwich) to 10 (Gingerbread).

UI Layout

I developed this app and I already knew that I would have some UI layout work ahead of me. In the initial implementation I had decided to use GridLayout. This is what caused me to have the ICS target level to begin with. I consulted a friend of mine who’s far more knowledgable of Android development than I, and he recommended that I fall back to RelativeLayout. He was even kind enough to give me a bare-bones skeleton that was tailored to my screen.

It took a bit of tweaking and experimentation to get things right, but mostly because I’m still pretty new to Android UI layouts — not that it’s that hard to do.


This app was also built with an ActionBar so that the app would have multiple tabs to allow for single-tap navigation to other views. Knowing that this capability was introduced somewhere around Android 3.0, I knew that this would not be as quick or easy as my UI layout re-work.

After concluding that the app would be far too clunky if I abandoned the tabbed views, I wondered “Surely I can’t be the first developer who’s had the need to support tabbed views in Android 2.x”. After a few quick searches, it was clear that ActionBarSherlock ( was the answer to this dilemma. In fact, ActionBarSherlock was written to solve this exact problem.

I downloaded ActionBarSherlock and set up a project for it within Eclipse and then added that project as a dependency. Voila! Next, I had to change the parent classes of my tabbed views to use classes provided by ActionBarSherlock. ActionBarSherlock turned out to be an outstanding solution to this problem — quick, effective, and painless. It turned out to be an excellent drop-in solution to provide the backwards compatibility that I needed without having to drop ActionBar from my app. Nice!

Device Testing

At this point, the app compiled cleanly for Android API level 10 and it’s just a matter of testing. Since I don’t make much use of the Android simulator (real devices for me, thanks), I then started to wonder how I was going to test. All of my existing Android devices were running more recent versions of Android and I needed to keep them intact. After clearing a few cobwebs from my memory, I remembered that I had an ancient Motorola Droid phone tucked away in a drawer. I found the device and charged it up and see that: (a) it’s still in working order, and (b) it’s running Android 2.2.3. Plug it into my laptop and launch the app — it works!


ActionBarSherlock kept my tabbed views working properly on an older device where the software had no concept of tabbed views. This lesson also affirmed that it’s sometimes good to be a packrat and store old technology away ‘just in case’.

BB10 — moment of truth is drawing near

As you’re probably already aware, RIM will soon (January 30, 2013) be unveiling BlackBerry 10 (BB10). Nearly everyone agrees on this — if they fail in any way, they’re done.  It’s also quite possible that even if their execution is perfect (or nearly so), they may still fail. I’m hoping that they succeed and this post explains why.

1.) Choice

Simply put, more options are better. Although I believe that Apple’s iOS solutions are the very best in the marketplace right now, I’m happy that Android is also there. I’m not particularly happy with many aspects of Android (more coming at another time), but competition and choices are both good.

2.) QNX

I have no first-hand knowledge or experience with QNX, but I’ve read enough about it over many years to have a great deal of respect and admiration for it. In a nutshell — it’s a small, real-time, Unix-like operating system. It’s been around for a long time and has survived the test of time (RIM’s business strategy notwithstanding). I would hate to see QNX fade away into oblivion because of a business failure.

3.) Qt

Not to be confused with Apple’s QuickTime (QT), this Qt is a different beast. It’s a mature, full-featured C++ framework that’s been around for a long time. It was started by TrollTech years ago and has been used successfully in many commercial (closed source) and open source projects, with KDE probably being the most high profile. Putting aside my pain points with C++, Qt has made remarkable progress over the years. Like with QNX, it would be very unfortunate to have this technology fade away due to a business failure.

4.) Industrial-Grade Server Infrastructure

I’ve never worked directly with any of the traditional BB server infrastructure, but from what I’ve read, RIM has produced some neat solutions regarding server infrastructure to manage their mobile devices. I think it’s safe to say that neither Apple/iOS nor Google/Android have anything even close to what RIM had available years ago.

RIM still has an uphill and very difficult struggle for survival ahead of it. Their execution has to be nearly perfect on many fronts. If BB10 fails while coming out of the gate, that’s it — it’s all over. However, I think that there’s a fairly large, yet mostly silent, group of mobile device users that really want to see RIM succeed with BB10 and provide an attractive and credible alternative to both iOS and Android. Another way to put it — we need a strong contender to enter the market and give both iOS and Android more competitive pressure.


Get every new post delivered to your Inbox.