In finance, the key to growing wealth exponentially over time is compound interest. Wealth simply grows faster when you earn a return on your capital, and then re-invest the return, to earn a return on that.
Many people have of course made analogies, applying the concept of compounding generally to life and work.
All the returns in life, whether in wealth, relationships, or knowledge, come from compound interest
But what no one really talks about, is the concept of booking profits and cutting losses.
When it comes to compounding wealth, compounded returns are earned when there are returns…
There are many ways to record audio on iOS, with the
AVFoundation framework being a veritable Swiss Army Knife of tools.
At the basic level,
AVAudioRecorder makes it dead simple to record audio in a variety of common formats, and save it to disk. However, the audio is only available after recording is complete. This is fine in most cases, but sometimes, we might need the audio while recording is happening, to do something with it — applying effects, streaming it to a web server, and so on.
This is where
AVAudioEngine comes in. Introduced in 2014, it provides a…
Swift, as a highly protocol-oriented programming language, is chock-a-block with a multitude of protocols in its standard library. In this series, I hope to discover & learn more about some of them.
Any two instances of a type that conforms to Equatable can be checked against each other to see if they’re equal in value.
If your custom type adopts this protocol, it is given the opportunity to specify what exactly this equality check is. Note that, by default, Swift structs & classes are not equatable.
The way you go about doing this, is using the == operator function:
One of the most powerful parts of Swift is its support for Generics. Using Generics, you can write code that is type-agnostic, meaning less code duplication.
But Generic code, as such, accepts any type. If you however want to constrain your code to accept only certain types, and that too only in certain conditions, what you need are Type Constraints.
Generics are made even more powerful and flexible by Type Constraints (and Where clauses). This article is my attempt at understanding where and how Type Constraints can be used, and the minutiae of their implementation. So here goes.
A protocol in Swift is generic when it does not enforce types in (some or all of) its variables and functions, on types that conform to it. Different conforming types can then implement the protocol in ways that’re relevant or convenient for them.
There are two ways to make a protocol generic:
The type for function parameters can be marked as Self. When this is done, the type is automatically resolved to the type of the conforming object. For example:
Protocols with self won’t work in the following cases though:
The MapKit framework allows you to create and embed maps in your app. But sometimes, embedding an entire map may be overkill — like if you want display multiple coordinates, as a list of maps in a UITableView. Or if you want the map to be non-interactive.
In such cases, it makes more sense to create a snapshot of a map, and use that in your app.
MapKit provides you a MKSnapshotter class that you use for the specific purpose of rendering a map as an image.
All the configuration for the snapshotter is defined by MKSnapshotOptions. The configuration includes…
When designing the models and data structure for your app, you would probably be deciding between Structs and Classes.
If you’re coming from a different programming language, it’s easy to settle into a pattern of using classes throughout your app.
However, structs in Swift are highly significant — they have been given tremendous importance throughout the Swift Standard Library itself. You too, should keep them in mind for your own apps. The following set of pros and cons should help you make a decision in this regard.
dispatch_group is a part of Apple’s Grand Central Dispatch (GCD) set of APIs that allows you to coalesce and synchronise the results of multiple asynchronous functions into a single point of execution.
With dispatch_groups, a thread is blocked until all tasks associated with that group are finished. And once they are finished, normal execution resumes, and you can be safe in the knowledge that all your asynchronous code has finished running.
Suppose you have multiple async network calls, that are not dependent on each other, but you still need to wait for all the calls to complete before proceeding. …
By default, Swift Playgrounds do not execute (asynchronous) code that depends on the RunLoop for callbacks or completion.
This includes, for example , NSURLConnection/Session requests, and NSTimer actions.
This is because, the code in the Playground is executed, and the process is terminated — the completion operations / callbacks are simply not executed.
To enable this, there are two options
XCPlaygroundPage.currentPage.needsIndefiniteExecution = true // Your Code
This creates a 30-second window for the async code to execute and finish, after which it’ll time-out. This duration can be customised using the timeline view (at the bottom of the playground). After the code is executed, you can call: