Project Directory

In a recent lecture, we were taught about the importance of properly preparing project files for handing them over to a client. This has been mentioned previously but here I will go into more detail about the directory itself.

Below is a screenshot of Terminal. I navigated to the directory and typed ‘ls’ which lists all of the files and sub-folders inside. Here you can see the initial organisation of the files, and the essential readme.md which contains more details about each of the files and folders. Below that I used a wonderful homebrew function called ‘tree’ which creates a file tree of the directory and all of the subdirectories and files. As there are a lot of files here, it only shows a small snippet of it, but you get the idea. The indentations are used to show the nesting of files and folders so you can easily track their locations and parent directories.

Screen Shot 2015-05-17 at 11.03.49We have tried our best to minimise duplicate files. This is essential so that there is only one location of the file as to not cause any confusion when working collaboratively. However there are some unavoidable duplicates in this directory. When we copy images into the application, it then makes a copy of the file in its directory, as well as the original inside the assets folder. This is pretty much unavoidable as all the files the app needs need to be in its directory. It is important to remember that if someone decides to update one of the image assets in the assets folder, they then need to update the copy of the image in the app folder to keep it up to date.

Programming: Source Control

Throughout this whole project, we made sure that we used source control (otherwise known as version control)  to keep track of all the changes and files used in the app code. Recording these changes allows you to jump backwards to older code, incase something breaks or the project files are lost. It allows you to compare changes over time and track the progress of the project as it evolves.

Using source control in todays day an age is an essential professional practice as it allows you to easily work collaboratively with other people – as was done in this project with two programmers.

We put our code in a private repository on Bitbucket. This repository is on a remote server and can only be accessed by people who have permission. This is great when you want to keep your code/ project a secret, and is something we had to do as mentioned in the contract signed at the beginning of this project. We use this repository as a backup of the code. When either one of the programmers makes any changes, we are able to push them up to the repository where they will be saved.

Below is a screenshot of our Commits page on the bit bucket repository. Here you can see all of the individual commits made and pushed to the server. A commit is made after some lines of code are changes, a comment is then added so we know what the changes were in the commit – making it easier to find where to jump back to if we ever need it. It also helps us keep track of what has been done so we don’t waste time repeating processes. If you were to click on one of the commits, it would take you to a new page were you can easily see which files were changes and which likes of code were edited.

Screen-Shot-2015-05-16-at-12.57.30

Locally, this source control was used in a couple of ways – either through Xcode itself or using Terminal. Inside of Xcode it has options for you to commit changes, push changes to the remote repository or pull changes from the repository. This is all done with a pretty graphic interface making it nice any easy to use. My personal favourite way of doing it is through Terminal, using the command line to do the same functions to source control my work.

Below is a snippet of the same commit log above, but presented through terminal.

Screen-Shot-2015-05-16-at-12.56.12

To be blunt, using source control for our code helps us meet the learning objective:

02 Originality, creativity and professionalism in the interpretation of a live brief, production conception, pitching, management and realisation of interactive media artefacts;

It is a professional practice which allows us to work swiftly (pun definitely intended) and collaboratively on this project. While I believe we did a fairly good job at making regular commits for the changes to the code, they could’ve definitely been more regular if it was possible. One of the biggest downfalls is that a lot of the code was only written on Thursdays and Fridays while we had workshops. Within these workshops we were able to quickly get  help as and when we needed it, rather than searching endlessly on the internet wasting valuable learning time. As a lot of progress was often made in short stretches of time, remember to stop and commit the changes wasn’t done as often as it should, and would usually be done at the end of the day after too many changes were made to accurately keep track of. That being said, source control has proved itself invaluable to this project and was an essential part of the whole process.

Programming: Bug fixes

Today we encountered a large problem when trying to load the app onto an iPad for testing. The problem was that the app was using too much memory for the iPad to handle loading the app. We were testing on an iPad 2 which only has ~1gb of RAM. We had to significantly reduce how much memory it was using to get it well below this 1gb threshold as the iPad still needs to run iOS as well as the app.

Once the app started up, it was using 1.53gb of RAM to run it. We never noticed this problem before as it never had an issue running on my laptop during the development as it has 16gb of RAM. During our short time learning how to program for iOS we weren’t taught about this kind of issue and what to look out for.

Xcode has some built in debugging tools which can be used to find issues within the app. With the help of the swift magician, Marc, we were able to find where about the problem was. We saw that as soon as the app opens, the memory spikes up to an exceedingly high value and they stays there for the duration of the app running. This make us think it was something to do with the Magna Carta image in the scroll view. Our suspicion was confirmed when we changed the image file to a far smaller one and it was using significantly less memory.

