Categories
Review

“Ed”

Sam Hughes

I’m reading Hughes’ work all out of order, but happily, there’s really no shared universe from story to story, so it’s not an issue. And, having now read all four of his books, I can say that “Ed” would be my recommended starting place, if you want to give it a go.1 It’s the lightest – a very silly beginning, and told by a narrator who’s further outside the story than any of his other works. While it’s not quite to that space opera feel, with the big events happening in the background and the story following regular-sized people just trying to make it through, it’s more human in scale.

It’s also very episodic most of the way through, so it’s easier to pick up and put back down for a while, if that’s your reading style, though there’s enough callbacks that you’ll be rewarded for going right through. (And, because this is a web-first piece of fiction, if you’re reading it online, a great deal of those callbacks are hyperlinks to the correct chapter – an easy way to catch yourself back up without devolving into “as you know, Bob” territory.)

All in all, “Ed” is a fairly short read, and a fun one. It’s got that characteristic “sprawling across space and time” feel that’s characteristic of Sam Hughes, but at no point do you feel like you need to stop and take notes to try to follow what’s going on. I quite enjoyed it. Give it a read, and if it really captures your interest, buy a copy!

  1. I’ve previous reviewed “Ra”, and will at some point write up my thoughts on “Fine Structure”, but my stance on “There Is No Antimemetics Division” is the simple “if you like SCP, you’ll like this; if you don’t know what that means, this isn’t a good starting point.”
Categories
Programming

Dev Blogs

I recently had someone ask for recommendations for dev blogs to fill out their RSS reader. After going through what I have in my RSS reader, I realized that this would make a good little post—these have all been helpful resources to me, so it seems likely they could be helpful to someone else. (I have also been informed by a friend of mine that I should include myself in this list, but I figure you’re already here. Go ahead and throw this site URL into your RSS reader, the feed is nice and discoverable.)

So, in no particular order, developer blogs:

  • Use Your Loaf posts fun little things, usually regarding iOS development.
  • The Always Right Institute does terrible, terrible things with Swift, and they’re consistently a delight to read.
  • SwiftLee writes very solid articles explaining various Swift language features, iOS API things, and general career tips.
  • Swift with Majid does weekly deep dives into SwiftUI… and may or may not be the inspiration for my recent spate of programming posts.
  • Swift by Sundell is one of the definitive Swift sites; not only does John Sundell write up plenty of great articles (see ‘Swift Fundamentals’ as a great starting point!), he also has a couple podcasts, if listening is more your style.
  • Reda Lemeden does some fun explorations of Swift, as well as more general things with his “This Week I Learned” posts.
  • Gui Rambo does some really neat explorations of what’s possible on iOS when he’s not cracking open the developer betas to see what features Apple forgot to feature-flag out of the build.
  • Povilas Staškus hasn’t posted in a while, but his posts are worth a back-read; the Jekyll-to-Publish migration was a fun one. And, hey, putting an infrequent poster in RSS is what RSS is for!
  • NSHipster is a venerable name in the iOS dev world; not as actively updated as it once was, but the back catalog is extremely solid, and will quite often be one of the first results when Googling various things.
  • Kristaps Grinbergs writes in a similar vein to Swift with Majid, with explanations of various parts of the SwiftUI API.
  • Julia Evans is a break from my very iOS-heavy list so far; she does comics and zines explaining general programming concepts, command line tools, and all sorts of stuff. Seriously good explanations, I recommend checking them out.
  • Brent Simmons blogs about NetNewsWire, life as a developer, and neat bits of history in the Apple world.
  • Steven Troughton-Smith may well be the expert on Catalyst apps; his recent post of various sample apps is a wonderful resource if you’re looking into bringing an iPad app to macOS.
  • Erica Sadun’s blog has recently been a lot of neat macOS automation stuff; she’s also a frequent contributor to Swift itself.
  • On Hacking With Swift, Paul Hudson provides excellent WWDC coverage and an amazing array of tutorials and documentation.1 If you’re just getting started, go through his free 100 Days of Swift and 100 Days of SwiftUI courses.

And, in addition to all those blogs, I also funnel email newsletters into RSS whenever possible. My top picks from that list are:

  • iOS Goodies provides a little commentary with a list of articles.
  • iOS Dev Weekly comes with much more commentary; I’m also a fan of the “and finally…” section, it’s a nice ending every week.
  1. Seriously, it’s so robust that one of my top bangs is !hws
Categories
Programming

Network Caching With Combine

I’m going to lead in to this post by saying that this isn’t a Definitively Correct way to do this; it works for my use case, but has some definitive issues. Still, in the interest of transparency—and not running out of content for this blog—I’m going to share it anyways.

