One of the great things about programming is that we will forever be able to expand our skills. New platforms (like watchOS) arrive, new programming languages are released while the old ones evolve, programming patterns change, and some practices inevitably lose their relevance.
Software engineering, like engineering in general, is too broad a field to master completely. Gone are the days when a skilled programmer would know most of what all the other skilled programmers know, and to a certain extent, we must all choose what we will learn and what we will not. It is probably wise to keep up to date on a core set of topics and technologies that pertain to your interests and activities as a programmer, however, given our common position as WatchKit developers, I'd like to suggest a couple of pointers.
Being mobile means talking to the internet and talking to the internet means mastering at least the basics of the hypertext transfer protocol, better known as HTTP. While we have touched on this topic in this book, it is worth spending some time expanding your knowledge of not only HTTP requests et al, but also of the NSURLSession framework that provides so much of the functionality that your mobile apps will use frequently.
The more comfortable you are with this topic, the better equipped you will be to meet the demands and challenges of an increasingly connected environment.
As has been mentioned elsewhere in this book, the Swift language is one that is still evolving. At the time of writing, Swift 2.2 is nearing release and a roadmap for Swift 3.0 is being discussed by Apple and the community at large, now that Swift as been made open source.
Apple's own publication, The Swift Programming Language, is available for free in iTunes and can be read using the iBooks app. It is part tutorial and part reference work, and is an excellent starting place to learn Swift. It is kept up to date and iBooks will download new versions as they are published.
But you probably know that already.
When developing apps, the programming language you use is far from everything. Most languages offer you considerable flexibility in terms of what kind of patterns you use to create programs from those languages, and the ways in which small areas of functionality are woven together to form fully fledged applications.
It is only natural to assume that the way we have learned to do something is in some sense the 'natural' or 'obvious' way to do it and software development is no exception. But beyond the style and practices followed in this book (and the majority of Swift orientated blog posts and code samples), there is a whole universe of doing things differently, sometimes completely differently.
Prepare to be amazed.
Let us first look at what we have covered in these pages in the context of the broader programming picture.
In the mobile space, Objective C, Java, and of course Swift, are three of the most popular programming languages, and all three of these languages share a large number of characteristics with respect to assumptions that are made about how the software they are used for writing will be structured. In all three of these languages (and many more besides), we tend to combine a number of functions and variables into well defined groups of code that we refer to as objects, of which we may create as many instances as we require. These have traditionally been expressed as classes, encapsulated areas of code that hide their internal workings from the rest of the code, exposing only a limited number of methods and properties though their Application Programming Interface, or more commonly, API.
This is the fundamental basis of program construction; objects are created, which may contain or create other objects. They may be handed around to other objects to be manipulated or read and are frequently sub-classed into objects that represent further specializations of the superclass's code. This style of programming is called Object Oriented Programming(OOP).
Now, Swift is a very modern and flexible language, and we will see shortly that it is capable of more than just OOP, but it is nevertheless the case that most code written in Swift, including the code written in this book, is object orientated, which would explain any reaction the reader may have along the lines of, well of course we use objects and subclasses and all. What else is there?
We will look at two general groups of programming paradigms (i.e. fundamental programming styles), imperative and declarative. Imperative programming includes object orientated programming, so we'll start with that.
Imperative programming means basically telling a program what you want it to do by writing a list of statements, that is, do this, then do that. Let's take a couple of lines of code as an example:
let a = 0let b = a + 1
What we are writing here is basically telling the compiler:
- Create something called
aand assign to it a value of1. - Evaluate the expression
a + 1. - Create something called
band assign to it the value returned the expression in point2.
Step by step, we are telling the program exactly what to do, thus the name imperative. We will contrast this shortly with declarative programming. But OOP is not the only imperative style around. It's not even the only imperative style available to development in Swift.
Other imperative paradigms include the following:
Protocol Orientated Programming is the new buzz-word in the Apple community. After an entertaining and very clearly explained presentation at the WWDC 2015 by David Abrahams, the iOS Swift community has been eagerly exploring the possibilities and advantages of using protocols to share behavior between objects instead of subclassing.
It is really worth watching, if for nothing else than discovering Crusty and his contribution to software engineering.
Machine Code and Assembly Language refer to languages that go right down to the metal and deal directly with the 1's and 0's that computers manipulate. In the case of assembly languages, there is a thin layer of abstraction, but, basically, this is programming in its rawest form. It's fun to try out, and it's essential to many embedded systems that rely on direct control of hardware, but you seriously don't want to be writing a web browser in machine code.
Procedural languages include C and Basic, and are basically imperative languages that don't support the use of objects to encapsulated code, so no subclassing and the like. They were the predecessor to object orientated languages such as C++, and are still in use today, particularly C. If you ever get involved in server side programming, for example, you are likely to need to be comfortable with C.
You would be right to think that the programming you have done in Swift includes vast quantities of such code, but the point is that these languages stop there, they offer no support for anything more. Thus, they are termed procedural languages.
So what is the alternative to telling a computer what to do, step by step? Hinting politely at what you want it to do?
Well, there is a grain of truth in that. Declarative programming means that you are telling a program what you want it to do, rather than how you want it done.
Consider the following: You can put a driver in a car and then give him turn-by-turn instructions on how to get to wherever you want to go. Every corner, every traffic light, perhaps even which foot to use to brake and accelerate. It will be a long list of instructions, to be sure, but you will get there in the end.
Alternatively, you can give the driver a map, name the destination, and sit back and enjoy the journey (or the conversation—I come from a city of very loquacious taxi drivers). Declarative programming involves describing the goals rather than the steps taken (though the how-to sections of code will possibly include short bursts of imperative subroutines). Code written in this style is often much easier to read, since it is possible to follow what a program is doing without wading through the intricacies of the steps it takes to do it.
SQL is a popular declarative language with which you may be familiar.
Functional programming languages like Haskell use this idea and combine it with the idea that a function should give the same output for a given input every time, which means removing any ability to refer to properties of objects or as we should call it, state. Variables are assigned only once (and are then not very variable, but there you go) and are said to be immutable, which sounds like an odd concept coming from an OOP background.
We can't do justice here to this fascinating topic, which has contributed so much, incidentally, to the development of Swift, and the reader is strongly encouraged to have a good look at what functional programming techniques can offer the modern developer, particularly the developer who has the good fortune to be working in Swift. It is also true to say that two or three days of learning a pure functional programming language such as Haskell will unlock much of the potential of many of Swift's features, and provide a mental framework for ideas that are a valuable supplement to object orientated programming techniques.
Logic programming, as supported by, for example, Prolog and symbolic programming as with LISP are also ideas that are worth at least some brief exploration, though probably less so than those listed above.
Swift is a multi-paradigm language, as are others such as Python and JavaScript. Object orientated, functional, protocol orientated, mix and match them in Swift as you see fit. It is still a very new language, it is impossible to predict how programming practices will develop over the next decade, and this is a really exciting time to be part of that development.
Certainly, you could remain ensconced within the object orientated paradigm and still write first class code, and it may be the case that you're more inclined at the moment to get more of that under your belt before venturing into other paradigms and even other languages. But in the end, the borders we draw between these patterns and paradigms are artificial ones, and there is absolutely no reason why a little functional knowledge shouldn't be as easy to gain and as valuable to have as a WatchKit framework that is new to you, some third party code that will save you reinventing the wheel or any other concept that may seem 'closer to home'.
We have had a brief introduction to the Model View Controller (MVC) program design pattern espoused by Apple, but it's not the only one by far, whether inside the object orientated paradigm or outside it. While these patterns may or may not spark your interest, it is worth having at least a passing familiarity with their broad concepts, and an alternative view of how things could be done is always of value anyway.
A two-sentence introduction here would be of very little value, and an in-depth look at these patterns is unfortunately beyond the scope of this book, so the reader is encouraged to research these topics online. Here are a few search terms to get you started:
- MVVM (Model-View-View-Model)
- MVP (Model-View-Presenter)
- Decorator pattern
- Strategy pattern
- Singleton pattern
- Factory method pattern
As with the programming paradigms, these are not topics that you need to master completely and immediately, but some familiarity with them will put your own current coding habits in perspective and will give you a much better view of the bigger picture as you expand your skills as a developer.
It is probably clear from this section that you can't do it all, nobody can. Try to maintain a balance between a broad general knowledge of what's going on in the development world and a deeper, more localized area of expertise in which you are likely to quickly attain a level of knowledge beyond that possessed by most programmers.
Your own interests, strengths, and intuitive inclination will guide you in the path you take and rest assured that however obscure your tastes and skills may be, somebody somewhere needs them.