Swift 4 and Foundation has finally answered the question of how to parse JSON with Swift.
There has been a number of great libraries for this, but it is quite refreshing to see a fully-supported solution that is easy to adopt but also provides the customization you need to encode and decode complex scenarios.
It’s worth noting that everything discussed here applies to any
Decoder implementation, including
PropertyListEncoder, for instance. You can also create a custom implementations of these if you need something different like XML. The rest of this blog post will focus on JSON parsing because that is the most relevant to most iOS developers.
If your JSON structure and objects have similar structure, then your work is really easy.
Here’s an example JSON document for a beer:
1 2 3 4 5 6
Shortly after this hit the store, Michael Moore (yes, that Michael Moore) posted on Facebook, and his website, a 10 Point Plan to stop Trump. In the article, he mentioned 5 Calls specifically as an easy way to get in touch with your representatives.
Here’s some great news: Someone has created an app to make this very easy: Go to the App Store and get “5 Calls”. The app will dial the friggin’ phone for you and give you talking points for when you speak to your reps!
Later on that week, he was invited to Chris Hayes’ show on MSNBC. Sure enough, he ended up giving an enthusiastic overview of the app on national TV during prime time.
I have become much more political in the last year than I ever have before. Like many, completely dumbstruck by the outcome of the election, I have been struggling with how best to channel my frustration and anger.
I decided to do something about it, and channel this energy into something I do think will have a positive impact on our democracy.
Arguing on Twitter, Facebook, etc is unlikely to affect real change (shocker). Our networks are largely echo chambers and it is difficult to influence those outside your network. Retweets won’t save us.
I often get asked what mic people should use when getting started screencasting.
Since screencasting is a significant part of my business, I am comfortable spending a little more than a hobbyist to get good quality sound. Pictured above you can see my microphone and audio interface.
I use (and recommend) the Heil PR-40 microphone. But this is an expensive mic that is really only useful next to somewhat expensive accessories. It’s not a compelling proposition to tell a hobbyist screencaster to fork out nearly $800 on a good mic setup.
I often see people using USB Condenser microphones, like the Blue Yeti or Audio Technica AT2020. I actually started recording NSScreencast with the AT2020. But I don’t think these mics are ideal for recording screencasts.
I keep this mic around for travel reasons, but I really don’t recommend it because it picks up so much room noise. When traveling I usually have pretty awful recording conditions, so it doesn’t work well there either. What I’d really like is a portable dynamic mic…
For the NSScreencast iOS app I wanted to support downloading videos for offline use. With each video being between 80-200 MB in size, this requires some attention to create a download system that is resilient to failure.
Downloading files on iOS is fairly straight forward. You configure a
URLSession with a
URLSessionConfiguration, create a
URLSessionDownloadTask with the URL that you want to download, and then call
.resume() on it.
Later on, during the transfer, if you want to pause this request (or cancel it), you call
cancel(byProducingResumeData:) and pass a block to it. This block yields to you what is called “resume data”. The docs describe it like this:
A data object that provides the data necessary to resume a download.
I’m working on a client project that has a pretty large legacy codebase. For some new features I’m working inside of an existing architecture, so I’m using a when-in-rome strategy for implementing new features. In other words, how I implement something may be different than if this were a greenfield project.
For instance, the existing application is written in Objective-C. While I would likely write the application in Swift if I were starting over, it makes total sense to continue the application in Objective-C for the short term.
One of my clients is submitting an app to the store under a different Apple Developer account than it was developed with.
This left us with about 50 devices in the old portal that they were using for development & beta testing. I needed to quickly get these over to the new portal.