little bites of cocoa

We've looked at allowing users to capture or choose images for use in our apps a couple times here. We learned about UIImagePickerController in Bite #83 and then ImagePicker in Bite #157.

Today we've got a new contender in this space called Fusuma. It's by Yuta Akizuki and aims to provide a very full-featured drop-in solution for this task. Let's try it.

We'll start by presenting the main FusumaViewController:

let fusuma = FusumaViewController() fusuma.delegate = self self.presentViewController(fusuma, animated: true, completion: nil)

Then later we conform to the FusumaDelegate protocol:

func fusumaImageSelected(image: UIImage) { imageView.image = image }

There's also fusumaDismissedWithImage and fusumaCameraRollUnauthorized functions for handling those cases.

Getting people to download our app can be tough. It's important to do everything we can to help users get to our app in the App Store, with a chance to download. One great way we can do that is with Smart App Banners. Let's check ‘em out!

These are Smart App Banners. They essentially add a section to the top of a webpage in Safari on iOS that highlights an app. They display the icon, name, rating, price, and a button to view the app in the App Store.

Let's add one to our app's webpage.

All we need to do for the basic set of functionality is add a single meta tag in the head tag of our page:

<meta name="apple-itunes-app" content="app-id=543298335, app-argument=spaceships://spaceship/7”>

The first parameter, app-id, is the ID of our app on the App Store. We can find this in iTunes Connect.

The next bit is where things get more interesting: Smart App Banners know if a user already has an app installed.

We can provide a URL-Scheme URL so that if the user <i>does</i> happen to already have our app installed, they can jump directly to the content corresponding to where they were on the web.

We've covered 3D Touch quite a bit here, we checked out View Controller Previews with Peek and Pop back in Bite #80.

Peek/Pop are great features, it's a shame only our users with the latest hardware can take advantage of them. Today, we'll check out a brand new library that aims to remedy this. It's from Roy Marmelstein and called PeekPop. Let's dive in.

The basic idea of PeekPop is to allow us to support 3D Touch style peeking and popping on devices that don't actually have 3D Touch hardware

The API is quite similar to UIKit's built-in one, let's try it out.

First, we'll register as a delegate, then conform to it:

peekPop = PeekPop(viewController: self) peekPop?.registerForPreviewingWithDelegate(self, sourceView: collectionView!) func previewingContext(previewingContext: PreviewingContext, viewControllerForLocation location: CGPoint) -> UIViewController? { return self.previewControllerForLocation(location) } func previewingContext(previewingContext: PreviewingContext, commitViewController viewControllerToCommit: UIViewController) { self.navigationController?.pushViewController(viewControllerToCommit, animated: false) }

That's it! Neat.

PeekPop will use 3D Touch if available, then fall back on older devices to monitoring signficant changes in a UITouch's **majorRadius **property. (Pressing harder usually causes this to increase, even on older devices, since often more of the surface area of the finger is in contact with the screen).

Setting our app apart can be tricky. We don't want to deviate too far from established conventions, but we don't want to blend in to the crowd either. Small amounts of "polish" to an app's UI can go a long way to making it feel special.

Today we'll check out one more tool in our arsenal for doing this. It's a library from Andrea Mazzini called SubtleVolume.

The idea here is to improve upon the default, screen-obscuring, built-in volume overlay. iOS's system interface is fine for most apps, but often it can get in the way of the content the underlying app is presenting.

SubtleVolume solves this by providing an elegant volume view that we can put anywhere on the screen. Let's try it out:

let volume = SubtleVolume(style: .Plain) volume.frame = CGRect(x: 0, y: 20, width: w, height: 4) volume.barTintColor = .whiteColor() volume.barBackgroundColor = UIColor(white: 1.0, alpha: 0.3) volume.animation = .FadeIn view.addSubview(volume)

Now, the view will automatically hide/show when the user changes the volume, Neat!

The real world doesn't have straight edges. Things are rounded. Our UIViews can be too! Most of us know about the cornerRadius property on CALayer. We can set a value, then see all the corners round themselves to that value:

