I wrote a 2-part series on GamePlayKit’s Rule Systems framework for Smashing Magazine.
Part 1 is the basic idea and shows how to replace conditional logic that might be strewn around a project into a GamePlayKit rule-system.
In Part 2, I show the support for fuzzy logic rule-systems (logic values ranging from 0.0 to 1.0 instead of strictly true and false). It covers a little more of the features of rule-systems and how to implement NOT, OR, and AND for fuzzy values.
Both articles are supported by Swift Playgrounds in GitHub so that you can play with the concept and try different rules.
Yesterday I gave a talk about practicing iOS development at NERD Summit. I had a great time — if you were there and had any questions or wanted more guidance on learning iOS development, please get in touch.
On March 18th, I’ll be giving a presentation to teach iOS development by looking at completed apps and customizing them.
If you are planning to attend and want help after the talk to set up your machine and get started on the exercises, here’s what you’ll need:
- To do the exercises, you need a Mac with Xcode 8.2+ installed. If you don’t have access to a Mac, I think we’ll have enough people with one and can pair you with someone.
- We’re going to be forking apps on GitHub, so having a GitHub account already would be good.
- You don’t need a device — we’ll be able to use the simulator for all of the examples, but if you want help getting apps on devices, sign up for a free Apple Developer account.
It’s a beginner talk, so anybody with an interest in programming will get something out of it. It will help if you have some programming experience (in any language).
Here’s the plan
- Basic Swift (enough to be able to read the apps)
- The MVC pattern as implemented in
- Interface Builder (connecting outlets and actions)
- Then, we’ll fork an app and make some customizations
- Based on the group’s questions, we’ll cover as much iOS Development and Swift as we need.
The idea is that the apps we’ll fork are generally useful apps that people might want a custom version of. All of the code is open-source, and you’ll be able to continue to develop them after the workshop if you wish and release them to the App Store.
I’ll introduce the apps in subsequent blog posts here (I have to make them).
There will be handouts so you can work on your own after the talk.
Earlier this year, Trello launched in 21 languages. I worked on the i18n effort of the iOS apps, and I have been collecting thoughts for a series of blog posts. The first one, about plurals, was published today on the Trello Tech Blog. It begins
On page 52 of my copy of K&R, in a discussion of the
?: operator, is this line of code
printf("You have %d item%s.\n", n, n==1 ? "" : "s");
And thus began my decades-long proliferation of plural-unfriendly strings.
To see why, read the rest of Lessons from Internationalizing Trello, Part I: Plurals on iOS
As a follow-up, I found a Russian translation of K&R. Here is how that line of code is translated
printf("Вы имеете %d элемент%s.\n", n, (n%10==1 && n%100 ! = 11) ?
" " : ((n%100 < 10 || n%100 > 20) && n%10 >= 2 && n%10 <= 4) ?
"а" : "ов");
Which is another way to do it, I guess.
At WWDC 2016, there was a code-sample published along with a talk about how to “talk to the LiveView” of a Swift Playground on iOS. As more iOS10 betas were released (and Swift was updated), this code-sample has become out of date. Here is my fix of TalkingToTheLiveView.
Back in 2008, I learned Objective-C to make my first “iPhone OS” app, Habits. When it was released, Habits looked like this:
This weekend I finally finished v3.0 and made it free.
As this is a developer site, the more interesting thing to note is that Habits was originally made in the first iPhone supporting version of Xcode (with external Interface Builder) and I have been migrating the project file from version to version since then (using 7.3.1 to make the current build).
Some things that were introduced into Habits for this version:
- Swift – all new classes were made in Swift and many existing ones were refactored into Swift
- Accessibility – Since NSSpain 2015, I’ve been running my iPhone with triple-Home to get into VoiceOver (suggested by Hermes Pique in this talk). Doing that made me realize (1) what it was like to use Habits without looking at it (2) how easy it was to make it work properly.
- fastlane – specifically “deliver” to manage the iTunes record and “frameit” for fancy screenshots
- Carthage – there had never been 3rd party libraries in Habits, but I decided that one was worth it this time.
- TOCropViewController – A simple framework that does one thing very well – provide a View Controller for cropping images. I use this instead of the built-in iOS one because it supports locked aspect-ratios.
I appeared on an episode of The App Guy podcast that aired yesterday (12/27).
If you build iOS apps and send the IPA to others to install, there are a few simple checks you can do before you send it that will make sure it will work.
- Go into your Build Settings and set the “Validate Built Product” to Yes — that way you won’t be able to build if your provisions are wrong. This is the default for new projects in recent versions of Xcode, but check it to make sure.
- Open the IPA that was created. It’s a bundle, so copy and rename the extension to .zip. Then look for the mobileprovision XML file. You should see the device UDID that you intend to send it to.
- Always increase the version # of any build that leaves your machine. If you don’t do this, iPhone Utility or anything else can decide to offer a cached version instead. If you have a good place in your app to show the version, do it.
If #1 above causes you not to be able to build, then use Apple’s Provisioning Troubleshooting guide.
If the device isn’t listed in the mobileprovision file, then make sure it’s added to the provision in developer.apple.com’s certificate area. Regenerate it and download it once it’s right.
Even if you are using a system like TestFlight, you should follow these tips. TestFlight can’t make an invalid app work, and it can’t fix an IPA that doesn’t have all of the device UDIDs in it. All it does is automate over-the-air IPA installs (which is great), but it still operates within the confines of the app distribution system.
When I announced Habits 2.0, a fellow Western MA Hackathoner, Molly McLeod, reminded me of BJ Fogg and his Tiny Habits method.
Only three things will change behavior in the long term.
Option A. Have an epiphany
Option B. Change your environment (what surrounds you)
Option C. Take baby steps
I had first learned of BJ from Ramit Sethi’s interview with him. The moment I remember most clearly was his method to start to floss. He suggested that you only commit to flossing one tooth each day — if you did that to start and internalized that that was success, you’d start flossing more eventually. I started doing this, and while I’m not a perfect flosser, I do floss most of the time. That convinced me that baby steps were a real thing. If you have any interest in this, sign up for a (free) week-long tiny habits session with BJ.
So, with Habits 2.0 out the door, I am going to plan 2.01, a baby step improvement of 2.0 by just doing a very small amount of work each day on it. I joined BJ’s tiny habits for this week and he recommends adding a 30-second behavior triggered by something you will definitely do each day. I decided that once I put my dinner plate in the dishwasher, I will sit at my desk and run the Simulator. Then, I will celebrate that as a success (and mark it done in Habits, of course).
I have been doing that for about 6 days, and each day when I run the simulator, I usually test Habits out a little, and write up a Trello card or write a small test. BJ’s advice is to keep it completely pain-free and small and to not worry about building on the tiny behavior. Still, in this time I have managed to make a bunch of small improvements to Habits, which I look forward to sharing soon.
Back in 2008, I made a simple iPhone app called Habits to help me remember to do some recurring tasks that were not a regular schedule. I made a few updates early on, but it basically did what I needed it to do, so it’s been a while since I have looked at it.
A couple of weeks ago, I decided to refresh its look in anticipation of iOS 7. Unfortunately, an app compiled with iOS 6 doesn’t automatically pick up the new look — at the very least, you need to recompile. Instead, I decided to design something custom that would look good now and feel at home on iOS 7. While I was at it, I updated the icon using the iOS 7 app icon grid.
You can see some screen shots on the Habits documentation page, and if you want to buy it, Habits is 99 cents on the App Store.
Here’s a full list of everything that I had to do for 2.0 in case you’re a developer with an older app and want to see what you might be in for.
- Converted to an ARC app
- Moved lots of properties to auto-synthesize
- Updated deprecated APIs to iOS 6.0 versions
- Skinned the tables, mostly with custom cells
- Added a pan gesture to the front-page cells (try moving them to the left for a short-cut)
- Supported local notifications and badges (requiring a new settings page)
- Made a new icon
- Updated my Google Toolkit unit testing to Xcode built-in unit testing (which was gratefully, very easy) — the main issue is dealing with unit-testing’s idea of the document folder
- Updated all button and default images
- Updated in-app help
- Converted my svn repository to git
- Added database migration to support the settings (this app uses sqlite API directly)
- Refactored a lot of code, mostly in the database, view controllers and custom cells, to share more code.
- Fixed a bug in the calendar to support iPhone 5 size better.
- Updated App Store listing, web page, made this post, etc.