The lists are native now, and the page is a button in the toolbar: it is
still where signing in happens, and it is still the whole of settings, the
admin page, the directory and OPML, which were never going to be rewritten.
LibraryStore holds a page of items and asks for the next, because the
sorting, filtering and searching are the server's work and ten thousand
items have no business being in memory to be sorted here. Read and pinned
are set locally and sent after, as the page's readWrites map does and for
the same reason: a list asked for before the write lands answers with the
old state, which put the dot back on an item just read.
The interface follows the account's light or dark rather than the phone's,
and defaults to dark when nobody has chosen, because that is what ipx's own
theme.ts does. Following the system instead put a light list in front of a
dark page. preferredColorScheme was not enough on its own -- inside a
hosting controller it did not reach the hierarchy -- so the style is
overridden on the controller, which also carries to the page presented over
it.
The sidebar had to be broken into sub-views: the whole list in one
expression was more than the type checker would work through, and it said
so rather than compiling it.
Tested against the real library, 135 feeds and eleven thousand items, and
the playback test now drives the native row rather than the page's button.
Thirteen pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The first native surface, and the one that settles how the rest will look.
Glass.swift is not a port of the stylesheet. ipx's Glass is already an
approximation of what UIKit gives away -- panels are a 70% colour under
blur(24px) saturate(180%) with an inset top highlight, which is a material,
and the palette names Apple's own colours in its own comments. So where the
CSS had to write #409cff in dark and #0055aa in light, because no single
blue clears AA over the wash, this asks for the system blue and gets both.
Only the wash keeps its hex values: there the colour is the design and
there is no system equivalent to ask for.
PlayerBarView draws what Playback knows, and Playback is the same object
the lock screen and the remote commands drive, so all of them agree without
anything being kept in step by hand. Back 15 and forward 30 match the page
and the lock screen, so every way of skipping moves by the same amount.
Seeking waits for the finger to lift rather than sending a stream of seeks
at a player still answering the last one.
The page's own bar is hidden rather than left to sit under ours. Its play
buttons still work -- they post to the host either way -- but two bars for
one player would be two sets of buttons disagreeing about what is playing,
and only one of them is what CarPlay will be driving.
One test had to be rewritten rather than the code: it asserted that one of
the fixture's two episodes had a file, which stops being true the moment
the event test asks the daemon to scan. The daemon is shared and keeps what
earlier tests did to it, so the assertion now asks what the downloaded
filter means instead of how many things match it today. Thirteen pass,
twice over the same accumulated state.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Everything native needs this first, and it is worth having whatever happens
to the rest: a CarPlay browse tree is built from exactly these calls.
API covers what a client reads and writes -- feeds, entries with the
server's own paging, filtering, sorting and search, read and pinned,
position, read-all, download, delete, fetch -- and APIModels is what ipx
sends, with the server's field names kept so a type here can be checked
against web.rs without translating first. It sends nothing of its own to
authenticate: ipx decides who is asking by cookie and CookieBridge keeps
HTTPCookieStorage in step, which is the same property that lets a plain
<audio src> work.
Events reads /api/events with URLSession's byte stream, so there is no new
dependency. An event this build has never heard of decodes as .other rather
than throwing, because a new one on the server must not stop the stream. It
reconnects with a backoff: a deploy closes the stream cleanly and should be
picked straight back up, a daemon that is down should not be hammered.
Library is gone, folded into API. Two clients writing positions was one too
many, and the page's forwarded beacon no longer carries a path: it asks the
host to save, and the host uses its own clock, which is the only one not
stale when the web view has been frozen in the background.
The tests run against the browser suite's fixture daemon rather than canned
JSON, because the shapes being decoded are the server's and a fixture would
only prove it matches itself. Thirteen pass, including a live scan reported
over SSE and the playback round trip, which still works after the move.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A shell around the ipodderx-rs web UI whose audio is played by the host
rather than the page, so it carries on with the screen locked and a car can
control it. The page's half of the bridge is web/src/native.ts in
ipodderx-rs (#45): it replaces the playback surface of the page's media
element with one that posts here, so player.ts is unchanged and the player
bar, the row buttons and the keyboard shortcuts work as they always did.
Playback, Library, Bridge and CookieBridge never touch a view, which is
what makes a CarPlay scene a later addition rather than a rewrite, and what
lets the same target build for Mac Catalyst with no conditional code:
AVAudioSession, MPNowPlayingInfoCenter and the remote commands all exist
there. The Mac gets media keys and Now Playing; it has no CarPlay and no
lock screen, so it is a convenience rather than the reason for any of this.
Authentication is the web view's. ipx decides who is asking by cookie --
ipx_session, and CF_Authorization from Cloudflare Access in front of the
tunnel -- and its auth layer was written so a plain <audio src> would work,
which is why the player needs no API of its own. CookieBridge keeps
HTTPCookieStorage in step with the web view's store and hands them to each
asset.
Named ipodderx-app, not -ios: native.ts already carries the branch for an
Android host, and the iOS project is one directory rather than the repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