Last week, I shared a fun little enum-based way of representing API endpoints in a type-safe manner. It’s also pretty easy to expand on to use as the key for an in-memory cache of endpoint results.

(This, by the by, is Caveat 1: it’s a purely in-memory cache, with nothing being persisted to disk. User quits out of your app? Cache is gone. For what I’m working on, though, this is the behavior we want, so it works well.)

Let’s get started with the actual API surface we want:

class ApiClient {
	func get<T: Decodable>(endpoint: Endpoint, reset: Bool = false) -> T? {
		...
	}
}

Now, the funky thing about how I’ve got this implemented is that this get method is idempotent – if you call it 10,000 times for the same Endpoint, it’s only going to spit out one network request, and will just continue returning nil until something is actually present. (Well, unless you’re setting reset to true – that’s really in there for debug purposes more than anything else. Give the API I’m using on this project, it’s almost never necessary.)

And, for use with SwiftUI, we want it to be called again when the network request finishes, so we’ll make it an ObservableObject.

Next, let’s work out how to store things to achieve that. The main thing we need is somewhere to store the network requests, and somewhere to store the results – the aforementioned in-memory cache. And, to get that “call the method again when the cache changes” behavior, we can make it @Published:

class ApiClient: ObservableObject {
	private var loaders: [Endpoint:AnyCancellable] = [:]
	@Published private var cache: [Endpoint:Decodable] = [:]
}

Now, to make Endpoint we need it to be viable dictionary key, which is pretty easy to accomplish:

extension Endpoint: Hashable { }

Finally, we need to implement the actual method. Without further ado:

class ApiClient: ObservableObject {
	private var loaders: [Endpoint:AnyCancellable] = [:]
	@Published private var cache: [Endpoint:Decodable] = [:]
	
	func get<T: Decodable>(endpoint: Endpoint, reset: Bool = false) -> T? {
		if reset {
			cache[endpoint] = nil
			loaders[endpoint] = nil // which implicitly calls loaders[endpoint]?.cancel(), via the deinit
		}
		if let _item = cache[endpoint], let item = _item as? T {
			print("\(endpoint): cache hit")
			return item
		}
		if loaders[endpoint] == nil {
			print("\(endpoint): cache miss; beginning load")
			loaders[endpoint] = URLSession.shared.dataTaskPublisher(for: endpoint.url) // 1
				.map(\.data)
				.decode(type: T.self, decoder: JSONDecoder()) // 2
				.receive(on: DispatchQueue.main)
				.sink(receiveCompletion: { (completion) in 
					print(completion)
				}, receiveValue: { (item) in 
					self.cache[endpoint] = item
				})
		}
		print("\(endpoint): cache miss; loading already in progress")
		return nil
	}
}

Two notes in there:

  1. You may want to swap out the use of URLSession.shared here for a parameter into the class’ constructor – it’ll make your testing a bit easier.
  2. Even more so than (1), you probably want to swap out JSONDecoder() here for something stored on the class – that decoder isn’t free to initialize!

Now, as I mentioned, this has some limitations. The first one I already went over – it’s a purely in-memory cache. The second is at the call site – since this is generic across Decodable, you have to annotate at the call site what the expected return type is, which isn’t the most ergonomic.

My actual thought on fixing that was very TypeScript-inspired – creating overloads that specify T based on the given endpoint. In Swift, this isn’t too difficult, just adding something like:

extension ApiClient {
	func getCategory(_ id: Category.ID, reset: Bool = false) -> Category? {
		get<Category>(endpoint: .category(id), reset: reset)
	}
}

Which, of course, can get a bit repetitive depending on the number of endpoints you have. But hey, it works for my use case, and it may be helpful to someone else, so: blog post!

As a post-credits scene of sort, the TypeScript version is a bit silly, and takes advantage of the absolutely bonkers way method overloads work in TypeScript. I’ll throw out some pseudocode:

