Nick Harris

Archive for the ‘Uncategorized’ Category

Protocol Oriented Programming

leave a comment »

The term “Protocol Oriented Programming” has been thrown around a ton over the last year. If you’re wondering what it means, here’s an example that I dealt with tonight while working on Euchre…


Over the weekend I implemented a way to save multiple in progress games and have iCould key/value storage sync them across devices. The initial implementation was pretty dumb and saved any game in progress. This lead to a long list of saved games just in my testing. That’s not a great user experience. The user should make the decision to save their current game or delete it.

In the app the user can start a new game from the regular Game View or they can elect to resume a game which shows the Saved Games View:

Screen Shot 2016 06 06 at 11 03 37 PM     Screen Shot 2016 06 06 at 11 03 52 PM

Both of the views need to be able to prompt the user to save their current game. They both also have different actions once the user makes their decision.

Protocol Oriented Programming Solution

The best way to solve this was to first create a protocol named SaveGameProtocol that has the current GameController that I want to archive:

protocol SaveGameProtocol {

    var gameController: GameController? { get set }


Next was to add an extension to that protocol that does the save / delete prompting and handles the users decision before invoking a completion handler. This makes the extension very generic. It does its save / delete job but leaves the rest up to whatever SaveGameProtocol adhering UIViewController that wants to call it.

extension SaveGameProtocol where Self: UIViewController {

