The final challenge of cupcake corner is to move the order details to a struct and wrap the struct in a class.

class SharedOrder: ObservableObject {
    @Published var data = Order()
}

struct Order: Codable {
// all variables previously in the class
}

However, we don't need to write custom encoding for the variables in the struct. This is because all of the data types (Bool, String, Double) inside the struct automatically conform to the conform to the codable protocol.

My questions:

1. Am I understanding the reasoning correctly? (Please correct me if I am not)
2. Why does Paul keep static let types = ["Vanilla", "Strawberry", "Chocolate", "Rainbow"] inside the class?
3. Why does Paul keep the CodingKeys enum inside the struct if we're not using them for a custom encoder?
4. What data types in structs would NOT conform to codable and would require a custom function to encode the data?

Encoding/decoding has been a challenging topic for me. I appreciate any guidance with this!

@iospIT asks:

What data types in structs would NOT conform to codable and would require a custom function to encode the data?

I think in another project you tap locations on a map of places you'd like to visit. These are processed as core locations in the struct, that is they are CLLocation objects with latitude and longitude. While CLLocations are great with maps, they cannot be turned encoded into JSON data. Consequently, you'll see that @twostraws introduces a clever way to use one data type to encode and store, and uses another to use in MapKit.

Please note: As a HWS+ member you get to see @twostraw's challenge solution.

Some Many of us don't have those resources. That is, we can't see how @twostraws wrapped an Order struct within a CakeOrder class. Perhaps this would be a good question in the "members only" forum?

To shed some light on your second question @iosPit, the static types array propery remains in the class so the code in the Picker view ForEach that loads the indices of the types array (in the ContentView file) does not change. If the static types property was moved to the struct, this code would need to change to point to the sturct type instead of the class type.

The same goes for the code in CheckoutView that builds the confirmation message from the decoded return from the reqres.in site.

It took me a minute to figure that one out after moving the static property in the struct and realizing the code would need to change!!

You haven't actually wrapped your struct in a class as the instructions told you to do. To do that, you simply need to move your struct definition inside of the curly braces of the class like this...

class SharedOrder: ObservableObject {
  struct Order: Codable {
    // all variables previously in the class
  }

  @Published var data = Order()
}

Am I understanding the reasoning correctly? (Please correct me if I am not) Yes, that is the reason you do not need to provide custom codable conformance. Because they are all simple data types.

What data types in structs would NOT conform to codable and would require a custom function to encode the data? Any type of struct or class that you create (or that exists in a framework) with a property that is not a simple data type (string, bool, int, double, etc) will not conform to codable on its own. So, if you are working with a struct that has an Image property, you will likely need to manually type code that will tell how to convert the image into data that can be written to memory in order for it to conform to Codable.

Why does Paul keep static let types = ["Vanilla", "Strawberry", "Chocolate", "Rainbow"] inside the class? He likely leaves the array in the class because it isn't really necessary data that needs to be encoded and sent for the order to be processed. It is more of a user interface element that is used to display an understandable label to the user. When you create the struct to hold all of your data about an order, you would want to keep it as simple as possible to encode and send the smallest amount of data that is necessary to know everything that you need to know about an order. In this case, we already have an Int named type to represent the user's selection, and don't need the label to be sent along with it for the order to be processed.

Why does Paul keep the CodingKeys enum inside the struct if we're not using them for a custom encoder? I am not sure about this one, but I don't have access to Paul's finished solution for this project, so I'd have to look at how he did it to get a better idea. I know that you have to used coding keys when working with @Published properties, but I think that the only published property you would need would be in your class. Are you sure that he isn't including the enum in the class and not the struct?