Skip to content

feat(proto): Wire custom SchemaHandler for proto field metadata#5310

Draft
jamesarich wants to merge 2 commits into
mainfrom
feat/proto-metadata
Draft

feat(proto): Wire custom SchemaHandler for proto field metadata#5310
jamesarich wants to merge 2 commits into
mainfrom
feat/proto-metadata

Conversation

@jamesarich
Copy link
Copy Markdown
Collaborator

Summary

Adds a build-time Wire SchemaHandler that auto-generates a ConfigFieldMetadataRegistry from (meshtastic.config_field) annotations in .proto files.
Companion to: meshtastic/protobufs#905

Problem

Jonathan's protobufs PR #905 adds custom field options (diy_only) to proto fields via extend google.protobuf.FieldOptions. The question was whether Android (Wire) could access this metadata without hacks.

Solution

Wire 6 handles proto extensions cleanly — it flattens them into typed properties on FieldOptions. However, the metadata lives at the schema level, not on generated message fields directly. To make it easily queryable at runtime without shipping the heavy wire-schema library in the APK, we use Wire's custom SchemaHandler mechanism:

  1. FieldMetadataSchemaHandler (in build-logic/convention) walks every message field at codegen time
  2. Reads (meshtastic.config_field) options via field.options.get(ProtoMember)
  3. Emits a static ConfigFieldMetadataRegistry Kotlin object

Generated output (auto-created at build time):

object ConfigFieldMetadataRegistry {
    fun isDiyOnly(messageType: String, fieldTag: Int): Boolean
    fun diyOnlyFields(messageType: String): Set<Int>
}

Usage example:

// In PositionConfigScreen — gate GPIO settings for DIY devices only
if (!ConfigFieldMetadataRegistry.isDiyOnly("meshtastic.Config.PositionConfig", 8) || isDiy) {
    DropDownPreference(title = stringResource(Res.string.gps_receive_gpio), ...)
}

Key properties

  • Zero runtime cost — static map, no reflection, no descriptor parsing
  • Auto-discovery — annotating new proto fields requires zero code changes
  • No app-size impactwire-schema is only a build-logic dependency, not shipped in APK
  • Only modify handler if ConfigFieldMetadata message gains new sub-fields (e.g. admin_only, min_value)

Changes

  • gradle/libs.versions.toml — added wire-schema library entry
  • build-logic/convention/build.gradle.kts — added wire-schema dependency
  • build-logic/convention/.../FieldMetadataSchemaHandler.kt — the custom handler + factory
  • core/proto/build.gradle.kts — added custom {} target + source dir registration

@github-actions github-actions Bot added build Build system changes enhancement New feature or request needs-review labels Apr 30, 2026
@jamesarich jamesarich force-pushed the feat/proto-metadata branch 2 times, most recently from e788874 to b1ba48e Compare April 30, 2026 19:43
Adds build-time codegen that auto-generates a ConfigFieldMetadataRegistry
from (meshtastic.config_field) annotations in .proto files.
- New FieldMetadataSchemaHandler in build-logic walks all message fields
- Emits a static Kotlin registry mapping (messageType, fieldTag) → metadata
- Zero runtime cost, no wire-schema dep in app binary
- Adding annotations to new fields requires no code changes
Companion to: meshtastic/protobufs#905
@jamesarich jamesarich force-pushed the feat/proto-metadata branch from b1ba48e to f610789 Compare April 30, 2026 19:47
…hemaHandler

The upstream proto (meshtastic/protobufs#905) has been simplified to use
a scalar bool extension instead of a message wrapper:
  [(meshtastic.diy_only) = true]
Wire 6's emitAppliedOptions now natively generates @DiyOnlyOption(true)
annotations on fields, eliminating the need for our custom
FieldMetadataSchemaHandler.
Changes:
- Delete FieldMetadataSchemaHandler.kt (~200 LOC)
- Remove wire-schema dependency from build-logic
- Remove custom {} handler block from core:proto build
- Add emitAppliedOptions = true to Wire kotlin {} config
- Update FieldMetadataDemo to demonstrate the native annotation
- Bump protobufs submodule to metadata-experiment branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Build system changes enhancement New feature or request needs-review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant