End of an era: BlackBerry no longer making its phones


Close-up of J. Scott Paul’s cover design for the Canadian edition of Losing the Signal: The Spectacular Rise and Fall of BlackBerry, written by Jacquie McNish and my schoolmate from Crazy Go Nuts University, Sean Silcoff.

BlackBerry CEO John Chen’s statement today marks the end of an era: “The company plans to end all internal hardware development and will outsource that function to partners.”

With revenues in the second quarter of 2016 falling by nearly a third and its recent pivot to Android failing to boost sales, there was no choice but to follow through on the promise to leave the handset business if they couldn’t make it profitable.


The same phone: Alcatel’s Idol 4 and BlackBerry’s DTEK50.

The departure from hardware isn’t unexpected. Analysts have been predicting that BlackBerry would switch to software for some time, and its most recent device are other vendors’ hardware with BlackBerry branding (the DTEK50 is an Alcatel Idol 4, and leaked photos suggest that the DTEK60 is the Idol 4S). There’s also the matter of Chen being less than enthusiastic about the company’s hardware business, from his focus on the software side of BlackBerry, to outsourcing manufacturing to several Taiwanese companies, to this “I don’t really use the thing” demo of the Priv from last September:

“We are reaching an inflection point with our strategy,” says Chen. “Our financial foundation is strong, and our pivot to software is taking hold.” The sea change may keep the company alive, but it’ll be a far different entity than the industry-defining behemoth it once was.


Thank you, GSG!


Things have been quiet here on Global Nerdy (and even on my other blog, The Adventures of Accordion Guy in the 21st Century) for the past few days. There’s a very good reason for this — I’ve been busy.

The reason I’ve been busy: I’m in the middle of transitioning from my current job to a new one.


I’ve enjoyed my time as a GSG’s Platform Evangelist. Landing a job with GSG was a very lucky break. From the fall of 2012 to the end of 2013, I ran a telecom consultancy with a former high school friend, and through his hustling and my presentations and documentation, we managed to pick up Rogers (a big Canadian telco with fingers in lots of pies from publishing to cable TV to sports teams — think of them Canuck version of Time Warner) as a client.

That job should’ve made me some decent coin, but it pretty much drained my bank account. That’s because my former friend pretty took all the money for himself while telling the rest of us that we’d get paid soon, “once the client paid us”. I was going broke and paying rent with my blogging profits (fortunately, I was having a hot streak with ad revenue at the time) while my friend started leasing a big house in Oakville, bought a new car, and who knows what else, a fact I discovered when invited to his house one Saturday for a little get-together.


Although working with my former friend turned out to have a lot of downside, there was one significant upside: it got me in touch with GSG. They were also working with Rogers, and loved the presentations and documentation that I produced. They offered me some contract work, which grew into my current job. They sponsored my TN-1 status, which allowed me to work in the U.S., and my first day as a GSGer was March 10, 2014.

I’m thankful for all the things I got to do at GSG, from helping them create a new web site, to changing all their marketing material, to working on interesting projects with GSG partners. I got us our moment on a Times Square billboard:


A GSG press release on a Times Square billboard. Click to see at full size.

I did a number of webcasts with partners, including Enterprise Mobile (a subsidiary of Honeywell)…

…and made a number of videos like this one for IBM, for which I wrote the script, created the graphics, did the narration, and assembled the video:

One of the highlights of my time at GSG was getting to meet (and perform on stage with) the folks at the office in Pune, India:


It was working for GSG that allowed me to move to Tampa to be with Anitra, make enough money to get out of the debt that working for my former friend had put me in, and help cover the costs of a wedding. For giving me the chance to start my new life in a subtropical paradise with a lovely lady, I will always be grateful to GSG.


I leave GSG with no small amount of reluctance. They’re great people to work with. GSG’s COO Amine Doukkali was impressed enough by my work and accordion playing to introduce me to CEO Andy Goorno and President Dan Hughes. I soon began work with Dan Goorno, Phil Caruso, Shauna Heydecker, Chris Martin, and Eric Goldman, as well as Mohan Sathe and Sudhir Bapat, who run the India branch, and so many other solid people.

