Archive for July 7, 2022

Thursday, July 7, 2022

Apple TV Siri Remote Firmware Update

Juli Clover:

There is no word on what’s new with the Apple TV Siri Remote, but it likely includes minor bug fixes and performance improvements.

[…]

Apple also does not provide details on how to update the Siri Remote, but the software will be installed over the air automatically through the Apple TV.

Cédric Luthi:

Yesterday, Apple released a firmware update for the Apple TV remote. Today, the mute and volume up/down buttons stopped working on my TV. 🤬 I don’t believe in coincidences! If anyone knows how to downgrade the firmware from 0x0070 to 0x0061, please share.

DenniSundaY:

Indeed I hope it’s more than ‘minor bug fixes’ as the remote gained a major bug with the previous update, the laggy volume controls that many people are experiencing namely…

I have definitely been seeing the laggy volume controls. Is there a way to block future firmware updates once you get to good one?

Update (2022-07-12): Josh Hrach:

Before this update, the latest Apple TV remote couldn’t control our TV volume. Looks like the hours I spent over a year ago on the phone with a senior Apple advisor and sending tvOS sysdiagnoses finally paid off.

Tatsuhiko Miyagawa:

Whatever this is, it broke the volume buttons on my Siri remote, paired with an LG TV.

Skipping the iPhone 14

Jason Snell:

If reports are true, the iPhone 13 mini will be the last of its line, replaced by a larger iPhone 14 Max this fall. And as someone who owns and loves an iPhone 13 mini, this makes me sad.

[…]

First, let’s consider the report that the iPhone 14 line will only feature a new A16 processor on the Pro phone models. So not only would the regular iPhone 14 models not get access to rumored innovations like an always-on display, they might not be any faster than the current-year models!

[…]

I really do believe the iPhone mini design will be back. One possibility is for Apple to simply alternate between iPhone models so that the mini appears one year and the Max the next. It’s also not impossible that Apple might just bring the mini design back every few years since it obviously has a following–just not a big one.

This is “my year,” but my iPhone 12 mini is still going strong, and I can’t see replacing it with model that’s larger and has a year-old processor. At this point, my best guess is that this form factor will return in the next iPhone SE, though presumably that will also have iPhone 14’s older processor. It would be nice to be able to get the latest processor and camera in the smaller size.

Update (2022-07-10): See also: Accidental Tech Podcast.

UIs Are Not Pure Functions of the Models

Jesper:

View models and functional UI look like solutions, and they are indeed effective ways of managing complexity by making all the constituent state visible and enumerated. But in my experience they also encourage a way of programming where you bind as much as possible, and the problem with that is that, as the title of the post notes, UIs are not pure functions of the models.

If you go from one place in your UI to another, you may want to be stopped because there are things that don’t validate or don’t fly. You may have pending changes that should neither automagically apply nor be lost. Both SwiftUI and React have state as a first-class concept and are theoretically well-equipped to handle this; what’s worse is that we don’t have a handle on it.

We don’t know how to think in state. For the edited-but-not-saved text of a text field, sure. For the in-progress-but-not-committed-changes in what is at least partially modal, somewhere in the UI? Hm, well, that sounds like a tree of Redux reducers - and therefore model data - or a bunch of nested view models to me. The SwiftUI talk mentions “sources of truth” a lot. Here, the source of truth for the hitherto unsaved data is nebulous. Living in 107 state variables? Living in provisionally updated properties of an ObservableObject that is kept uncommited from the database or real source of truth?

Previously:

Blackbird: a Reference Architecture for Local-First Connected Mobile Apps

Marcel Weiher (tweet, Hacker News):

Blackbird depends crucially on a number of architectural elements: first are stores of the in-process REST architectural style. These can be thought of as in-process HTTP servers (without the HTTP, of course) or composable dictionaries. The core store protocol implements the GET, PUT and DELETE verbs as messages.

