Day 31 of the 100 Days of Swift challenge featured a technique project. Well, technically it featured two projects referred to as Project 6a and Project 6b. When I say technically it was two projects please don’t infer that I just didn’t know how to count. After all, “there’s an app for that”. What I meant was that Project 6a was not a full-blown project per se. Rather it was a continuation of Project 2 or more to the point it corrected deficiencies in Project 2.
For those who may not be following along with this blog on my journey to learn Swift programming, Project 2 was a Swift game called, Guess the Flag. In this game the user was presented three flags from different countries and the name of a country. You had to choose the correct flag. If you were correct you earned one point; if your answer was incorrect a point was taken away.
Project 2 has become a family favorite as my wife still asks to play it once in a while. Of course it’s just elementary and only contains 12 flags so after playing a few times you can almost guarantee a good score because you have seen the flags enough times. I’ve thought about going back and re-visiting the game and adding more flags just to increase the difficulty level.
So, when Paul Hudson stated that we would be revisiting Project 2 on Day 31 I almost expected that is what we would be doing. Unfortunately, that was not the case. Instead we would be looking at another problem that I had not even realized the game had.
When we initially built Project 2 we told Xcode that the game could be used in portrait and landscape mode on the device. In reality, the way it was coded the content does not fit the screen when in landscape mode making the game hard to play. Project 6a was designed to fix that by introducing Auto Layout and constraints.
The changes were relatively minimal, most if not all of the work was done in the Interface Builder of the main storyboard. Regardless, it was a valuable lesson and helped to remind me that if I check those boxes to support different devices and different screen orientations, I need to test those to make sure they work.
Project 6b was more intense as it introduced the Visual Formatting Language and Auto Layout anchors to manage the user interface programmatically. I have to be honest here, while I appreciate the level of control you can have via programming layout, reading and writing Visual Formatting Language code is akin to watching a really bad horror movie from the 1950’s. It’s entertaining but I wouldn’t want to make a date sit through it. That being said, it is necessary to learn it and understand it as you will likely run into code using it and need to understand how it works.
The challenges at the end of Project 6b were entertaining and for the most part pretty straight forward. There were three of them and I will go through each along with the code I used to accomplish them in case others get stuck or are curious to see how someone else solved the problem.
During Project 6b we were introduced to AutoLayout Anchors. In the project we created colored bars that stretched across the screen with labels and used the widthAnchor to have the bars go from screen edge to screen edge. Challenge 1 asked us to replace width with leadingAnchor and trailingAnchor.
The leadingAnchor and trailingAnchor are similar to right and left anchors but assist in localization as they change depending on the language being used. So for left-to-right languages such as English they are the same as left and right respectively. But if you have a right-to-left language such as Hebrew then leadingAnchor is equivalent to right and trailingAnchor is equivalent to left. Confused? It’s best to just ponder that a bit and it makes sense.
The code I used to do this was fairly simple although on the surface seems a bit less efficient:
label.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor).isActive = true
label.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor).isActive = true
The reason I say less efficient is that I basically replaced one line of code using the widthAnchor with two for leading and trailing. I get why, it’s just with this particular example I’m not sure it was warranted.
The second Challenge was very helpful. On phones such as the iPhone X series, there is the notch in the upper part of the screen. Using the screen height, some of your content is lost at the top. If you rotate the device to landscape, some of the content is lost on the left or right depending on which way you rotated the device.
This was solved in the lines of code above by replacing view.leadingAnchor in the equalTo: parameter with view.safeAreaLayoutGuide.leadingAnchor as an example. Adding the safeArea portion tells the code to take into consideration the screen nuances and only put content where it can be read. I guess if Apple ever comes out with the donut hole shaped phone this code will work by not displaying content in the donut hole. I’m kind of eager to test that.
The third Challenge was a little more difficult and fun. When we built the application initially, we set the height of the colored bars to a constant value of 88 pixels. The challenge was to modify that to make the bars each be 1/5th of the screen minus the 10-pixel space we added between bars.
What made it challenge was that you needed to add a multiplier and a constant to the parameter list. I wasn’t sure you could do that, so I took a swing at it and shocked myself to find that it worked. The code was just one line that managed the heightAnchor for all five color bars. The code is:
label.heightAnchor.constraint(equalTo: view.safeAreaLayoutGuide.heightAnchor, multiplier: 1/5, constant: -10.0).isActive = true
In this line the multiplier was 1/5 which told the program that each bar should represent 20 percent of the screen real estate. The constant of -10 said that the value of the height should be reduced 10 pixels to account for the space we wanted between each colored bar. This works both in portrait and landscape mode.
It was an interesting project and great challenges. I now have a better understanding of how AutoLayout works.
0 Comments