Combining server-side Swift, and Google’s Protocol Buffers by creating a simple server-client system.
In the first part of this blog post, we will build the server-side application. Second part of this blog post will be about building the client iOS application. Both applications will be built with Swift, and communication between them will be done using protocol buffers.
Two Ways of Implementing AnySomething
Sometimes, we can use a protocol as a standalone type. However, with a protocol like IteratorProtocol, this isn’t (yet) possible, because it has an associated type. The compile error says: “Protocol ‘IteratorProtocol’ can only be used as a generic constraint because it has Self or associated type requirements.”
Swift differentiates between escaping and non-escaping closures. An escaping closure is one that is (potentially) called after the function the closure is passed to returns — that is, the closure escapes the scope of the function it is passed to as an argument.
Functions and closures are first-class objects in Swift: you can store them, pass them as arguments to functions, and treat them as you would any other value or object. Passing in closures as completion handlers is a common pattern in many APIs we all know and love.
When you pass a closure into a function in Swift 3, there’s a new wrinkle: the compiler assumes closure parameters are non-escaping by default. What does this mean? What’s the difference between an escaping and a non-escaping closure?
Should you upgrade to 2.3 or 3.0?
If you have a significant Swift code base — as we do here at VTS — the answer to this is – yes, both.
This is “amazing” series of open source projects.
Swift is a general-purpose programming language developed by Apple Inc. for iOS, OS X, watchOS and tvOS. Currently it is the most popular open source programming language on Github.
Unless you’re the type of person who likes to write everything themselves, chances are you’ll have a lot of dependencies in your code on classes from external frameworks. These don’t often fit within your personal (or company’s) API guidelines or architecture. You also can’t apply dependency inversion as easily as with your own classes.
Since in Swift you can extend any type (including types from other frameworks) with whichever methods or computed variables you please, controlling external types is easy.
The approach I use for this is wrapping the external classes into a protocol I control. It boils down to extending the external class to conform to one of your protocols.
SourceKit is more than just crashes & HUDs! It’s a powerful tool that can empower you to be a more productive Swift programmer. In this talk at App Builders 2016, JP Simard looks at a few examples of how you can leverage SourceKit to accomplish powerful tasks simply.
The Principles of OOD based on Uncle Bob articles.
Over the last weeks, there have been a number of blog posts that want to add dynamic behavior to Swift. Swift is already a very dynamic language: it has generics, protocols, first-class functions, and the standard library is filled with functions like map and filter, which dynamically get their operation (not using a string like with KVC, but using a function, which is safer and more flexible). Most of the people that say they want dynamic behavior mean that they want reflection specifically: they want to analyze and modify the program at runtime.