feat(ui): show member created dates when the system opts in - #62
Merged
Conversation
Client side of the new show_member_created_date system setting. Off by default, matching the backend: some systems want to see when each member was added, others find it noise. The toggle lives in Settings > Profile under a Display heading, saved with the rest of that form rather than applying instantly, which is how the web client does it too. Saving writes the updated system through to the local cache so the profile picks the change up immediately instead of waiting for a Home refresh. On the profile itself the date is a row in the details card, next to birthday and privacy. Web shows it as muted text under the name, but on Android that is where facts like this already live. Rendered date-only in the resolved display timezone: the hour a member was added is noise on a profile. The flag is read from the cached system rather than its own request, because this screen's loads are sequential and a fifth call would add a round-trip to every profile open for a setting that changes about never. A missing field (old cached payload, or a server predating the setting) reads as off, so the date stays hidden rather than appearing unasked. Wire-contract tests cover the snake_case name in both directions, the absent-means-off default, and that switching the toggle back off still reaches the wire instead of being dropped as a null.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Android side of the "member created date" setting. Held back until the server field shipped; it's in v1.3.5 now, migration included, so this is unblocked.
Verified against the tag rather than the branch I originally built from:
SystemRead.show_member_created_date: bool,SystemUpdate.show_member_created_date: bool | None, model defaultfalse. Matches what's implemented here.The setting
Settings > Profile, under a new Display heading: a switch, "Show member created dates" / "Show when each member was added, on their profile."
It saves with that form's Save Changes button rather than applying instantly, which is how web does it too. Saving also writes the updated system through to the local cache, so the profile picks the change up immediately instead of waiting for a Home refresh.
The display
A Created row in the member profile's details card, next to Birthday and Privacy, rendered date-only ("Mar 4, 2026") in the resolved display timezone.
Three deliberate differences from web
Placement. Web puts it as muted text under the name and PK id. Android's profile already keeps exactly this kind of fact - birthday, privacy - in the details card, so a row there is the consistent thing; loose text under the name would be the only such text in that header.
Date only, no clock. Web formats it with the system's
date_formatsetting, which Android doesn't have at all (there's nodate_formaton ourSystemRead). Date-onlyMMM d, yyyyinstead, since the hour a member was added is noise on a profile. Honouringdate_formaton Android generally is separate work.No extra request. My first cut fetched
systems/mein the profile loader, then I noticed that screen's loads are sequential - it would have added a round-trip to every profile open for a setting that changes about never. It reads the flag from the cached system instead, with the write-through above covering freshness.Safe against older servers
A missing field reads as off, so an old cached payload or a server predating v1.3.5 keeps the date hidden rather than showing it unasked. No fallback needed beyond that: the setting simply stays off and the row never appears.
Testing
:app:assemblePlayRelease,:app:assembleOpenRelease,:app:testPlayReleaseUnitTestgreen, rebased onto current main.Three wire-contract tests (13 in that file now): the snake_case name round-trips both directions, absent-means-off, and switching the toggle back off still reaches the wire. That last one is the silent-failure case -
SystemUpdatefields are nullable and Moshi omits nulls, so a null would make un-toggling a no-op the server would happily report as unchanged.Device checklist:
Not covered
The wear member profile doesn't show it. The setting says "on their profile" and web only does its own, so I left the watch alone rather than guess.