Forgetting to read before writing code
Tags: development, ios, aws, apns
Published: 2019-07-05 18:46:01

---
title: Forgetting to read before writing code
published: true
description: Lessons learned from doing before thinking
tags: development, iOS, AWS, APNS
---

> "Give me six hours to chop down a tree and I'll spend the first four sharpening the axe." --Abraham Lincoln

How many times have you started to fix a bug in your code, it was something you were pretty confident on how to fix, and two hours later you realized that maybe the issue was bigger than you realized and you finally admit to yourself it's time to `git stash`? How many times have you done this on non-development tasks?

A couple weeks ago, my father and I were installing a canopy on his tractor. The West Georgia sun in the summer is brutal and having to spend all day on tractor in that heat is just plain miserable. So he ordered a canopy and when I came to visit for Father's Day, he wanted to install it. We open the box, pull out the hardware, and, alas, no instructions.

Not to worry. I pulled out my phone, searched the Kubota website and found what was necessary. We glanced at the picture on the opening page, figured we had a good sense of how to get started, and dismissed the rest of the pdf.

Wonder how that turned out?!

An hour later, we had finished installing the canopy, but not without having to remove it several times. We had several false starts, whether it be putting the support braces on backwards, not leveling the braces, or not taking the cross-beam off the fiberglass canopy and installing it first before finally placing the canopy on top.

Frustrated at the end, but glad to be finished, I happen to glance at the document still open on my phone and scrolled down. There was only one more page and had I stopped and looked first, I'd have seen the **3** steps necessary. I couldn't help but laugh when I showed my dad and we both commented about how we just proved the stereotype about men and instructions.

Fast forward to last Monday. I was pulling a ticket out of the backlog regarding the push notifications we send out in the app when one user places a call to another using our support feature. The actual text box that slides down from the top of your iDevice is called the alert. Usually, though not always, you'll hear a sound or vibration (if you've got the ringer turned off). In some instances, if the notification is not read or reacted to, a badge will appear on the app icon with the appropriate number of missed alerts.

![](https://thepracticaldev.s3.amazonaws.com/i/881t0ra44wqgmih1ccjf.jpg "messages badge" )

Anyway, the alert always came through as intended, but eventually a tester noticed that if the phone was in their pocket, they never actually knew anything had come in. Basically, no sound alert or vibration.

So I went looking through the code and double-checked to makes sure we asked the user if they're agreeable to receiving notifications. Apple has a function baked into the `UserNotifications` API to help us do this.

~~~swift
UNUserNotificationCenter.current().requestAuthorization(options: 
[.badge, .alert, .sound]) { (agreed, error) in ... }
~~~

Sure enough, the code to request user access to use these items was there so I started typing in a few things and logging what I figured the response would be. In 10-15 minutes, I had several more lines of code added, some of which I thought might be the issue, and other where I wasn't quite sure, but I wanted to see what printed out.

I got up to get some coffee, sat back down and something just didn't look right. Here I had added 15-20 lines of code to prove to myself something I was pretty sure was set up correctly to begin with. Occam's razor kept repeating in my mind and I thought, "Hmm...maybe the code here is just fine. Maybe there is something I'm missing elsewhere." I remembered the lesson with dad, and went searching through the Apple Docs, again, regarding [Remote Push Notifications](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1). This time, however, instead of glossing over, I made myself slow down and read thoroughly.

Here is what I found. When you use a remote service to send push notifications, it needs a json payload with the following structure...

~~~json
{
    "aps" : {
        "alert" : "You got your emails.",
        "badge" : 9,
        "sound" : "default"
    }
}
~~~

You specify the `alert` key, the `badge` number, and the `sound` you want to use. Sounds can be customizable, but if you prefer Apple's default, just specify that value for the `sound` key

So now, I needed to know what kind of payload we were sending to AWS Simple Notification Service to help us fire off our push notifications. A 30 minute meeting with a team member on the backend helped me figure out that the only key we send to AWS in the `aps` dictionary was the `alert`. A short ticket request, followed by a couple emails, and the `sound` key and `default` value were added. Once pushed up, we tested and voila! Alert _AND_ sound comes through as originally intended!

It is an immensely satisfying feeling to fix something so small, yet significant. I imagine just a few months before I'd have torn half of the app apart trying to track down why the sound piece of the notification wasn't working. Turns out, lessons applicable to software development can be learned while helping out on the farm.