Vacationing️

I spent the last few days on vacation. We didn’t go anywhere (other than a soccer tournament - in the rain), the kids had school and my wife was working. So, what did I spend my time doing? Writing code. Obviously…

I’ve been working a big update to Beer Style Guidelines. The updates include a lot of “new” iOS features. These include:

All of this and I’m still trying to learn (and use) Combine and SwiftUI. I was very excited when those technologies were announced (almost) 2 years ago. I just haven’t had the ability to use Combine or SwiftUI at work. I’ve used them here and there in my side-projects, but not enough to feel proficient in them.

So, why am I spending my vacation time learning about these features and implementing them? Honestly, I don’t get an opportunity to learn and work on this during my day job. At work, we need to support iOS 11/12+ (depending on the app). That means that I don’t get to use the new hotness at work. So I need to do this learning and implementing using my side-projects.

Using my vacation time to learn “new” (well, almost 1 and 2-year old) technologies isn’t ideal. But I feel like this is something I need to do. It’s either this or continue to feel like I’m always behind in iOS development.

I’ve made a lot of progress on my update to Beer Style Guidelines. I hope that I can get this latest update out into the App Store before WWDC. That will give me the opportunity to start learning the next set of iOS features I want to implement over the Summer.

Running 🏃🏻‍♂️

I started running a long time ago. The first run I logged into Nike Run Club was in August of 2006. I think I started running a year or two before that.

The reason that I started running was that I was fat. Seriously. Looking back at the photos, it looks like I ate one of my kids. I weighed roughly 60lbs more than I do now. I think I used to wear size 38 or 40 jeans (loose fit).

Getting started

I started by walking. That worked for a while, and then I decided that I wanted to run. I had never really run before this. But I decided that it was something I wanted to do. So one Saturday morning, I went to a local park (with a circular trail) and I ran one lap, and then walked a bit. Then I did it again. I think I did it three or four times before calling it a day.

Since that day, I have run miles and miles and miles. In Nike Run Club, I’ve logged over a thousand miles. I’ve also logged hundreds of miles in RunKeeper and hundreds of miles on my Apple Watch. This doesn’t include the miles and miles I’ve run without any sort of tracker.

5k(s)

I’ve run in countless 5k events. I used to sign up for a lot of these each year. My brother and I used to run these together all the time. At one point, I did well enough to finish in the top 5 (or 10) of my age group.

Half Marathon(s)

Then I started running in half-marathons. I think I ended up running in 3 or 4. I still have the medals for these in the basement somewhere. The best of these that I ran was under 2 hours for a half marathon. This was probably at my peak running. I loved running during this time and loved competing in half marathons.

Marathon

Somewhere along the line, I got it in my head that I wanted to complete a full marathon. So my brother and I signed up for the Philadelphia Marathon and started the training. I ran almost every day. It got to the point that if I was scheduled to run for less than 6 miles on a given day, it just wouldn’t feel worth it.

Finally, race day came and I felt great through about 13.1 miles. The halfway point was also the endpoint for the half marathon (duh). When I got there, I almost decided to end it there. But I continued.

We finished the race, I had to walk more than I wanted. I also finished slower than I wanted. I hated myself for the last 3 or 4 miles. But I finished, that’s the important point.

Life after the marathon

It’s funny. I loved running before the marathon. Since the marathon, I don’t really want to run to train for anything anymore.

I still run. Usually once or twice a week. I have a day where I’ll run for 10 minutes to finish my workout and another where the entire workout is a run. I don’t enjoy it as much as I used to, but it gives me time to listen to a book or catch up on podcasts.

I also run on vacation or while traveling. Running is an easy exercise to plan out. I don’t need to find a gym, or bring equipment, just a pair of running sneakers.

I have zero interest in ever attempting another (full) marathon again. A half-marathon was the sweet spot for me. There’s a part of me that wants to run another half-marathon, but I’m not sure if I have the conviction to see that through.

🏃🏻‍♂️

UIKeyCommand — Part 3: macOS Catalyst Menu Items

This is the final post in a series on adding UIKeyCommands (keyboard shortcuts) to an iOS app. In this post, we’ll cover how to add menu bar items to a macOS Catalyst app using UIKeyCommands.

This will not be a full tutorial on how to add menu items to macOS Catalyst apps. Instead, this post will demonstrate that you can use the same keyboard shortcuts created in part two and create menu items.

In macOS Catalyst apps, your UIApplicationDelegate class (usually AppDelegate) will configure the menu bar. This is handled in the func buildMenu(with builder: UIMenuBuilder)  method (documentation). In this method, you can add and remove menu items and sub menu items.

You can download the corresponding sample app here (the branch is part-3-catalyst). I slightly refactored the code that creates the UIKeyCommand to be a class level variable on the two view controllers. They can now be easily accessed like: TableViewController.showTableAlert.

Use the existing UIKeyCommand objects in a UIMenu initializer and then added to the builder object in the buildMenu method (from above) like this:

let menu = UIMenu(title: "Show",
				  identifier: .show,
                  options: .displayInline,
                  children: [TableViewController.showTableAlert,
                             DetailViewController.showDetailAlert])

builder.insertChild(menu, atStartOfMenu: .file)

This little block of code adds the “Show Table” and “Show Detail” menu items. When you run the app, it will look like this.

Resulting menu

That’s it. That’s really all there is to it to take existing keyboard shortcuts and add them to a macOS Catalyst app as menu items.

UIKeyCommand object are incredibly versatile in the situations we’ve gone over in this series. They can be added to both simple and more complex apps. They can also be used in macOS Catalyst apps to provide menu bar items.

Part 1 | Part 2

UIKeyCommand — Part 2: Split View Controller

In the first post in this UIKeyCommands series, we went over the basics of UIKeyCommands and adding keyboard shortcuts to an app. Adding keyboard shortcuts to a real app can be a little more complicated, but not much.

First, some background

My latest update of Beer Style Guidelines has these keyboard shortcuts reenabled. A long time ago, I had keyboard shortcuts enabled within the app. At that time, I didn’t have a clear understanding of how they worked. This lack of understanding meant that the keyboard shortcuts didn’t quite work the way I expected them to (or at all sometimes).

I became frustrated with my lack of understanding and I just disabled the keyboard shortcuts. I didn’t have a lot of time to investigate and figure out what was wrong. But I was determined to figure it out. Recently, I had purchased an iPad Air (4th Generation) and an Apple Magic Keyboard. This gave me the kick in the butt to get the keyboard shortcuts working again.

Getting the keyboard shortcuts working wasn’t a lot of work. I just lacked an understanding of how to put it all together. I hope to impart some of that wisdom in this post.

Beer Style Guidelines has a Split View Controller view architecture.

Split View Controller Wireframe

In my first iteration of keyboard shortcuts, I had two or three commands. They were all triggered from the Detail View Controller (the large part of the screen). I wanted to add more keyboard shortcuts, but I was paralyzed with not knowing how to proceed.

Ok. So, what was holding me up? I wasn’t sure which view controller in the app I needed to implement the keyboard command. Did I need to add them all to my Split View Controller class? Did I need to implement the commands in one view controller or the other, based on a user’s focus?

I started by adding the commands to the split view controller class. But it turns out that isn’t the correct answer. The correct answer is that you implement the keyboard commands wherever you need them, and let the Responder Chain take care of the rest.

Responder Chain? What?

In iOS, there is this thing called the responder chain. The responder chain is how iOS (and UIKit) determine how to handle events. This chain starts with the first responder and then traverses the rest of the chain looking to handle the event. In the case of UIKeyCommands, UIKit will traverse the responder chain and collect the UIKeyCommands for the current scenario.

This WWDC video (Support hardware keyboards in your app) does a fantastic job of explaining all of this. It’s also super short. I only discovered the video after I figured out how this works.

You may have noticed that the UIApplicationDelegate class (usually called AppDelegate) is a subclass of UIResponder. What you may not have noticed is that all UIViewControllers and even UIViews subclass UIResponder.

Back to UIKeyCommand

Getting back to where to implement the keyboard shortcuts. I ended up implementing the keyboard shortcuts for the list view (search, change guide, etc), in the list view controller. The keyboard shortcuts used in the detail view controller (like toggle favorite, next/previous section, etc) were implemented there.

Like in part one, I’ve created a sample app to put this into practice. This sample app uses a Split View Controller and implements keyboard shortcuts where it makes sense. The sample app only has a few keyboard shortcuts.

The list view controller has two keyboard shortcuts and so does the detail view controller.

You may notice something strange about these keyboard shortcuts. Both have the “Show Info” keyboard shortcut. I did this as a test more than anything. I wanted to see what would happen if there are duplicate keyboard shortcuts. Likewise, I also wanted to see where this was called from when triggered. I discovered that found that the keyboard shortcut in the detail view controller usually wins. I think that’s because it’s the first responder in the chain that responds to this command.

This may feel a bit overwhelming. But it’s not very difficult. The sample app should give you a better idea of how easy it is to implement keyboard shortcuts in a split view controller.

There’s one more post in this series. Next time, we’ll stray away from iOS slightly to use UIKeyCommands to add menu items to a macOS Catalyst app.

Part 1 | Part 3

UIKeyCommand — Part 1: The Basics

This post is the first in a series of three on UIKeyCommands on iOS. In this first post, we’ll go over UIKeyCommand at a high level.

What are UIKeyCommands?

UIKeyCommands represent a key press (or combination of key presses) on a hardware keyboard that will trigger an action. In short, you can think of these as keyboard shortcuts. The system already has a few built-in keyboard shortcuts. Some of these are keyboard shortcuts are Cut (⌘ + x), Copy (⌘ + c), and Paste (⌘ + v).

Beginning in iOS 7, Apple started allowing developers to implement keyboard shortcuts. The system already handles Cut, Copy and Paste and developers won’t need to implement these.

These keyboard shortcuts have been around for a few years. So, it’s easy to see how other developers have implemented these. A great way to discover what keyboard shortcuts apps have is to launch the app, and then hold down the command (⌘) key. Here’s an example from my app Beer Style Guidelines.

iPad Keyboard Shortcut Discovery

How do I implement my own UIKeyCommand?

There are two parts to implement UIKeyCommands in your app. First, is the UIKeyCommand object itself. Then these UIKeyCommands need to be integrated into the app.

The initializer for UIKeyCommand has a lot going on. You don’t need to use every parameter. Here are the minimum parameters to create a UIKeyCommand object. Those parameters are:

  • title: This is the display title of the keyboard shortcut.
  • action: This parameter points to the method that gets called from this shortcut.
  • input: This is the keyboard key (a string) that is part of the keyboard shortcut. For example, the “c” in the Copy shortcut (⌘ + c)
  • modifierFlags: This is the modifying key that is the other part of the keyboard shortcut. For example, the “⌘” in the Copy shortcut (⌘ + c)

Putting all of this together, you can create a keyboard shortcut like this:

let infoCommand = UIKeyCommand(title: "Show Info",
                               action: #selector(showInfo),
                               input: "i",
                               modifierFlags: .command)

In this example, the user will trigger a keyboard shortcut to show info when they use ⌘ + i. This will show them an iOS alert with a simple message in it.

I’ve created a sample app that pulls all the various pieces together. The sample app, is simple. It has a single keyboard shortcut. You can discover this just like keyboard shortcuts in other iOS apps.

Download and run the sample app. Once launched, hold down on the Command key (⌘) until you see the prompt showing the single keyboard shortcut within the app.

Testing in the simulator.

If nothing shows up, and you’re testing this in the simulator, you may need to enable “Send Keyboard Input to Device” in the simulator. This can be done through the menu system by selecting I/O → Input → Send Keyboard Input to Device. Or, you can click on this button in the toolbar (below) of the simulator. Without doing this, sometimes the keyboard shortcuts can be lost, and it will seem like the keyboard shortcuts are not working.

Send Keyboard Input to Device

That’s it. Keyboard shortcuts are straightforward to set up and get working in your apps. Next time we’ll get a little more in-depth on UIKeyCommand.

Part 2 | Part 3