The field that GSG is in — a mix of telecom expense management, enterprise mobility and networking management, and communications lifecycle management — is filled with companies many times GSG’s size, but you wouldn’t know it by its work. GSG punches well above its weight class because its people go above and beyond what anyone should expect. I’m leaving only because an exceedingly rare and precious opportunity came up — otherwise, I’d have gladly continued my work at GSG. I’m proud to have worked there, and would glad cross paths with them in the future.




Thank you, GSG for everything; I hope you benefited from my being there as much as I did.

If you’ve read this far, you’re probably wondering what my new job is. I’ll tell you later this week.


The two states of every programmer


Sometimes, it feels as if we spend more time in the latter state.

Thanks to Bil Simser for the find!


Social media reports of Samsung Galaxy Note 7 warnings on flights


I’ve been seeings reports from friends on Facebook and Twitter of warnings about using Samsung Galaxy Note 7 devices on flights.

Sutha Kamal, VP Technology Strategy for Technicolor, whom I know from DemoCamp Toronto, was on a KLM flight this morning. He posted on Facebook that one of the safety announcements was “It is strictly forbidden to turn on or charge your Samsung Galaxy 7 phone on this place”. I wonder how actively they had the flight crew looking for Galaxy Note 7s (and not Galaxy 7s, which don’t have the battery problem), what with everything else they have to do.

In response to Sutha’s post, Stuart MacDonald, principal at his Toronto-based consulting company said that Air Canada is doing gate checks for Galaxy Note 7s, and another friend of Sutha’s said that United did the same last Friday.

Farhan Thawar, formerly Mobile CTO and VP Engineering at Pivotal Labs, and currently co-founder of a startup in stealth mode, tweeted this:

web horizontal rule

From there, I decided to search Twitter and found similar reports:

New York Times tech reporter Mike Isaac tweeted this:

Adobe’s principal graphic designer Khoi Vinh tweeted:…

and he blogged about it as well.

Brian Behlendorf, executive director at the Hyperledger Project, had this to say earlier today:

From Rajat Agrawal, BGR India and Mashable India editor:

Buzzfeed’s Anne Helen Petersen:

And there’s this gem from @Pelangihani:

web horizontal rule

Khoi Vinh summed it up quite well in his blog entry:

Potentially embarrassing and even dangerous technological flaws are a fact of life for every hardware company—they may be extremely rare, but they are an ever present risk. What sets the best companies apart from others is their ability to respond in a way that preserves their brand and wins back the trust of customers. Unfortunately, I can’t imagine a worse situation for Samsung than having what amounts to a public service announcement before every flight advising customers not to use your product.


“Return TRUE to win”


Looking for some programming puzzles to test your skill? Try return true to win, a site that challenges you to complete the JavaScript functions it gives you to return the value true. It will also remind you how full of “wat” JavaScript is.


Swift 3 text field magic, part 2: Creating text fields that accept only a specific set of characters


In the previous article in this series, we added a long-missing feature to iOS text fields: the ability to limit them to a maximum number of characters, specifying this limit using either Interface Builder or in code. In this article, we’ll add an additional capability to our improved text field: the ability to allow only specified characters to be entered into them.

MaxLengthTextField: A quick review


A screen shot of the example app demonstrating our improved text field class, MaxLengthTextField, in action. Download the project files for the app.

In the previous article, we subclassed the standard iOS text field, UITextField, to create a new class called MaxLengthTextField. MaxLengthTextField uses the following to give it the ability to limit itself to a set maximum number of characters:

  • It adopts the UITextFieldDelegate protocol, giving it access to its textField(_:shouldChangeCharactersIn:replacementString:) method, which is called whenever is called whenever user actions change the text field’s content. This method lets us intercept this event, and determine whether or not the changes should be allowed. If the method returns true, the changes are allowed; otherwise, it forbids the change, and the text field acts as if the user didn’t do any editing.
  • It adds a private variable, characterLimit, which stores that maximum number of characters allowed into the text field.
  • It adds a property, maxLength, which is used to get and set the value stored in characterLimit. maxLength is marked with the @IBInspectable attribute, which allows its value to be read and set from within Interface Builder.
  • The code within textField(_:shouldChangeCharactersIn:replacementString:) determines the length of the string that would result if the user’s edits to the text field were to be made. If the resulting number of characters is less than or equal to the set maximum, the method returns true and the changes are allowed. If the resulting number of character is greater than the set maximum, the method returns false, and the changes do not take place.