class ApiClient{
	func get(endpoint: Endpoint.Category, reset: bool): Category?
	func get<T>(endpoint: Endpoint, reset: bool: T? {
		...
	}
}

Yes, method overloads like this are just declaring the method multiple times before the actual body. And yes, you can specify an individual enum case as a type.

Categories
Programming

Safe API Calls with Enums

I really hate runtime errors. I’m a firm believer in the concept that as many errors as conceivably possible should be caught at compile-time. It makes sense, after all: a compile time error for me means a few minutes of my time spent fixing it; a runtime error for my users means a few seconds of their time staring at an error… multiplied across however many users there may be. And, really, how often are you working on an app where you outnumber the users?

In this vein, I’ve been tinkering with how to handle network requests. The easy first thing to do was to swap out stringly-typed URLs for an enum, and Swift’s associated values make this a breeze:

enum Endpoint {
	case globalConfiguration
	case category(Category.ID)
	case product(Product.ID)
	...
}

Your definitions may vary – this is, of course, very specific to the actual use case. But look at that – not only do we have clear representations of the various endpoints available, we can even link the variable components of those URLs to being the proper type for the model we expect to get back. How’s that for self-documenting code?

Next, we need a way to convert from this lovely enum to the actual URL we’re going to use to make our requests. I’ve split this up a little bit:

extension Endpoint {
	var pathComponents: String {
		switch self {
			case .globalConfiguration:
				return "/config.json"
			case .category(let ID):
				return "/category/\(ID).json"
			case .product(let ID):
				return "/product?id=\(ID)"
			...
		}
	}

	var url: URL {
		#if DEBUG
		return URL(string: "https://dev.my.app")!.appendingPathComponent(pathComponents)
		#else
		return URL(string: "https://api.my.app")!.appendingPathComponent(pathComponents)
		#endif
	}
}

Et voila, converting to our known URLs, and a nice little “automatically use the dev server in debug mode” check, while we’re at it.

Now, depending on how you’re organizing your networking code, we can tweak the API surface here a little bit to make things clearer. Add those extensions in the same file as the code that makes the network requests, and declare them fileprivate – and now, you’ve got an automatic reminder from the compiler if you start writing some URL-based networking code outside of the network component. No more leaky abstraction!

Categories
Technology

WWDC21

I’m writing this a bit after WWDC has ended, and publishing it a bit further after that, so pardon the tardiness as I share my thoughts, in no particular order:

  • As a user, I am quite excited by the new functionality in FaceTime, and the new Focus system for managing notifications. The system of tiered notifications looks great, and I’m excited for the, oh, 15 minutes most people will have between ‘installing iOS 15’ and ‘an app first abusing the notification level to send them spam.’1 In iOS 16, can we get a “report notification as spam” button that immediately flags the app for App Review to yell at?
  • As both a developer and user, I was immensely excited to see the ManagedSettings and ManagedSettingsUI frameworks – I really like the concept of Screen Time for externalized self-control, and being able to use custom implementations or build my own seemed like a dream.2 Unfortunately, all those dreams were immediately crushed by the reveal that this all requires FamilyControls, so not only can I not do anything interesting with it as a developer, I can’t even use it myself. Because, as we all know, the only use case for “my phone won’t let me use it to waste time” is “parents managing their children.”
  • Swift’s implementation of async/await looks great, and the stuff Apple’s doing with @MainActor seems to have met the goal of “the language eliminates an entire class of error” that initially gave us optionals, so I’m quite happy about that. I hope Vapor updates to async/await soon, I’d love to untangle some of my flatMap chains.
  • The new Human Interface Guidelines section on Inclusion is very well-written and hits on some important points.
  • I am incredibly excited about the virtual KVM thing coming to macOS and iPadOS – my desk setup features two monitors for macOS, and an iPad perpetually on the side, and the idea of being able to control the iPad without taking my hands off the main keyboard and mouse is very exciting.3
  • Safari on iOS got support for web extensions, which is neat. I also like that they’re pulling things down toward the bottom of the screen, should be more reachable.
  • Safari on macOS might finally do something that Mozilla never managed to do: convince me to switch to Firefox. I sincerely hope this is the peak of “aesthetics over functionality” in Apple’s design, and that it gets better from here, because this is a mess: lower contrast text, the core UI element moves around all the time so you can’t have any muscle memory, and they’ve buried every single button behind a ‘more’ menu.
  • SwiftUI got lots of little updates, but the thing that I may be most excited about is the simple quality of life improvements as a result of SE-299.listStyle(.insetGrouped) is much easier to type than .listStyle(InsetGroupedListStyle()), especially considering that Xcode can actually suggest .insetGrouped.
  1. In my case, it’ll probably be a couple days, and then Apple Music will punch through a Focus mode to notify me that Billie Eilish has a new single or something.
  2. I already have a name for the app I want to build using these API. My first feature would just be “the existing Screen Time system, but it actually knows how time works.” Something like 90% of the time that I hit ‘one more minute’ I’m instead given a couple seconds. Apple, I know that time is hard, but it isn’t that hard.
  3. Why the iPad? Because iPadOS is sandboxed, which limits the sort of bugs that Teams can introduce and evil that Zoom can. Sure, they both have macOS apps – but you shouldn’t install either of them.
Categories
Review

Circle of Magic

Tamora Pierce

I suspect I have mentioned in the past that Tamora Pierce’s Circle of Magic series is one of my favorite things to read. As a general rule, I reread most of her bibliography at least once a year – quite often when I’m stressed. Tamora Pierce is my comfort reading.1

I’ve recently stumbled my way into a lovely group of people, and among many of the projects we created for ourselves was something of a book club. And we started with the Circle of Magic.2

And here’s where I begin to struggle in writing this, nominally a review of the first quartet. I’ve been reading and rereading these books for so long that it’s impossible for me to come at them with fresh eyes. I can’t even begin to put myself in the mind of someone who hasn’t read them, to try to figure out what about them I should mention to convince someone they’re worth the time to read. I wouldn’t be the person I am today without their influence.

Instead, I’m just going to list some thoughts about the different books, in no particular order.

Tris’s Book is, I think, my favorite of the four. I identified the most with Tris, growing up – a total bookworm, and too quick a temper. It is, unsurprisingly, in Tris’s Book that we get to see what Tris is thinking, and what made her that person – and, conversely, that we see her start to grow, and learn to trust.

Briar’s Book scares me to this day. I’d say “even more so, considering,” but, having just reread it last week, I don’t think the amount it scares me has changed, even in light of living through a pandemic. It’s still terrifying – and it turns out to have been pretty accurate about just how scary, and lonely, and crushing it all is.

“Most disasters are fast, and big. You can see everyone else’s life got overturned when yours did. Houses are smashed, livestock’s dead. But plagues isolate people. They shut themselves inside while disease takes a life at a time, day after day. It adds up. Whole cities break under the load of what was lost. People stop trusting each other, because you don’t know who’s sick.”

Daja’s Book is all about the important of family, and how family doesn’t always match what you grew up thinking it would. You can find more people who love you, and who you love, and they can be just as much family as the one you were born into.

Daja’s Book is also… a big spoiler, in how I’m going to phrase this, so I’ll tuck it into a footnote. You’ve been warned!3

Sandry’s Book… is coming home.

I cannot, cannot express how much I love these books. Please, please give them a try.4 And, because I adore Tamora Pierce, also check out her patreon – the next goal is an admirable one.5

