These notes I wrote down while converting our project to a Swift 3.0 project. Hopefully someone finds them useful. If you have comments or like to see something added, please let me know.

Let me start with a big fat warning.

⚠️ Don’t ‘Update to recommended setting’. Do this later. ⚠️

So the steps to undertake and achieve Swift bliss are this.

1. Create new branch.
2. Change `Podfile` to reflect the following
platform :ios, '9.0'
use_frameworks!
inhibit_all_warnings!

3. Update dependencies with a pod update
4. Commit changes to git
5. Convert to Swift 3 syntax
6. Commit changes
7. Fix errors (loads of them)
8. Lint
9. Commit changes

Breaking changes in Swift 3 Conversion

So first things first – you are not alone in this. Apple has created a good starting point with their migration guide. Read it before starting the conversion and keep it as a reference while converting.

• New keywords. It takes some getting used to. Current behavior changed too.
• String indexes and Ranges work different
• ErrorType ⇒ Error
• All enum cases are now lowercase
• Use of _ in methods to supres/omit names parameters. Named parameters are now default.
• .[upper/lower]caseString ⇒ .[upper/lower]cased() because it is mutating.
• for can now be used for named parameters .addTarget(self, action: ..., for: ...)
• containsString() ⇒ contains()
• .objectForKey(...) ⇒ object(forKey: ...)
• Colors are not a function call anymore but [class var](https://developer.apple.com/reference/uikit/uicolor/2091975-black)
• where keyword in optional binding not needed anymore, you can now just use a comma
• CGColorRef ⇒ CGColor
• when using multiple properties in single guard you must use let for each property. Also in optional binding.
• UIControlState.Normal ⇒ UIControlState()
• UIView.animateWithDuration ⇒ UIView.animate(withDuration
• NSFetchedResultsController is now a Generic and must be called with a concrete Type of the Entity you wish to fetch. Like so: NSFetchedResultsController Same with NSFetchRequest(entityName: "Enitity")
• String(self) ⇒ String(describing: self)
• Dispatch Queues tend to f-up the migrator wizard syntax. It mangles it like this: DispatchQueue.main.sync(DispatchQueue.mainexecute: { () -> Void in
  but should have been DispatchQueue.main.sync {
  Swiftable has more info on this

Errors:

Q: “Argument label does not match any available overloads”
A: In the conversion to Swift 3 something went haywire, look in the original implenmentation wat the function signature is you want to implement.

Q: “Ambiguous reference”
A: You need to provide more Type detail. Usually this is fixed by adding an : Type or an as? Type or with an optional binding if let .... When this method comes from an Objective-C external lib – what also helps is to annotate the Objective-C methods with NS_SWIFT_NAME(method(arg1:arg2:))

Q: “Method cannot be declared because its parameter uses an internal type”
A: Take a close look at the access modifiers. The above states that there are no (and thus internal), or wrong access modifiers used.

Q: “Instance method ‘method(param:)’ nearly matches optional requirement ‘method(in:)’ of protocol ‘SomeProtocol'”
A: In some cases the Swift migrator fails but does find something that looks like that method signature. Usually fixable by searching and copying the orginal protocol for the method signature. In UIKit protocols is almost always the case that you need to supress the param name by adding an underscore to it. So func method(param:) becomes func method(_ param:)

Q: “Expression of type “SomeType?” is unused”.
A: (This answer comes directly from Stack Overflow) Before Swift 3, all methods had a “discardable result” by default. No warning would occur when you did not capture what the method returned.

In order to tell the compiler that the result should be captured, you had to add @warn_unused_result before the method declaration. It would be used for methods that have a mutable form (ex. sort and sortInPlace). You would add @warn_unused_result(mutable_variant="mutableMethodHere") to tell the compiler of it.

However, with Swift 3, the behavior is flipped. All methods now warn that the return value is not captured. If you want to tell the compiler that the warning isn’t necessary, you add @discardableResult before the method declaration.

If you don’t want to use the return value, you have to explicitly tell the compiler by assigning it to an underscore:

_ = someMethodThatReturnsSomething()

Why did this change in Swift 3:

• Prevention of possible bugs (ex. using sort thinking it modifies the collection)
• Explicit intent of not capturing or needing to capture the result for other collaborators

The UIKit API appears to be behind on this, not adding @discardableResult for the perfectly normal (if not more common) use of popViewController(animated:) without capturing the return value.
Warning of unused result
SE-0047 Swift Evolution Proposal

API Changes:

Apple keeps a list of API’s that changed, the ones that have a Swift method signature. This way you can cross reference if you get any ‘Instance method nearly matches optional requirement of protocol’ errors.

When you use your own libraries with Cocoapods.

Cocoapods fails when linting.

Errors with Generics

I’ve hit a couple of compiler errors which are already filled with Apple. Try to work around it or find a different solution to your problem. Unless Apple fixes this (which will probably be next version)
Once all your errors are gone and you linted your project with SwiftLint – now you can update to the latest project settings.

When running a program things can just crash and Xcode and LLDB are not particularly friendly or verbose about it’s error messages. In Xcode you can have two types of breakpoints: ‘Workspace’ and ‘User’. When adding a breakpoint to ‘Workspace’ it is only visible for that project. But wouldn’t it be cool you set your breakpoints once and they show up in every project you create? ⌃-click on the breakpoint and select ‘Move breakpoint to => user’. Now you have that breakpoint in every project you create in Xcode.

In the above video, they talk about adding a breakpoint and printing the first argument. Which is actually the error message. They do this with ‘po $arg1’.

I’ve taken this example and extended it somewhat. Having a error message is nice, but I would also like to see where that error message comes from. One breakpoint is not bound to one action only – you can set up multiple actions when a breakpoint is hit. you can add sounds or backtraces. The later gives us more information about the crash.

⌃-click on the breakpoint and select ‘Edit breakpoint’, now add two actions. The first is a debugger command with ‘po $arg1’. And click the + to add a new action and select debugger command from the pulldown (if not already selected) and type in ‘bt’. This is the LLDB command for ‘backtrace on the current thread’. (More command for LLDB can be found on their site.). (This should look like the image below)

When compiling again we can actually see where our crash/error is coming from and it a has a more verbose error message.

Happy debugging

Misconceptions
There are some misconceptions about iBeacons and I’ll start by clearing those up. The only thing a (i)beacon does is broadcast information. Three bits of information to be exact, or to be more exact, three public bits of information (BLE actually sends 5 bit of information, but only 3 are public). A beacon does not get information on the internet, and a beacon does not know it’s own location. Basically it’s a very dumb device which can only say and broadcast it’s name and number.

The information these devices broadcast are a UUID (very unique value), a major and a minor value. (Most of the time) the UUID belongs to the vendor that sells the beacons and most of the time this is fixed in the hardware. The major and minor values are usually set to a default value and can be changes by the developer. (Some vendors allow you to change the UUID as well).

For my experiments I’ve used beacons by Estimote and Roximity. The later were rather useless since none of the major and minor values can be changed. Which is rather important if you want to actually DO stuff. All communication goes through their own SDK/API and CMS. I’ve also found that one of the first calls the API makes (The register call) goes directly to their back-end and send information about all running processes on your device. I send them a tweet and first they responded with this:

@sidneydekoning Hi Sidney! We collect device information to allow our merchants to provide personalized experiences. Email us for more info! — ROXIMITY (@ROXIMITY) July 22, 2014

I mailed them asking them to explain a little bit more about those ‘personalized experiences’ and they replied with this:

There are a number of things that processes on the phone help us with. One example is targeting devices known to have twitter with a deep linked URL or specific twitter based messages. Overall, we are using the data to create segments of customers that merchants can later reach back to, like shoppers or gamers. Often, it’s simply merchants want to target similar customers based on there own data, but using process we can help group them.

I’m still not sure about implementing their API – Maybe their end goal is a buyout with all this bigdata. But that is just guessing. So in the end I decided to go with Estimote. This turned out to be a solid choice. Their support is fast and to the point and their service awesome. (At one point I had to cut open all my beacons to replace the battery)

@sidneydekoning We’re happy to help Sidney, let us know if you need anything — Wojtek Borowicz (@Esti_Wojtek) July 29, 2014

So let us get back to beacons.

Development Phase: Proof of Concept
For about two weeks I absorbed all the information I could find and created a proof of concept for a client (A big Dutch beer brand with a green logo – figure it out…). This proof of concept entailed the scanning of six beacons, linking the major an minor values to represent a value in their backend, so when an engineer walks through the brewery they get notified about when machines need maintenance and what specific part needs attention. Pretty fucking cool if I say so myself.

Developement Phase: Architecture
Scanning for beacons is pretty straight forward. For this particular proof of concept the adding of beacons needed to be generic so I could not use the Estimote SDK unfortunately – since their SDK is pretty well thought out, architecture wise.

Using CoreLocation I’ve setup a location manager that manage all the beacons. From a backend call I get a JSON structure with a common name, UUID, major and minor values – this way the app always has the latest beacon description and adding new beacons to the app is a breeze. No need to release an update of the app if new beacons are added/purchased. This also solved my problem with the potential of different beacon vendors and not having to implement every single SDK that is vendor specific. (Yes I could have used the Adapter Pattern and abstracted my code and only have one interface to talk to – but having everything talk directly to the CoreLocation framework seemed like a better choice).

The JSON kindof looks like this:

{
"name" : "My pretty beacon"
"UUID" : "3C074D4B-FC8C-4CA2-82A9-6E9367BBC875"
"major": 54321
"minor": 123
}


After the location manager has been set up and the beacons are registered you start monitoring and then you start ranging for beacons. This is a two step process and I’ll explain what this means.

• Monitoring: You basically tell the system that ‘these are the droids you are looking for’ and depends on the list of beacons you start monitoring
• Ranging: As soon as you enter a beacon region, the ranging allows you to get the distance and proximity to the beacon itself (plus a bunch of other info). So ranging only starts when you enter a region and should be stopped when you exit a region

After the CLLocationManagerDelegate fires locationManager:didRangeBeacons:inRegion you can take appropriate action per beacon. Show a UIView, get some data, etc.

If the iDevice is locked/screen is turned off, the background process kicks in and your app is still able to range beacons. If a beacon is found in this way the locationManager:didEnterRegion and locationManager:didExitRegion are called, depending on if you enter or exit a region. And to make proper use of this it is considered good practice to show UILocalNotification.

I’ve found that UILocalNotification does not have a timeout to show the notification on the lockscreen. But with sending out a notification you can also play a sound. One little hack I did is to play an empty mp3 that lasts 15 seconds. Turns out that while this is playing the notification is still showing. So there. Timeout method.

Distance and Proximity
The CoreLocation framework does a lot of the heavy lifting for you calculating distance and proximity. It normalizes the fluctuating values and gives you a rather smooth end result. Even though sometimes there are some false positives. The distance to an beacon is an estimate in meters. This value can fluctuate between 1 meter and 3 meters even though the beacon is located 1.5 meters away from your device. Another property is proximity. This is calculated in region (circles) around the beacons.

One trick to benchmark your beacons is to place them exactly one meter away (use a ruler!) and then check what the advertising interval is and signal strength, then look at the estimated value, and adjust those values to represent a meter.

Learnings
With this there are a lot of thing that I learned, one of the most important is that I assumed that the signal strength would be stable. “Assumption is the mother of all fuckup” still echoes in my mind.

• Apple has a restriction concerning the UDID’s that cannot be circumvented. Per app a maximum of 20 UDID’s can be present.
• The initial setup and monitoring of beacons has a latency of about 10 seconds. Also exiting a region can take some time – this is about 30 seconds and is per Apple’ implementation – sometimes even more. We, developers, have no influence in this, what so ever.
• The actual configuration of the beacons is a very time consuming process as this has to be done per beacon. This process takes about 1.5 minutes per beacon. In a later stage it would be considered more optimal to create an app (desktop and /or mobile) to do this configuration. Or just find one that does.
• The signal of the beacons is, per default settings, not very stable. Playing with the signal strength (RSSI), broadcasting strength and the advertising interval makes this more stable and thus more workable. Try finding the ‘sweet spot’ for your application.

The Room Finder
For another proof of concept I hung two beacons on the doorpost of the meeting- and lunch room in our office and wrote a small app for it ‘The Room Finder’ – it uses iBeacons to show if a room is booked or not. If the room is available you can book the room at the time you desire. If the room is currently booked – You can see who is in the meeting, what the booked times for this room are, the available facilities and if it concerns the lunch room – what today’s special is. All from Google Calendar. Got my inspiration from Robin. This demo took me about 6 hours to build and another 2 to shoot and edit the video. Below is this video.

I hope I’ve given you enough information to start playing with iBeacons yourself. If you have questions leave a comment.

Happy Coding

PS. Here are some more photo’s of the inside of the beacons. I had to cut them open to replace the battery. Luckily Estimote was nice enough to replace the enclosures.

You can download it from Apple’s site.

My approach was simple; When my view was loaded I would setup the Keychain and under certain circumstances I needed to clear a key/value combo, I would do this.

- (void)viewDidLoad
{
    self.keychain = [[KeychainItemWrapper alloc] initWithIdentifier:[[NSBundle mainBundle] infoDictionary][@"CFBundleDisplayName"] accessGroup:nil];
}
...
- (void)resetKeyChain
{
    [self.keychain setObject:@"" forKey:(__bridge id)kSecAttrAccount];
    [self.keychain setObject:@"" forKey:(__bridge id)kSecValueData];
}
Boy was I was dead wrong – it would not clear my keys from the Keychain. Took me hours to find a solution – looking for the proverbial needle in the keychain. (Debugging Keychain is a bitch. Also when deleting an app, the keychain is not cleared, which makes it next to impossible to see changes).
A better approach would be to set up the Keychain like so;

- (void)viewWillAppear:(BOOL)animated
{
    self.keychain = [[KeychainItemWrapper alloc] initWithIdentifier:[[NSBundle mainBundle] infoDictionary][@"CFBundleDisplayName"] accessGroup:nil];
}
...
- (void)resetKeyChain
{
    [self.keychain resetKeychainItem];
}

This would clear the appropriate stuff from my Keychain and present my user with a login dialog again. Problem solved

Just like last year several online book publishers are coming together on the ‘Day against DRM’ – download, keep or share your purchase. And I fully support this! That’s why I’m writing this post.

O’Reilly, who always publishes books without DRM, is doing a massive discount today by offering you 50% off on everything they offer. You can use DRM2014 at the checkout. (Of course I would love it if you picked up a copy of my book

Packt is offering all its DRM-free content at $10 for 24 hours only on May 6th – that’s all 2000+ eBooks and Videos.

So I hope you support this cause too and pick up some great books in the mean time.

The manual states;

help.autocorrect

This option is available only in Git 1.6.1 and later. If you mistype a command in Git, it shows you something like this:

$ git com
git: 'com' is not a git-command. See 'git --help'.

Did you mean this?
commit

If you set help.autocorrect to 1, Git will automatically run the command if it has only one match under this scenario.
git config --global help.autocorrect 1
The final parameter to that command is the amount of seconds, unline what the manual states. Setting it to 15 means 1.5 seconds, setting it to 1 means 0.1 seconds.

Git Autocompletion.
Open up Terminal and type in the following;
curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion

This downloads the git-completion script and places it in your home folder.
Open up ~/.bash_profile with your favorite editor and add the following line at the end of it.

source ~/.git-completion

You are now good to go. No open a new Terminal tab or force this command by ‘refreshing’ the terminal by typing source ~/.bash_profile Still in Terminal type git com and press the tab key. This should either autocomplete the command or if there are more commands starting with ‘com’ show you a list of possible options.

Enjoy! No moer typos in Git.

From frustration comes inspiration – one of my biggest frustrations while using Xcode is that there is no build in way to do code formatting. Well ok, you do have ‘re-ident’ but that is mostly a manual process and i like using the keyboard. Also this is not quite what I was after.

After some searching I found Uncrustify a generic “Source Code Beautifier for C, C++, C#, ObjectiveC, D, Java, Pawn and VALA”. I checked out the sourcecode, build it and placed the newly created binary in my bin folder. Next up was this Xcode plugin. Easiest and fastest way to get this on your system is by unzipping the binary and placing it in your ~/Library/Application Support/Developer/Shared/Xcode/Plug-ins folder. Don’t forget to restart Xcode after you do this.

After you restarted Xcode, you can open the plugin by navigating to Edit -> Format Code

• Use the menu Format Selected Files to format the selected items in the project navigator.
• Use the menu Format Active File to format the source file actually opened in the editor.
• Use the menu Format Selected Lines to format the selected source code (multiple selection is supported). The selection is automatically extended in full lines. If the selection is empty, it uses the line under the cursor.
• Use the menu Edit Configuration to edit the formatter configuration in an external editor.
• Use the menu BBUncrustifyPlugin Preferences to change the plugin preferences.

The real magic happens when you assign it to a key binding. Unfortunately this cannot be done in Xcode and have to be done system wide. So go to System Preferences -> Keyboard. Under Keyboard Shortcuts select ‘Application Shortcuts’ and press the plus sign to add a new program. Select Xcode and call it Format Active File. The naming is very important to be exactly the same as the actual item in Xcode. Naming it differently makes it unusable.

Formatting.
You can also use different configurations for your own source code. If you create a directory called .uncrustify in your user home directory and check out this repository in that location, you have a very good starting point for your own formatting style. If you have questions regarding the formatting and indentation etc, there is a lot of answers on StackOverflow, be sure to check it out if you want to make your own formatting magic happen.

When you go back to Xcode and you see a key binding next to the Format Selected Files you know everything worked out.

Et voilà! Pressing that key combo adds magic/formats your source code in the flavor you like. Enjoy!

[UPDATE]
To make this work for Xcode 5.1 find the plugin file, right click on the file and select ‘Show Package Contents’ and open up the Info.plist in a plain text editor. Then look for the key DVTPlugInCompatibilityUUIDs and add A2E4D43F-41F4-4FB9-BB94-7177011C9AED under the last entry. Save and reopen Xcode. Tada!

I’ve found some resources that help me on my way, so here is a quick reminder/walk through to do it (I don’t take credit for exposing this method, i just use it). It takes about 3 minutes to set up and can save you *a lot* of frustration.

1. Find IDETextKeyBindingSet.plist in the folder /Applications/Xcode.app/Contents/Frameworks/IDEKit.framework/ Resources, get the file info and change the rights to “read & write” for user everyone. This allows you to make changes to the file. Now open it in Xcode.
2. Add a new key as a Dictionary and call it Customized and add a String.
   
3. As String key add Duplicate Current Line and as value fill in selectLine:, copy:, moveToEndOfLine:, insertNewline:, paste:, deleteBackward:
4. As String key add Delete Current Line and as value fill in deleteToBeginningOfLine:, moveToEndOfLine:, deleteToBeginningOfLine:, deleteBackward:, moveDown:, moveToBeginningOfLine:. Save file and close and reopen Xcode.
5. Now go into “Key Bindings” under “Preferences” and press Customized


6. Now give the two newly added key bindings the binding you’d like, i’ve set mine to CMD-D for deleting a line and CMD-SHIFT-D for duplicating a line.
7. Enjoy!

One of the things I really love is code-reviews by my peers, they are mandatory at the place I work. They basically go through my code and comment on it when I fuck up or make dumb mistakes. Lately I had to return the reviewing favor.

Looking through code of my co-workers and myself I noticed a couple of things and thought it would make a good bit for an article. I’ll go through as much of the bad stuff I can find and discuss them here. As habits are hard to change, get in the habit of changing them as soon as you see them in your own code. This is by no means a definitive list and if you have suggestions for more, let me know in the comments.

1. Commented Code
Since you use a VCS like Git or SVN, there is absolutely no need to leave commented code in your source files since you can always revert. So remove it.

2. Duplicate Code / KISS
If you have a lot of duplicate code all over the place – you are doing it wrong. KISS and refactor (see point 6.)

3. NSLogs
Since Apple defines logging *only* for errors, a better way to get information from your app is by utilizing your debugger. There have been numerous articles about not using NSLog in (production) code and why it’s better to use a breakpoint. The cool thing about breakpoints in XCode is that you can use non-breaking breakpoints that send a message to the output window.

4. Retarded and/or short unreadable variable names
No matter what language you write code in, you always need to make sure it is readable. For your team members or for yourself when you come back to a project a year from now. This includes the correct naming of variables. Since Objective-C is by itself a very verbose language, variable name tend to have the same tendency. Using myReallyLongVariableName is oke, since compilers nowadays are optimized to deal with this. Verbosity and readability over brevity and difficulty to read code.

5. Small is beautiful
Just like an app or program, methods need to do one thing only and do that one thing well. Like the UNIX philosophy.  That’s what I’m taught and still believe. Don’t bloat your methods with doing six things. This makes it very difficult to read, understand and debug. Small is beautiful.

6. OOP.
What I see *a lot* is that people don’t know how to use proper OO. Not knowing how to extend classes or know how to design to a protocol (Objective-C’s term for interfaces) is basic stuff. Don’t be afraid to ask your peers, even if you’ve are an (iOS) senior.

7. Design Patterns.
While design patterns are not a magical, ready made solution or a silver bullet if you will, i do advise you to get a proper book on design patterns and learn about Model View Controller (MVC), Key Value Observation (KVO) / Observers and Delegation. These are the fundamentals of iOS programming.

8. Refactoring
The problem with writing code is that there is always ego involved. Even in ego-less programming (MUST READ!). That one brilliant solution you created for that one project will look like crap to another team member. People see things in different ways and that is oke. People do things to solve problems. Don’t try to rewrite everything just because it doesn’t look proper to you, try to put yourself in their shoes when they wrote this piece of code you are looking at. And breathe.

9. Lose the Ego
Reality check: Your code is not you. What? Your code is not you. It is just a solution to a problem, even though sometimes a very good solution. Don’t think you are the only one that can have good solutions. I don’t. (Well I actually do, sometimes – but I’m learning) The best solution come from unexpected corners or people. Even veterans make thinking mistakes, I know I do. And lose the ego. Realizing that makes you grow and makes better software.

10. Take responsibility
The next person that says “Nah that wasn’t me that wrote this” will get a kick in the groin. Seriously. I truly believe developers in general need to take responsibility for the code they create. Not taking responsibility is not believing what you wrote in the first place. You do care about your code right? Otherwise you are in this for the wrong reasons. Making a mistake is not the worst thing that can happen, it’s just a piece of code we are taking about. So have some balls.

BONUS. My debugging mantra
As I already mentioned on Twitter some time ago; Bugs are communication errors between you and the machine and can be fixed by asking ‘what do you think i said and why do you think that?’. Taking this step back can help you debug faster.

So. Embrace change, be open, don’t be cocky, loose the ego, look with children’s eyes, have a shoshin mind and enjoy what you are doing – only then will you grow as a coder.

]]> http://www.funky-monkey.nl/blog/2014/02/code-reviews/feed/ 0