接触確認を行った最新の日時をホーム画面に表示する

[keiji]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

#106 (comment) より

ぜひ実装していただきたいですが、この通知機能を実装する前に、診断キーのダウンロードの最新時刻がユーザーから確認できるようにして欲しいです。
理由：現状ユーザーは「N日間使用中」という事しかわかりません。そこへ、いきなりの通知を見て、「毎日使用していたのに、実は７２時間使えていませんでした」と受け取られれば、ユーザーの怒りを買います。
参考までに、ドイツのCorona-Warn-Appのdeadman では、最新時刻が以下のように変数に代入されています。
https://github.com/corona-warn-app/cwa-app-android/blob/de207de84a795dad78229913458509a3d5da8ae9/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/deadman/DeadmanNotificationTimeCalculation.kt#L31
同じことが出来る場合、例えば「陽性者情報の入手時刻」としてユーザーに提示してください。この時刻が毎日更新されるだけでも、「動作してる感」は増えると思います。

解決策についてお書きください / Describe the solution you'd like

接触確認を行った最新の日時をアプリのホーム画面に表示する。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

iOS, Androidともにシステムから接触確認の記録を見ることができるので、そちらを案内する。
ただし、ユーザー負荷は下がらないと思われる。

---

Internal IDs:

• PBI 2155
• PBI 1797

[i-maruyama]

issue 登録、ありがとうございます。 git GitHub 初心者で無作法でしたら、ご容赦ください。

きっと、GetLastProcessTekTimestamp @ ExposureNotificationService.cs を使うのだと思いました。

cocoa/Covid19Radar/Covid19Radar/Services/ExposureNotificationService.cs

Line 162 in 872cc86

public long GetLastProcessTekTimestamp(string region)

これは、以下で使われる SetLastProcessTekTimestamp @ ExposureNotificationService.cs と対をなすものだと思います。

cocoa/Covid19Radar/Covid19Radar/Services/ExposureNotificationHandler.cs

Line 172 in 872cc86

exposureNotificationService.SetLastProcessTekTimestamp(serverRegion, newCreated);

私は preferencesService や httpDataService について不明なのですが、同じ仕組みで Tek の時刻だけではなく、Tek リスト長さも set,get できると思いました。

  exposureNotificationService.SetLastProcessTekTimestamp(region, newCreated);
+ exposureNotificationService.SetLastProcessTekCount(region, tekList.Count); // add
  loggerService.Info($"region: {region}, newCreated: {newCreated}");

このための修正は、

