TCN Lost on iPhone

[SSNimnicht]

Describe the bug
While noting the issues documented in TCN is not changing in Debug screen #256, I saw my TCN for my iPhone 7 disappear. It still (several hours later) has never reappeared. I had loaded onto my iPhone 7 with iOS 13.5.1 commit c36a5bd of develop branch.

To Reproduce
Steps to reproduce the behavior:

1. Open CoEpi and select Debug at bottom of Home Screen.
2. On BLE tab, note My TCN is filled in.
3. Navigated away from BLE Debug Screen to Logs Debug Screen or into App and then navigated back to BLE Debug Screen.
4. My TCN section is no longer populated. (See picture attached--TCN_Disappeared_on_iOS)

Expected behavior
The TCN should change every 15 minutes and should not disappear.

Screenshots
Screenshot 1 is Pixel 2 phone that 'saw' my iPhone 7.

Screenshot 2 is iPhone 7 losing its own TCN, but still seeing the Pixel 2.

[ivnsch]

Related: #258

[ivnsch]

@SSNimnicht Did you notice if after the TCN disappeared it was still detected by another device?

[SSNimnicht]

@i-schuetz Yes. Screenshot 1 of my Android seeing the iPhone remained constant. As in when my iPhone lost its TCN, the Android still displayed it under the discovered section. Even after closing the application and reopening it this morning, the Android still shows that same screen as inserted above.

[ivnsch]

I can't reproduce this issue. Anyway, to provide background:

1. On iOS (sender) / Android (listener) case, as per doc, iOS will write its TCN to Android.
2. iOS will write its TCN/generate it only if it hasn't yet (based on a temporary Android identifier).
3. iOS doesn't have a timer to update its TCN (doesn't seem needed, since it's either generated on demand when receiving a read request or written to Android, but not continuously broadcasted, like in Android).
4. The debug display updates only when the TCN generation callback is called.
5. The BLE background service is longer lived than the non-background code, which means that the cache used to determine whether it should write the TCN (2.) can survive restarting the app. So there's a possible situation where only the "frontend" is restarted and since, because of the cache, the TCN generation callback will not be called, it doesn't have a TCN to show. It's unclear how this situation can happen with the steps described here though, as navigating between tabs or screens of course doesn't restart the app and there don't seem to be other actions that could invalidate the frontend-cached TCN (BleAdapter.myTcn).