Forem: Chris Myers

Coordinator Setup Changes

Chris Myers — Mon, 13 Dec 2021 14:36:49 +0000

It's been awhile since I set up a coordinator flow in a project. My previous project was well established and once the flow was set up to start the project, it was rarely modified.

For those that are unfamiliar with the Coordinator pattern, there are many blog posts regarding use and set up. These are some of my favorites to look at because I always need a refresher when setting up a new project.

So imagine my surprise when I decide to create a new sample project last week and couldn't find var window: UIWindow? anywhere in the AppDelegate. It's just not there.

The Old AppDelegate

The New AppDelegate

As it turns out, some of the delegate methods associated with the AppDelegate have been migrated over to a new file that comes out of the box when setting up a new project, SceneDelegate when Apple released iOS 13. A wonderful overview of the differences in AppDelegate and SceneDelegate can be found here: Understanding the iOS 13 Scene Delegate

I strongly encourage reading the article, especially about changes to the info.plist, which I won't cover in this post.

The SceneDelegate

The SceneDelegate file now contains the window property.
var window: UIWindow?

Okay, no big deal, I'll set up my coordinator from here.

Still doesn't work

Well, looking at the developer documentation, the AppDelegate still conforms to UIApplicationDelegate, but the delegate methods have changed. It is still the file to use to register for Push Notifications, responding to those notifications, responding to events that target the app itself, but there is also a new area that allows you to configure the app scenes--specifically, connecting to and discarding SceneSessions.

The SceneDelegate file conforms to UISceneWindowDelegate, which itself conforms to UISceneDelegate. The window property is part of the UIWindowSceneDelegate and the main window associated with the scene.

The associated functions in the SceneDelegate are protocol methods from UISceneDelegate. They handle what the app should do if the scene enters the foreground, goes to the background and handle any other life-cycle events occurring within a scene.

But getting back to the window: UIWindow property, there is a new way to initialize this variable. In the past, initializing the window property in the AppDelegate was something like this:

self.window = UIWindow(frame: UIScreen.main.bounds)

You can still set up your window this way. UIScreen.main.bounds still is available. However, with the introduction to Scenes, Apple lets us know that there is a new, preferred way to initialize the UIWindow.

Inside of the delegate method, func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) sits this comment:

Use this method to optionally configure and attach the UIWindow window to the provided UIWindowScene scene.

If using a storyboard, the window property will automatically be initialized and attached to the scene.

This delegate does not imply the connecting scene or session are new (see application:configurationForConnectingSceneSession instead).

So instead of using UIScreen to initialize the window frame, this is what is expected:

Step One: safely unwrap the provided scene: UIScene in the delegate method and cast it as a UIWindowScene.
Step Two: Initialize the window property using the unwrapped UIWindowScene.
Step Three: set the windowScene property now found in a UIWindow with the unwrapped windowScene from step one.

Step three is vitally important, because if this step is missed, you'll just get a blank screen when running the app.

In code, this looks like the following:

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = (scene as? UIWindowScene) else { return }
    let uiWindow = UIWindow(frame: windowScene.coordinateSpace.bounds)
    self.window = uiWindow
    self.window?.windowScene = windowScene
}

Thus far, I haven't mentioned anything about the actual coordinator. I wanted to separate the two, because once the window initialization is set up, the coordinator piece is pretty straight forward.

First, start with a protocol... :)

protocol Coordinator {
    func start()
}

Next, create an application coordinator conforming to the protocol. (I'm using the Ray Wenderlich blog post I linked above as my sample AppCoordinator)

class AppCoordinator: Coordinator {
    let window: UIWindow
    let rootViewController: UINavigationController

    init(_ window: UIWindow) {
    self.window = window
    rootViewController = UINavigationController()

    let mainVC = MainViewController()
    rootViewController.pushViewController(mainVC, animated: true)
    }

    func start() {
    window.rootViewController = rootViewController
    window.makeKeyAndVisible()
    }
}

After that, it's just a matter of modifying the previously mentioned delegate method in the SceneDelegate.

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = (scene as? UIWindowScene) else { return }
    let uiWindow = UIWindow(frame: windowScene.coordinateSpace.bounds)
    self.window = uiWindow
    self.window?.windowScene = windowScene

    let appCoordinator = AppCoordinator(uiWindow)
    self.appCoordinator = appCoordinator
    appCoordinator.start()
}

I chose to set up my app without using storyboards. Just note, to remove references to the storyboard, the main storyboard can be found in the SceneConfiguration in the plist. Just deleting from the Main Interface in the App Target isn't enough.

