I admit it. I was pretty down when Swift was announced. I appreciated the finer points of the reasons for it, however, they weren’t convincing–at least not to me–not at first. I denied that it was actually “expressive” as the overall community was referring to it, however, that was before version 2. It’s at the point when the lights went on for me. I am now a convert and this post explains why–at least one of the reasons. The only question I ask now is while you can do some really cool expressive things, should you? You’ll see what I mean if you read on.
(more…)

You can find other articles on the interwebs about NSExpression and NSExpressionDescription, however, I wasn’t really satisfied with the explanations I’ve seen. I decided to write a post myself after I recently had to become much more intimate with the way Core Data aggregate fetches work. I hope this will make clear what has to be done in order to harness this powerful feature of Core Data.

You’ve heard it said before and sometimes in a scolding tone, “CORE DATA IS NOT A DATABASE. IT’S AN OBJECT GRAPH!”. What normally follows is a discussion about what that means, if you’re lucky. Otherwise, you’re just on your own to go figure it out. In my mind, though, it’s not necessarily wrong to think of it as a database as they have enough things in common to make it a reasonable thing to do and at the end of the day Core Data is backed by a SQLite database. I think that if it helps you understand what is going on behind the scenes better, then go for it. You do have to remember some key differences that can bite you like the need to fetch before updating or deleting, for example. Though with recent additions–last year with iOS 8’s NSBatchUpdateRequest (link to iOS 8 API diff since it’s not currently documented) which allows you to perform a batch update similar to a SQL update query or this year with iOS 9’s NSBatchDeleteRequest (See WWDC 2015 session 220 for more info) which allows for batch deletes based on whatever predicate you give it, the lines seem to be blurring more and more. (more…)

If you get this message when you are adding your server to a team to implement continuous integration using Xcode bots and OS X server:

Server encountered an error with Apple Developer.

Please try again later. If the problem persists, contact Apple Developer Technical Support for help.

It could be a red herring. There’s a support note here: https://support.apple.com/en-us/HT203853 that states the issue has to do with making sure you login as an Agent or Admin. That’s probably a valid scenario, but it may not be as in my case. I got this error message simply because an updated program license agreement needed to be accepted on the web portal. Once that was done, I was able to add the server to the team and could continue on.

(Yes, I know it’s April first, but this is not a joke)

Until today we had no category for a post like this. It now exists…

We offer our deepest condolences, thoughts, and prayers for all those affected by the tragic loss of such a great friend to this community, Jordan Breeding. He lost his fight with cancer this morning and we grieve deeply along with the rest of you. Jordan will be sorely missed.

Sincerely and with heavy hearts,

• Marcus, Matt, and the rest of the CIMGF family.

Many years ago now, I wrote a tutorial for the beginner to learn how to use outlets and actions as this is often one of the least familiar aspects for new developers who are wanting to learn iOS. It’s simple once you’ve seen it, but until then, there’s a gap. This time around I’m presenting an application that is similar to the one I did back then, however, it’s up to date with Xcode 6 and Swift. If you are new to iOS development, this should help get you going.

Beginning iOS Application Development with Swift from Skye Road Systems on Vimeo.

---

tl;dr; Download the Value For Key Path Playground

---

I was incredibly disappointed in Swift when I started to look into how key value coding might be preserved in the transition from Objective-C. Of course, Apple would preserve that, right? And I don’t mean by resorting to using Foundation classes–you know all type-casty and everything (yeah, type-casty). Are we progressing forward or looking to the past, after all? I shouldn’t have to rely on NSArray like this:

var values = (items as NSArray).valueForKeyPath("value")

Right? Who wants to do that? What’s the proper Swift way?

Well, my early assumption from what I was seeing in Swift was that valueForKeyPath: was gone and no longer did we have a convenient way to grab only the fields we needed from a collection of objects. It appeared that it couldn’t be done–at least not in any idiomatic elegant way. Then I downloaded some sample code from the Apple developer site and noticed they were doing what I needed, but using map to do it. The answer was map. Here’s an example:

var lastNames = items.map({$0["last"]! as String})

Now the lastNames variable contains a list of strings with just the last name property of my items array. Given an array of dictionaries like this, you can see how that is providing pretty much what we used to get from valueForKeyPath:

var items = [
    ["first" : "Billy", "last" : "Bogart", "address" : ["street" : "111 Main Street"]],
    ["first" : "Gary", "last" : "Gollum", "address" : ["street" : "2277 AB Street"]],
    ["first" : "David", "last" : "Dangerly", "address" : ["street" : "22311 Place Ave."]],
    ["first" : "Johnny", "last" : "Jones", "address" : ["street" : "10 Orange Rd."]]
]

lastNames now contains:

["Bogart", "Gollum", "Dangerly", "Jones"]

Notice we also have an address property that points to a dictionary. If want to get the street property inside of address, we can drill down the same way:

var streetAddresses = items.map({ $0["address"]!["street"] as String})

Now, you can see we had to force-unwrap the address property in order to access the street property. This works perfectly and is a fine replacement for valueForKeyPath: of old. When the call succeeds we now have all of the street addresses in the streetAddresses array:

["111 Main Street", "2277 AB Street", "22311 Place Ave.", "10 Orange Rd."]

Take a look at the Value For Key Path Playground if you want to see it in action.

What About Safety?

In Objective-C, if you message nil, it’s a no-op. In Swift, however, if we unwrap an optional that is nil, we will crash. So, on this line:

var streetAddresses = items.map({ $0["address"]!["street"] as String})

when we unwrap using the bang ! operator, if that value doesn’t exist, we’re in trouble. Say our data was changed to this:

var items = [
    ["first" : "Billy", "last" : "Bogart", "addr" : ["street" : "111 Main Street"]],
    ["first" : "Gary", "last" : "Gollum", "addr" : ["street" : "2277 AB Street"]],
    ["first" : "David", "last" : "Dangerly", "addr" : ["street" : "22311 Place Ave."]],
    ["first" : "Johnny", "last" : "Jones", "addr" : ["street" : "10 Orange Rd."]]
]

Notice the address field has been changed to addr. This causes a crash.

Meanwhile, with the old Foundation way, we do this:

var oldStreetAddresses = (items as NSArray).valueForKeyPath("address.street") as NSArray

but look what the output is. NSNull!

[NSNull, NSNull, NSNull, NSNull]

No crash. So which is better?

Well, if your data can be unpredictable, which really shouldn’t happen, then the Foundation outcome is “safer” from a crash perspective. However, your data should be nailed down, so a crash would actually tell you what’s wrong with your data pretty quickly.

What, though, is the safe Swift way of handling this? We can coerce our objects to optionals and use optional chaining instead:

var streetAddresses = items.map({ $0["address"]?["street"] as? String})

So our first optional operator says to return the object or nil and the second operator says that is should be an optional of type String. This call returns an array of optionals that has this output in our playground:

[nil, nil, {Some "22311 Place Ave."}, {Some "10 Orange Rd."}]

Assuming the following data:

var items = [
    ["first" : "Billy", "last" : "Bogart", "addr" : ["street" : "111 Main Street"]],
    ["first" : "Gary", "last" : "Gollum", "addr" : ["street" : "2277 AB Street"]],
    ["first" : "David", "last" : "Dangerly", "address" : ["street" : "22311 Place Ave."]],
    ["first" : "Johnny", "last" : "Jones", "address" : ["street" : "10 Orange Rd."]]
]

Notice the first two use the bad addr field and the last two use the correct address field.

For my applications, I think I would prefer to see a crash so I know my data is bad. It’s the server developer’s problem. Am I right? ;-)

Taking Map() Farther

The map() function really goes far beyond this trivial little valueForKeyPath: replacement example. You can really massage your data into any form you want with it. Say for example you wanted to create an transformed array of dictionaries from your array of dictionaries that had some of the same data, but organized differently. For example:

var fullNames = items.map({ ["full_name" : ($0["first"] as? String)! + " " + ($0["last"] as? String)!] })

This returns an array of dictionaries that contain a single key value pair with a key called full_name and value of the first name and last name of each item in the original array concatenated together. The output looks like this in our playground:

[["full_name": "Billy Bogart"], ["full_name": "Gary Gollum"], ["full_name": "David Dangerly"], ["full_name": "Johnny Jones"]]

As you can see, there really are a lot of possibilities for massaging your data structures using map. The tough part is imagining how it might be used and often that just comes from experience. The more you use it, the more obvious the solutions will become.

Swift Is Not So Bad

There are certain complaints about Swift I still have, however, I am finding that it is growing on me. I am starting to have much more success making my code pure Swift–pulling back from my old habits and considering how problems should be solved in this brave new Swift world. It’s getting better and some of the language aspects are actually better than Objective-C. I couldn’t see that forest for the trees just a couple short months ago. Until next time.

Sometimes you have a set of objects you want to display in the same form–say, for example, in a table view controller. What if those objects have, by design, nothing in common and nothing to do with each other? This is a case where you can create and conform to a protocol–known in some languages as an interface–to provide a simple way to have each class type provide a display name that can be displayed in your table view controller.

Recently while using this language feature writing Swift code, I ran into a few snags and learned from the process. I figured I would document it in this screencast. It walks you all the way through from project creation, so it’s about 35 minutes.

Here’s what you will learn:

• How to setup CoreData entities in the data model
• How to add a run script action to build your managed object classes using mogenerator
• How to create a protocol in Xcode 6
• How to implement a protocol in the various managed object classes
• How to preload your CoreData store with test objects in code
• How to load each object type generically into a table view controller

And if you want to just cut to the chase, grab the code from github.

Protocols in Swift With Core Data from Skye Road Systems on Vimeo.

App developers need ways to promote their apps and audio and video provide a way to do that. At a recent iOS developer camp in Colorado I gave a talk in which I demonstrated some ways developers can create their own creative content like audio and video in-house. In one segment I demonstrated a technique that I refer to as creating a Happy Appy Song. What is it, you ask. You’ve heard it. It’s a happy sounding fanciful tune that plays in the background as some narrator describes the wonders and benefits of an app (or other product for that matter). The basic premise of the happy appy song is that, first of all, it’s easy to create, but second there’s a simple formula. Here is all you need:

1. A happy chord progression in a major key
2. A simple drumbeat
3. A glockenspiel sound

And now I present to you, Creating a Happy Appy Song

[ylwm_vimeo height=”400″ width=”600″]66576979[/ylwm_vimeo]

I tweeted a call for help today to figure out how to get crash logs from a device that syncs with iCloud rather than with iTunes and a cable. The issue is that you can only sync with one and not both and switching between them willy nilly can be perilous unless you enjoy losing your data just for the fun of it.

Several responses suggested taking things into my own hands by rolling my own logging mechanism when building an app I intend to ship. I think this is likely the approach I will take in the future, however, it doesn’t help my immediate problem. How do I get crash logs from an app I already shipped that is running on client’s device not physically located near me? Here’s a summary of what people suggested. Drill down in the settings app and copy the contents of the crash log like this (click/tap to enlarge):

Then, paste that into an email:

Then you can send the crash log to any email address you specify.

It certainly is not a pretty approach, but it will get the job done.

Thanks to the folks who responded to my call for help, @davidiom, @therealkerni, @thenighttrader, and @rckoenes. I appreciate it!

I’ve been using StackOverflow nearly since it started back in 2008. I remember when it first started there didn’t seem to be much going on and so I forgot about it for a time. Then, one day, while searching the interwebs for an answer to a programming question, SO was the first hit in my search results. At that point I went back and started using it regularly–not only to find answers, but to offer my own experiences and expertise to help others. It’s a great site and I have nothing but high praise for its founders, Jeff Atwood and Joel Spolsky. The entire StackExchange network is an impressive engineering achievement. (more…)

