So today marks the start of the Applied Design unit, and although we haven’t been given the official brief yet (coming later today), we know we will be using Swift in xCode to develop a mobile application for an external company.
To get us started, we were introduced to the programming language Swift. Swift is a relatively new programming language that was released by Apple in 2014. It is built for iOS and OS X apply and builds on the previous Objective-C. Swift provides a platform which is friendly towards new programers, supporting ‘playgrounds’ (see below).
this morning we had a workshop to act as an introduction to the programming language and how it is used. Familiarising ourselves with basic programming setup (learn’t last semester) we went through a few different functions that will play a part in developing our own mobile application.
Above is where we started off, in xCode’s ‘playground’ which, without requiring you to compile and run a complete project, it provides quick feedback for the results of coding experiments without the need of running the application in full.
We familiarised ourselves with if statements, optional values and inserting objects into the space. What I liked about this is you were able to see the results of what was typed updated in real-time in the right hand menu without having to run it opposed to programmes like Processing where you had to finish tying then run the whole canvas to see if you had developed any errors.
We then learnt about model-view-controllers (MVC’s) which an architectural pattern for implementing user testing. It divides an application into three interconnected parts to separate internal representation of information from the ways that the information is presented/accepted from a user.
As well as diving the application into the three different kinds of components, the MVC design defines the interactions that occur between them.
1. A controller can send commands to the model to update the state, for example editing a document. It also sends commands to the associated view to change the presentation of the model, for example scrolling through a document.
2. A model notifies its associated views and controllers when a change of state occurs. This notification allows the views to produce an updated output, and the controllers to change the available set of commands.
3. A view requests information from the models so it can generate an output representation to the user.
We then moved onto using the main project interface to create a test model to just see how the interface works and demonstrate the work process that will be used to build an application.
We used the ‘main.storyboard’ and ‘viewController.swift’ to create a simple button when pressed it would display a message to get to grips with the simplicity of the task. This was reassuring, as after struggling with the Processing canvas, a nice design interface was very welcomed.
Little code was actually needed to create a simple button that had an output and xCode provided a easy interface to avoid actually having to type out lines of code to create the button and then change what happens, when it happens and what type of input is needed from the user.
Below is the result of the code.
So far I am looking forward to using Swift in xCode and quite motivated to extend my learning outside of the workshops to develop my skills in this area. I plan over the next few days to undertake some begginer tutorials so that when I come across the more tricky aspects in workshops I will already have some basic understanding to build onto.