Counting Bits in an Integer

During a tech screen I was given the task of writing a function to count the number of bits in an integer given. I thought I’d share what I came up with.

#include <stdio.h>

int count_bits(int i) {
    int bit_count = 0;
    int comparator = 0x1;

    for (int x = 0; x < sizeof(int) * 8; x++) {
        if (comparator & i) {
            bit_count++;
        }

        comparitor <<= 1;
    }

    return bit_count;
}

int main(int argc, char *argv[]) {
    // 1
    printf("%d\n", count_bits(1));
    // 2
    printf("%d\n", count_bits(3));
    // 4
    printf("%d\n", count_bits(0x00011101));
    return 0;
}

I don’t know if there’s a better way to do this, but what I did create a comparator with 1 bit (0x1), loop through the number of bits in an int (sizeof(int)*8), do a bitwise AND to see if that bit is flipped in the int I’m counting against, and then shift left one and do it again.

Putting Code on Dropbox

On the latest episode of Under the Radar, David mentioned that he stores all of his code in Dropbox, rather than pushing and pulling to a Git repo to sync between his machines. Of course, he’s not an animal, so he also uses Git, just not for syncing between his personal machines.

I’ve never done this but once he said it, I was pretty much convinced and moved all of my code to a folder on Dropbox. Why wouldn’t I want the current state of my work, including what branches I was working on locally that I haven’t necessarily pushed to GitHub to be kept in sync so everything I need to work is automatically wherever I am?

In fact, if I’m just working by myself on a project by myself, I don’t even need to push it to GitHub at all until I want to share it with someone else in order to get the benefits of having my code backed up externally and kept in sync across my machines?

Am I crazy, missing something, or was everyone else already doing this?

If Object-Oriented Programming Were Announced Today

Graham Lee has a post titled If Object-Oriented Programming were announced today:

Here’s an idea: the current backlash against OOP is actually because people aren’t doing OOP, they’re doing whatever they were doing before OOP. But they’re calling it OOP, because the people who were promoting OOP wanted them to believe that they were already doing OOP.

Basically, Graham argues that a lot of the “newer” paradigms are just OOP by a different name, and that none of us were really doing pure OOP to begin with. You should also check out his talk at UlKonf 2015Object Oriented Programming in Objective-C — where he talks about a lot of the same things in greater detail.

My New Podcast: The Run Loop

The first episode of my new podcast, The Run Loop, is now available in iTunes, Overcast, and wherever else great podcasts are found. You can also listen and subscribe on the shows website. The Run Loop will be a weekly discussion about making iOS and Mac apps with great designers and developers. In this episode I talk to my friend Samuel Goodwin about how he got started, peer mentorship, our trip to Japan, and more.

If you like what you hear, please subscribe, rate, and recommend the show.

You can also help support the show through Patreon. If you donate $1 or more a month, you will receive my sincere gratitude and help me make more and better content, but up to five people can also donate $50 a month and receive an hour a month of my time for a design or code review.

I also want to thank to Joe Cieplinski for creating great artwork for the show. I hope you enjoy this first episode, and I’m looking forward to making many more.

The CocoaPods App

Managing third party code on iOS has always been a pain. In the past 9 years or so I’ve done everything from dragging source directly into projects, to Git submodules, to CocoaPods, to Carthage, to Git submodules again. Right now I’m using CocoaPods.

I’ve had three problems with CocoaPods from the beginning:

  1. It messes with my Xcode project files.
  2. It stops working for me all the time.
  3. I don’t want to mess around with Ruby gems.

While the first issue seems pretty much intractable, the CocoaPods app seems to (potentially) fix the second two by bundling its own Ruby environment in the app. Because it’s from the people who make CocoaPods, I assume it’ll keep updated to match the command line tool.

The app itself is pretty barebones. I’d love to see a future version let me see what updates are available for my pods from within the app and abstract away me having to edit the podfile by hand. Either way, I’m going to give it a shot. You can check it out on the CocoaPods website.

Creating StoryWorth for iOS 1.0

I’m really excited to announce that a new app I’ve been working on for several months has come out today. The app is called StoryWorth, and you can download it now. It’s a companion to the website of the company I work for. StoryWorth lets you collect and share (with recipients you choose) your family stories. To get started, you invite a storyteller (mom, dad, grandma, etc), and then we start sending them questions. They can answer through the app, email, or on the website with text, images, or audio. Once you’ve collected some stories, we can print them up in a nice book (you can pay to have audio transcribed) you can put on a shelf and keep forever, regardless of what happens to us. I should mention too that StoryWorth is a paid service. We’re not interested in showing you ads or selling your information.

Oh, also, we have an app now. It looks like this:

HomeStorytellerStory

Design

For the design, a big focus was accessibility. We have users as old as one hundred, so we could be pretty sure some of the people using the app would have limited mobility or vision. The default sizes for text in the app tends to be a little on the large size, but I also did my best to support Dynamic Type so that users who needed to could turn up the font size. I’m looking forward to taking the accessibility stuff even further in future versions.

Aesthetically, we wanted to go for sort of a book feel, while still looking cool and app-like. We did that mostly by focusing on typography and restricting the color palette so that the content and actions really stand out from each other. We use a sans-serif font (Lato) in our primary red color (except in navigation and toolbars) for actions, and a serif font (Merriweather) for most content and long form text entry. Overall I’m really happy with how the design of the app turned out.

