Ray Wenderlich Course Part 3 (up to lesson 24)

So last time it was all a bit of a rush! I could not for some reason get the label showing the correct number on the slider. I tried doing it the usual way - connecting and selecting it as a reference instead of Ray's suggested way, then tried his way anyway! So the first thing to do is to see if I can fix the issue myself before continuing with the course....

Ahhh OK - I just missed that in the video. I had the currentValue variable in the wrong place - he moved it to the viewDidLoad override func! That now figures.

Now, the other bit that wasn't working was the target value being a random number. Let's try that in different places to see before I check his video...

YES all figured out - wrong place too! So let us now continue....

Writing Methods

Now I know that methods are functions within a class or object. I reckon that what we need to do is have an 'update' function so that every time the button is hit, the scores get updated. Let's just have a go at that on my own first.

    func updateScores() {

        

        targetValue = Int(arc4random_uniform(101))

        currentValue = lroundf(slider.value)

    }

    

That's better - so I have created a function as planned, then included this in both the viewDidLoad method, as well as the button pressed. One problem still - the sliderValue is not updated until the time after it is clicked! Not sure why....

OK, found out the other issue - where I had updated the currentValue. All working OK now!

So the viewDidLoad is already in-built for an Xcode project. 

And this is calling the methods! That helps distinguish between methods and functions.

DRY - Don't Repeat Yourself!

Connecting Outlets

So now I have a challenge - 

I need to have the target value label displayed here! Should be easy enough...

 @IBOutlet weak var targetScore: UILabel!

AND....

targetScore.text = "\(targetValue)"

As part of the updateScores function. 

Again, I think it is a BAD idea to type out the @IBOutlet when I can just connect it directly. Sorry Ray!

So Ray did a separate function for updating the label. I would rather have it in the same function as it means less repeating. Looking at the Q&A forum, this is what he says...

A lot of times in development, there are multiple ways to do things. In this case, both ways work! 

When it comes to deciding whether to put code into a separate method, there are two things I think about:

1) Would it make my code easier to read/work with if it's in a separate method? For example, the updateLabels() method is nice because a) you know to put any code relating to updating the labels there, and b) it makes your code a bit easier to read. 

2) Am I likely to want to run this code from more than one spot? If so, you might want to put it into a method. Having made a bunch of apps, there's lots of times where I want a method to "refresh the screen based on my data model", hence why I probably did that out of habit.

In this case, honestly both ways are fine and it's a matter of programmer preference or debate. Your way definitely wouldn't be considered bad practice in this case, it's fine.

However, if you ended up setting that target value label somewhere else in your code, then rule #2 would apply and you would probably want to extract it to a method in that case to avoid duplication.

So it's basically fine! I can't see how I would ever need that label as a separate method. 

Well we have completed 7 out of 11 items! Good stuff!

That was pretty satisfying - working out a lot of the bugs myself and applying logic. Of course, one of the great yet frustrating things with Swift is how there are multiple ways of doing things. This is ultimately a good thing as it allows for creativity - rather than one fixed solution. Anyway, I'm finishing this entry here as it is a natural point to, but will be doing another entry shortly today!