As mentioned in a previous post, we already had to compress the Magna Carta image as the original file was far too large. This file was compressed down to ~188mb, about half the size of the original. Apparently this image is still far too big. When loaded into to the scrollView to display the image, the memory needed vastly increases to approximately 3 times the size. We’re not entirely sure why it uses so much memory, but if we reduce the image file size enough, it will be able to run on the iPad.

The original image we were using was using over 60,000 colours. This gave us a good level of fidelity when zooming into the image. Unfortunately we had to vastly reduce this amount to compress the image to make it usable in the app. We reduced the image down to 128 colours, saving 73% on file size. This reduced image size meant that the app only used ~380mb of RAM to run. While this is still very high, it is just small enough for the iPad to be able to run it without crashing.

The client has said that they will be purchasing an iPad so they they can use our app in the exhibit. We are hoping that they will be buying one of the newer iPads as they have more memory than the one we’ve been testing with – meaning that the app will be more stable while running.

Programming: Final Changes

As we come up to the final week, we’re just adding the final touches to the application to make sure that it is the best product we can provide for the client.

Last week we were given the final translations and contextualisations to use in the app from the client, so the first step was to add these into the code. After we did this, we noticed that they were significantly smaller than before. Because of this, the detailView seemed far too tall compared to the text inside it.

Originally the detailView was 500 high. This value was just an estimate size as it stuck throughout most of the development. First we tried lowering this down to 300. This worked well with some of the shorter clauses as the box didn’t drown them, but with the preface and suffixes, it seemed to be far too small and required too much scrolling. We went for the final option of 400 high. This was a good middle ground between being small enough for the shorter clause translations and big enough for the larger ones.

While doing this, I went through and cleaned up the code. This meant adding comments to functions and deleting excess line breaks to make it neater and easier to read. Commenting the functions and code is essential when handing the project over to someone else, and is always good practice to do just for myself. It is a way of always knowing what the code does and why it works/ was included. Sometimes what seemed like a simple thing to write at the time can seem complex and difficult to understand a week later. Commenting the code speeds up the workflow and is a good professional practice to get into so the code is clear and easy to read, edit and understand.

I also removed the swiftyJSON.swift file from the code. This remained in there from when I experimented with using JSON to get the translations into the code. There were also some old image files left in the project folder from when I was testing for the best solution and images to use. It is good practice remove excess files and text to keep file sizes to a minimum. Its not good to bulk out the project with assets and code which aren’t even being implemented as it makes it cluttered takes up unnecessary space.

Programming: Styling the Side Menu and Navigation bar

With the navigation and Side Menu the styling for this was a little bit more tricky than the styling that we had done for the rest of the App. As majority of the app was made programatically it was easy to see where we needed to add/change the styling eg colour, font size, font style etc but there were elements in the side bar that were created in storyboard.

The navigation bar was done programatically. Using the same colour scale that we used for the detail view all we needed to do was specify the exact RGB values. The line of code “barTintColor = UIColor(r: 76, g: 61, b: 61, a: 1) ” Is the code that changes the background colour for the navigation bar. From this we were able to speciy the colour for the burger  ( menu button), The line for that is “tintColor = UIColor.whiteColor()”. As there is an image within the navigation bar, you need a UIImage and from there you can frame how big you want it too be and what image to use. See below on the code that implemented the logo and the colour of the bar.

Screen Shot 2015-05-19 at 00.03.10From this it achieved the logo we wanted and the colours scheme to match our designs.

Screen Shot 2015-05-19 at 00.12.19The title for ‘filter categories” was styled in the same manner as before. The line of code “barTintColor = UIColor(r: 239, g: 233, b: 211, a: 1)” Is the code that changes the background colour behind the text. From this we were able to specify the colour for the text that was being displayed. The line for that is “.titleTextAttributes = [NSForegroundColorAttributeName: UIColor(r: 76, g: 61, b: 61, a: 1)]” See below full code. Note this is very similar to the styling of the navigation bar as it is but for the SideMenuController rather than ViewController.

Screen Shot 2015-05-19 at 00.21.18However to change the styling of the categories was needed to be done in the storyboard. This was only tricky because we had’t been using storyboard which meant I was a little bit ropy on how to change elements. Once I had realised where to go and how to change this elements it was plain sailing from there.

StoryBoard make it very easy to change the colours of each of the cells. You just need to click on the particular cell that you want to add some styling too then on the right hand side there are attributes such as background colour, tint, alpha levels which can all be adjusted to change the colour of each element you want to change.Note: you must make sure that you select the correct element you want to change colour.

Screen Shot 2015-05-19 at 00.25.55As you can see from above all the different cells have been coloured in. By selecting these cells you can also change any labels (text) that you have. This is done in the same way.

