A lot has been introduced at the WWDC 2017. Apple introduced iOS 11 with new and powerful features and APIs that allow developers to create apps using machine learning, augmented and virtual reality, accessing music and a lot more. iOS 11 has a strong emphasis on iPad introducing drag and drop, new Dock, file management, and multitasking improvements. Xcode 9 and Swift 4 were also introduced, bringing useful tools to developers.
iOS 10 brought rich content to push notifications. You can view an image, gif or video directly in the notification without first opening the app. This is achieved using notification service extension which intercepts remote notifications and allows your application to download and prepare appropriate rich content before it is displayed to the user.
RxSwift is a very powerful framework and a lot of components are already available but often you’ll find yourself in a situation where you’d have to implement your own reactive extension in order for certain component to work seamlessly with the rest of your reactive codebase. This is the case when you’re using third party SDKs or libraries that you’re interacting with using different delegate methods. I created a sample project to wrap AdMob banner and interstitial view delegates.
MVVM is a design pattern in software development that separates main application components into three interconnected categories: Model, View and ViewModel. Model represents the data, View represents the user interfaces and ViewModel represents the main link between View and Model.
When you name a new class, you want that name to be meaningful and describe why this particular class exists and what it does. This is much harder than it seems. The name of a class usually consists of two components. The first part of the name is usually related to a domain, e.g. a feature name or a screen name. That one is pretty much given. The other part of the class name is related to a type of the problem it is trying to solve and it may be much harder to come up with a meaningful name for this. I found that when you’re in a “naming paralysis”, going through the list of some common suffixes is generally enough for that bulb to light up when you come across a name that you see fit.
As I wrote in a blog post about Value vs Reference types, in Swift Enums and Structs are first class citizens. They contain properties, methods and extensions which are usually only found in Classes. Value types do not support inheritance in Swift, but they can conform to protocols which makes them convenient for use in Protocol Oriented Programming.
Swift properties associate values to a certain class, structure or enumeration. There are two kinds, stored and computed properties. Stored properties are constant or variable values that exist in an instance. Computed properties do not store a value, instead they represent a value that is calculated from other values. Another difference between the two is that stored properties cannot be contained in enumerations. Classes and structures can contain both stored and calculated properties.
There is an expression that states: “There are only two hard things in programming – cache invalidation and naming things”. More often than not, so little effort goes into naming things. We’re usually eager to start working on the “important” stuff as soon as possible so in a matter of seconds we make up a name that is going to be the first and most important point of contact for anyone looking into that particular part of the implementation. The name of a variable, function, class or any type should roughly tell you what it does, how it’s used and why it exists. That is why much more thought and effort should go into naming things.
When creating UITableViewCell or UICollectionViewCell subclasses you usually need to define a few things both in xib and in code. First when you create the layout in the interface builder, you also define the reuse identifier for that cell. Implicitly for UITableViewCell and UICollectionViewCell you define the height/size. Automatically generated xib has the same file name as the name of the class. These are all things that you have to define in two places – one is the xib itself, and the other is in code.
Loading a view from a xib requires you to instantiate a UINib object, providing a Nib name and bundle. On that UINib object you use the instantiate method, providing an owner and options. The general pattern is that the name of the Nib is the same as the name of the class, and the bundle used is the main bundle. I like to simplify this pattern to use a method called loadFromNib that has an optional parameter called name where you can provide the exact name of the nib to load the view from. If the name parameter is not provided, the name of the nib is assumed to be the same as the class name. Since that is usually the case, you don’t have to provide a name parameter, just use e.g. let myView: MyView = loadFromNib().