contentView.layer.cornerRadius = 8

Nice, but what if we only want to round some of the corners though?

let cornerRadius: CGFloat = 8 let maskLayer = CAShapeLayer() maskLayer.path = UIBezierPath( roundedRect: view.bounds, byRoundingCorners: [.BottomLeft, .BottomRight], cornerRadii: CGSize(width: cornerRadius, height: cornerRadius) ).CGPath view.layer.mask = maskLayer

For this, we'll need to get a bit more creative. We can use an often-overlooked type called UIRectCorner.

It lets us describe which corners we'd like to round. Then we'll use a UIBezierPath to create a "mask" layer that will only allow some of the content to "show through".

We pass in an option set for the byRoundingCorners parameter, listing out the corners we'd like rounded.

Today we'll look at an interesting library from Evan Dekhayser called KBKit. It extends UIKit to add support for navigating around using a physical keyboard. (Think either bluetooth or other keyboard connected to an iPad, but would also work on iPhone.) Let's take a look.

KBKit consists of a few subclasses of common UIKit classes. KBTableView adds Up Arrow, Down Arrow, and Return Key functionality to UITableView. Very cool.

let tableView = KBTableView(frame: CGRect.zero, style: .Plain) tableView.onSelection = { (indexPath: NSIndexPath) in // called when user pressed 'Return' or 'Command + D' } tableView.onFocus = { (current: NSIndexPath?, previous: NSIndexPath?) in // called as user navigates with arrow keys }

We can use KBNavigationController to gain a Command + Left Arrow shortcut for going "back" (i.e. popping to the previous view controller in the stack).

Last but not least, KBTabBarController adds support for pressing Command + 1, Command + 2, Command + 3, etc. to change the currently selected tab. It supports up to 5 tabs. Neat!

Swift Enums are super handy. With associated values, they can be used in some quite interesting ways. Today we'll check out a couple. These aren't working examples, but might spark some ideas. Let's take a look.

Enums with Extensions

Keeping colors in one place is a great way to ensure consistency in a project.

public enum Color : String { case Green = "28A860" case Blue = "3B87D6" } extension Color : UIColorConvertible { public func asColor() -> UIColor { return UIColor(hexString: rawValue) } }

This same technique is great for images too!

Enums with Closures

This one is a little crazy (but fun!). Imagine we had our own custom system for laying out views in our app. We could not only describe that system perfectly with enums, we could even add a little more dynamic spice to the mix by making one of the associated values of our enum a closure. Neat!

public enum LayoutStrategy { case SizeToFit case Fixed(width: CGFloat, height: CGFloat) case Relative(closure: ((parentSize: CGSize) -> CGSize)) }

Those who have been an iOS, OS X, tvOS, or watchOS developer for any significant amount of time know that Xcode is an incredibly tool for creating awesome apps. Until it isn't. Sometimes Xcode gets confused and needs our help. Today we'll look at one way we can clean up our environment and possibly get back to work.

There's a myriad of reasons why the following technique resolves many common Xcode issues. The important part is that it works. Sometimes. Maybe.

Anyways, there's this folder full of "invariants" and temporary files that Xcode shuffles things around in as we use it to build our app. It's called DerivedData and contains caches, compiler waste, build products, etc.

If we ever find ourselves wondering if a certain compiler error or unexpected Xcode behavior really is our fault or a bug in Xcode, we can try clearing out this folder before jumping on the Google train.

The "manual" quick/dirty way is to quit Xcode then run:

rm -rf ~/Library/Developer/Xcode/DerivedData

Then re-launch Xcode. Also keep those fingers crossed.

Alternatively, we could use an app to do all this for us. Watchdog is an app that lives in our menu bar and cleans up stale cache files in Xcode. Very cool!

When Swift debuted, we said goodbye to using #pragma pre-processor definitions to organize our code. Don't worry, Xcode still has our backs. We can use a few different "special" comments in our code and Xcode will pick up on them and display them in its jump bar:

The extra dash character in the name of our MARK gets us those sweet separators in the source navigator dropdown.

Xcode also supports a similar bit of functionality for TODO and FIXME comments. They'll show up in bold in the same dropdown.

func launch() { // TODO: launch here } func land() { // FIXME: shouldn't crash }

As a bonus, we can use a little regex magic to get Xcode generate build warnings for TODO and FIXMEs. We'll just add a new Run Script build phase to our project that contains:

Today we'll check out a few different tips and tricks for working with UITableView. Let's get started.

Adding a Refresh Control

We can add pull-to-refresh capabilities to any UITableView easily:

let refreshControl = UIRefreshControl() refreshControl.addTarget( self, action: Selector("refreshed:"), forControlEvents: .ValueChanged ) tableView.addSubview(refreshControl)

Then we just implement that refreshed: function like this:

func refreshed(sender: UIRefreshControl) { refreshTheThing { sender.endRefreshing() } }

Reload Visible Cells

Here's a quick (almost) one-liner to reload only the visible cells in the table view:

tableView.reloadRowsAtIndexPaths( tableView.indexPathsForVisibleRows ?? [], withRowAnimation: .Automatic )

Accessing Rects

It's often handy to grab a reference to the actual frame of a cell, section, header or footer. We can do this easily with:

tableView.rectForRowAtIndexPath( selectedIndexPath )

Animate Height Changes

One easy trick to make our app look a little nicer is to animate changes to the heights of the UITableViewCells in our UITableView. All we need to do is make whatever changes to our models we want to cause our cells to be a different height. (For example we might let the user tap a button to "expand" all comments in an app). Then we just call:

tableView.beginUpdates() tableView.endUpdates()

The guard statement was added to Swift in its 2.0 release. It can dramatically increase the readability and clarity of the conditional checks in our code.

It supports Swift's inline optional unwrapping as well as pattern matching. Let's try it out!

We can think of the guard statement like a sort of inverted if statement. We essentially say: "this thing must be true otherwise we're bailing out!". Here's a fairly full-featured example:

func launch() { guard let fc = fuelCell where fc.level > 0.5 else { showLowFuelWarning() return } startEngines() // ...etc }

Here we're ensuring that we have a fuelCell using optional unwrapping, then using pattern matching to make sure that our (now unwrapped optional) fuel cell has enough fuel in it for us to launch. Right away we can start to see how much clarity this adds.

If either part of our condition fails, we use the else block to run some code then return from the function.

Also as a bonus, the variables we unwrapped in the guard statement are now available, unwrapped, and in-scope for the rest of our function (anything below the guard statement). Neat!

This allows the rest of our function to focus on the actual work being done, rather than checking for validity throughout. We can stack these up too, it's quite common to see multiple guard statements at the top of a functions in Swift.

Today we'll continue looking at initialization in Swift with Designated Initializers. Let's get started.

Swift's initialization system is made up what are essentially a set of rules. We'll step through them here. Let's start with a class.

The first rule of Designated Initializers is that we need one. All classes must define (or inherit) at least one.

Ok, we've added one designated and one convenience initializer. Not too shabby. Now, let's use this base class.

Uh oh, what's going on here? Turns out it's the next rule. We're writing the designated initializer for Peakachew. Designated initializers must call a designated initializer from their immediate superclass, not a convenience one like we tried to do here.

Well, we've fixed our first problem but we've hit the next rule. Designated initializers have to initialize all stored properties on their class before calling super.

Lastly, designated initializers must call their parent class's initializer before assigning a value to any properties they've inherited from it.

With that, we're done. We're now following all the rules:

class Monster { var name: String init(name: String) { self.name = name } convenience init() { self.init(name: "Nameless Monster") } } class Peakachew : Monster { var shouldFollow: Bool init(shouldFollow: Bool) { self.shouldFollow = shouldFollow super.init(name: "Peakachew") } }

Whew!

Often when working with data from an API or third-party we'll need to manipulate or analyze it in a very specific way. In these cases, many of us simply search Google for "how to do the thing to a String in Swift". This usually works out fine, but what a bummer.

Today we'll check out a library from Andrew Mayne called SwiftString, which can help us here.

SwiftString is essentially a collection of a ton of String manipulation and analysis utilities. It has functions like this:

"<rock>blah</hardplace>".between("<rock>", "</hardplace>") // "rock"

"hello".isNumeric() // false "hello7".isNumeric() // false "31.0".isNumeric() // true "-31.0".isNumeric() // true

"star wars".split(" ")[0] // "star"

"star wars"[0...1] // "st"

"#203: Simplifying Common String Operations".slugify() // "203-simplifying-common-string-operations"

"Some [string], *with* %junk in it.)".stripPunctuation() // "Some string with junk in it"

"yay "strings"".decodeHTML() // "yay \"strings\""

We might only need one or two of these functions in a single app, but thanks to SwiftString, we'll never have to write them ourselves again.

Following up on Bite #201 about reporting bugs to Apple, today we'll take a look at a tool that makes reporting bugs even easier called QuickRadar. It's great and will give us a chance to discuss one more piece of this puzzle, OpenRadar.

QuickRadar is a open-source menu bar app for OS X that simplifies and improves upon the "traditional" bug reporting process we looked at in Bite #201. We can download it for free from quickradar.com. We'll move it over to /Applications, then start it up.

We can head over to QuickRadar's preferences to fill in our Apple ID credentials.

Next, we'll select New Radar... to see the app's main interface. Here we can describe our bug, drag in a sample project, etc.

We'll see another option at the bottom: "Send to Open Radar". Open Radar is a site run by the community that catalogs and allows us to search/compare bugs with each other.

Usually we have to post them there manually, but with QuickRadar, we'll just add our credentials in preferences, then check the box. Finally, to ease confusion, links like rdar://12345 only work for Apple employees.

QuickRadar is available at quickradar.com

We've all been there. We hit a bug, and after a bit of debugging we determine the cause actually lives in one of Apple's frameworks. 😱Perhaps even worse, we find a crashing bug in Xcode itself 😨. When we hit these types of issues, our first step to getting it fixed should be reporting the bug to Apple. Today we'll check out how to do it. Let's begin.

We'll start by going to bugreport.apple.com and logging in with our developer account Apple ID.

Once inside, we'll see a delightful iOS 6-ish interface. Yeah... Anyways, we'll click the New button to get started.

Next, we'll select the platform/product we're reporting for.

Finally, we'll be shown the main New Problem form. Most of the fields are self explanatory, but don't feel too boxed in by the format. Just be direct, describe the exact problem as we'd want to hear it described ourselves (imagine if we were the ones tasked to fix it!)

Here's a quick example:

Way back in Bite #1 (zomg!) we talked about initializing View Controllers in Swift. Swift's init functions are still a source of confusion for many newcomers. Today we'll look at a couple cases where Swift synthesizes inits for us.

Structs

Swift offers free "memberwise" initializers for Structs. This means that if we define a Struct, and opt not to any initializers, one will be synthesized for us under the hood using the properties we've given to the Struct. If we add one though, we lose the synthesized init, and become responsible for defining 100% for the Struct's inits.

struct Spaceship { var name: String } let ship = Spaceship(name: "Outrider")

Default Initializers

Classes can synthesize a default init function for us. Only one that accepts 0 parameters, though. We'll get this if we define a class, while assigning default values to all its properties:

class Spaceship { var topSpeed = 1000 var currentSpeed = 0 }

let ship = Spaceship()

iOS gives us a ton of great capabilities to build upon. Being able to use the user's current geographic location in our apps really has changed the world.

We always need to ask for the user's permission first though, so we might as well do it in style! Today we'll check out a simple yet beautiful library from Sven Tiigi called STLocationRequest that uses Flyover to provide a great looking "location access prompt" view controller.

We'll begin by importing STLocationRequest, and configuring and showing a location request controller.

self.showLocationRequestController( setTitle: "Allow location access?", setAllowButtonTitle: "Sure", setNotNowButtonTitle: "Nope", setMapViewAlphaValue: 0.7, setBackgroundViewColor: .orangeColor() )

Then, we can subscribe to the NSNotifications the library posts to know how the user responds.