You can absolutely use coordinators with a storyboard (See Paul Hudson's article linked above) if you so choose.

Making sense of 2D arrays

Chris Myers — Tue, 29 Jun 2021 23:48:46 +0000

Arrays.

They are the data structure I use most when programming in Swift. Easy to insert, easy to loop through, and sometimes, I can even remember how to successfully map through one and transform values.

let lonesomeDoveCharacters = ["Gus", "Woodrow", "Deets"]
lonesomeDoveCharacters.append("Jake")

Accessing the values in an array is just a matter of using a for-in loop...

for character in lonesomeDoveCharacters {
    print("Character name: \(character)")
}

However, when an extra set of braces is thrown in there to create a two dimensional array, my brain just shuts down.

[
 ["Gus", "Woodrow", "Deets"], 
 ["Jake", "Laurie", "Newt"], 
 ["July", "Roscoe", "Clara"]
]

I've written in the past how to use flatMap to reduce nested arrays, but sometimes, that isn't what is required of us. Sometimes, we need to gain access to data inside multi-dimensional arrays without modifying the existing structure.

Lately I've struggled to get my brain going in the mornings. To combat this, I've started working problems on the HackerRank. The first few days were pretty straight forward and didn't require much though to write a working solution that also passed all the test cases. Then, I came across this one:

Diagonal Difference

The basics of the problem are that you have a square matrix and they want you to find the absolute value of the difference in the sum of the diagonals.

1 2 3
4 5 6
9 8 9

The diagonal sums are (1 + 5 + 9) and (3 + 5 + 9). Then the want the absolute value of the difference between those sums or |15 - 17| which would be 2.

My first mistake when thinking about this problem was trying to collect all the information I needed in one pass. My second mistake was not immediately thinking I needed access to the index values of the arrays (both the outside array that holds all the information and each individual array sitting inside of it.)

Admittedly, I got pretty discouraged. I was trying to think this through in my head and anytime I attempt to solve a problem this way, frustration sets in or mistakes happen because I can't "see" the solution.

Additionally, I chose to just focus on one aspect of the problem. How would I access the values of the forward diagonal (1, 5, 9). This helped me with problem #1. Break up the problem into a subsets of problems. Now, I will be the first to admit I didn't know what all the subsets would be, but I knew this was one of them.

The first thing I did was pull out some paper and a pencil and started writing down what was happening during each iteration of the loop.

let twoD = [[1,2,3], [4,5,6], [9,8,9]]

Position 0 in twoD is the array [1, 2, 3]. Let's call this subArray1.

Position 1 in twoD is the array [4, 5, 6] Let's call this subArray2.

Position 2 in twoD is the array [9, 8, 9] Let's call this subArray3.

Interesting. The index of each object in the twoD array is also the index of the value I need inside each object (subArray).

Once I diagrammed that out (and bought a whiteboard off Amazon so I wouldn't have to use paper as often), I realized that an enumerated for-in loop would give me access to the objects (subArrays) as well as the index value of each object (subArray). So I could write something like this:

func diagonalDifference(from arr: [[Int]]) -> Int {
    var frontWardsSum = 0
    for (index, subArray) in arr.enumerated() {
        frontWardsSum += subArray[index]
    }
    return frontWardsSum
}

The values going backward were still not clear and I had to talk out loud.

"I want to go to the end of the first subArray, grab the value and add it to an existing sum. I want to go to the end of the second subArray minus one index value, grab that value and add it to the existing sum. I want to go to the end of the third subArray minus two index values, grab that value and add it to the existing sum."

As you can see, a pattern emerges. The trick is to write code to tell it just that.

Step One: find the end of each subArray object.
Step Two: figure how many places back from the end to travel.
Step Three: subtract places necessary from endIndex
Step Four: grab the value using appropriate index.
Step Three: Add it to an existing sum.

I decided to put this in it's own loop so I can pay attention to just what is happening. I wound up realizing later I could refactor everything into just one loop instead of using two separate ones in my function.

func diagonalDifference(from arr: [[Int]]) -> Int {
    // to obtain frontwards diagonal value
    var frontwardsSum = 0
    for (index, subArray) in arr.enumerated() {
        frontWardsSum += subArray[index]
    }

    // to obtain backwards diagonal value
    var backwardsSum = 0
    for (index, subArray) in arr.enumerated() {
        let endPosition = subArray.count - 1
        backwardsSum += subArray[endPosition - index]
    }

    let absoluteValue = abs(frontwardsSum - backwardsSum)
    return absoluteValue
}

endPosition had to be reduced by 1 on account of arrays being zero-based indexing, so if the array has three objects (as these do), those positions are 0, 1, and 2 rather than 1, 2, and 3.

From there, after drawing it out that the first object I didn't want to subtract anything because I was already at the end position. Fortunately, the index value is 0 because it is the first object & position in the twoD array so endPosition minus 0 is still endPosition. As I work to the next object, it's position is 1 and the object value I need is endPosition minus 1 and so on.

Finally, I could take the absolute value of the two sums by using Swift's built in abs(_:) function.

I ran the test in hacker rank and it passed, but I realized that what was being done in two loops, could all be combined in one, so I cleaned everything up and submitted the following:

func diagonalDifference(from arr: [[Int]]) -> Int {
    var frontwardsSum = 0
    var backwardsSum = 0
    for (index, subArray) in arr.enumerated() {
        // to obtain frontwards diagonal value
        frontWardsSum += subArray[index]

        // to obtain backwards diagonal value
        let endPosition = subArray.count - 1
        backwardsSum += subArray[endPosition - index]
    }
    let absDifference = abs(frontwardsSum - backwardsSum)
    return absDifference
}

Perhaps there are people that can do all of this in their head. Or maybe they work with multi-dimensional arrays often enough, that accessing the necessary info has become second nature. I know for me, though, that pencil and paper, talking out loud, and trying to keep the steps small is what allowed me to work through this challenge. Moreover, I know you hear more seasoned developers say "start with whatever approach makes sense first. You can optimize it later." It really is true. I had three or four pages of scrap paper just doodling what would happen at each iteration--which is why I bought a whiteboard for my office for future challenges.

Lastly, for those of you who struggle with problems like this, you are not alone. I wanted to give up several time due to frustration. However, when I took the keyboard away and started putting pencil to paper, I was able to slowly talk myself through the problem without focusing on the blinking cursor on my screen waiting on my solution.

Learning from my daughter

Chris Myers — Wed, 10 Mar 2021 01:39:49 +0000

Late last summer, my youngest daughter decided she wanted to swim summer league next summer. I had just taught her to dive and she was getting comfortable in the pool. So we look around and find a local swim team that offers a swim school (that followed COVID protocols) and we signed her up. Two times a week, for 30 minutes per practice, she learned the four strokes of competition swimming.

Swimming was the one sport I was pretty decent at growing up, and she has seemingly inherited similar abilities because after six months, she was asked to be evaluated for the regular team. Last Friday, she showed up, swam one length of the pool in each stroke and was told she was a prime candidate for the age group 3 team, and she could start the following week.

So Monday's practice comes around and there are more swimmers, more structure, and more instruction thrown at her than she had before. I watched from outside the building as she was mentally trying to keep her head above water. Circle swimming, kicking drills, flip turns, breathing, dryland exercises--all of it new. I was not sure how she'd handle all this unfamiliarity and I could tell she was getting frustrated with not knowing what she was supposed to be doing right from the off. Her coach would remind her of the drill, send her on her way and continue to remind her until she got it right.

I walked away after 15 minutes for fear that my presence might be an additional pressure and I went and sat in my truck. I came back for the last 15 minutes of practice and saw, that as exhausted she was (practice is an hour), she appeared to be more confident in the water. There wasn't this look of uncertainty and tentativeness that I had seen earlier. She embraced the unfamiliarity, trudged along while getting feedback on where to improve and though utterly exhausted by the end of practice, proud of herself for being able to complete what she called "real practice".

This lesson hit home for me as over the last few weeks at work, I felt like I haven't been getting much done. I've had to focus on tasks where I don't feel comfortable with what I'm doing and I'm not all that sure that my solutions are going to work. But watching her practice reminded me that my console is my coach, pointing out my errors, trying to nudge me in the right direction, and that if I continue to listen, I will eventually feel more comfortable in the task assigned. So like my daughter, I'm trying to remind myself to jump in, break some things and get the feedback I need to learn and grow. It is rewarding to see my daughter learn these lessons, and so good for me to see problem solving through the eyes of a child.

What I learned last week - 30 December 2019

Chris Myers — Mon, 30 Dec 2019 16:11:02 +0000

I didn't.

Not a thing.

I worked last Monday to finish up what I had been working on the previous Friday.

I took the rest of the week off.

I celebrated the holidays with my family.

I took a short vacation to Oregon and spent as much of it outdoors as possible.

I didn't bring my laptop.

I used my phone for taking pictures and uploading to social media...and checking Liverpool football scores.

I even went 5 days without working out, trying to let my body rest. On the 6th day, I ran and then went hiking.

It was glorious.

I urge everyone to take breaks from your career. Burnout is all too common and this notion that we always have to keep up with all the latest going-ons in our profession is the fastest way I know to burnout. Take some time for yourself. Make sure you have hobbies or interests outside of software development. It will always be there.

Multnomah Falls, Oregon

What I learned last week - 23 Dec 2019

Chris Myers — Mon, 23 Dec 2019 18:33:57 +0000

So this week was more organizing, filtering, and using of data from the model I mentioned last week. A couple of updates...

Update from last week

First, the RateDetail array that I created by flattening the arrays it was nested within was a good first start. In the end, I wound up creating a dictionary with the array of rate detail as the value, and the schedule it was related to as the key so that I could provide my view with the necessary information. In order to do that, I need the schedule name at one level of the nested array and then build the array of RateDetails in the very bottom or last level.

I wound up going into my UtilitySeason model and creating a variable called seasonRatesDictionary which is a dictionary with a String for the key and Array<RateDetail> for the value. The rate details sit inside the another model called TimePeriods, which just happens to be a property within UtilitySeason

struct UtilitySeason {
    let seasonID: String
    let timePeriods: [TimePeriod]
}
~~~{% endraw %}

Inside of {% raw %}`TimePeriod`{% endraw %} sits the {% raw %}`TimeOfUse`{% endraw %} property, which is where the information needed to build the instance of {% raw %}`RateDetail`{% endraw %} sits.{% raw %}

~~~swift
struct TimePeriod {
    let periodName: String
    let tou: [TimeOfUse]
}
~~~{% endraw %}

With this information, I can build my dictionary.{% raw %}

~~~swift
var seasonRatesDictionary: [String: [RateDetail]] {
    let tempDict = timePeriods.reduce(into: [:]) { (dict, timePeriod) in
        dict[timePeriod.periodName] = timePeriod.tou
    }

    let periodsDictionary = tempDict.mapValues { (touArray) -> [RateDetail] in
        touArray.map { (touInstance) -> RateDetail in
            RateDetail(rate: touInstance.touRate,
                       startTime: touInstance.touStartTimeFormatted,
                       endTime: touInstance.touEndTimeFormatted)
        }
    }

    return periodsDictionary
}
~~~{% endraw %}

As it turns out, {% raw %}`reduce`{% endraw %}, which I always associated with just adding stuff together since that's the default example you see in explanations of it, can be used to build a dictionary. The first parameter in the closure refers to the empty dictionary that I created in the {% raw %}`into: [:]`{% endraw %} part of the reduce function. The second parameter refers to each timePeriod inside the {% raw %}`timePeriods`{% endraw %} property of my {% raw %}`UtilitySeason`{% endraw %} model. I'm building a temporary dictionary first to set all the keys in the dictionary with the value of its respective {% raw %}`TimeOfUse`{% endraw %} array, and then make use of the built in {% raw %}`mapValues`{% endraw %} function associated with Collection-conforming types to go into that temporary dictionary and create my {% raw %}`RateDetails`{% endraw %} array for the returning dictionary. 

I chose to build this in the model because having to dive a few layers in to extract values out, in my opinion, should be the work of the model. It has layers of information, and I think should be able to give me what I need so that I don't have to write some function to do it and busy up my ViewController.

####New Learning'####
However, what I learned this week that really blew my mind was something called composition.

Here is what I was trying to do...{% raw %}

~~~swift
for dict in arrayOfScheduleDictionaries {
    request.addBodyPairs(dict)
}
~~~{% endraw %}

I have to send some data out in a POST request. It just happened to be the dictionary I was building earlier. The framework we use to do this allows us to append dictionaries to the body of the POST using {% raw %}`addBodPairs`{% endraw %}

Now I know the for loop above works, but since I'm trying to incorporate a more functional approach to my code, I settled on this...{% raw %}

~~~swift
let _ = arrayOfScheduleDictionaries.map { request.addBodyPairs($0) }
~~~{% endraw %}

It isn't very often I have an unassigned variable (i.e. {% raw %}`let _ `{% endraw %}) so I turned to Slack and asked if there was a better way of writing this.

While it might be personal preference, the code above does work, but the overwhelming opinion was that "if you are writing {% raw %}`let _` on the left side of your `map`, then that should be a hint that `map` isn't the right tool for the job." Instead, it was suggested that I try {% raw %}`forEach`{% endraw %}.{% raw %}

~~~swift
arrayOfScheduleDictionaries.forEach { request.addBodyPairs($0) }
~~~{% endraw %}

It does what I want it to do, add each dictionary to the network request I am making, without resorting to using {% raw %}`_`{% endraw %} for my unassigned variable.

Now I was ready to go and make use of this new found knowledge, but another poster mentioned that it can be taken a step further, by calling it "point-free". I asked what this was and was told that the tl;dr version is that it avoids creating another function to call a function.

A slightly more in-depth version is that in my example above, point-free means I don't have to reference {% raw %}`$0`{% endraw %} in the {% raw %}`addBodyPairs`{% endraw %} function.

I was pointed to an article about point-free and the opening sentence states: 

>It is very common for functional programmers to write functions as a composition of other functions, never mentioning the actual arguments they will be applied to.

I will admit that this goes beyond my knowledge and I still don't really understand it. But I do know that Object-oriented programming uses composition with classes, and in Swift's case, structs and enums. Protocols are a good example. In a protocol, I don't really define the implementation, I just define the name, parameters and return value of the function that the object conforming to the protocol must implement. 

In this case, I gather the same is true of the functions. {% raw %}`forEach`{% endraw %} wants a function of the type {% raw %}`(T) -> Void`{% endraw %}. It doesn't care what {% raw %}`T`{% endraw %} is, it just wants to accept that function type.

Coincidentally, {% raw %}`addBodyPairs`{% endraw %} is a function of type {% raw %}`(T) -> Void`{% endraw %}. So I can use it as a parameter in the {% raw %}`forEach`{% endraw %} function. 

Admittedly, I still didn't understand how addBodyPairs was getting a reference to the dictionary in {% raw %}`arrayOfScheduleDictionaries`{% endraw %} because reading a wikipedia post on composition just confused me further. 

Fortunately, in another time, I used to be a high school economics, as well as computer programming teacher, and I was constantly telling my students that the internet will help them find answers. My favorite recommendation was [Khan Academy](https:www.khanacademy.org). The videos are short, descriptive, and come chock full of examples and sample problems. So I turned to the video to explain mathematical composition to me so that I might understand programming composition better.

[Khan Academy Video on Composition](https://bit.ly/2ZkesqI)

It helped. I still need to think about it more to see if I can explain it, and come up with a couple examples on my own, but it appears that the functions keep passing themselves back to the left to the previous function until there is a value to use. In our case, it's each dictionary in the {% raw %}`forEach`{% endraw %}. From there it can evaluate. 

In the end, the call ended up like this:{% raw %}

~~~swift
arrayOfScheduleDictionaries.forEach(request.addBodyPairs)
~~~{% endraw %}

That's a lot to write about just to be able to remove {% raw %}`$0`{% endraw %} but as I said before, this blog is document what I'm learning--even if I don't have the clearest understanding of it yet.

What I learned last week - 16 December 2019

Chris Myers — Mon, 16 Dec 2019 18:25:34 +0000

Introduction

When I first started learning iOS development, I blogged weekly about what I was learning. Once I completed my bootcamp, I fell away from it as I was just trying to stay afloat at work.

However, blogging helped me retain a lot of information, and lately, I feel like I figure something out, feel happy, but then promptly forget it and a few weeks later, have to do the same thing again, and try and relearn. So this is my attempt to pick the writing habit back up. I'll just write about a challenge, or learning opportunity I faced and how I went about solving it, or in same instances, re-explain how it was explained to me--if for nothing else, but to reinforce the concept.

Challenge - Nested Data

A current feature I'm working on at work is to display a rate schedule for plumbers to view when installing a water heater. This schedule is a cost structure of the cheapest and most expensive times to heat water throughout the day, and their associated rate per kilowatt-hour (kWh).

The data we receive with the rates, times, seasons, etc... is...involved. There can be multiple schedules. Within each schedule, there can be multiple seasons. Each season has a two time periods. Within the time period, there can be anywhere from 1 - 5 rates and 1 - 5 times.

I've pared down the actual data into what I'm using just for this blog post, but below is a visual representation of how deeply nested the data coming back is.

struct UtilityScheduleResponse {
    let schedule: [UtilitySchedule]
}
struct UtilitySchedule {
    let scheduleID: String
    let scheduleName: String
    let seasons: [UtilitySeason]
}

struct UtilitySeason {
    let seasonID: String
    let touSeason: String
    let seasonName: String
    let seasonDescription: String
    let timePeriods: [TimePeriod]
}

struct TimePeriod {
    let periodID: String
    let periodName: String
    let periodDescription: String
    let tou: [TimeOfUse]
}

struct TimeOfUse {
    let touID: String
    let touName: String
    let touStartTimeFormatted: String
    let touEndTimeFormatted: String
    let touRate: String
}

However, for the purposes of displaying all rates and times, there is just a few items of data I need to throw into the RateScheduleCell.

So I started to dive into the data into the first way that popped into my head...Nested loops.

Attempt 1

func nestedScheduleDetailsExample(for schedule: UtilitySchedule) -> [RateDetail] {
    var rateDetailsArray: [RateDetail] = []
    for season in schedule.seasons {
        for timePeriod in season.timePeriods {
            for timeOfUse in timePeriod.tou {
                let rateDetail = RateDetail(rate: timeOfUse.touRate,
                                            startTime: timeOfUse.touStartTimeFormatted,
                                            endTime: timeOfUse.touEndTimeFormatted)
                rateDetailsArray.append(rateDetail)

            }
        }
    }
    return rateDetailsArray
}

Hmmm...okay, it works, but I know I need to work on functional programming and there has to be a way to do this functionally.

Functional Attempt 1

func functionalAttempt1(for schedule: UtilitySchedule) -> [RateDetail] {
    var rateDetailsArray: [RateDetail] = []
    for season in schedule.seasons {
        for timePeriod in season.timePeriods {
            rateDetailsArray = timePeriod.tou.map({ (tou) -> RateDetail in
                return RateDetail(rate: tou.touRate,
                                  startTime: tou.touStartTimeFormatted,
                                  endTime: tou.touEndTimeFormatted)
            })
        }
    }
    return rateDetailsArray
}

So this worked...sort of. All I ever got was the last rate detail in the json. This is because I failed to realized that after the first iteration of timePeriod in season.timePeriods, the rateDetailsArray would be overwritten with the next timePeriod. So while the map was working to turn the timePeriod.tou array into an array of RateDetail objects, it was removing the previously created ones on each iteration in the timePeriod for-in loop.

Okay, so now I need an array of timePeriods with its own array of RateDetail objects. So I rewrote the function.

FunctionalAttempt 2

func functionalAttempt2(for schedule: UtilitySchedule) -> [[RateDetail]] {
    var rateDetailsArray: [[RateDetail]] = [[]]
    for season in schedule.seasons {
        rateDetailsArray = season.timePeriods.map { period in
             period.tou.map { timeOfUse in
                RateDetail(rate: timeOfUse.touRate,
                           startTime: timeOfUse.touStartTimeFormatted,
                           endTime: timeOfUse.touEndTimeFormatted)

            }
        }
    }
    return rateDetailsArray
}

But I didn't really wanted a nested array of objects. I just wanted an array of all the RateDetails. I was stuck. So I turned to the Slack boards to ask for help in making my function more...well, functional...but also to have a single array.

Almost immediately, I got several responses. I guess I knew this at one point and forgot, but flatMap will flatten an array, meaning taking a nested array and concatenating the result into one array. Mostly, when I thought of flatMap I remember it used to be a way to return an array that excluded nil values.

When Swift 4 was released, compactMap took over that role and I guess I thought 'flatMap` had been deprecated.

compactMap

Returns an array containing the non-nil results of calling the given transformation with each element of this sequence. Use this method to receive an array of non-optional values when your transformation produces an optional value.

flatMap

Returns an array containing the concatenated results of calling the given transformation with each element of this sequence. Use this method to receive a single-level collection when your transformation produces a sequence or collection for each element.

Turns out, flatMap was deprecated for the non-nil role, but is still alive and kicking doing what it's name implies...flattening an array.

For me, just being told to use something often leads to paralysis. I have an answer, but I'm not sure how to use it. Thankfully, everyone I talked to on Slack gave some examples of the use of flatMap.

Functional Attempt 3

func functionalAttempt3(for schedule: UtilitySchedule) -> [RateDetail] {
    let rateDetails: [RateDetail] = schedule.seasons
        .flatMap { (utilitySeason) -> [TimePeriod] in utilitySeason.timePeriods }
        .flatMap { (timePeriod) -> [TimeOfUse] in timePeriod.tou }
        .map { (tou) -> RateDetail in RateDetail(rate: tou.touRate,
                                                 startTime: tou.touStartTimeFormatted,
                                                 endTime: tou.touEndTimeFormatted)
    }

    return rateDetails
}

Okay, so there is a lot to unpack here. rateDetails has a type of Array<RateDetail>, so the final part of that code better be creating instances of RateDetail and appending it to the array. Everything leading up to it is diving through the UtilitySchedule to find the TimeOfUse array which contains instance of TimeOfUse. Each instance is then used to create a RateDetail.

I've purposely left the longer notation for map and flatMap because, for me, I prefer the readability. I know what kind of object each closure is taking in (i.e UtilitySeason, TimePeriod, TimeOfUse), and what the expected output at the end of each flatMap or map call should create (i.e. Array<TimePeriod>, Array<TimeOfUse>, Array<RateDetail>. If I had not used flatMap, I'd have something like:

Array<UtilitySeason<Array<TimePeriod<Array<TimeOfUseArray<Array<RateDetail>>>>

or to see it visually another way,

[[[[RateDetail]]]]]

I think we can agree a completely mapped version is pretty ugly and unwieldy to navigate through.

By using flatMap on the first three arrays (UtilitySeason, TimePeriod, and TimeOfUse), I'm able to flatten out the entire thing and just map the part I want to transform into one single array of RateDetail. This makes setting my tableView cell much easier and less error prone because lord knows trying to set the prices with something like

cell.weekdayPrice.text = utilitySchedule[0][0][3][1].rate

would have been just asking for disaster.

I am so grateful for the help on Slack. Every time I've ever asked a question, it's always been met with genuine interest in helping me. I've never been belittled for not knowing something, or ridiculed for asking what may seem like a "simple" problem. Everyone gets stuck on things sometimes, or has a hard time seeing through an answer. In the end, I refactored my models some so I would not have to write this function in the ViewController, but I think I need to continue to remind myself to START SOMEWHERE! I can always make it prettier later...but at the very least, make an attempt to solve it rather than trying to do it in my head and hoping to write the perfect algorithm on the first try.

Update: I also want to thank Donny Wals @donnywals for editing this for me. He gave me some helpful insight and was a wonderful sounding board.

Forgetting to read before writing code

Chris Myers — Fri, 05 Jul 2019 18:46:01 +0000

Liquid syntax error: 'raw' tag was never closed

My transition to Codable

Chris Myers — Sun, 12 May 2019 20:39:18 +0000

Two or three weeks into my iOS bootcamp, I saw something that looked like this...

{
    "latitude": 37.8267,
    "longitude": -122.4233,
    "timezone": "America/Los_Angeles",
    "currently": {
        "time": 1557685055,
        "summary": "Mostly Cloudy",
        "icon": "partly-cloudy-day",
        "nearestStormDistance": 0,
        "precipIntensity": 0,
        "precipProbability": 0,
        "temperature": 53.72,
        "apparentTemperature": 53.72,
        "dewPoint": 50.31,
        "humidity": 0.88,
        "pressure": 1016.37,
        "windSpeed": 6.11,
        "windGust": 10.03,
        "windBearing": 260,
        "cloudCover": 0.9,
        "uvIndex": 4,
        "visibility": 10,
        "ozone": 351.5
    }
}
~~~{% endraw %}
I remember how magical it felt when I was taught how to parse web data (JSON) and use it in meaningful objects in my code. Hundreds of lines of data, parsed down into usually 5-7 pieces of useful data relevant to what I was doing.  The first time was some sample JSON that our instructor had given us, the second time was creating JSON of our own and grouping it together. Finally, we started getting JSON from the web. DarkSkys, Spotify, Google APIs, we were consuming their data and making it useful to our own needs. Thousands of pieces of data bending their will to my fingertips--obey me puny pieces of binary!

The process we were taught was to create a model with the relevant data you want, then write some code to take the data that comes in from a network call, turn it into a dictionary, and extract the values from the necessary keys. Then inject that data into your model instance. My very first attempt looked like this...

##### Step One: Create the model
I wanted a few things to show. Weather summary, temperature, chance of rain, basically every piece of data a farmer with crops in the field might find relevant. (I'm from the South. Weather is ALWAYS a topic of conversation!). I was shown a neat trick where I could create a custom initializer that accepted a dictionary and parse the data right there in the model. I was indeed feeling good about my skills.{% raw %}

~~~swift
class WeatherData: NSObject {

    var latitude: Double = 0.0
    var longitude: Double = 0.0
    var summaryDescription : String = ""
    var icon : String = ""
    var precipProbability : Double = 0.0
    var temperature : Double = 0.0
    var humidity : Double = 0.0
    var windSpeed : Double = 0.0

    override init() {
        super.init()

        self.latitude = 0.0
        self.longitude = 0.0
        self.summaryDescription = ""
        self.icon = ""
        self.precipProbability = 0.0
        self.temperature = 0.0
        self.humidity = 0.0
        self.windSpeed = 0.0
    }

    init(dict: [String: AnyObject]) {
        super.init()

        if let latitude = dict["latitude"] as? Double {
            self.latitude = latitude
        }

        if let longitude = dict["longitude"] as? Double {
            self.latitude = latitude
        }

        if let currentlyDict = dict["currently"] as? [String: AnyObject] {
            print(currentlyDict)

        if let summary = currentlyDict["summary"] as? String {
            self.summaryDescription = summary

        } else {
            print("I could not parse summary")
        }

        if let icon = currentlyDict["icon"] as? String {
            self.icon = icon

        } else {
            print("I could not parse the icon")
        }

        if let precipitation = currentlyDict["precipProbability"] as? Double {
            self.precipProbability = precipitation

        } else {
            print("I could not parse precipitation")
        }

        if let temp = currentlyDict["temperature"] as? Double {
            self.temperature = temp

        } else {
            print("I could not parse the temperature")
        }

        if let humid = currentlyDict["humidity"] as? Double {
            self.humidity = humid

        } else {
            print("I could not parse humidity")
        }

        if let wind = currentlyDict["windSpeed"] as? Double {
            self.windSpeed = wind

        } else {
            print("I could not parse speed")
        }
      }
   }

}  
~~~{% endraw %}

#####Step Two: Take data and turn it into a dictionary
I'd then make a network call, and if all went according to plan, would take raw data and process it with a handle little function...{% raw %}

~~~swift
func parseJSON(_ data: Data?) -> [String: AnyObject]? {

        var theDictionary : [String: AnyObject]? = nil

        if let data = data {
            do {
                if let jsonDictionary = try JSONSerialization.jsonObject(with: data, options: []) as? [String: AnyObject] {

                    theDictionary = jsonDictionary
                    //print(jsonDictionary)

                } else {
                    print("Could not parse jsonDictionary")
                }
            } catch {
            }
        } else {
            print("Could not unwrap data")
        }
        return theDictionary
    }
~~~{% endraw %}

#####Step Three: Call for the data, parse, and inject into the model
Finally, somewhere in my completion handler to the network call, I wrote some code where I take the raw data that comes back, use my handy {% raw %}`parseJSON`{% endraw %} to serialize it and turn it into a dictionary, and then inject it into my {% raw %}`WeatherData`{% endraw %} model using my custom initializer.{% raw %} 

~~~swift
// ...somehwere in the network call...

                if let jsonDictionary = self.parseJSON(data) {
                    print(jsonDictionary)                

                        let theWeatherData = WeatherData(dict: jsonDictionary)

                        DispatchQueue.main.async(execute: {
                            self.delegate?.passWeather(theWeatherData)


                        })

                        print(theWeatherData)
                    }

                } else {
                    print("I could not parse the dictionary")
                }
~~~{% endraw %}

The process got pretty involved pretty quickly. If you had an array or dictionary of information and within that more arrays of dictionaries, the parsing strategy got incredibly complex. It wasn't uncommon for me to write down on paper how I needed to get into deeper levels of nested information. It reminds me of the old Atari game "Dig Dug". 

When Codable came out a couple years later, I was impressed but never had much need to use it. Scratch that. I was too lazy to bother learning. At the time, my job didn't require much pulling down of data, and what little there was I just parsed the way I knew how--{% raw %}`JSONSerialization`{% endraw %}.

A few months later, I had to send some data back and I thought, "hey, maybe now is a good time to update my knowledge base here." My data wasn't particularly complex--a few values, nor did it have anything nested, but you know, start small.

So I watched a couple videos, read some blogs on how to do it, and away I went. For what I needed, it worked great, was easy to read by my fellow developers in our research lab and I felt quite proud of myself. 

But had I really learned anything? No. I learned how to take some code someone else  wrote and fit it into what I needed, which, don't get me wrong, is a good first step at learning something. I've never been good at taking something abstract and making sense of it. I need to see it in action, play with it and then, maybe after a few months of using, start to make sense of what I'm doing. 

Last year I left the research lab I was working in and went to work in the private sector. It was here that I learned just how often big production apps use network calls to send and receive information. My old method of using NSObject and writing some parsing initializer got way too convoluted. I decided to make use of the benefits of Codable and haven't really looked back since. I went through some trial and error, but the place I started was with my original parsing project from my bootcamp. Taking weather data and using Codable to process it.

#####Step One: How do I use Codable again?!
By this point in my development career, [Apple Docs](https://developer.apple.com/documentation/foundation/archives_and_serialization/encoding_and_decoding_custom_types) didn't intimidate me as much as they used to. My thinking was that if I needed to really understand how to do this, I should get use to seeing Apple's intentions on how to use it. As it turns out, Apple had really good documentation and an example to follow and it managed to make the code above look incredibly simple. 

What I needed to do, was create a struct with the values I wanted...{% raw %}

~~~swift
struct WeatherData {
    var latitude: Double
    var longitude: Double

    var summaryDescription: String
    var icon: String
    var precipProbability
    var temperature: Double
    var humidity: Double
    var windspeed: Double
}
~~~{% endraw %}

Now the problem is that while latitude and longitude are at what I call the "top-level" of the json coming in, the remainder of the items are in a nested dictionary called {% raw %}`currently`{% endraw %}. And while I could again go the way I did earlier with diving into a nested dictionary and pulling out relevant information, I do run into the issue where I may misspell something by making key stringly-typed. Apple helps us out with this by the use of CodingKeys.{% raw %} 

~~~swift
// appending to my WeatherData model...

enum CodingKeys: String, CodingKey {
        case latitude, longitude, currently // the currently case is necessary to go down one level to get into summary, temperature, etc...
    }
~~~{% endraw %}


CodingKeys allow us to create an enum with the dictionary keys as the cases. Since the enum is a string, it allows us to edit the raw value of the case to match whatever the actual json dictionary key is. For instance, the word {% raw %}`windspeed`{% endraw %} is one word. I decide I want my coding key to be {% raw %}`windspeed`{% endraw %}. However when I look back into the json, the key they use is 'windSpeed{% raw %}`. I can edit the enum case to match the actual json key...

~~~swift
    enum CodingKeys: String, CodingKey {
        case latitude, longitude, currently
    }

    enum CurrentlyKeys: String, CodingKey {
        case summary, icon, precipProbability, temperature, humidity, windspeed = "windSpeed"
    }

You will notice that I have two sets of enums. CodingKeys is my data at the top level of the json. CurrentlyKeys is data within the currently case.

At present, none of this will work if we try to decode. Simply because with haven't asked our model to conform to the Codable protocol. Codable is simply a type alias for both Encodable and Decodable protocols. If you're only receiving information, you can choose to implement on the Decodable protocol. If you're sending, Encodable, or if you think you might need both, conform to Codable. Since I'm only receiving information, I'll stick with using Decodable.

If you look at the bottom of Apple's documents, it will offer some insight into decoding manually, specifically if not all your information is on the same level (i.e. nested). Instead of making the struct conform to Decodable, it uses an extension off of the struct to write the required decodable initializer. I've personally preferred this way because you never know when you might want to let your struct be able to use it's member-wise initializer somewhere down the line.

extension WeatherData: Decodable {
    init(from decoder: Decoder) throws {
        let values = try decoder.container(keyedBy: CodingKeys.self)
        latitude = try values.decode(Double.self, forKey: .latitude)
        longitude = try values.decode(Double.self, forKey: .longitude)

        let currently = try values.nestedContainer(keyedBy: CurrentlyKeys.self, forKey: .currently)
        summaryDescription = try currently.decode(String.self, forKey: .summary)
        icon = try currently.decode(String.self, forKey: .icon)
        precipProbability = try currently.decode(Double.self, forKey: .precipProbability)
        temperature = try currently.decode(Double.self, forKey: .temperature)
        humidity = try currently.decode(Double.self, forKey: .humidity)
        windspeed = try currently.decode(Double.self, forKey: .windspeed)

    }
}

So what is happening here?

According to the Apple Docs regarding container the data coming in is stored in a container, and can be referenced by the corresponding CodingKey. So let values... is asking the data to be sorted into the three CodingKeys categories we specified earlier. From there we can easily parse out latitude and longitude giving their type and the CodingKey assigned to it earlier.

However, all of the remaining values sit inside the currently dictionary, which is is also a container. So Decodable has another method called nestedContainer which works much like container. It just needs a set of coding keys to use to sort out the information inside of it. So once I establish that currently is a nested container using the CurrentlyKeys, I can go in and parse the remaining values in my model. At the end, we have something along the lines of this:

struct WeatherData {
    var latitude: Double
    var longitude: Double

    var summaryDescription: String
    var icon: String
    var precipProbability: Double
    var temperature: Double
    var humidity: Double
    var windspeed: Double

    enum CodingKeys: String, CodingKey {
        case latitude, longitude, currently
    }

    enum CurrentlyKeys: String, CodingKey {
        case summary, icon, precipProbability, temperature, humidity, windspeed = "windSpeed"
    }
}

extension WeatherData: Decodable {
    init(from decoder: Decoder) throws {
        let values = try decoder.container(keyedBy: CodingKeys.self)
        latitude = try values.decode(Double.self, forKey: .latitude)
        longitude = try values.decode(Double.self, forKey: .longitude)

        let currently = try values.nestedContainer(keyedBy: CurrentlyKeys.self, forKey: .currently)
        summaryDescription = try currently.decode(String.self, forKey: .summary)
        icon = try currently.decode(String.self, forKey: .icon)
        precipProbability = try currently.decode(Double.self, forKey: .precipProbability)
        temperature = try currently.decode(Double.self, forKey: .temperature)
        humidity = try currently.decode(Double.self, forKey: .humidity)
        windspeed = try currently.decode(Double.self, forKey: .windspeed)

    }
}

After that, it's a matter of taking the json data, converting it and using our Decoder


let weatherJson = """
{
"latitude": 37.8267,
"longitude": -122.4233,
"timezone": "America/Los_Angeles",
"currently": {
"time": 1557685055,
"summary": "Mostly Cloudy",
"icon": "partly-cloudy-day",
"nearestStormDistance": 0,
"precipIntensity": 0,
"precipProbability": 0,
"temperature": 53.72,
"apparentTemperature": 53.72,
"dewPoint": 50.31,
"humidity": 0.88,
"pressure": 1016.37,
"windSpeed": 6.11,
"windGust": 10.03,
"windBearing": 260,
"cloudCover": 0.9,
"uvIndex": 4,
"visibility": 10,
"ozone": 351.5
}
}
"""

let jsonData = weatherJson.data(using: .utf8)!
let decoder = JSONDecoder()
let currentWeather = try decoder.decode(WeatherData.self, from: jsonData)

print(currentWeather.latitude)
print(currentWeather.temperature)

I imagine there are other examples out there that follow this exact same model. I mean, it is how Apple's documents set it up. However, there are times at work where I have several nested layers of information, and using nestedContainer over and over within the intializer makes an already involved extension more complex. So I prefer to attack it a different way. Each nested level gets it's own struct, it's own CodingKeys, and it's own extension. I prefer this because it keeps my structs small, and in my mind, easier to read. Allow me to refactor the above.

I'll start at the beginning with my WeatherData model

struct WeatherData {
    var latitude: Double
    var longitude: Double
    var currentWeather: CurrentWeather

    private enum CodingKeys: String, CodingKey {
        case latitude
        case longitude
        case currentWeather = "currently"
    }
}

extension WeatherData: Decodable {
    init(from decoder: Decoder) throws {
        let values = try decoder.container(keyedBy: CodingKeys.self)
        latitude = try values.decode(Double.self, forKey: .latitude)
        longitude = try values.decode(Double.self, forKey: .longitude)
        currentWeather = try values.decode(CurrentWeather.self, forKey: .currentWeather)
    }
}

I prefer to have CurrentWeather as it's own struct. So here my top level has a reference to top level properties, my next level has a reference to only the properties within it, and so on an so forth. I have changed up what I'm sending back from the earlier model to keep things shorter. You'll also notice I included a way to handle optionals. In my line of work dealing with manufacturing data, we do have some models with more information than others and many of those fields are blank or nil.

struct CurrentWeather {
    var summary: String
    var temperature: Double
    var windspeed: Double
    var uvIndex: Int?

    private enum CurrentWeatherCodingKeys: String, CodingKey {
        case summary
        case temperature
        case windspeed = "windSpeed"
        case uvIndex
    }
}

extension CurrentWeather: Decodable {
    init(from decoder: Decoder) throws {
        let values = try decoder.container(keyedBy: CurrentWeatherCodingKeys.self)
        summary = try values.decode(String.self, forKey: .summary)
        temperature = try values.decode(Double.self, forKey: .temperature)
        windspeed = try values.decode(Double.self, forKey: .windspeed)
        uvIndex = try values.decodeIfPresent(Int.self, forKey: .uvIndex)
    }
}

For me, the breaking it down into separate models makes it easier for me to understand the layers. It also keeps it small. I generally keep all the models in the same file and label it something like WeatherDataResponse.

I have noticed that my top level CodingKey has to be named CodingKeys if you plan on not using an extension to write your own initializer and just have WeatherData conform to Decodable. If I name it anything else, the playground gives me an error. Nested level names for the CodingKeys do not seem to matter. However, I generally like using extensions to keep my member wise initializer, so this isn't a problem for me.

All in all, this post was just as much about me explaining Codable (well, mostly Decodable...) to myself as it was about explaining it to others. I hope, perhaps, that some find some use out of it, or at the very least, encourages you to learn something new. Any constructive feedback is welcome.