  1. In fact, many times the thing that makes me realize quite how stressed I am is the realization that I’ve picked up one of her novels. It’s automatic!
  2. The book club may have come about as a result of my strongly urging everyone to read these books. As far as the #influencer life goes, “encouraging people to read Tamora Pierce” is probably the best possible outcome.
  3. Daja’s Book is a beautiful example of a happy ending in a book, with everything getting tied together beautifully. It’s not just that every thread gets wrapped up nicely, it’s that half of them are solved by being the solution to another problem. To borrow a phrase that I first heard as a descriptor of another favorite piece of media of mine, it’s competence porn.
  4. I’m breaking my usual ‘use Bookshop links instead of Amazon’ pattern here, but Sandry’s Book isn’t available on Bookshop at all, and based on the paperback prices on Amazon, is thoroughly out of print. The Kindle edition is available, though!
  5. I’m of the opinion that she (or her staff) haven’t done a good enough job of advertising this, because I’ve had her public blog in my RSS reader for years, and just found out about the Patreon a few days ago. So now I’m doing my part by telling you, dear reader. Go support her! She’s great!
Categories
Programming

FocusedValue on tvOS

Alright, let’s set the scene with a mildly contrived example: you’ve got a list of things, and you want the surrounding View to match them. For a tvOS app, this could be swapping out the background and some title text to match the selected episode; since I don’t feel like coming up with some fake episode titles, however, we’re going to go with colors:

At first thought, you’d probably reach for @State, something akin to:

struct ColorsView: View {
	@State var selectedColor: Color
	let colors: [Color]

	var body: some View {
		VStack {
			Text(colorName(selectedColor))
			HStack {
				ForEach(colors) { color in 
					Rectangle().fill(color).focusable()
				}
			}
		}
			.background(WaveyShape().fill(selectedColor)
	}
}

Not too bad; attach on onFocus to the Rectangle() and it should work!

But… what if there’s more layers in between? Instead of a Rectangle(), you’ve got some other View in there, maybe doing some other logic and stuff.

Oof, now we’re going to need a @Binding, and – oh, what happens if the user swipes out of the rectangles and to our nav bar, can selectedColor be nil?

Happily, SwiftUI has something built out to handle basically this exact scenario: @FocusedValue. There’s some great tutorials out there on how to do this for a macOS app, which allows you to wire up the menu bar to respond to your selection, but it works just as well on tvOS.

Let’s get started:

struct FocusedColorKey: FocusedValueKey {
	typealias Value = Color
}

extension FocusedValues {
	var color: FocusedColorKey.Value? {
		get { self[FocusedColorKey.self] }
		set { self[FocusedSeriesKey.self] = newValue }
	}
}

Now we’ve got our new FocusedValue available, so let’s use it:

struct ColorsView: View {
	@FocusedValue(\.color) var selectedColor: Color?
	