Screen Shot 2015-05-19 at 00.34.50It was important to make sure that the styling for the app matched the designs that were created and that we made sure that the colours and style conformed to the original style guidelines that were given to us by salisbury Cathedral and Red Balloon. We believe that the overall look for the navigation bar and side bar with the design icons that were made, meet the criteria of these guidelines.

Screen Shot 2015-05-19 at 00.38.40

Programming: App Icon and Splash screen

At the beginning we mentioned that our app is now going to be a separate app that is designed for iPad and going to be an installation that sits next to the Magna Carta document. We felt it necessary to provide Salisbury Cathedral with a complete packaged mobile application. That includes the actually app itself packaged with all the features the client wanted but also a Splash screen so when the app is opened (and for our case a long time) it shows an image of what the app is that’s being opened and an Icon to display on the launch pad on the iPad device.

Using the design guidelines set by Salisbury Cathedral we created these elements that conformed to the styling. Making sure that all the colours that were used were colours that we defined by the guidelines, all the fonts that were used were the same as the other work that will be displayed in the exhibition and making sure all image assets are copyright free or the cathedral hold the copy right for them.

Below the design that was created for the app icon. Using a online icon generator  I was able to make the image Icon on a square 1024x 1024 then it created the images into all the sizes that we need for the app icon to work.

magnacarta_icon

See below the exported images that all the different sizes that are needed within the app.

Screen Shot 2015-05-18 at 14.56.28Of which can be then put into the imageAssest’s appIcon file which when xCode builds the app it will take the images and compile them into the app. See below all the images in the asset file for an iPad device, we could also put in the sizes for iPhones however as we are explicitly making it for an iPad we haven’t included these.

Screen Shot 2015-05-18 at 16.04.03The method for the splash screen was very similar, however there wasn’t a website that created all the different sizes which would mean I would have to export all the different sizes myself. Luckily enough there is a LaunchScreen.xib that allows you to create the splash screen on a storyboard* which I added a UIImageView to place the same image as the app icon. See below splash screen.

splash However as the splash screen is scaleable depending on what iPad model it is. Therefore we have separated the background image to the text. This way the background can be scaleable but the text will remain the same size and centred by using constraints within the launchscreen.xib.

* This is a self-declared storyboard which is for a launch screen it has the same layout however it doesn’t hold the same properties as a storyboard.

Programming: Hidden Details Cateogory

The Magna Carta has special facts and details that are hidden within the app. Either historical context of the Magna Carta or additions and accidents that have happens to the document that we thought were important to the app and will give the audience a new insight to the document itself.

Below is an image of where the little details are featured within the app. While it is cool that each of the details have been highlighted, this is just an initial reference to where all the details are, as it isn’t easy to see what is being pointed out.

Screen Shot 2015-05-14 at 12.02.00

Using photoshop (other design program are out there) we drew boxes around each of the details making sure there was enough room around each of the detail wasn’t covered up by the boxes by using the same border thickness size we would use within the app. See below.Screen Shot 2015-05-18 at 13.36.15From this document we were able to get the co-ordinates of each of the boxes that we needed to use and place them within Xcode. This was achieved by pressing Command ⌘-T which allowed you to transform the object however it also tells you the X and Y axis positioning and the height and width the box is, then this information was placed in the correct hidden detail, the same way as the over co-ordinates for the clauses.

It was great that we had all the boxes mapped out, however these particular overlays would need to be transparent inside the boxes and translucent for the edges so that each detail is highlighted in a big enough area but you can still see what is actually inside the boxes. Like the photoshop document, however the overlays we had created only used a background colour.

To achieve this within the overlay.swift we needed to create an function that gave all the overlays a border however we only want the hidden details to have the border therefore we created a if statement that will set the default of the function to false and only when the function gets called within the clauses.swift the border will appear.  See below, the function.Screen Shot 2015-05-18 at 13.47.17

Therefore within the information about each of the clauses and the overlays, it was possible to specify whether the isHidden function is needed within the clause. See Below.Screen Shot 2015-05-18 at 13.53.55

In addition to this we set the hidden details to have a different background colour ( colour3) which would allow us to make the background colour transparent. By using “let colour3 = UIColor.clearColor() “. From this it has allowed us to show the hidden details within the document however it doesn’t stop the user from being able to see the detail itself which if we used the same overlays for the clauses it would. See below the result. Screen Shot 2015-05-18 at 13.59.39As part of the mystery of the hidden details and part of the charm of the document, we have kept the hidden details are a category on its own as we think they are important to the document but also didn’t want to distract the users from the content itself. Therefore they aren’t within the ‘All category’. They would overlap many of the clauses which would look messy.