When choosing what features the app would have, our goal for 1.0 was to get parity on the most important things (writing, reading) with the website. It’s not completely one for one yet, but it’s an awful lot of it. Having a solid basis of a native app is also going to let us do things that the website can’t do easily when it comes to things like recording audio, offline reading.

Technical

StoryWorth is the first app I’ve shipped that’s entirely written in Swift. In the beginning, learning Swift while writing the app probably slowed me down a little bit, but it didn’t take me very long to become productive. At this point I feel completely comfortable in Swift and think I made the right decision. Swift still has some rough edges, but there’s enough good there to make it an overall win. Mostly the problems I run into have to do with using it with the iOS frameworks, storyboards, and other things that came around before Swift existed.

Speaking of storyboards: I don’t know, man. I used them, and I guess they made things easier, but I also sort of want to tear them out half the time. I hate how they’re stringly typed, I hate prepareForSegue:, and I hate how using them pretty much precludes being able to use non-optional properties in my view controllers. On the upside, they’ve improved a bit over time. Storyboard references make it easier to break up a big monolithic storyboard into many smaller ones. Setting up child view controllers is really easy in a storyboard too. I only used a static table view in one place, and it ended up needing some cells to show or hide conditionally, so that wasn’t especially useful. As cool as that is, it turns out I never end up having more than one or two static table views in an app.

Going back to Dynamic Type, there’s a couple of things I did to implement that. The first was to create UILabel subclass which listens for content size category notifications and adjusts itself as needed. This worked pretty well for pretty much anywhere I had labels, but not for some other things. Dynamically sizing table view rows were also a godsend, since all I had to do was set up my constraints and the table view would do the right thing if the font of it’s contained labels got bigger. Overall, I found working with Dynamic Type sort of a pain when it comes to native views. I’d like to come up a better solution in the future that will make it easy for me to support it in the places I didn’t get to in 1.0.

I do use web views in a couple places in the app though, and it turns out supporting Dynamic Type in those is crazy easy. All you have to do is use one of the -apple-system styles for your CSS font property, set font-family and font-size (in em) to whatever you want. Make your controller listen for UIContentSizeCategoryDidChangeNotification, and whenever a notification comes in, reload the web view. Easy. There’s a good post about it on the official WebKit blog.

Grab Bag

  • UIStackView is rad.
  • Protocol extensions are neat and useful.
  • The new Swift selector syntax doesn’t like nil targeted actions.
  • Carthage breaks much less than CocoaPods for me.
  • I love universal assets.
  • I don’t know if I’m going to stick with Core Data.
  • Color spaces are confusing.
  • App review remains a magical experience.

Conclusion

I took a job at StoryWorth because I wanted to work with nice people on something that’s actually useful, whose business model I understood, and where I could have a big impact. It’s been a while now, and I really like it still. I’m excited to improve the app over the next several months. Please download the app and invite your family. There’s a free trial, and if you decide to subscribe it helps us a lot. Getting to know your family and having something to hold onto forever is something you’ll thank yourself for.

Moving From Parse to OneSignal for Push Notifications

Parse is shutting down, and if you want your app to keep working, you’ll need to move to something else. I’d recommend doing it sooner than later. Thankfully our app isn’t out for another few weeks, and since the only thing we were using Parse for was push notifications, it wasn’t more than a couple hours of work to switch over to something new. The thing we found to handle our push notifications was One Signal.

Aside from Parse I’ve also used Urban Airship, Push IO, and a custom push server. Custom was definitely the worst. If I were writing the backend myself, custom might not have been so bad, but since I was always working with other developers, it was always a pain because it required involving someone else to test the thing and there was always something wrong with the certificate setup on the server. Out of all of those OneSignal has been the easiest, followed by Parse. I like OneSignal better than Parse though because it’s just push instead of one part of a larger thing that sort of expects me to be using their whole platform.

Email Validation String Extension

I’ve been using this extension on on String to make checking if a string is a valid email easy. If you know a better place this could live, let me know, but an extension on String felt as good a place as any. I didn’t write the original regex (although I did need to tweak it to make addresses with + in them work), but I’ve tested it and it works well as far as I can tell.

extension String {
    func isValidEmail() -> Bool  {
        if self.isEmpty {
            return false
        }

        guard let regex = try? NSRegularExpression(pattern: "^([a-zA-Z0-9_\\-\\.\\+]+)@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.)|(([a-zA-Z0-9\\-]+\\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\\]?)$", options: []) else {
            return false
        }
        return regex.numberOfMatchesInString(self, options: [], range: NSMakeRange(0, self.characters.count)) == 1
    }
}

Less Gross Storyboard Segue to a Navigation Controller

This is a really ugly piece of code I’ve found myself writing in Swift whenever I’m preparing a storyboard segue where the destinationViewController is a UINavigationController whose root view controller is the thing I actually need to set properties on:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
    if let viewController = (segue as? UINavigationController)?.topViewController {
        // Set up the view controller
    }
}

And so I decided to make this slightly less terrible by adding this category to my app:

extension UIStoryboardSegue {
    var navigationController: UINavigationController? {
        get {
            return destinationViewController as? UINavigationController
        }
    }
}

So now that ugly line becomes this:

if let viewController = segue.navigationController?.topViewController {
        // Set up the view controller
}