A Chemist Coding iOs

by Christopher Brandow

Husband, Parent, iOs Developer, Chemist, PEN, used to exercise.

Page 2

Short  Watch Thoughts - III The Missing Magic

Two things made the original iPhone so incredible:1

  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

Continue reading →

Partial vs. Complete Functions

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

Continue reading →

Short  Watch Thoughts - II

 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.1

    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

Continue reading →

Short  Watch Thoughts - I

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.


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

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 on the watch, the phone

Continue reading →

UICollectionView Pagination

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

Continue reading →

The Only “Failure” of  Watch for Me So Far.

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

Continue reading →

NSFetchedResultsController and Time-Based Predicates

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.



Continue reading →

Better IBActions

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:

ibButton - events.png

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

ibButton 1.png

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

ibButton choose arguments.png

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

Continue reading →

This is How I Would Like to Blog

I sort of got away from this mentality and it made making a single blog post a slog.

I am quite impressed by David Walsh’s blog in this regard. Although, David is an amazing programmer who writes awesome posts, he doesn’t go through such a detailed thought process when he has to write something. He often writes nifty tricks and How-To posts that have helped me countless no of times and yet, there are still very few blogs that might be doing the same thing.

Hoping to get back there.

Continue reading →

On Learning Programming

Brian Kernighan and Dennis Ritchie in their classic The C Programming Language wrote that the biggest hurdle in starting beginning learning a programming language is to write a program to print the ‘Hello World’ on the screen, the rest is relatively easy. This is because it requires mastering the mechanics of writing a program : writing it somewhere, running it and seeing where the output went.

This quote from an excellent introductory tutorial on quartz composer perfectly encapsulates my relationship with programming and stumbling blocks that have at times kept me pursuing it more than I did.

There are a lot of ways that this simple idea could/should be applied to efforts to recruit people/children/women/minorities/low income folks/etc. into programming. I know from my personal experience that seemingly small barriers can prevent otherwise qualified folks from doing something they

Continue reading →