Cwa-app-ios: Stop showing conflicting logging status during startup

[christianMurschall]

Avoid duplicates

• [x] This issue has not already been raised before (could not find any: if already raised I will gladly remove this issue.)
• [x] If you are proposing a new feature, please do so in CWA-Wishlist

Current Implementation

During startup the app (version 1.5.1) shows conflicting logging status information. ("Exposure Logging Active" vs "Exposure logging stopped", please see attached image)

After the risk is calculated it turns green and the "Exposure logging stopped" message disappears.
Kindly see recorded startup:

Suggested Enhancement

I would suggest to show a loading screen before the app is displaying the logging status and risk level.

Expected Benefits

The startup is always a source of wondering for me. It confuses me because it makes me think the app isn't working or configured.
Indicating that something in the background is going on would definitely help me

[sin-azucar]

I have the same problem, it seems to appear only when the last risk calculation is more than 24 hours old.

According to this PR: #1048 actually a different card should be shown ("Risikoermittlung nicht moeglich").

(BTW, a little funny to see in the graphs how something simple can be overengineered, but maybe that's just me. 😈 )

As we all know, the background job does not run reliably exactly every 24h, so "Risikoermittlung nicht moeglich" might also be suboptimal from a UX point of view. In any case, "Risikoermittlung gestoppt" is plain wrong and is a bug IMHO. 🐞

[Ein-Tim]

Duplicate of #770

Maybe not an exact one but still very similar so it would be good to focus on one ticket

[christianMurschall]

Okay, I will close this one if favor of #770 .
But please have something done about that. The people in my environment do not appreciate this little game the app plays during startup:
The potential lifesaving app tells my it's not working anymore - couple of seconds later: just a joke everything is in order :)

[Ein-Tim]

@christianMurschall @sin-azucar Is this behavior still the same with 1.7.1?

[christianMurschall]

No it is fixed.
It was fixed with 1.6.0, but unfortunately with 1.6.1 the old behavior was reintroduced.
1.7.1 fixed it again.