In software engineering, dependency injection is a technique in which an object receives other objects that it depends on. These other objects are called dependencies. In the typical “using” relationship the receiving object is called a client and the passed (that is, “injected“) object is called a service.
The code that passes the service to the client can be many kinds of things and is called the injector. Instead of the client specifying which service it will use, the injector tells the client what service to use. The “injection” refers to the passing of a dependency (a service) into the object (a client) that would use it.
Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987.
The Liskov Substitution Principle is the third of Robert C. Martin’s SOLID design principles. It extends the Open/Closed principle and enables you to replace objects of a parent class with objects of a subclass without breaking the application. This requires all subclasses to behave in the same way as the parent class.
“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.” – Robert C. Martin
A violation of this behaviour would imply your code is not SOLID and it may be prone to malfunctioning.
A new version of the Swift programming language is coming: Swift 5.0. It’s slated to be released early 2019, with a fair number of changes. How does this Swift update affect practical iOS development? And who’s making these changes anyway?
In this article, we’ll walk through some of the proposed and accepted changes for Swift 5.0. We’ll also discuss how the process of making changes to the Swift language works, and why that’s relevant for iOS developers.
Version 5 of Apple’s Swift language used for iOS and MacOS application development will arrive in 2019 with ABI (application binary interface) stability in the standard Swift library a primary focus.
ABI stability is half of what is needed to support binary frameworks. The other half, module stability, will be a “stretch goal” for Swift 5 and may not make it into the release, Apple’s roadmap notes.
Non-retina devices have a scale of 1.0. Retina devices have a scale of 2.0 or 3.0.
Some dimensions common to all screen sizes:
Nav Bar/Toolbar Icon
20 x 20 pts (transparent PNG)
Tab Bar Icon
30 x 30 pts (transparent PNGs)
Points vs. Pixels
Apple introduced retina displays starting with the iPhone 4. You don’t have to modify your code to support high-res displays; the iOS coordinate system uses points rather than pixels, so the dimensions and position in points of all UI elements remains the same across all devices.
iOS supports high resolution displays via the scale property on UIScreen, UIView, UIImage, and CALayer classes. If you load an image from a file whose name includes the @2x modifier, its scale property is set to 2.0. Similarly an image with a @3x modifier has a scale of 3.0. Otherwise the scale defaults to 1.0.
To support high-resolution graphics on devices with retina displays, you need @2x and @3x sized images:
button.png 60 x 20
firstname.lastname@example.org 120 x 40
email@example.com 180 x 60
To refer to an image in your code (or in Interface Builder), just use the filename of the standard sized image. iOS will automatically detect and use the @2x or @3x version if the device supports it:
Deep linking basically enables you to open an app from another app or a website while passing on parameters. This mechanism works with custom URL schemes which you can define in the .plist of your app.
Why deep linking?
If you have an app with lookup functionality (e.g. an app for finding song lyrics) you might want to perform a lookup without having to navigate to the designated screen and typing in the query. This can be achieved by opening the following example URL MyAppScheme://myAction=lookup&myQuery=What%20is%20the%20meaning%20of%20life in another app of the browser. In this case the app is programmed to read the ‘myAction’-parameter on startup to determine the action and the ‘myQuery’-parameter for the search query. Often, deep linking doesn’t go as planned and you might need to debug your app.
Why is debugging this difficult?
Deep linking might occur in three kinds of scenarios:
The app hasn’t been installed yet
The app is running in the background (or foreground for that matters)
The app is installed but not running at all
Scenario 1 is irrelevant in this case, so we’ll skip this one. Scenario 2 should be no problem since the app is running on the device (or simulator) while in a debug session. Scenario 3 requires you not to have the app running, but you need the debug session to be able to debug. This is a problem because Xcode starts the app automatically when starting a debug session. Instead of letting Xcode start the app, you want to do it yourself using the deep link URL.
So… tell me how to do this
There is a convenient option which enables you to start a debug session by manually starting the app. To achieve this, go to the ‘Edit scheme’ screen and tick the ‘Wait for MyApp.app to be launched manually’ option on in the ‘Run’ configuration.
Whenever you run the target in Xcode, the app doesn’t automatically starts and the debug session will only start when you manually start the app.