I want to start a new series where I show snapshots of my Zettelkasten work. Because it’s tremendously useful for programmers – but at the same time it’s hard to grasp what I actually do. The mechanics are very simple. Trivial even, especially for programmers who have their favorite editors and writing tools.

So below you see a new file I just created and wrote a bit into.

#uicollectionview

On iOS, `UICollectionView` and `UITableView` support cell-based
configurations that inform how the view is built. This allows them to
vary more easily than the macOS counterparts which often need to be
subclassed.

`UICollectionViewCell.contentConfiguration` can be set to a
`UIContentConfiguration`-conforming object to update its `contentView`
(to which you would add subviews; not its `backgroundView`).

- UICollectionView.CellRegistration<CellView, Model> to prepare setup
- Use `UIHostingConfiguration` for SwiftUI
- Use UIView subclass with UIContentConfiguration conformance?

It’s filename is “202505020614”, a timestamp for 2025-05-02 06:14. I don’t know what the title of that note is going to be just yet. That’ll come later this time because I’m just collecting some information on modern collection views on iOS that I haven’t used, yet.

But I do know that I am going to learn something, and that I need to explicate what that is to remember it, and compare it with what I do with Mac apps. In some sense, this is a “buffer note”: a scratchpad to buffer what I’m learning and researching.

So what’s next?

I had the urge to start this note because I know what I’ll get out of the capturing and writing process eventually. You may not. So in my mind, it goes like this:

• I need to know this part of the API.
• The API contains a couple of pieces that play together which I want to show in one place, like how to get SwiftUI views into UIKit collection view cells.
• I do have code with a UIHostingConfiguration. I will continue to play with that and learn about the API’s mechanics. But the project code should only contain a solution; I need a space to record experiments and what I learned from them. Condensed summaries of toy projects and experiments. That’ll go into the note.
• I know I want to have 1 cell with different states (objective). I believe I can get there by re-using existing content views and switch them out (hypothesis). I need to experiment with switching out configurations on-the-fly in response to state changes.

So what I usually do, and recommend to people asking for help with their programs that don’t behave properly, is to start a new app project and extract only that one thing that is being investigated. Experimenting with a collection cell view in an existing app that needs to compile, launch, and then I need to navigate there etc., that all takes away time and effort from learning how to tweak things. A toy project is much better at this. But even with a toy project, I’ll need to record my various experiments so I don’t have to redo them in a year or so.

Toy projects reduce friction and increase focus. Like good experiments, they remove variables and really bring into focus the one thing you want to observe.

A Zettelkasten can accompany this as a programming lab log-book, from which you then extract learnings into short texts, tutorials and reminders for your future self.

Today, it started as a rough introduction to an API I wasn’t familiar with.