dotSwift 2016 Highlights, part 1
Lots of inspiring ideas after coming back from last dotSwift at Théâtre des Variétés, Paris. I would like to highlight the most important, so here’s the first part of my personal dotSwift 206 highlights.
Beyond Crusty
The first talk in a conference is always really important: this subtle detail might capture the attendees from the very beginning. dotSwift organizers knew this pretty well so I am assuming that’s basically why this was the first one.
All the code repetition was making him ornery, and if Crusty ain’t happy, ain’t nobody happy.
Also known as we should always try to get rid of unneeded complexity, which is not necessarily an easy task. You might remember last year’s WWDC session about Protocol Oriented Programming in Swift (make sure you watch it if you haven’t yet): this was the perfect follow up to it.
The idea of this session was to quickly introduce the protocols with associated types (PATs) problem and how to solve them with type erasures. This basically consists in wrapping protocols into generic structs, which are then initialized with objects which promise some function (conform to the aforementioned protocol). It might sound a bit confusing at the beginning, but the process is actually quite mechanical:
But things got really more interesting when Rob went beyond this concept and made us actually consider why are we using protocols at all. The question here is also really simple: why don’t we, instead of passing objects that promise some function, pass the functions themselves?
Which also means: why don’t we just get rid of the protocols? After all, they might be adding unneeded complexity which is definitely not what we want: and that’s what actually made Crusty angry, no the fact about using protocols or not.
Personally, this was the best moment in the whole conference. Ever since I started learning about Swift, I’ve probably been trying to fit protocols everywhere without really worrying too much about it. And I strongly believe “Protocols all the things” is the first feeling every single Swift learner has. Aren’t we dealing with a protocol oriented language after all? 🤔
And there’s a fun thing about this: we already knew this, we have seen it before! It’s called delegates and handlers and, believe it or not, they were everywhere in Objective-C.
To properly illustrate this, the speaker went from a first solution to a problem which took 4 protocols and lots of where clauses into a rather simpler solution to the same problem, which used no protocols at all, but composition of generic structs instead.
Without going into too many details here about the transitioning between this two (I really encourage you to watch the talk in order to better understand this), you might just want to check out the difference between both the first and last solution:
“So what then? Are protocols the worst thing ever now?” Of course not. This is what I personally take from it:
- Protocols are still great, and it’s always a good thing to “start with a protocol” when writing new code. This normally lets you better abstract common behaviours in your code.
- But we should always consider whether we might be overusing a language feature or not. Don’t be afraid of rethinking your first solutions.
- Things are normally much simpler than we think.
Localization is Hard
“Wait, what? A full talk about localization is one of your highlights?” — Yes, yes and thousand times, yes.
Over the last ten years we have seen the rise of Test Driven Development. What I also want to argue for is Localization Driven Development.
Besides properly dealing with large strings with Auto Layout and checking the Double Length Pseudolanguage Xcode setting, after this session I realised I knew nothing about the topic: Roy gave me a wider understanding on the issue.
Let me quickly introduce some features I was not aware of. Let’s start simple: how do you normally convert a string into an uppercase string? Well, uppercaseString should be our friend here, right?
WRONG, check this out:
localizedUppercaseString it’s Swift only and so available from iOS9, so you might need to also use the previous uppercaseStringWithLocale method which needs to be given a NSLocale instead.
How about handling localized plurals in your app? Did you know about .stringsdict files? There’s so many different plural systems around the world, and so these files will take care of handling all the logic to properly present the different plural strings for us.
The only thing we just have to take care of is adding the different [one, two, few, many, other] rules to our .stringsdict file (check how this works here) and all the magic behind will happen for us when using localizedStringWithFormat:
<dict>
<key>user-profile-friends</key>
<dict>
<key>NSStringLocalizedFormatKey</key>
<string>%#@friends@</string>
<key>friends</key>
<dict>
<key>NSStringFormatSpecTypeKey</key>
<string>NSStringPluralRuleType</string>
<key>NSStringFormatValueTypeKey</key>
<string>lu</string>
<key>one</key>
<string>%lu friend</string>
<key>other</key>
<string>%lu friends</string>
</dict>
</dict>
</dict>
</plist>Last but not least, I’d like to mention how to deal with weight or distance in your app. Did you know there is a MKDistanceFormatter hidden somewhere in MapKit? 😅
Good news is, both MKDistanceFormatter and NSMassFormatter are really straightforward to use: just pass in the value in Meters or Kg, and the formatters will use the current locale to properly format them. NSMassFormatter would even handle persons or “things”!
Those are only some tricks I learned from this talk, but again I am skipping lots of details here for the sake of simplicity: make sure you watch it for further information.
So, what did I learn here? What do we really need to take from all this besides some implementation details?
- It’s pointless to focus on user experience without properly handling localization.
- Tackling this from the very beginning can save us lots of time and overhead.
- It’s fairly easy to overlook language differences which you are trying to support: don’t be lazy if you want your users to be happy worldwide.
