Learning Swift — Day 106

Recap and reflections on Days 104-5

I could not find the time to write anything yesterday but, as usual, I take my Sunday(s) off if I can — no religious matter, just in a deeply religious country you have to choose the same day when the other people stop!

Day 104 was a great one because I could complete all of Hacking with Swift project 30 and all of its three challenges. I still have to figure out how to do the bonus part which is saving the pictures as they are loaded. I am finding this abnormally difficult to picture in my mind and, to be sincere, even looking at a solution didn’t help at all. Their code was so differently laid out compared to mine that I could not fathom how to implement their ideas into mine so I closed it and said to myself that I will come back to this when I perform the review of this book.

So yes, my ultimate plan, hoping that Paul will release the updated version of the book before WWDC next week, is to finish Hacking with Swift and to review it thoroughly all the while creating my code snippets library.

Day 105 was a brain-melting day because I watched yesterday’s Swift on Sundays stream and it was so hard that I could do nothing else but copying the code almost mindlessly. I understood about a half of what was happening and all those files arranged like this really do not help my understanding. For sure everything is clear for Paul but I really hope that when he finally publishes the book on these streams I will have a chance of understanding what is going on.

So my decision is to stop watching the Sunday streams and to focus on my learning bit by bit. Also, my music notation work is having a very good momentum and I do not want to lose what I have for something I have no warranty will ever bring me anything. I have therefore set my limit of learning to minimum 1h maximum 2h per day as I also want to learn more about design (using the Adobe CC suite or not) and about music production. Moreover I need to take back my skills in mathematics and manage to master the Apple softwares for creativity to achieve the Apple Teacher title.

These are so many things to do, too many for sure so I have to limit coding a bit if I want to insert them as well.

---

So, what’s on the menu today? Day 99 of the program, the last Consolidation Day. Of course I have seen what other people have created and I know it will take ages for me to build this but, as I said, I am in no hurry.

Let’s get started, shall we?

What we learned in Projects 28-30?

A whole lot of things as usual! The first thing was the usage of the Swift Keychain Wrapper to save user data in a safe way. Of course we just scratched the surface on all this and we had to use an external library imported in form of two Swift files to access its functionality in a simple way but, in the end, we managed it.

Then we learned how to resign the first responder status of the keyboard for a text view or a text field, thing that makes the keyboard disappear. On the heel of this discovery we learn how to detect when the app is moving to the background by asking to be notified of the UIApplication.willResignActiveNotification. Also here, as for the bit masks, I read this as “will resign active” and then “notification”, otherwise my pudding brain just doesn’t get it. Also the local authentication framework was interesting as it allowed us to lock the app and allow unlocking only through biometrics (Touch ID or Face ID).

Technique-wise, we learned about the stride() function that allows us to loop across a range of numbers using a specific increment.

The color creation using hue, saturation and brightness was a completely new thing and a harsh reminder that coding skills are just the last ring in the chain and that I need to bring back to an acceptable standard my mathematical skills and, with urgency, to study design very seriously. I need to know how these colour schemes work and why otherwise whenever I will start developing my own apps I will just be stuck in front of the screen trying to figure out how these things work… Paul explained, as usual, what we needed to know, which is that keeping the saturation and brightness constant while choosing different hues would create similar color palettes easily. But still, I am very confused and I need some practical example as, in the projects, we just had numbers thrown at us, which is great but pedagogically useless.

The SpriteKit texture aliases are an interesting thing but with this little time with them my brain is just having a foggy memory of all that. I just remember how to create them, not how to take advantage of them.

Precise collision detection makes collisions work better with small, fast-moving physics bodies such as our mighty nuclear bananas but as I said multiple times, I do not feel comfortable at all with SpriteKit and I don’t know why.

The transitioning technique to pass between scenes was really interesting and I think I learned a lot about that, just I feel like I have forgotten everything after just a few days!

We were introduced to the .clear blend mode in the Core Graphics playground but inside code it was a mess to understand for me. I do not have time now to go back and re-analyse everything but I will for sure do so when I get to review this.

The dynamic shadows part was really interesting but as it was inserted in the debugging context I am not sure I saved a lot of it. I am really looking forward to the review period.

The difference between UIImage(named:) which has an automatic cache to help load common images and UIImage(contentsOfFile:) which is an initialiser for scanning the content of the bundle. This gives me some inspiration for that last challenge of Project 30 as it seem we need to use the first one to create a cache of images. But we will see…

Key points

We met here the weak keyword which is exactly the same one we use for the capturing of self inside closures. In project 29, having the game scene weakly own the view controller and the view controller strongly own the game scene allows to avoid strong reference cycles. Here the view controller already has an SKView and it already owns it strongly (this is an indirect strong ownership but it is strong nonetheless). This is an important aspect of object-oriented programming and it should be taken with a lot of care.

The second key point is the difference between UIImage(contentsOfFile:) and UIImage(named:), which is the first doesn’t cache the loaded image while the second does. Trying to solve the problem of force unwrapping that comes with the first option, we are going to learn convenience initialisers as well.

Convenience initialisers are wrappers around basic initialisers that are designed to make coding a bit more pleasant. They are able to perform some work before calling a regular initialiser and we are also going to attach bailable initialisers to this part. The following code creates an UIImage extension that creates a new, failable, convenience initialiser called UIImage(uncached:) that works like UIImage(named:) but that doesn’t need to provide the full bundle path and, at the same time, doesn’t cache the images!

extension UIImage {
    convenience init?(uncached name: String) {
        if let path = Bundle.main.path(forResource: name, ofType: nil) {
            self.init(contentsOfFile: path)
        } else {
            return nil
        }
    }
} 

I wonder if I could use it in that challenge … am I becoming obsessed with it? Yes, definitely! 🙂

Challenge

So, finally, we have come to the closing challenge of these 100 Days and it is the toughest challenge yet, the creation of a memory pairs card game! The priorities for this games are these:

• [ ] _ Come up with a list of pairs. Traditionally this is two pictures, but you could also use capital cities (e.g. one card says France and its match says Paris), languages (e.g one card says “hello” and the other says “bonjour”), and so on.
• [ ] _ Show a grid of face-down cards. How many is down to you, but if you’re targeting iPad I would have thought 4×4 or more.
• [ ] _ Let the player select any two cards, and show them face up as they are tapped.
• [ ] _ If they match remove them; if they don’t match, wait a second then turn them face down again.
• [ ] _ Show a You Win message once all are matched.

This is a big one…! If we manage all these points and want to push ourselves a bit further, then we can add the following:

• [ ] _ go for a variant of the game that uses word pairs and add a parental option that lets them create new cards. This would mean:
  
  • [ ] _ Authenticating users using Touch ID or Face ID.
  • [ ] _ Showing a new view controller that lists all existing cards and lets them enter a new card.
  • [ ] _ Use a UIAlertController with one or two text fields for the card entry, depending on what kind of game we are making.

As usual, now is the time to feel lost and cry against the sky but it will pass fairly quickly. Now let’s go!

---

If you like what I’m doing here please consider liking this article and sharing it with some of your peers. If you are feeling like being really awesome, please consider making a small donation to support my studies and my writing (please appreciate that I am not using advertisement on my articles).

If you are interested in my music engraving and my publications don’t forget visit my Facebook page and the pages where I publish my scores (Gumroad, SheetMusicPlus, ScoreExchange and on Apple Books).

You can also support me by buying Paul Hudson’s books from this Affiliate Link.

Anyways, thank you so much for reading!

Till the next one!