Maximizing the Preview Assistant Editor in Xcode 6

While working through a coding tutorial in the excellent iOS 8 by Tutorials book by the Ray Wenderlich crew, I learned about the new Preview Assistant Editor in Xcode 6. This is a feature that you can enable in an assistant editor while editing a view file (e.g. a storyboard or XIB). It shows what that view looks like on the ever-growing plethora of screen sizes, vastly reducing the time spent testing out UI changes on device simulators. It can also be used to see how a view will look when using strings from different languages, such as infamously long German words.

Rechtsschutzversicherungsgesellschaften!

Having this very useful feature relegated to an assistant editor is a shame. An assistant editor must share a window with its primary editor. I would prefer to open the preview in a new window, which would live on my second monitor, enabling me to see many different previews at the same time without needing to scroll around the assistant editor. I am not aware of a way to do this, but I found the next best thing. Here’s what my setup looks like:

The lefthand screen has the main Xcode window, in which I edit a view. The righthand screen has a maximized window with a nearly fullscreen preview of the view I’m editing on the left. As you can see in the photo, I can fit a preview of all four iPhone sizes into the screen at the same time. When I edit the view on the left, the changes are immediately reflected in the previews on the right. It’s pretty sweet!

Here’s how you can set this up…

  1. In the Project Navigator pane, single-click a storyboard/XIB file to open it in the main Xcode window.
  2. Now double-click that same file to open it in a new window.
  3. Move the new window to another monitor and maximize it.
  4. Click on the new window to make sure it has input focus, then type Option+Command+Enter to open an assistant editor in that window.
  5. In the assistant editor’s jump bar click on ‘Automatic‘ to open the drop-down menu (see the screenshot below if you don’t know what this means).
  6. Click on the ‘Preview‘ menu item to open the preview editor.
  7. Click and hold next to the assistant editor’s jump bar, then drag up or left (depending on which editor layout you prefer; vertical or horizontal), to maximize the preview’s screen real estate.

In case you didn’t understand the step involving the assistant editor’s jump bar, here’s a screenshot for reference:

Have fun!

Posted in iOS8 | Tagged , | 3 Comments

A Swift App that Calls JSON Web Services

In this article I introduce a small iOS 8 app written in Swift, named SwiftPlaces. I wrote the app in order to get more experience with the language and try out some new features in iOS 8, such as Adaptive Layout.

The source code is available on GitHub.
https://github.com/ijoshsmith/swift-places

SwiftPlaces allows the user to search for places by postal code and then view details about a place, including its current weather. It is a universal app, meaning it runs on the iPad…

…and on the iPhone…

iPhone

I made use of the new support in iOS 8 for using UISplitViewController on the iPhone, as well as the iPad. Due to the Adaptive Layout features in iOS 8 it was only necessary to create one storyboard to cover both device types, which is great news!

There are too many bits and pieces I find interesting to review here, so I suggest you download the code from GitHub and check it out in Xcode 6. Here are a few things to keep an eye out for…

Web services

The app calls two Web services from www.geonames.org, namely postalCodeSearchJSON and findNearByWeatherJSON. I wrote a simple class that fetches JSON from a server, named JSONService. Both of the Web services listed above are consumed via that class, which provides closure-based completion handling and the ability to specify which NSOperationQueue the closures run on. Here is an example of fetching a list of places with a given postal code, taken from SearchViewController.

postal-code-search

The success closure uses my custom marshal operator function (~>) to move between a background thread and the main thread, as explained here. This allows the app to create data model objects out of JSON, eliminate duplicate entities, and sort them by name on a background thread, leaving the main thread to only display those objects in a UITableView.

Note: I realize that some postal codes include letters, but it seems that the geonames Web service that I’m using doesn’t support them. I didn’t investigate the matter more than a few failed attempts at using Canadian postal codes. A happy side effect of this is the fun way I show an error message if the user tries to search for something other than a number. Check out UISearchBar+ErrorMessage.swift for details.

JSON processing

I decided to write the JSON-to-model conversion code in Objective-C, because Swift’s type safety is at odds with such an inherently “type unsafe” task. There has been quite a lot of activity and debate around JSON processing in Swift, but I found it was just plain easier to write that code in Objective-C. The following code is from Model Builders.m:

There is quite a bit more to explore in the project, so I encourage you to grab the code and check it out. If you know of a better way to use Swift or iOS 8 features than what I’m doing, please tell me about it in a comment.

Posted in iOS8, Swift | 8 Comments

Simplifying NSJSONSerialization in Swift

While writing a pet project app in Swift I put together this convenience function that simplifies converting an NSData into JSON objects via the NSJSONSerialization class. My JSONObjectWithData function adds a Swift-friendly API on top of the Foundation method of the same name. Here is a Gist showing how it works and how to use it.

Posted in Swift | Tagged , | 2 Comments

Nil-coalescing Operator in Swift

Update: As of Xcode 6 Beta 5 this article is obsolete. Swift now includes a nil coalescing operator (??). I am leaving this article on my blog for people who are curious about why such an operator exists or when to use it.

Working with optionals in Swift can lead to a lot of uninteresting code that unwraps a value and, if it is nil, uses a suitable default value. The problem is compounded by the fact that Swift requires if/else bodies to be enclosed with { braces }. This can cause what should be a simple, small piece of code to become tedious and verbose.