    func promptUserSaveCurrentGame(completionAction:(()->())) {

        let alertController = UIAlertController(title: NSLocalizedString("save_game_alert_title", tableName: "GamePlay", comment: ""), message: nil, preferredStyle: .Alert)

        let saveGameAction = UIAlertAction(title: NSLocalizedString("save_game_button", tableName: "GamePlay", comment: ""), style: .Default) {
            action in

            if let currentGameController = self.gameController {


        let deleteGameAction = UIAlertAction(title: NSLocalizedString("delete_game_button", tableName: "GamePlay", comment: ""), style: .Destructive) {
            action in

            if let currentGameController = self.gameController {


        presentViewController(alertController, animated: true, completion: nil)


There is a trick here though. In order to present the UIAlertController using presentViewController we need to make sure the caller is a UIViewController subclass. That can be enforced by using a where clause on the extension:

extension SaveGameProtocol where Self: UIViewController


The last step was to set both my views to conform to the SaveGameProtocol then call the extension with whatever code each needs to continue.

Screen Shot 2016 06 06 at 11 20 34 PM     Screen Shot 2016 06 06 at 11 20 20 PM

And that’s it! Shared save game prompting code for any UIViewControllers that needs it!


Hat tip back to Natasha the Robot  for the pattern.

Written by Nick Harris

June 7, 2016 at 5:41 am

Posted in Uncategorized

Core Animation

leave a comment »

Core Animation is by far my favorite framework to mess around with. Its been my favorite since I started writing Euchre way back for iPhoneOS 2.1. Its simple to use and can be incredibly powerful in calling attention to UI elements when they change. Its also very easy to over do it with animations. I liken it to salt and pepper in cooking. You can enhance your app with just a pinch but too much and it ruins everything else you’re trying to do.

I’ve been playing around with how to show trick winners and hand winners in Euchre for the umpteenth time over the last two evenings. Its one of the parts of continuously re-creating a Euchre game for iOS that I really love. This effort is especially meaningful after getting a grip on how to represent the game in AutoLayout.

I overdid my animations in Super Euchre (the version available in the App Store) particularly around when a team wins a trick or a hand. The state of the game was over represented on the view and the animations to those changes were jarring. With my new take on Euchre I cut those down substantially while still doing subtle things to draw attention:


I like it but I’d be interested in hearing thoughts*.

I had a blast with animations on Solitaire. Dragging piles was a little challenging but fun.


*I don’t present myself as a designer. I’m just a developer who wants to tinker with the design of my own apps that make little money.

Written by Nick Harris

May 11, 2016 at 5:31 am

Posted in Uncategorized

Top Toolbar Design

leave a comment »

I saw this screenshot from the Starbucks app tonight. I was curious (I’m not a Starbucks guy) so I downloaded the app myself.

Screen Shot 2016 05 05 at 10 29 57 PM

Personally I like the design a lot. But what really caught my eye is the use of a top of view toolbar instead of a bottom tab bar.

For my Solitaire experiment I decided to go with the same top toolbar approach. When I went back to working on Euchre I made the same decision.

Screen Shot 2016 05 05 at 10 30 23 PM     Screen Shot 2016 05 05 at 10 31 43 PM

The biggest reason for me was the perception of persistence that tab bar views have. Each tab feels like something that’s always active in the app. For my dumb card games, things like rules or best scores don’t need to feel like they persist. You can bring them up when you’re interested but can then dismiss them and feel like they’re “gone”. Using animations can enhance that feeling for the user instead of the flat feeling of switching between tabs. Presenting modal views on top of your base view feels more interactive to me then tabs.

I’ve also accidentally tapped another tab when holding my phone and jumping me from what I was trying to do. Having the navigation buttons further away from my “work area” means I need to make a more definitive action to switch my working context.

The Starbucks app seems to do exactly what I’ve been attempting to do with my horrible design skills. Views appear from the bottom and overlay the base view while leaving the menu visible. Swipe gestures can be used to dismiss them instead of reaching all the way for the top toolbar. Its not a difficult effect to do and I really like the feel of the app more then I would if they had used a tab bar. There are some things they could do to tighten down the animation (adjusting the background image after viewDidAppear is rather jarring) but all in all I do like this approach to app navigation.

Are there other apps taking this approach?

Written by Nick Harris

May 6, 2016 at 4:48 am

Posted in Uncategorized

PDF Playing Card Assets

leave a comment »

Xcode gave us the ability to use PDF (or single vector driven graphics) a while ago and I’ve never heard good or bad if they should be used instead of strict sized based PNG assets.

I’ve been playing around with them though with Euchre and Solitaire and I like how my PDF assets look on all my devices.

There was a sizable resistance against PDF assets a few years ago. Is that still the case?

Here are some screen shots of my PDF cards on a 4s, 5, 6, 6SPlus, iPad Air and iPad Pro…



5 (or SE)




6S Plus


iPad Air 2


iPad Pro



Those blog images are probably hard to judge from.

Here is my Sketch file and PDF assets I made.

Feel free to use them in your own apps.

But back to the original question…

Are PDF assets OK now?

Written by Nick Harris

March 23, 2016 at 7:16 am

Posted in Uncategorized

Selectors With Parameters in Swift 2.2

with 16 comments

I went back today and recompiled all my latest Swift projects  – Euchre, CloudKitPOC, Suntracker, Solitaire – to see how much Swift 2.2 would break them. The only thing that I got warnings about (I’m a 0 warnings dev) was about changing from string selectors to using the #selector() syntax. They were all warnings but I had problems fixing one of them. The “Fix-it” solution ended up being another warning.

In Solitaire I have a GameController and a GameViewController. The GameViewController is strictly UI only. There is no game logic what-so-ever in it. All of that is contained in the GameController. I also created a PlayingCardImageView subclass of UIImageView to handle all the interaction with the playing cards. For instance, tapping a playing card will execute any plays that card can make in the game.

When implementing this, I had to decide if I wanted pass the GameController into every PlayingCardImageView or have the target and selector of the UITapGestureRecognizer refer back to the GameViewController. I opted for the later. I only wanted one class to be responsible for passing user interactions back to the GameController.

My code in the PlayingCardImageView for 2.1 was:

let tapGestureRecognizer = UITapGestureRecognizer(target: gameViewController, action: "cardTapped:")

The “Fix-it” solution:

Screen Shot 2016 03 22 at 9 07 33 PM

which then lead to…

Screen Shot 2016 03 22 at 9 12 24 PM

Hopefully the first thing you’re thinking as a seasoned Xcode user is “Never use Fix-it!!” and you’d be right. Unless you understand what Fix-it is actually doing its much better to dig into the problem yourself and figure out what the fix should be.

The proper solution in Swift 2.2 for this is:

let tapGestureRecognizer = 
UITapGestureRecognizer(target: gameViewController, action: #selector(gameViewController.cardTapped(_:)))

It wasn’t the most obvious syntax to arrive at but at least I know now.

BTW – here’s a great rundown of Swift 2.2 changes. I’m looking forward to trying out tuple comparisons – particularly with my NSOperation operationResult tuples in unit tests.


I want to point out that I figured it out quite easily with Xcode code completion. I don’t want this post to sound like a dump on the Xcode team. Xcode gets better and better with every release! I bet its just a miss in the Fix-it logic.

Screen Shot 2016 03 22 at 10 03 02 PM 

Written by Nick Harris

March 23, 2016 at 3:37 am

Posted in Uncategorized

Klondike Solitaire Weekend Challenge

leave a comment »

Friday was a snowy day in Denver. There was a lot of basketball on TV too. I decided to give myself a challenge…

How hard would it be to write a Klondike Solitaire app for iOS?

The challenge was just to see how far I could get just on weekend evenings (my weekend days are not for coding). I was going to be watching NCAA tournament games so might as well have something to do during downtimes.

I think I got pretty far! Its not complete, but its easily less then a weeks worth of work to complete.

What isn’t there

– dragging between piles
– scoring
– different game rules (single card from the waste pile is all that’s supported)
– undo

Here’s my game on Phone 6S Plus:

Why Solitaire?

Klondike Solitaire has been a staple on both Mac and PC. After working on this I can see why. The logic is pretty easy. The challenge in the UI. Once you have solid game code the only challenge is passing user interactions into the games controller.

I bet that’s why its been a constant in OS versions for decades. The big challenges are always UI based. The code that drives my game is less then 700 lines of code all told. Its a really simple game with simple rules. I spent much more time figuring out how to make it work on multiple devices.


I’m both surprised at what I got done with 16 hours of work over three days as well as being a bit disappointed that I didn’t finish more. I spent much more time in UI driven roles (creating assists, dealing with Storyboard Autolayout) then I would have wanted too. I wonder how much of what I think is left i would had gotten done if I wasn’t fixated on having something in a video.

The total app is less then 1025 lines. I don’t see it getting more then 2000 when all is said and done.

Fun weekend and fun challenge though!

Written by Nick Harris

March 21, 2016 at 7:42 am

Posted in Uncategorized

Firing People

leave a comment »

Zach Holman wrote what may be my favorite post I’ve read in a very long time titled Firing People. The whole thing is fantastic and I highly recommend taking the time to read it all.

I’ve never been fired but I have been laid off as well as leaving on my own when things didn’t work out the way I had wanted. One was a failed product that I had invested so much of myself into but the company decided wasn’t worth continuing and the other was a role that I never quite figured out how to succeed at given the circumstances. In all those cases though, a lot of what Zach writes about really resonated with me.

One part in particular is knowing where you stand with stock options.

Unfortunately, vested unexercised ISOs are capped at 90 days post-employment by law, meaning that they disappear in a puff of smoke once you reach that limit. This poses a problem in today’s anti-IPO startups who simultaneously reject secondary sales, which limit all of the options available for an employee to exercise their stock (the implications of which for an early employee might cost hundreds of thousands of dollars that they don’t have, excluding the corresponding tax hit as well).

Another possibility that’s quickly gaining steam lately is to convert those ISOs to NSOs at the 90 day mark and extend the option window to something longer like seven or ten years instead of a blistering 90 days. In my mind, companies who haven’t switched to a longer 90 day window are actively stealing from their employees; the employees have worked hard to vest their options over a period of years, but because of their participation in the company’s success they’re now unable to exercise their options.

I’ve talked a lot about this in greater length in my aptly-titled post, Fuck Your 90 Day Exercise Window, as well as started a listing of employee-friendly companies with extended exercise windows. Suffice to say, this is a pretty important aspect to me and was a big topic in the discussions surrounding my separation agreement.

After 8 years at one company I had vested a lot of stock options. When I decided to leave it didn’t dawn on me until I got the formal paper work that it would cost me more then $8,000 to exercise all of the options I had vested and I only had 90 days to do it. There was no way I could spend that kind of money at the time so I lost a good portion of my options. I love the “Fuck Your 90 Day Exercise Window” quote. I burned a few bridges venting about my situation though I’ve since had some great conversations with the company’s founder and ex-CTO about it. If I’m ever in a situation again with stock options I’ll be sure to setup a savings account specifically for exercising them when the time comes without the shock of the price.

If you’re a company that does stock options, be sure you’re very open about how much your employees have vested and remind them of it often. Also be sure to let them know about exercising them in 90 days. I know more then one employee of that company that lost all their stock options because they didn’t know about the 90 day cutoff.

Another great idea Zach talks about it setting up an alumni group.

One of the very bright points from all of this is the self-organized GitHub alumni network. Xubbers, we call ourselves. We have a private Facebook group and a private Slack room to talk about things. It’s really about 60% therapy, 20% shooting the shit just like the old days, and 20% networking and supporting each other as we move forward in our new careers apart.

The same company I spent 8 years at has one and its great. Its not a very active group but when someone is looking for something new, or if someones new employer is hiring, it gets posted to everyone. When the company had a round of layoffs last year the alumni group welcomed them all in easily hitting that 60% therapy mark. It was great though. I really appreciate that group. In fact I’ll be heading to the early round games of the NCAA tournament tomorrow here in Denver with a former co-worker who was just laid off from another job last week. I can guarantee we will be talking about companies we’re looking at since we already have been.

There’s a lot of other great stuff in that post. You should really go read it.

Written by Nick Harris

March 17, 2016 at 2:49 am

Posted in Uncategorized