RW.com: Storyboards Segues Article - Part 1

Here we are! Onto the next article. The first one was useful as it gave me a lot more confidence with connecting the different bits and pieces, along with a few segues. This next article (same author) is all about segues. So I'm sure that there will be various useful bits!

Start Time - 8:07


Here is the link I'm following:

https://www.raywenderlich.com/5055396-ios-storyboards-segues-and-more

Great, something he makes clear that there will be full functionality this time! That's a relief as last time it was a bit strange not to have it after all that work!

This time the project has been set up and organised. New VCs are going to be created.

So a new Swift file made under the view controller folder.

And here's the code added:

class PlayersViewController: UITableViewController {

  

  var playerDataSource = PlayersDataSource()

}

We have a UITableViewController, and in this an instance of the PlayersDataSource class (same name). 

It is a TVC as it is a specific table with the detail. Makes sense for a list!

*I've realised that this is not using SwiftUI. Not a problem as it gives me the breadth and depth of understanding of seeing this with UKit.

I've changed the view of one of the Players Scene to be the PVC in the settings, the one just created. I'm presuming that the code here will match to what is on that screen, from what I remember of Swift UIKit. Easier on Swift UI!

Changing from static to dynamic I presume means there will be link to the code. 

The identifier bit - player code - gives the means to reference the cells from the code. 

This extension has been added to the PVC file - 

extension PlayersViewController {

  override func tableView(

    _ tableView: UITableView,

    numberOfRowsInSection section: Int

  ) -> Int {

    playersDataSource.numberOfPlayers()

  }

  override func tableView(

    _ tableView: UITableView,

    cellForRowAt indexPath: IndexPath

  ) -> UITableViewCell {

    let cell = tableView.dequeueReusableCell(

      withIdentifier: "PlayerCell",

      for: indexPath)

    return cell

  }

}

It's become clearer why extensions are good - they keep the code organised! Having all of this in the same bit of code would be hard to read. 

Another Swift File - a cocoa class. This is a subclass of table view cell. Not exactly sure why yet!

OK so in the cell on the table view from before, I have just changed settings to PlayerCell (the subclass of TV cell we've just made) then connected each of the @IB outlets (the labels/star rating image) all in one go!

So I have added this to the PC code - 

// 1:

  var player: Player? {

    didSet {

      guard let player = player else { return }

      gameLabel.text = player.game

      nameLabel.text = player.name

      ratingImageView.image = image(forRating: player.rating)

    }

  }

  // 2:

  private func image(forRating rating: Int) -> UIImage? {

    let imageName = "\(rating)Stars"

    return UIImage(named: imageName)

  }

What does this do....?  It means that all of the labels now show the unique values for each player, rather than the same one three times.

A bit more code - quite technical stuff involving upcasting and bits. 

Another Swift file, then changing again on the Custom class option. 

A point here is that you can't just connect outlets to views in dynamic cells. With static cells it is all safe. 

This is a great real-life use of didSet (property observer) - 

var game = "" {

    didSet {

      detailLabel.text = game

    }

  }

It means that the label will be updated - that's something I've struggled to get before!

Nice! Now we're adding the cancel and done button functionality. 

These unwind methods were added to the code - 

extension PlayersViewController {

  @IBAction func cancelToPlayersViewController(_ segue: UIStoryboardSegue) {

  }

  @IBAction func savePlayerDetail(_ segue: UIStoryboardSegue) {

  }

}

It was the right hand of the icons to control and click it to!

So these unwind segues automatically reverse all segues.

So now we need to capture the player info and add it to the form. This is always tricky to do - I remember trying it before with a to do list app.

Again, I've noticed with Swift UKit how fiddly it is - creating separate files for different objects, in this case it is the use of the game picker. 

So again, lots of extra code needed within the VC. I can use and play around with this to get a better understanding of it. 

Stopped at 9:04 (approx 55 minutes)

So a productive session, even if it's not all straight forward stuff. The code to put in the VCs is a bit baffling at the moment - there's a lot of very specific code required, which then matches up to the storyboards. I'm stopping here as that's enough in one go but will continue this later or tomorrow. Good stuff!