tl;dr Summary

This is me, figuring out how map and flatMap work in Swift.

tl;dr Conclusions:

1. Think of optionals as an array that can hold 1 or 0 items.
2. Arrays and optionals are both containers that can have map or flatMap applied
3. map unwraps a container, transforms value with supplied function and rewraps result.
4. flatMap unwraps a container, transforms value with supplied function and rewraps either a raw value, or the non-nil value of a contained result¹

Complete Version With Complete Examples

Recently, I had an issue where I was using a tableView with multiple selection allowed, and I had a short array with names ([String]), and I wanted a map function that would return the index of that name in a larger array with all the possible names.

smallNameArray.map({ largeNameArray.indexOf($0)! })

However, .indexOf() returns an optional value, and Swift won’t let map return nil...

Great, But Limited physical UX design

One of my favorite things about the design of the  Watch was the digital crown. It was a perfect translation of traditional watch interaction for a digital watch with scrolling and push interactions available. The addition of the second button was also very tastefully done and together they make a great palette for UX.

However, as others have noted, there are a couple of ways in which the ability to control the Apple watch is limited.

First, when the watch is wet, most touch interactions, including 3D touch, go out the window. This is very unfortunate when I am exercising. Otherwise I love running with the watch despite most exercise apps limitations.

Second, pressing the digital crown works quite reliably as the “home” button for the watch but often feels underutilized when I get the the app home screen.

Third, the primary action of the...

Two things made the original iPhone so incredible:¹

1. It could do incredible things that no “phone” had ever done before.
2. It did a very good job of disguising the slow things that it couldn’t do well right off the bat. (think checker box web views in original Safari)

I think that the Apple watch compares very favorably on item 1, but too often fails at 2 (thinking spinner when trying to launch the simplest of apps). Additionaly, it may be that the acceptable delay is shorter than it is on a phone, since we are so accustomed to responsive phones, and because holding your arm up while looking at a postage-stamp sized screen quickly becomes unpleasant.

Obviously, passing data between the phone and the watch is REALLY hard to do. I wouldn’t suggest otherwise. But that is the constraint around which Apple either needs to impose a simpler paradigm on its users, or figure out how to fake it...

Whoo boy, stick with this seemingly complicated article (linked in the title), because it directly addresses that subtle issue that I face regularly when functions or methods that I write can’t properly map directly all input to your desired output.

This reminds me of a great, simple bit of writing by (I think) David Smith regarding optionals in Swift. Of course, I can’t find it. But the point of that article was that the elegant thing about optionals is that it codifies the fact that all objects are not only subject to having a variety of values but also subject to being assigned a value or not. Making this fact explicit and requiring the author of the code to handle it, leads to better, safer code.

The article in question here is worth reading, even if parts of it are too “academic”. His simple examples really make it clear.

Basically what he is arguing for is that you should not...

Watch Paradigm

The Apple watch is best when it hues to this analogy:

Apple Watch : Information :: Watch : Time

Things that follow from this paradigm:

1. It must deliver information quickly. Almost instantly. I should never “feel the burn” in my shoulder as I hold the watch up waiting to see an app show up.¹

   I will have more to say on this, but I don’t understand why even native apps are so slow to load. This alone has made avoid using almost any app.

2. Information should rarely be more than 1 level deep. This is not a platform for exploration.

3. Any interactions should be without ambiguity. Fiddling is death.

   1. I think that the touch detection is a little sub-par, compared to what I am accustomed to on the phone.
   2. I also think that the icon layout is at least a minor violation of Fitt’s Law. I think that center 7 (1 + 6) icons should be 10-15% larger at the expense of showing the two...

Since I can’t seem to complete thoughtful blog posts over a couple hundred words without getting bogged down, then distracted, I will attempt a series of blog posts on UI/UX thoughts.

Love

I love that I can get notifications about calendar stuff and about messages without having to pull out my phone and potentially interrupt a meeting. I particularly like this when I am spending one-on-one time with someone. Yes, I know that I should just ignore any vibrations in my pocket, or better yet, turn off the phone. But I don’t.

Don’t Love

Problem - Messaging UX

This is a big one for me, and is what drove me to want to write about the Watch. Most of the messaging UX is fine, but I have one issue that might sound fussy, but it has bitten me in the butt a few times.

As you dictate a response, the watch displays the text as it is parsing from your voice, which is great. But, when you tap Done...

I was inspired by @jaredsinclair a while ago, because I had noticed, as he had, the lovely side-swiping UI in the Twitter iOS app. It is paginated, but there is some of each neighboring card visible. So it has three key features: the first and last cards align to their edge; the remaining cards all align to the center; and you can only swipe one card at a time. He posted a rough-and-dirty method.

I had been wanting to try this UI out for something, so I looked to his implementation, as well as another that I came across. They both required some knowledge of external state. First of all, I just wanted to understand how to implement it, then as I did so, I found myself trying to remove as much state as possible. I basically got rid of all the state. I have not taken the next step to turn it into a category method, but maybe later. The formatting below, kinda stinks, so here is the gist...

Having used the Apple Watch for a few months now, I love many things. In particular, I love how quickly and easily I can get messages and notifications and how easily I can send quick messages.

But I have one serious issue with the UX experience for sending messages, and it has bitten me in the butt a few times.

When you dictate a message, it typically starts converting voice to text in real-time. Then you tap done and it processes the voice further, then two buttons slide up, one to send the raw audio and one to send the now fully processed text. You tap one to send. However, if you do not tap either button at this point, and ignore the message, it will eventually disappear.

The problem is that by converting the voice into text in real-time, it implies to a user, like me, that the message is in a “sendable” state and “Done” means send. After pressing Done, the user might lower their...

So, I have a better NSFetchedResultsController blog post in draft form, but after spending a week or so trying to figure out why our NSFetchedResultsController was not getting alerted when the background ManagedObjectContext merged with the foreground MOC…

I found posts on threading, and all other sorts of sophisticated problems, I worried about conflicting insertions, etc.

But it turned out that when we received new data, it was newer than the date defined in our previously created fetchRequest predicate. So:

1. No alerts.
2. No Data upon fetching.

Ugh.

Madness.

This is a small thing, but I am not sure how I have never seen anyone describe this feature of creating IBActions with storyboards, and quick googling doesn’t show me anything obvious.

But when you ctrl-click-drag from UIButton (UIControl) into the implementation section of code in a .m, you get a popup for naming the IBAction that looks like this:

<yawn> Yes, we all know that. But as you can see there are options that can be used, and sometimes we should!

Instead of using the standard event TouchUpInside:

Nor does the sender need to be typed to the default (id)sender:

Lastly, you can choose which arguments are sent to the method:

Being able to choose the type of event right there in the pop-up is great, I was previously, using the side “Attributes Inspector” to drag and connect things. Not as simple.

Being able to have the argument as a typed argument is a nice thing...