It seems like a pretty useful feature, anonymous image file upload in iOS with imgur. If you need to upload images and don’t want to fool with some authentication mess like OAuth this technique is perfect. There are libraries that have simplified the OAuth process, however, it’s nice to be able to just initiate an upload, get a result URL back and be on your way. No fuss, no muss. That’s what I was looking for, so I wrote a little app that demonstrates how to do exactly that.
(more…)

In my Xcode LLDB Tutorial, I mention using the debugger to interrogate data collections. Well, I wanted to elaborate on that idea a little because there are some techniques you can use for querying objective-c data collections that are very powerful.

If you develop apps for clients, you my be one of the lucky ones–the ones who actually get to model your data and use Core Data to store and access it. But I’m betting there are many of you who aren’t the lucky ones–or at least not on all of your projects. From time to time you have to deal with data in whatever format your client gives it to you. Maybe you’ve even suggested taking the CSVs or Plists (or whatever other formats clients have come up with to ruin your life) and actually loading those into Core Data. But they don’t get Core Data and they shoot down the idea. Well, you may want to just walk away from the gig. However, if you’re like me, you’ve got bills to pay and clients (the good ones at least) tend to help you accomplish that. Well, fortunately for us, Objective-C makes dealing with this kind of data manageable using a little technique known as KVC, Key-Value-Coding, with array filtering and sorting.

This is not an advanced topic, so if you’re already familiar with how KVC and array filtering and sorting works, this post may not help you as much. But for those of you who are fairly new to iOS development, you need to know about this magical feature of the language as all the senior iOS developers use it and you should too. (more…)

Being that I’m a blogger as well as a software developer, I’m going to deviate a little from the normal Cocoa specific programming fare and focus a bit on leveraging basic SEO on your blog. These are some of the lessons I’ve learned and I think they might be helpful to others.

People do some pretty shady things to try to improve their page rank. There are companies who claim to be able to improve page rank. In fact it’s an entire market full of snake oil sales people. I’m sure there are some legitimate “consultants” out there, but they’re tough to find. In the end, the techniques for “optimizing” your page so that search engines find your content more readily are the same for the legit folks, like bloggers such as those of us who write for CIMGF, as they are for the folks who are trying to game the system. The difference is that gaming the system is exactly what true SEO helps eliminate. Google will blacklist your site if they detect you are trying to game them and getting off of that list will prove very difficult. It is not worth it to game the system. In the end when leveraging basic SEO, the old adage remains, “Content is King”. That single principle is the one and only differentiator. Write great content for your users and everything else will fall into place. (more…)

What inspired the Xcode LLDB Tutorial? Well, I tweeted this the other day:

A few people then responded over twitter asking that I would elaborate by writing a tutorial here on CIMGF. So here it is. Your wish is my command, The Xcode LLDB Tutorial

(more…)

Since last year I’ve spent a lot of time working on iPad apps for medical device companies. These companies want to be able to display their sales materials/digital assets to potential buyers on the iPad because of its gorgeous presentation. We can’t blame them. This is a great choice especially with the retina display on the third generation iPad. It’s incredibly compelling.

Our go-to solution for presenting these files until recently has been to just load everything into a UIWebView because it supports so many formats. Voila! Done! We like simple solutions to problems that would otherwise be very difficult.

This solution has worked great, but over time it’s become a noticeably dull spot in the app with some UX problems to boot. This is not good–especially for the part of the app that gets the most customer face time. It needs to shine. To go fullscreen, we just load a full size view controller modally. One issue with this approach though was that it only worked in landscape. For some reason it would get wonky (engineering parlance for, “um, I don’t know”) if we allowed both orientations since the rest of the app supported landscape only. It also had a nav bar that would never be hidden, so the user would always see it even when they were scrolling through the document content. Finally, there was no way to jump down deep into a document. If you needed to get to page 325, for example, you had to scroll all the way there. That’s just a bad user experience–incredibly tedious making it unlikely anyone would use it with a large document. These were some significant drawbacks and I didn’t have a good solution to bring the polish that this segment of the app deserved. (more…)