Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
This key might be missing altogether
Always "checklist"
Used in:
This key might be missing altogether
This would have been better modelled by inheritance, or better still using oneOf. Unfortunately, inheritance is not supported and oneOf cannot be used with repeated fields.
Used in:
Not present for items, "comment" for section headings
Might be present both for section headings and normal items
Not present for section headings, optional for normal items
The fields below are not fully supported. Specifically, it doesn't seem like actions have a UI. Still, they can be included in template checklists, which breaks the import process. We want to avoid generating empty actions upon export for space and safety reasons. However, we also don't want to ignore all "unknown" fields in general. The "best" protobuf solution seems to dynamically type such fields, e.g. describe `actions` as a raw JSON list.
This key might be missing altogether
ForeFlight has 3 metadata fields for checklists: 1. Tail number 2. Name (not file name!) 3. Detail (make and model) All 3 fields can be empty. If so, the checklist will be displayed as `No name` and exported as `No name.fmd`. If **only one** of these fields (tail number or name or detail) is present, it will be used as identifier **and** as filename. If **multiple** fields are present, then the filename can be either "tail number, name" or "tail number" or "name". The detail always appears below the identifier and is never part of the filename.
Used in:
All objects in the checklist payload have object_id's that are UUID V4 lowercase and without dashes. Presumably these are used for checklist synchronization between devices.
Used in:
Always "1.0"
Luckily always present and has 3 elements
Used in:
This key might be missing altogether