Consider a simple scenario where the user can type a number into a UITextField, which is then parsed from a String to an Int and stored in a data object. String.toInt() returns an Optional<Int> because not all strings can be parsed to an integer value. Regardless of this minor complication, there is no reason why performing such a task should require more than one line of code.

As seen in the last example above, I created a custom operator function, dubbed the nil-coalescing operator. That operator function evaluates to an optional’s value unless it is nil, in which case it evaluates to a fallback/default value. This is based on the null-coalescing operator in C#, which is formed by two adjacent question marks (??). Since Swift does not allow custom operator functions to include a question mark (correction: it does as of Xcode 6 Beta 5), I instead opted for two adjacent exclamation marks (!!). I think of it as “If the optional cannot be unwrapped (because it’s nil), then use this value instead.”

It’s important to note that the expression on the right-hand side of the operator does not execute unless the left-hand expression evaluates to nil. I accomplished that intuitive and expected behavior by making use of “auto-closures”; a relatively obscure Swift feature that allows you to create closures without using { braces }.

Here is a GitHub gist that shows the nil-coalescing operator definition and a few use cases.

Notice that the second to last example does not cause the getDefaultNumber() function to execute, but the last example does because it’s optional value is nil.


I’d like to thank my friend Jordan Nolan for bringing this point up and nudging me to work out a solution.
Posted in Swift | Tagged , | 21 Comments

Custom Threading Operator in Swift

The Swift language supports custom operator functions, similar to operator overloading in C++. This kind of language feature has been known to enable overly “enthusiastic” developers to create a quagmire of unreadable code, which is why I was surprised to see it included in Swift. However, when used with careful consideration and restraint, defining new operators can yield elegant and expressive code with minimal cognitive friction for its readers. In this article I show how to define an operator that simplifies thread marshaling, in particular the transfer of execution from a background thread to the main thread of an iOS app.

The code reviewed in this article is available on Github.
https://github.com/ijoshsmith/swift-threading

This code was compiled and tested against Xcode 6 Beta 5.

Demonstration

The sample project on Github uses a custom operator function in the ViewController.swift file. After the user taps a button two anonymous functions execute on a background thread. When a function completes on the background thread an associated function (i.e. closure) executes on the main thread.

When this code executes it logs:

[back] hello
[back] adding...
[main] goodbye
[main] sum = 49995000

Note that the handleButton action method appears to join closures with a mysterious new ~> operator…

{ /* background code */ } ~> { /* main thread code */ };

Operator ~>

The Tilde-GreaterThan operator (hereafter known as the marshal operator) is not part of Swift proper. I invented it to express thread marshaling semantics. It executes the lefthand closure on a background thread and when that completes it executes the righthand closure on the main thread. This is a very common thing to do when writing iOS apps that don’t suck, but with Objective-C there was never a terse, streamlined way to express it. Swift to the rescue!

I wrote two versions of the marshal operator. Let’s examine the simple version first.

Since Swift does not contain a ~> operator it is necessary to declare its existence, which is the first line of code seen after importing Foundation. The operator function is declared as infix because the ~> appears between two closures. This makes sense if you think of the tilde (~) as representing a thread doing its work and then “pointing at” (>) the next closure to execute when it completes.

The next line of code is an implementation detail. That queue constant is bound to a serial GCD dispatch queue on which all background closures execute. I chose to make it serial instead of concurrent because that simplifies the programming model, but feel free to make the queue concurrent if you prefer it that way.

The operator implementation is basic Grand Central Dispatch API usage, simply executing the background closure on a queue and, when it completes, marshaling back to the main thread’s queue to invoke a completion handler.

As seen previously, there is another version of the marshal operator that allows the background closure to return a result, which is passed to the main thread closure as a parameter. That operator function definition is very similar to the one seen above.

Other ideas

This code is just a starting point. There are many similarly useful versions of the marshal operator just waiting to be written. For example, you might have an array of closures on the lefthand side that all must complete before the main thread closure executes, which could make use of a dispatch group to manage completion handling. Or perhaps an operator that chains together multiple background closures and ends with a main thread closure. The possibilities are endless. Just make sure you don’t go overboard with it!

 

Posted in Swift | Tagged , , | 16 Comments

Understanding Swift’s reduce Method

Swift’s API includes many functions and instance methods that reflect its functional programming heritage. A prime example is called reduce.  You can reduce a collection of values down to just one value, such as calculating the sum of every person’s age in an array of Person objects. Using reduce eliminates the need for writing many loops in a program. Here is an annotated code listing that shows a loop and the equivalent usage of reduce to add together the age of every person in an array.

There are three matching parts between the two code snippets. The green box in both snippets shows how an initial value is defined, in this case zero. The yellow underline shows how each approach iterates the array of Person objects. The red underline is where the sum is accumulated. In the reduce code, the first closure argument ($0) is the running total, which starts at zero, and the second parameter ($1) references a Person object in the people array.

Posted in Swift | Tagged , | 7 Comments

Create a Swift Dictionary from an Array

Here is a Gist I posted showing a Swift utility function that enables you to create a Dictionary containing an optional entry for every element in an Array. It uses the reduce function to create one Dictionary from every element in an Array, based on a closure you provide that turns an array element into a key-value tuple.

This code was compiled and tested against Xcode 6 Beta 3.

Posted in Swift | Tagged , , | 2 Comments