	var body: some View {
		VStack {
			Text(colorName(selectedColor ?? Color.clear))
			HStack {
				ForEach(colors) { 
					ColorRectangleView(color: $0)
				}
			}
		}
			.background(WaveyShape().fill(selectedColor ?? Color.clear)
	}
}

The one big change here is that selectedColor can be nil. I’ve gone ahead and defaulted to .clear, but do what fits your use case.

Finally, we need to set the focused item:

struct ColorRectangleView: View {
	let color: Color

	var body: some View {
		Rectangle()
			.fill(color)
			.focusable()
			.focusedValue(\.color, color)
		}
	}
}

Et voila, it works!

Now, this may not seem like a huge change over doing it via @Binding, but keep in mind: @FocusedValue is a singleton. You can have every view in your app respond to this, without passing @Bindings every which way.

Categories
Programming

Position vs Offset

I’ve had reason recently to be doing custom position of things in SwiftUI, and figured I’d share something that I found a bit of a tricky distinction at first: position vs offset.

So, let’s set the scene:

struct DemoView: View {
	var body: some View {
		HStack {
			Rectangle().fill(.gray)
			Rectangle().fill(.blue)
			Rectangle().fill(.gray)
		}
	}
}

And now I’ll add some visuals, for ease of reading. (I made these in Sketch, so the graphics aren’t precisely what you’d get by running this code, but hey, artistic liberties.) Here’s our view:

Three squares in a row.

Now let’s tinker!

struct DemoView: View {
	var body: some View {
		HStack {
			Rectangle().fill(.gray)
			Rectangle().fill(.blue)
				.offset(x: 150, y:150)
			Rectangle().fill(.gray)
		}
	}
}

We’re offsetting the middle square. What does that look like?

Three squares; two are in a row, and there is a space in the middle where the third could fit, but it is below and to the right of that space.

I’ve left in a little ghost image to show where it was, because it’s an important distinction! As far as the HStack is concerned, that space is still occupied. Think of it like throwing your voice – you don’t move, just the perception of where you are.

Let’s try something else, now:

struct DemoView: View {
	var body: some View {
		HStack {
			Rectangle().fill(.gray)
			Rectangle().fill(.blue)
				.position(x: 150, y:150)
			Rectangle().fill(.gray)
		}
	}
}

Looks pretty similar in code, right? We’ve just swapped out ‘offset’ for ‘position’. What do we get on screen?

Three squares; two are in a row, while the third is out of alignment and slightly overlapping.

Ooh, very different! No more ghost, because now it’s actually in a different place – not holding that spot in the HStack. It’s also in a different spot than the previous one, what gives?

It’s in the name: ‘offset’ offsets the view from where it normally would’ve been. Our starting position was where the ghost stayed:

Three squares; two are in a row, and there is a space in the middle where the third could fit, but it is below and to the right of that space. The distance from the space to the square is labeled, with 150 in the top distance and 150 in the left distance.

‘Position,’ on the other hand, skips the whole question of where it would go and instead just puts it in an exact spot, using the top left corner of the screen as the point (0,0):

Three squares; two are in a row, while the third is out of alignment and slightly overlapping. The distance from the misaligned square to the top and left of the image are labeled with '150' on each.

The other approach that worked for my brain, coming from doing a lot of web dev, is to think about ‘offset’ as being CSS’ ‘position: relative’, while ‘position’ is equivalent to ‘position: absolute’.

Hopefully this helps the whole thing make sense!

Categories
Programming

Transitions in ZStacks

The other day, I found a fun little SwiftUI edge case: using a .transition() modifier in a ZStack doesn’t work. As a basic demo, let’s do something like this:

struct DemoView: View {
	@State var showing = true
	
	var body: some View {
		ZStack {
			Rectangle().fill(Color.red)
				.onTap {
					showing.toggle()
				}
			if (showing) {
				Text("Hello, world!")
					.transition(.opacity)
			}
		}
	}
}

Pretty simple example, yeah? Seems like it’d Just Work(TM) out of the box. It doesn’t, though; instead of a lovely opacity animation, it just pops in and out. Hmm.

Worry not, though, as I have a fix:

struct DemoView: View {
	@State var showing = true
	
