feat(#308): add Sensors to the contact type filter
Sensors were the one advert type with no filter. advTypeSensor (4) already existed in the protocol and Contact.typeLabelRaw already returned 'Sensor', but ContactTypeFilter stopped at rooms, so sensor contacts could not be isolated in either the contacts list or discovery. - ContactTypeFilter gains `sensors`. Both exhaustive switches over it were found by the analyzer rather than by hand: the contacts list predicate and the search-hint text. - discovery_screen's predicate has a `default: return false`, so it compiled without a sensors case but would have silently shown an empty list. Added explicitly. - New l10n strings contacts_searchSensors and listFilter_sensors, regenerated across all 18 locales. The 17 non-English locales fall back to the English text and are recorded in untranslated.json, matching how existing strings are handled. - Persisted round-trip verified: UiViewStateService stores the filter by name with orElse -> ContactTypeFilter.all, so older persisted values cannot throw and `sensors` persists like the rest. Groundwork for the Contacts filter rail (#307), but useful on its own: the existing filter menu now offers Sensors. flutter analyze clean, dart format clean, 445 tests pass.pull/324/head
parent
e194800541
commit
f1930549ed
@ -1,3 +1,3 @@
|
||||
enum ContactSortOption { lastSeen, recentMessages, name }
|
||||
|
||||
enum ContactTypeFilter { all, favorites, users, repeaters, rooms }
|
||||
enum ContactTypeFilter { all, favorites, users, repeaters, rooms, sensors }
|
||||
|
||||
Loading…
Reference in new issue