Josh's Swift Journey

Cracking on with protocols. Some of this will be to do with 'encapsulation' I think. Anyway, let's see what we have...! Protocol Orientated Programming Pasan   goes over the example from the object-oriented Swift course, where we had different structures and classes. enum Direction {          case up, down, left, right } protocol Movable {          func move (_directionL Direction, by distnace: Int ) } protocol Destructable {          func descreaseLife(by factor: Int ) } protocol Attackable {          var strength: Int { get }     var range: Int { get }          func attack(player: Player )      } So all of these protocols are involved in the game I programmed before - as part of the struct/class course. The 'get' bit I'm still not too sure about.  ...

I'm getting more used to protocols. This is also the first time in a little while I've managed two consecutive days! Hopefully it will become clearer with more experience.  Protocol Inheritance A point that Pasan makes is that you may not want to inherit like with classes as it takes on EVERYTHING. E.g. from a plane, you may only want to inherit the fly method for a bird. protocol Printable {          func description() -> String      } struct User {          let name: String     let age: Int     let address: String          func description() -> String {                  return " \ ( name ), \ ( age ), \ ( address )"     } } let user = User (name: "Josh" , age: 33 , address: "placeHome" ) user . description () But we need to include a more specific p...

So having started learning about these, I know that I'm just scratching the surface. Last time, I got my head around some of the syntax - now it's about understanding the meaning of them in context. Here we go! import Foundation enum EmployeeType {          case manager     case traditional      } struct Paycheck {          let base: Double     let benefits: Double     let deductions: Double     let vacation: String } class Employee {          let name: String     let address: String     let startDate: Date     let type: EmployeeType init (name: String , address: String , startDate: Date , type: EmployeeType ) {          self . name = name     self . address = address     self . startDate = startDate   ...

So I got something wrong - the next course in my 'Beginner IOS' track is Protocols, not making an app! Not sure how that happened. Anyway, I'm not sure what Protocols are, but I assume it's do with more complex methods. Here we go.... What is a Protocol? Pasan uses the coffee shop example. The concept is to define a blueprint of methods, properties and other behaviours. Expected behaviours. protocol FullNameable {          var fullName: String { get }      } So that's the syntax for protocols. Whatever uses this protocol must use the fullName property and apparently it is 'gettable'. Not sure what that means...yet.... OK, we can read the property but not set it until we get an initial value....still not clear! Creating a Protocol struct U ser: FullNameable {      } An error comes up here as I have not put in the necessary properties. struct User: FullNameable {     var ful...

Well, I haven't been able to maintain my every/most day but to be fair, two missed days is not the end of the world! Optionals and Enumerations are still pretty fresh in my head. I've used 'Swifty' to consolidate my understanding and go over a few concepts. This next blog should be the last one in the Optional/Enum course.  Raw Values Enums can store different types. Enum members can be populated with default - raw - values. enum Coin {          case penny     case nickel     case dime     case quarter } let coins: [ Coin ] = [. penny , . nickel , . dime , . dime , . quarter , . quarter , . quarter ] func sum (having coins: [ Coin ]) -> Double {          var total: Double = 0          for coin in coins {                  switch coin {            ...

The second part of optionals! I get Optional Binding so we'll see what we have next... Downsides to using If Let Optional binding is used with the if let. The example Pasan gives highlights a couple of flaws - what if we don't have the data? Well, we would have to use else and nil. struct Friend {          let name: String     let age: String     let address: String ? } func new(friendDictionary: [ String : String ]) -> Friend ? {          let name = friendDictionary[ "name" ]          if name == nil {                  return nil     }          let address = friendDictionary[ "address" ] } The issue here is we would have to return the values using ! which is not recommended. The main point Pasan makes is that optional binding is laborious but it was necessary...

Yes - one day's break, but not because I needed or wanted one! I was genuinely to busy for any Swift yesterday, so it feels good to be back! Having written entries each day for a week, I missed it! Enumerations are done for now; Optionals are next... The Absence of Data I think the idea of this is 'nil' - nothing! Pasan explains 'safe' code, where crashes need to be avoided. Optionals are new - since the inception of Swift I believe.  struct Person {          let firstName: String     let middleName: String ?     let lastName: String } I've pre-empted the ? - to make middleName an optional. If I didn't have this, then an error would be caused - you can't input nil. The question mark - making it an optional - means that nil CAN be used. So it means it may have a value OR may be nil. They do seem cumbersome, but apparently they are powerful and useful! In the example above, it means that it is a string and ma...