	var body: some View {
		ZStack {
			Rectangle().fill(Color.red)
				.onTap {
					showing.toggle()
				}
				.zIndex(1)
			if (showing) {
				Text("Hello, world!")
					.transition(.opacity)
					.zIndex(2)
			}
		}
	}
}

Et voila, your transition works!

Now, I haven’t exactly done rigorous experimentation to figure out why, exactly, this works, but I do have a theory: when SwiftUI removes the Text, it loses its place in the ZStack, and gets assigned to “behind everything else.” By manually specifying the order, the slot stays reserved, and it can stay there while it fades in and out.

Categories
Programming

Playing Videos in SwiftUI

As of WWDC 2020, we have a way to play videos in SwiftUI without bailing out to UIKit with UIViewRepresentable. At first glance, it’s pretty simple, as well:

import SwiftUI
import AVKit

struct VideoPlayerView: View {
	let videoURL: URL

	var body: some View {
		let player = AVPlayer(url: videoURL)
		VideoPlayer(player: player)
	}
}

Et voila, you’re playing a video! You can overlay content on top of the video player pretty easily:

import SwiftUI
import AVKit

struct VideoPlayerView: View {
	let videoURL: URL

	var body: some View {
		let player = AVPlayer(url: videoURL)
		VideoPlayer(player: player) {
			Text("Watermark")
		}
	}
}

Seems like we’re good to go, no?

Well, not quite. Let’s talk memory management.

VideoPlayerView is a struct – it’s immutable. SwiftUI allows us to mutate the state of our views with user interaction using things like @State, thanks to some Compiler Magic.

Every time some aspect of the state changes, SwiftUI calls the body getter again.

Spotted the catch yet?

We’re declaring the AVPlayer instance inside the body getter. That means it gets reinitalized every time body gets called. Not the best for something that’s streaming a video file over a network.

But wait, we’ve already mentioned the Compiler Magic we can use to persist state: @State! Let’s try:

import SwiftUI
import AVKit

struct VideoPlayerView: View {
	let videoURL: URL
	@State var player = AVPlayer(url: videoURL)

	var body: some View {
		VideoPlayer(player: player)
	}
}

Whoops. We’ve got a problem – self isn’t available during initialization, so we can’t initialize the AVPlayer like that. Alright, we’ll write our own init:

import SwiftUI
import AVKit

struct VideoPlayerView: View {
	let videoURL: URL
	@State var player: AVPlayer

	init(videoURL: URL) {
		self.videoURL = videoURL
		self._player = State(initialValue: AVPlayer(url: videoURL))
	}

	var body: some View {
		VideoPlayer(player: player)
	}
}

(I suppose we could drop the let videoURL: URL there, since we’re using it immediately instead of needing to store it, but for consistency’s sake I’m leaving it in.)

Okay, sounds good – except, hang on, @State is only intended for use with structs, and if we peek at AVPlayer it’s a class.

Okay, no worries, that’s what @StateObject is for, one more tweak:

import SwiftUI
import AVKit

struct VideoPlayerView: View {
	let videoURL: URL
	@StateObject var player: AVPlayer

	init(videoURL: URL) {
		self.videoURL = videoURL
		self._player = StateObject(wrappedValue: AVPlayer(url: videoURL))
	}

	var body: some View {
		VideoPlayer(player: player)
	}
}

There, we should be good to go now, right? Right?

Alas, the compiler says no. AVPlayer doesn’t conform to ObservableObject, so we’re out of luck.

Fortunately, ObservableObject is pretty easy to conform to, and we can make our own wrapper.

import SwiftUI
import AVKit
import Combine

class PlayerHolder: ObservableObject {
	let player: AVPlayer
	init(videoURL: URL) {
		player = AVPlayer(url: videoURL)
	}
}

struct VideoPlayerView: View {
	let videoURL: URL
	@StateObject var playerHolder: PlayerHolder

	init(videoURL: URL) {
		self.videoURL = videoURL
		self._player = StateObject(wrappedValue: PlayerHolder(videoURL: videoURL))
	}

	var body: some View {
		VideoPlayer(player: playerHolder.player)
	}
}

Phew. At long last, we’ve got a stable way to hold onto a single AVPlayer instance. And, as a bonus, we can do stuff with that reference:

import SwiftUI
import AVKit
import Combine

class PlayerHolder: ObservableObject {
	let player: AVPlayer
	init(videoURL: URL) {
		player = AVPlayer(url: videoURL)
	}
}

struct VideoPlayerView: View {
	let videoURL: URL
	@StateObject var playerHolder: PlayerHolder