• ./Covid19Radar/Covid19Radar/Common/PreferenceKey.cs に LastProcessTekTimestamp と同様に LastProcessTekCount を追加
• ./Covid19Radar/Covid19Radar/Services/ExposureNotificationService.cs に SetLastProcessTekCount, GetLastProcessTekCount の関数を新規追加
• ./Covid19Radar/Covid19Radar/Services/ExposureNotificationHandler.cs#L172 の SetLastProcessTekTimestamp の下に、SetLastProcessTekCount(region, tekList.Count); を追加
• アプリのホームに表示(例)
• 1行目：2021年1月1日から 10日間 使用中
• 2行目：直近14日の陽性登録 1,234 件 (ただし、下記予想が正しい場合）
• 3行目：更新時刻 2021年1月11日 09:00:00
• 4行目：「陽性者との接触を確認する」ボタン

という感じです。ただし、上記予想は間違いかもしれません。 tekList は

 List<TemporaryExposureKeyExportFileModel> tekList = await httpDataService.GetTemporaryExposureKeyList(region, cancellationToken);

と定義されており、私は、下記urlの陽性登録件数の累積値（？）のうち、１４日間の陽性登録件数になると予想していますが、予想にすぎません。

https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/cocoa_00138.html

以上、不正確かもしれませんが、コメントいたします。ここに貢献されている皆様には、感謝するとともに大変期待しております。

[i-maruyama]

git ではなく GitHub に不慣れということですね。(直しておきました）

アプリケーションを開いて確認するユースケースでは LastProcessTekTimestamp は通常アプリケーションの起動時刻になります。

この辺り、少なくとも、私は以下の３つに混乱していました。

• (1) :ユーザーがアプリで「陽性者との接触を確認」＝ボタンOnClickExposures, exposureNotificationService.GetExposureCount()＝（別 issue 「陽性者との接触確認　○件」と表示されましたが、陽性者との接触から14日以上を経過しても元の画面に戻りません #121)
• (2) :アプリが OSへ「接触確認」＝元issue 一定時間、診断キーのダウンロードと接触確認が行われなかったときにユーザーに通知を表示する（Watchdog）機能 #106 で議論＝ (本issue 接触確認を行った最新の日時をホーム画面に表示する #128 の代替案、「アプリによる接触確認の履歴」)
• (3) :アプリがサーバーから「TEKダウンロード」＝ LastProcessTekTimestamp

そもそもは、通知「接触確認が完了していない」により、(1)のボタンを連打するユーザーを想像し、問題は(1) と(2)が両方「接触確認」である事と思ったのですが、結局は本 issue にもある私の表記「陽性者情報の入手」というのは、(3)を指すべき文言ですね。

さて一方で、私の提案は、本質的には「情報はユーザーがアプリで確認可能にして」という事です。上記に関連するのは、

• (1) の GetExposureCount の前回日時(あるいは secureStorageService の更新日時)
• (2) の 接触確認の日時とキーの数（と一致の数）
• (3) の TEK ダウンロード日時 LastProcessTekTimestamp と tekList.Count

ですが、(2)だけはソースコード的に可能なのか、まだ分かってません。探しているうちに、(3)だけでも「ホーム画面に表示する」ことができるなら素晴らしいと思って、上記コメントになっています。通信制限ぐらいなら (3)だけでも、ユーザーが認知できるとは思います。

ちなみに実は、要望の多い「単なる接触人数」についても xamarin の外まで探索していました。iOSなら storedAdvertisementCount @ ENAdvertisementDatabase.h がキー数かなと思ったのですが、分かってません。

[keiji]

ぼくはホーム画面には最後に接触確認を行った日時を掲載するのみに留めるのが妥当と考えています。

単なる接触人数についてはGoogle/AppleのExposure Notification APIには用意されていないので、COCOAではやらない（できない）と認識しています。

また、配信されているTEK（Temporary Exposure Key）の数＝陽性登録数ではありません。
一人の要請登録者から複数のTEKが提出されることは普通にあります。あるTEKがどの陽性者に紐付くかはExposureNotificationの性質的に、できない（するべきではない）ことになっていると理解しています。

一方、すでに指摘されているように、アプリを起動すると初期化処理中にバックグラウンド処理が実行されるので LastProcessTekTimestamp が更新されて、利用者がホーム画面を見た時には接触確認ができているように見えてしまうという課題はあります。

LastProcessTekTimestamp が更新されるのは、現在のLastProcessTekTimestampより新しいTEKが存在してダウンロードと接触確認を行った場合になります。もしLastProcessTekTimestampより新しいTEKが存在しなければLastProcessTekTimestamp
は更新されませんから、LastProcessTekTimestampは必ずしもアプリの起動日時とは合致しません。

バックグラウンド処理の成功日時を表示するという提案に関してですが、現在のCOCOAではバックグラウンドでの接触確認の成否とフォアグラウンドでのそれを分けられるように作られていないと認識しています。やるとしたら結構な大事になるので、別の課題として取り扱った方が良さそうです。

本IssueのDescriptionの内容（ホーム画面に最後に接触確認を行った日時を掲載する）の方法でも、アクセス制限のあるネットワークに接続しているなどの理由でCOCOAがサーバーにアクセスできず、実は接触確認ができていなかった」ケースを拾い上げることができるので、まずはそこからやっていく方向で開発チームと相談したいと考えています。

バックグラウンドで実は動いていないというケースをどうカバーするかという点に関しては、ぼくとしてはWatchDog ( #106 ) で検討したいと考えています。もちろん、もっと良いアイデアがあれば、提案お待ちしています。

[i-maruyama]

お二人とも、ご対応と情報ありがとうございます。

どのような情報を確認したい（させたい）のか。それを知ることによってユーザーがどのような利益を得るのかをもう少し具体的に説明して貰えると助かります。

利益というより、キー数はCOCOA普及の一助に、日時の表示はCOCOA動作の理解に繋がると考えています。私が想定するのは、例えば「陽性者との接触を確認する」ボタンを電車乗り換える毎に押して安心するようなユーザーです。このようなユーザーを怒らせない（失望させない）ことが重要ですが、動作が不明すぎる現状は問題です。

またユーザーの利益だけではなく、開発側（新規参入者）に必要な情報だと考えます。
実際、私は上記(3)などを実装し、数日様子を見てみました
が、 LastProcessTekTimestamp はアプリ起動時刻にはならず、 https://covid19radar-jpn-prod.azureedge.net/c19r/440/list.json の最新日時になります。

まずはそこからやっていく方向で開発チームと相談したいと考えています。

何をするにしても、開発側にとっては負担ですので、少しずつ進むことを期待しております。

単なる接触人数についてはGoogle/AppleのExposure Notification APIには用意されていない

詳細な説明をいただきお手数おかけしましたが、ありがとうございます。接触人数ではなくBLEの接触キー数で十分ですが、これも無いようですね。ドイツ側で何度か issue 化されていますが、進展は不明でした。

とりあえず、私が作ったデモページは別 issue にしたいと思います。
https://github.com/i-maruyama/cocoa/tree/demopage

[i-maruyama]

[i-maruyama]

現在確認している範囲では、LastProcessTekTimestamp と teklist.Count は https://covid19radar-jpn-prod.azureedge.net/c19r/440/list.json の最新日時と件数(zipファイル数)になります。

この件数(zipファイル数)が数日、 122 で一定値です。ファイル自体は更新されていきますが、総数は変わりません。また、ファイルの最初のいくつかは非常に古い日付になっています。こういう仕様なのでしょうね。皆さんご存知だったかもしれませんが報告します。

ともかく、件数(zipファイル数)が一定値なら teklist.Count はユーザー向けには意味は無いです。(私の当初の意図はzipの中の export.bin にあるキーの数を見れば良いですが)

• 陽性情報の最新日時 LastProcessTekTimestamp : 毎日深夜更新で、各ユーザーで同一なので、友達と比較すれば自分の情報が最新かどうかが確認できる。(現ログにあり)
• 接触確認(C19R submit batches)の最新日時 : これが issue の確認日時に対応する。ほぼ１日１回更新され、バックグラウンドまたはアプリ起動時刻になる。(現ログにあり)
• 接触確認のzipファイル数 downloadedFiles.Count : 日々変動するが、動作確認は日時で出来るので、ユーザーメリットは少ない。デバッグページにあってもよい。(現ログにあり)
• 陽性情報の zip ファイル数 teklist.Count : 一定値(122)なら無意味。デバッグページにはあっても良い。ログだけでも良い。(現ログになし)

上の２つは、有用だと思いますが、いかがでしょうか？

接触確認(C19R submit batches)の最新日時は、

cocoa/Covid19Radar/Covid19Radar/Services/ExposureNotificationHandler.cs

Lines 170 to 172 in ed5b702

	await submitBatches(downloadedFiles);
	exposureNotificationService.SetLastProcessTekTimestamp(serverRegion, newCreated);

に現在時刻をセーブする機能を追加して実験していました。

[i-maruyama]

DebugPage #160 と、Debug_Mock #179 は軽いのですが、こちらはリリースにかかわる重い案件だと思います。少なくとも、

1. 実装方針の設定
2. ページデザインの設定
3. 英語・日本語・中国語の準備

の三つが必要です。

実装方針として、最初の案は、

cocoa/Covid19Radar/Covid19Radar/Services/ExposureNotificationHandler.cs

Lines 170 to 173 in ed5b702

	await submitBatches(downloadedFiles);
	exposureNotificationService.SetLastProcessTekTimestamp(serverRegion, newCreated);
	loggerService.Info($"region: {serverRegion}, lastCreated: {newCreated}");

のところに、

+                    exposureNotificationService.SetLastSubmitBatchesTime(serverRegion, DateTime.Now);

のように追加するという方針で,「 submitBatch が成功した最新日時」という意味での接触確認日時の実装が可能でした。

一方で、 ENSは重要部分なためユーザーへの通知程度に使うのは避けた方がよいという考えもあり、例えば

+                    UserDataService.SetLastSubmitBatchesTime(serverRegion, DateTime.Now);

のような方向もありえます。

良案がありましたら、ご教示ください。

[keiji]

こちらはリリースにかかわる重い案件だと思います。

そうですね。デザインにも関わってくるので開発チームと相談して方針を決める。場合によっては開発チーム側での作業が良いかもしれません。ここは確認します。

[keiji]

これは @cocoa-dev 預かりになりました。

というのも、このIssueに合わせて接触確認APIの動作状況の表示、WatchDog機能（ #106 ）などを段階的に導入することが検討されていて、そうなるとUIに比較的大きな変更が加わることが予想されます。個別にやるとデザインが破綻する危険性があるので、現在開発チームのデザイナーさんにデザイン調整を依頼をしています。

よろしくお願いします。

[i-maruyama]

了解です。 本 issue については、

1. ホームページやUIの改変を始める前に、先行して、追加機能（接触確認日時の変数追加）の master へのマージと導入報告を行っていただき、
2. それを DebugPage, Debug_Mock 側に反映させ（ますので）、
3. バグ出し等をこのコミュニティにも担当してもらう

という方針を提案しますので、開発側でご検討ください。

ところで、機能的には「接触確認の日時の追加」が必要と推察していますが、実装は簡単です。より難しいのは、それを日本語でどう表記するか（どうすれば一般ユーザーが理解できるように表示できるか）です。私が実装したときも、結構悩み、上記の demopage も最善とは思っていません。そもそも「N日間使用中」は、あまり意味のない情報です(なぜなら単なる StartDate と現在時刻の引き算です。しかもリロードしなければ変更されないので、実は古い日数のまま）。

本issue では「接触確認の日時」を追加する案となっていますが、真のゴールは、例えば「現在 M月D日、正常動作中」などで、正常動作されていない場合のみ、ホームに日時を表示するなどもありうると、今は考えています。

おかげさまで、 demopage が随分ましになって PR #191 にまとまりました。 （その過程で、issue #167 & PR #168 、issue #169 & PR #170 を Close しました。レビューしていただいたのに遠回りさせて申し訳ありません。）

[kvaluation]

この件数(zipファイル数)が数日、 122 で一定値です。

陽性登録件数が少なくて、1日の配信zip数が13に満たないと、例えば2021年4月5日は、zip数は122ではなく117でした。

また、ファイルの最初のいくつかは非常に古い日付になっています。こういう仕様なのでしょうね。

zip番号　接触日
865　2027/8/25
866　2027/8/24
867　2027/8/23
868　2027/8/22
869　2027/8/21

接触日（rollingStartNumberによる鈴木推定値）が未来となっていて、接触日から一定期間（仕様は14日、現状16日）経過しないので、いつまでも削除されません。

Temporary Exposure Key (TEK) Publishing Guide
https://github.com/google/exposure-notifications-server/blob/main/docs/getting-started/publishing-temporary-exposure-keys.md#server-access-configuration

Keys with a future start time (rollingStartNumber indicates time > now), are rejected.

とあるので、ダミー2027は、想定外の動作をもたらしてしまう可能性もあるかと考え、2020年9月に厚生労働省の窓口にメールでご報告済みですが、現在も残っています。

[i-maruyama]

ダミー2027は、想定外の動作をもたらしてしまう可能性もあるかと

なるほど。もしかして、実験環境下（電波暗室とか）で接触確認テスト用とかなら、意外と良い手かも・・・

バックグラウンド処理の成功日時を表示するという提案に関してですが、現在のCOCOAではバックグラウンドでの接触確認の成否とフォアグラウンドでのそれを分けられるように作られていないと認識しています。

安直に Xamarin 側の DoWork でフラグを立てて、バックグラウンドを認識する仕組みで、実験しています。

#127 にあるとおり、長エネ（省エネ）モードでバックグラウンドは走らないのですが、
「アプリ起動時に、ついでにバックグラウンドが走る」
という動作があり（Aquos sense3lite)、バックグラウンド処理の成功日時を一つ表示していると、アプリ起動時刻になってしまいます。もし表示するなら、複数分が良いという事まではわかりました。

ご存じかもしれませんが、報告しておきます。

[b-wind]

#419 で実装され、 v1.4.0 でリリースされてるっぽい？

[keiji]

されてますね。
夕方くらいにクローズします！

[kvaluation]

zip番号　接触日
865　2027/8/25
866　2027/8/24
867　2027/8/23
868　2027/8/22
869　2027/8/21

2021年9月11日配信分から、この865-869が通知サーバーから削除され、端末に配信されていないことを確認しました。ご対応ありがとうございます。close後にすみません。