Build a Vending Machine App - Part 1

Here we go! Moving on from Error Handling (what a waste of time that was!), I'm now embarking on my second 'app project' - this time a vending machine! Although I don't need this specifically, I'm sure that the skills involved will be useful. I learned so much from the 'Fun Facts' course. So, here we go!

Modelling an Interface

OK the idea for this looks really interesting - choosing items to purchase and seeing if enough money is there. Handling the errors where necessary - that is the point for this particular course. Also, this app will be using multiple screens - not just the same one! Also, we're moving on from just buttons to using 'variable information'. Good stuff!

Starter File Walkthrough

A UI CollectionView is used - this is for an ordered collection of items in a customisable layout.
WARNING - concepts I am not familiar with will be in this!

OK one issue - the main storyboard I have has one big button rather than lots of little ones. Strange and I hope it doesn't ruin the course...

Right, not a problem - when the app is run you see all of the smaller boxes. So there is something clever on Xcode where the main storyboard is a bit separate to that. The other main screens are talked about - complex stuff but just about making sense of it so far.

Laying the Groundwork

OK, so a bit strange - the swift file I've created is already there...no matter, I've just commented out the bits, now creating the new ones. Something that's been mentioned a few times with protocols is get/get set. Just want to clarify that before continuing. Q

From 'Stack Overflow':

The getting and setting of variables within classes refers to either retrieving ("getting") or altering ("setting") their contents.

Consider a variable members of a class family. Naturally, this variable would need to be an integer, since a family can never consist of two point something people.

So, if we are getting, we are retrieving, which means it will be for a value that is already there. If it is setting, it means changing it in a some way...OK, that's something!

enum VendingSelection {

    

    case soda

    case dietSoda

    case chips

    case cookie

    case sandwich

    case wrap

    case candyBar

    case popTart

    case water

    case fruitJuice

    case sportsDrink

    case gum

}

protocol VendingItem {

    

    var price: Double { get }

    var quantity: Int { get set }

   

}

protocol VendingMachine {

    

    var selection: [VendingMachine] { get }

    var inventory: [VendingSelection: VendingItem] { get set }

    var amountDeposited: Double { get set }

    

    init(inventory: [VendingSelection: VendingItem])

    func vend(selection: VendingSelection, quantity: Int)

}

Here is what we have so far. Let's break it down...

The enum is just a list of food/drink items - each case is clear from that list. Simple.

The protocols (blueprints for certain behaviours/values) use a number of variables, which are going to be accessed at some point. 

The func is specifically for error handling - this is is to counteract any potential error that could happen. 

Concrete Types and Property Lists

Creating a struct rather than using a class - again Pasan makes the point of when and why to do this. Value types are better for enums/structs - they DO things. A struct has member wise initialisers automatically. So why the protocol? Apparently it gives flexibility. It's to do with get/set! The protocol shows us the cost and quantity, but we can use whatever logic we want to acquire that. Still not crystal clear but getting there. 

Then we've made a class. It's better as class is better for state - particular values for a point in time. 

One of the aspects here is using the dictionary and using protocols as they key/value pairs. That gives me ideas for many things - from F1Facts to F1 game! Basically, I could have 'question' and 'answer' as protocols/enums, then being accessed...or true/false to go with each question. With the F1 game, it could be types of tyres, corners...all sorts!

class FoodVendingMachine: VendingMachine {

    

    let selection: [VendingSelection] =

    [.soda, .dietSoda, .chips, .cookie, .sandwich, .wrap, .candyBar, .popTart, .water, .fruitJuice, .sportsDrink, .gum]

    

    var inventory: [VendingSelection : VendingItem]

    var amountDeposited: Double = 10.0

    

    required init(inventory: [VendingSelection : VendingItem]) {

        self.inventory = inventory

        

    }

    

    func vend(selection: VendingSelection, quantity: Int) throws {

        

    }

    

    func deposit(_amount: Double) {

    

    }

}

So a lot to this, including previous functions from the VendingMachine protocol. 

Another way of looking at 'get' - read only!

Property Lists and XML

P-lists (property lists) - organises values into named values and lists of values (think arrays!). They are used in IOS and Mac development - used mostly for user preferences but can be used for other purposes. I sense that these could be useful for many things!

XML - this is what the data is converted to. It's a language to help read the lists more easily. 

P-lists only work with primitive data types - not protocols, classes etc. 

So why do all this? Well, it's about getting data from the web to use in an app! Data should not be tightly coupled to the model. It is better to standardise the way the data is used, rather than having it all within the class etc.

Type Methods

There is a chance of an error. There's no point of having an instance of Vending Machine without any data. Objects need to have a single responsibility....

Instance methods - a method used on the instance of a particular type

Type methods - associated with the type itself. Using 'static' before the method name. Calling it directly on the type.

OK that makes sense but why use Type Methods? Or a stand-alone function instead?

From Property List to Dictionary

Type alias - alternative name for an existing type. AnyObject is one of these - for a class type. Any is basically used for anything! 

NSbundle...

The NS is a prefix from the Objective C language - a bundle pack in this case. The bundle is a friend that will help us out! It knows where to look. However as it's Ob C and not Swift, it's not all so compatible. Others have been updated e.g. NSdate is now date. 

And that's plenty for now! Lots of new concepts and plenty to digest here. Using so many protocols is still a bit of a mystery, but the whole get/set aspect has shed some light on why to use them. Overall, positive even though it is conceptually challenging. Looking forward to more tomorrow!