	init(videoURL: URL) {
		self.videoURL = videoURL
		self._player = StateObject(wrappedValue: PlayerHolder(videoURL: videoURL))
	}

	var body: some View {
		VideoPlayer(player: playerHolder.player)
			.onAppear {
				playerHolder.player.play()
			}
	}
}

Will start playing the video as soon as the view opens. Similarly, you could add some Buttons, build your own UI on top of the video player, all sorts of fun.

And, from the other end, you can put more logic in the PlayerHolder, as well. Say you need some additional logic to get from a video ID to the actual URL that the AVPlayer can handle? Try something like this:

class PlayerHolder: ObservableObject {
	@Published var player: AVPlayer? = nil
	init(videoID: Video.ID) {
		NetworkLayer.shared.lookupVideoInformation(videoID) { result in 
			self.player = AVPlayer(url: result.url)
		}
	}
}

(Now, that’s not the nice, Combine-y way to do it, but I’ll leave that as an exercise for the reader. Or possibly another post.)

Categories
Programming

tvOS Carousels in SwiftUI

It’s a fairly common pattern in tvOS apps to have a carousel of items that scrolls off screen in either direction – something vaguely like this:

Image a tvOS wireframe, showing two horizontally-scrolling carousels.

Actually implementing this in SwiftUI seems like it’d be easy to do at first:

VStack {
	Text("Section Title")
	ScrollView(.horizontal) { 
		HStack {
			ForEach(items) { 
				ItemCell(item: $0)
			}
		}
	}
}

Which gets you… a reasonable amount of the way there, but misses something: ScrollView clips the contents, and you wind up looking like this:

A tvOS wireframe, showing two horizontally-scrolling carousels; both have been clipped to the wrong visual size.

Not ideal. So, what’s the fix? Padding! Padding, and ignoring safe areas.

VStack {
	Text("Section Title").padding(.horizontal, 64)
	ScrollView(.horizontal) {
		HStack {
			ForEach(items) { 
				ItemCell(item: $0)
			}
		}
			.padding(64) // allows space for 'hover' effect
			.padding(.horizontal, 128)
	}
		.padding(-64)
}
	.edgesIgnoringSafeArea(.horizontal)

The edgesIgnoringSafeArea allows the ScrollView to expand out to the actual edges of the screen, instead of staying within the (generous) safe areas of tvOS.1

That done, we put the horizontal padding back in on the contents themselves, so that land roughly where we want them. (I’m using 128 as a guess; your numbers may vary, based on the design spec; if you want it to look like The Default, you can read pull the safe area insets off UIWindow.)

Finally, we balance padding on the HStack with negative padding on the ScrollView; this provides enough space for the ‘lift’ (and drop shadow, if you’re using it) within the ScrollView, while keeping everything at the same visual size.

  1. tvOS has large safe areas because TVs are a mess in regards to useable screen area.
Categories
Review

“How to Avoid a Climate Disaster”

Bill Gates

I just have to begin by expressing my admiration for Bill Gates. Which still feels strange – I grew up on “Micro$oft” jokes and the image of Gates as the corporate Big Brother, a la Apple’s 1984 ad. Watching him go from icon of capitalism to the world’s foremost philanthropist has been interesting, to say the least. As a relevant aside, I highly recommend the Netflix documentary on his life, it’s fascinating, and works well to provide context on where he’s coming from in writing this book.

The book itself does what it says on the tin: it ends with plans of action for preventing the sort of global climate disaster that we, as a species, have been gleefully sprinting towards ever since we realized those funky rocks we dug up would burn longer than the trees we were chopping down. And the plans aren’t just “buy an electric car and vote for green energy;” not only are there more action items than just that, there are plans for people depending on which hat they’re wearing. Sure, you the consumer can buy an electric car… but you the citizen can write your legislators, and you the employer can invest in R&D, and you the local government official can tweak building codes to allow for more efficient materials.

The first half, or more, of the book is an accounting of what’s driving climate change, and it’s a fascinating overview. Your first guess about the largest culprit, in broad categories, is probably wrong.

And in the middle, there’s a great deal of discussion of the technologies we’re going to need to get through this transition. As a life-long nerd, that was the part I enjoyed the most; as someone who’s very sold on the importance and utility of nuclear power, my absolute favorite moment was a throwaway reference to “we should be building nuclear-powered container ships.”1

Here at the end, where I usually say “I enjoyed this book, and I recommend it,” I’m still going to do that.2 But beyond enjoying the book, it feels like the single most important thing I’ve read… possibly ever. The pandemic is the definitive crisis of the last couple years; climate change is the definite crisis of this generation. Go read the book. Buy a copy, read it, and pass it along to someone else to read. Take notes, and follow the plans of action that’re applicable to you. Let’s go save the world.

  1. I may have set some kind of land-speed record going from “what the hell” to “that makes perfect sense.”
  2. It’s not that I like every book I read, it’s that, as a general rule, I don’t write reviews of the ones I don’t like. If you don’t have anything nice to say, don’t say anything at all.
Categories
Technology

Custom Queries in Vapor Fluent

While the QueryBuilder interface is pretty neat, it’s still missing some things. Recently, I needed a GROUP BY clause in something, and was rather unsurprised to find that Fluent doesn’t support it.1

Fortunately, it’s still possible to write custom SQL and read in the results. Make yourself a convenience struct to unpack the results:

struct MyQueryResult: Codable {
	let parentID: Parent.IDValue
	let sum: Double
}

(Strictly speaking, it can be Decodable instead of Codable, but as long as the Parent.IDValue (generated for free by making Parent conform to Model, I believe) is Codable, Swift generates the conformance for us.)

Now, in your controller, import SQLKit, and then get your database instance as an SQL database instance:

guard let sqlDatabase = req.db as? SQLDatabase else { 
	// throw or return something here
}

After that, write your request:

let requestString = "SELECT ParentID, SUM(Value) FROM child GROUP BY ParentID"

Note – your syntax may vary; I found that, using Postgres, you need to wrap column names in quotes, so I used a neat Swift feature to make that less painful:

let requestString = #"SELECT "ParentID", SUM("Value") FROM child GROUP BY "ParentID""#

If you want to use string interpolation, swap out \() for \#().

Finally, make the query:

return sqlDatabase.raw(SQLQueryString(requestString)).all(decoding: MyQueryResult.self)
  1. Entity Framework Core, which is an incredibly robust, full-featured ORM, only barely supports GROUP BY, so seeing this rather young ORM not support it isn’t all that shocking.
Categories
Development

Forms & Lists

If there’s one area where SwiftUI really shines, it’s forms and lists. I have one area of the app that’s meant as, at most, a fallback option for managing some data, and putting together that management interface took, oh, an hour? It was a breeze. Admittedly, it’s not the prettiest list I’ve ever made, but like I said: fallback option.

Screenshot of a list with a title, two items showing a date and value each, and an 'add' button.
Managing data points in a data set. Unpolished? Sure. Functional? Absolutely.
Screenshot of a Settings screen showing two lists, with an 'edit' button.

I was delighted to find that the automagic ‘edit’ button function handles multiple editable lists within the same View. As this is part of the ‘Settings’ screen, one of the three core screens in the app, it has received a bit more polish.

And I’ve continued to have fun building custom versions of the Picker control, with an expansion on my previous custom picker to support inline management of the above Data Sets and the addition of another one for picking a type of graph:

Screenshot of a picker showing three types of graphs.

At the moment, I’m showing a pretty basic dataset for these, but at some point I think I may create something a bit more visually interesting. The trick being, of course, that I can’t just random-number-generate the data, because I want all three to show the same data points, and since the user can also control the color, I want it to stay consistent if you leave, change the color, and come back.

(The solution here is probably to hard-code a data set, but where’s the fun in that?)

Categories
Development

File > New > Project…

I recently started working on a new development project. Or rather, a project I’ve been thinking about for a while, but just recently started developing – the first draft of the design is from almost a year ago, now, something that I worked on as a class project. But, mostly on a whim, I signed up for SwiftUI Jam, and took it as an excuse to start actually building the thing.

Now, normally my approach to projects is very Apple – refuse to admit I’m even working on something new until it’s complete, ready to present to the world. This time, though, the vague rules of the jam meant it had to be done at least somewhat in the open, and I figured I may as well do some proper write-ups as I go. Could be interesting.

I’m starting with… not the first thing I built, but the one that was the most fun so far. I’m doing the whole app in SwiftUI, and it really shines for building forms.

Screenshot of an iOS application showing a form: Title, Color, and Data Set; Comparison? is set to false.
Screenshot of an iOS application showing a form: Title, Color, and Data Set; Comparison? is set to true. The first three questions are repeated.
Screenshot of an iOS application showing a list to choose from, with groupings such as Activity featuring items like Calories Burned and Cycling Distance.

As I said, a fairly simple form – Title, Color, and Data Set, with the option to add a second of the same three items. The Data Set picker is a custom version of a Picker, because I wanted to give the options in a grouped list rather than just alphabetical order.

I suspect I’m going to be building a second custom Picker implementation sometime soon – this time, choosing from more visual options. Should be fun to put together.