The role of URLs in REST is taken by Polymorphic Identifiers. These are objects that can reference identify values in the store, but are not direct pointers. For example, they need to be a able to reference objects that aren’t there yet.

[…]

Blackbird refines the MVC view update mechanism by adding the polymorphic identifier of the modified item in question and placing those PIs in a queue. The queue decouples model and view even more than in the basic MVC model, for example it become fairly trivial to make the queue writable from any thread, but empty only onto the main thread for view updates. In addition, providing update notifications is no longer synchronous, the updater just writes an entry into the queue and can then continue, it doesn’t wait for the UI to finish its update.

[…]

In Blackbird, there is a single channel for backend communication: a queue that takes a polymorphic identifier and an http verb. The polymorphic identifier is translated to a URL of the target backend system, the resulting request executed and when the result returns it is placed in the central store using the provided polymorphic identifier.

[…]

One aspect of this part of the architecture is that backend requests are reified and explicit, rather than implicitly encoded on the call-stack and its potentially asynchronous continuations. This means it is straightforward for the UI to give the user appropriate feedback for communication failures on the slow or disrupted network connections that are the norm on mobile networks, as well as avoid accidental duplicate requests.

Parts of it are open source in MPWFoundation. For more about polymorphic identifiers, see this post.

Previously:

Model View Controller Store: Reinventing MVC for SwiftUI With Boutique

Joe Fabisevich (tweet):

Apple has never provided a blessed architecture for SwiftUI, and many developers have spent thousands of hours filling the gaps with their own ideas. A familiar approach for many developers is to take the MVVM pattern many people adopted in their UIKit/AppKit apps and translate it to the needs of SwiftUI. That can work well enough, but you begin to see some cracks in the architecture when you need to manage state and data flow due how heavily SwiftUI leans on having a single source of truth. Others have taken the path of integrating powerful libraries such as The Composable Architecture which provide you with the tools to reason about your entire application. TCA takes inspiration from redux, more specifically The Elm Architecture, two patterns that are rather incredible in how they allow you to define your entire application as a tree of state. But TCA’s great power comes with great responsibility a very high learning curve, which can make it difficult to learn personally. TCA’s goals are much more of a fit for solving problems with a very high level of complexity, which may not be necessary for every app.

[…]

You can think the Store as the storage for your model objects, in SwiftUI this would be your single source of truth. If you model your data correctly then your user interface will always do what you expect it to do. That relationship between data and user interface is why Views having a single source of truth is so important.

I’ve built a batteries-included Store that comes with everything you’ll need out of the box called Boutique to be the foundation for that data. Boutique does no behind the scenes magic and doesn’t resort to shenanigans like runtime hacking to achieve a great developer experience.

Bodega:

Bodega is a straightforward actor-based library for writing files to disk with an incredibly simple API. Bodega is fully usable and useful on its own, but it’s also the foundation of Boutique.

[…]

Bodega provides two kinds of storage for you, DiskStorage and ObjectStorage. DiskStorage is for writing Data to disk, and ObjectStorage builds upon DiskStorage allowing you to write any Codable object to disk using a very similar API.

Both DiskStorage and ObjectStorage are implemented as actors which means they take care of properly synchronizing disk reads and writes.

Boutique:

Boutique is a simple but powerful persistence library, and more. With its dual-layered memory + disk caching architecture Boutique provides a way to build apps that update in real time with full offline storage in only a few lines of code using an incredibly simple API.

[…]

Storing images or other binary data in Boutique is technically supported but not recommended. The reason is that storing images in Boutique’s can balloon up the in-memory store, and your app’s memory as a result. For similar reasons as it’s not recommended to store images or binary blobs in a database, it’s not recommended to store images or binary blobs in Boutique.

[…]

The Store is a simple way to gain the benefits of offline storage and realtime updates, but by using the @Stored property wrapper we can cache any property in-memory and on disk with just one line of code.

Previously:

Copyright © 2000–2024 Michael Tsai.