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().
There are usually two common reasons when you have missing files in the project after a merge.
The first case is when the commit contains references of files only, but not the files themselves. That means a developer adds e.g. images to the project and commits the project file, but forgets to commit the actual image files. When you merge those changes, you get those familiar red file names that clearly state missing files. You need to get a hold of the actual files and add them to resolve the issue.
There is a railroad crossing near my house and my 2yr old likes to watch the gate arm go up and down to let the train/traffic cross. As much as I’d love to stay with him on that crossing all day long 🙂 I decided it would be much easier to build a smaller version of the gate arm at home for him to play with.
Swift is a programming language that strongly emphasizes value types. Structs and Enums are first class citizens in Swift. While value types do not support inheritance, they contain properties, methods and extensions, features usually related to classes.
Value types usually don’t manipulate the data they store. It is the owner of that value type that manipulates the data stored in the value. The value type itself can contain interface and convenience methods for computation and calculations using the stored data. This results in a clean and predictable control flow.
Deep links are used to take users directly to the content they are interested in inside your application. In Facebook Ads you’re showing specific content that users are interested in which leads to app install. Using deep links you can take the users straight to that content upon installation. Without deep links users are left on the home screen once they run the application and they have to search for that specific content themselves.
Batch deletes are fast and efficient for deleting Core Data entities when using an SQLite persistent store. They provide far better performance than deleting specific NSManagedObjects because batch delete operations are performed in the persistent store (at SQL level). Since the changes are reflected in the persistent store, they are not reflected on objects that are currently in memory.
When I started looking into FRP (Functional Reactive Programming) on iOS, ReactiveCocoa was pretty much the only way to go. Today there are quite a few FRP frameworks available, with ReactiveCocoa and RxSwift as the two most popular. ReactiveCocoa has been out there for a while and at the moment it is obviously more popular, but RxSwift is catching up fast. Both frameworks are extremely powerful and you can’t go wrong with either, but my vote goes to RxSwift for a few reasons.
iOS Universal Links are a great way of handling your regular website URLs directly in your application without a need to open it in Safari. The users get a seamless experience of navigating straight to the content in the app. If the application is not installed, the system will fallback to opening the URL in Safari. Custom URL Schemes have been used for communication between the apps, but the problem is that other applications can claim the same URL scheme. Universal links solve that problem.
If Xcode cannot symbolicate the crash report automatically, you can use “Symbolicatecrash” tool to symbolicate the report manually. There are three files you’re going to need for this to succeed. The .app file (or if you have an ipa file just rename it to zip and uncompress, you’ll find the app file in that package), the .dSYM file and the .crash report.