Proximity Beacon API が最初に発表されたとき、私が想像した使用例は、クライアントによって取得されたメタデータ (添付ファイルとキー/値のプロパティ) が現在そのデータを表しているビーコン ハードウェアとは別であるため、ビーコンフィールドの置換が簡素化されたシステムを作成することでした。 (本質的にはAdvertisedId)。
私の考えでは、アタッチメントとプロパティはビーコンの役割(バス停 X、店の正面玄関など) を表していましたが、必要に応じてハードウェアをその役割に交換することができました。つまり、ビーコンが故障して交換が必要になった場合、API を使用しAdvertisedIdて同じ役割の新しいビーコンを簡単に登録/アクティブ化し、古い (故障した) ビーコン ハードウェアを非アクティブ化/廃止することができます。
このユースケースが現在の API で実際に可能かどうかを判断するのに苦労しています。登録時にビーコンに名前を付けることはできず (AdvertisedId のバージョンに自動的に名前が付けられます)、AdvertisedIdその後の更新では無視されます (したがって変更できません)。
私が言える最善の方法は、「現場でビーコンを交換する」唯一の方法は、新しいビーコンをアクティブにして、すべての添付ファイル/プロパティ/その他をコピーすることです。古いインスタンスから。API での関心の分離を誤解していませんか? API の外部でそれを管理するためのビーコンロールを作成する唯一の方法はありますか? ビーコン フィールドの交換は、設計のコア テナントのように思えました。