We’ll build our new text field class, which we’ll call AllowedCharsTextField, as a subclass of MaxLengthTextField. Before we do that, we need to tweak the MaxLengthTextField class so that it’s easier to subclass.

Let’s refactor MaxLengthTextField, just a little

If you didn’t work with any of the code from the previous article, don’t worry — this article will provide you with the code for MaxLengthTextField. In fact, it’ll provide you with a slightly tweaked version, shown below.

Create a new project, and within that project, create a Swift file named MaxLengthTextField.swift, which you should then fill with the following code:

import UIKit

class MaxLengthTextField: UITextField, UITextFieldDelegate {
  private var characterLimit: Int?
  required init?(coder aDecoder: NSCoder) {
    super.init(coder: aDecoder)
    delegate = self
  @IBInspectable var maxLength: Int {
    get {
      guard let length = characterLimit else {
        return Int.max
      return length
    set {
      characterLimit = newValue
  func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
    guard string.characters.count > 0 else {
      return true
    let currentText = textField.text ?? ""
    let prospectiveText = (currentText as NSString).replacingCharacters(in: range, with: string)
    // 1. Here's the first change...
    return allowedIntoTextField(text: prospectiveText)
  // 2. ...and here's the second!
  func allowedIntoTextField(text: String) -> Bool {
    return text.characters.count <= maxLength

This version of MaxLengthTextField differs from the version in the previous article in two ways, each one marked with a numbered comment.

The original version of the textField(_:shouldChangeCharactersIn:replacementString:) method contained all the logic of determining whether or not the text field should accept the changes made by the user:

  1. First, we filter out cases where the changes do not add any characters to the text field. In such a case, we know that the changes will not cause the text field to exceed the set maximum number of characters, so we accept the changes by returning true.
  2. Then, we determine what the prospective text — the text that would result if the changes to the text field were accepted — would be.
  3. Finally, use the length of the prospective text to decide whether or not to accept the changes.

Steps 1 and 2 are applicable to any text field where we want to limit input to some criteria. Step 3 is specific to a text field where we want to limit input to a set maximum number of characters. We’ve factored step 3 into its own method, which returns true if the prospective text meets some criteria. There’s a method to this madness, and it’ll become clear once we build the AllowedCharsTextField class.

Now let’s subclass MaxLengthTextField to make AllowedCharsTextField

Add a new a Swift file to the project and name it AllowedCharsTextField.swift. Enter the following code into it:

import UIKit
import Foundation

class AllowedCharsTextField: MaxLengthTextField {
  // 1
  @IBInspectable var allowedChars: String = ""
  required init?(coder aDecoder: NSCoder) {
    super.init(coder: aDecoder)
    delegate = self
    // 2
    autocorrectionType = .no
  // 3
  override func allowedIntoTextField(text: String) -> Bool {
    return super.allowedIntoTextField(text: text) &&
           text.containsOnlyCharactersIn(matchCharacters: allowedChars)

// 4
private extension String {
  // Returns true if the string contains only characters found in matchCharacters.
  func containsOnlyCharactersIn(matchCharacters: String) -> Bool {
    let disallowedCharacterSet = CharacterSet(charactersIn: matchCharacters).inverted
    return self.rangeOfCharacter(from: disallowedCharacterSet) == nil


Here’s what’s happening in the code above — these notes go with the numbered comments:

  1. The instance variable allowedChars contains a string specifying the characters that will be allowed into the text field. If a character does not appear within this string, the user will not be able to enter it into the text field. This instance variable is marked with the @IBInspectable attribute, which means that its value can be read and set from within Interface Builder.
  2. We disable autocorrect for the text field, because it may try to suggest words that contain characters that we won’t allow into it.
  3. Overriding MaxLengthTextField‘s allowedIntoTextField method lets us add additional criteria to our new text field type. This method limits the text field to a set maximum number of characters and to characters specified in allowedChars.
  4. We extend the String class to include a new method, containsOnlyCharactersIn(_:), which returns true if the string contains only characters within the given reference string. We use the private keyword to limit this access to this new String method to this file for the time being.

Using AllowedCharsTextField

Using AllowedCharsTextField within storyboards is pretty simple. First, use a standard text field and place it on the view. Once you’ve done that, you can change it into an AllowedCharsTextField by changing its class in the Identity Inspector (the inspector with the identity-inspector icon):


If you switch to the Attributes Inspector (the inspector with the attributes inspector icon icon), you’ll be able to edit the text field’s Allowed Chars and Max Length properties:


If you prefer, you can also set AllowedCharsTextField‘s properties in code:

// myNextTextField is an instance of AllowedCharsTextField
myNewTextField.allowedChars = "AEIOUaeiou" // Vowels only!
myNewTextField.maxLength = 5

A sample project showing MaxLengthTextField and AllowedCharsTextField in action


If you’d like to try out the code from this article, I’ve created a project named Swift 3 Text Field Magic 2 (pictured above), which shows both MaxLengthTextField and AllowedCharsTextField in action. It’s a simple app that presents 3 text fields:

  1. A MaxLengthTextField with a 6-character limit.
  2. An AllowedCharsTextField text field with a 5-character maximum length that accepts only upper- and lower-case vowels. Its Max Length and Allowed Chars properties were set in Interface Builder.
  3. An AllowedCharsTextField text field with a 10-character maximum length that accepts only the characters from “freaky”. Its maxLength and allowedChars properties were set in code.

Try it out, see how it works, and use the code in your own projects!

xcode download

You can download the project files for this article (68KB zipped) here.

Coming up next in this series…

In the next installment in this series, we’ll build a slightly different text field: one that allows all characters except for some specified banned ones.


Tampa iOS Meetup, Tuesday, Sept. 27: Making sticker packs and apps for iOS 10’s Messages app!


Join us on Tuesday, September 27th for Tampa iOS Meetup, where we’ll cover making sticker packs and apps for iOS 10’s overhauled iMessage app!

With the newly-released iOS 10, the iMessage app will introduce a boatload of new features, including the ability for users to really customize their messages with:

  • Stickers: static and animated pictures that you can include in messages, and
  • Apps: extensions to iMessage that let you use it to customize messages, send payments, play games and more!

One really interesting thing about iMessage sticker packs is that you don’t do any coding to create them! If you’ve got art skills but no coding skills, stickers are your chance to put something in the App Store.

For those of you with coding skills, you’ll find iMessage apps interesting — they’re apps that live within iMessage and extend its capabilities! You can build apps that use iMessage as a platform so that friends can play games, send customized messages, make payments, and more! We’ll show you how to get started writing iMessage apps.

When and where


Come join us at the Tampa iOS Meetup on Tuesday, September 27th at 6:30 p.m. and learn about making stickers and apps for iMessage, which promises to be a great new way to break into the iOS market.

You don’t even need coding skills to get something from this meetup. To make sticker packs, all you need is a Mac, Apple’s free Xcode software and a developer account (we’ll show you how to get these), and a little creativity. If you’re new to Swift but have some programming experience in just about any language, whether it’s Java, JavaScript, C#, Python, Ruby, or any other object-oriented programming language, you shouldn’t have any trouble following the iMessage apps presentation. We’ll make all of our presentation materials, and project files available at the end of the meetup so you won’t leave empty-handed!


Please note that this session of the Tampa iOS Meetup will take place at a new location: the Wolters Kluwer offices at 1410 North Westshore Boulevard (Tampa).

We’d like to thank Jamie Johnson for letting us use his office, Energy Sense Finance for the past year. We couldn’t have done it without you!

What you’ll need


You don’t actually need to bring anything to the meetup, but you can get even more out of it if you bring a Mac with Xcode installed (you can download it for free from Apple).

If you have any questions, please feel free to contact me at