Only use check-ins of last 15 days (EXPOSUREAPP-5910)

[LukasLechnerDev]

Even though we have a worker that deletes all stale check-ins, it's still possible to have stale check-ins in the database because the worker runs only once a day.

This PR adds another function to CheckInRepository, called checkInWithinRetention. This function only returns the check-ins which end date isn't older than 15 days.

This new function is now used:

• CheckInViewModel: To not show outdated check-ins
• MainActivityViewModel: To not include outdated check-ins in the badge-count in Bottom Nav
• SubmissionTask: to not submit outdated check-ins
• CheckInWarningMatcher: To not match outdated check-ins

I also refactored the retention logic of TraceLocations by also adding a traceLocationsWithinRetention property to DefaultTraceLocationRepository.

[vaubaehn]

@LukasLechnerDev
Hi Lukas, some short questions to understand the idea behind this PR:
Why did you decide on 'hiding' the stale check-ins until the worker is run, instead of cleaning the database when the app is openend/going to foreground? Does database cleaning take much time or could cause any conflict in the opened app? Could there be any scenario, where a stale check-in could cause a problem (bug) but cannot easily be spotted by the users, because it's hidden?

[LukasLechnerDev]

Hi @vaubaehn ! Great questions!

Why did you decide on 'hiding' the stale check-ins until the worker is run, instead of cleaning the database when the app is openend/going to foreground?

We decided that doing it on every app start is not enough (apps can be started and running for a long time) and doing it every time the app is brought to the foreground is too much :). Either way, we still could have outdated check-ins as some time will pass from the point in time when the user opens the app or brings it to foreground and then sees the check-ins or submits the check-ins.

Therefore, I think it is best to just load the up-to date check-ins whenever we need them and also let a worker run daily to clean up all outdated checkins.

Does database cleaning take much time or could cause any conflict in the opened app?

I don't think it takes that much time. One issue we could have if we clean the db when the user is currently in the check-ins screen could be that suddenly some outdated check-ins disappear.

Could there be any scenario, where a stale check-in could cause a problem (bug) but cannot easily be spotted by the users, because it's hidden?

I can't think of such a scenario ...

[vaubaehn]

@LukasLechnerDev
Hi Lukas, very convincing answers!
Thanks a lot for your thorough reply, hope it didn't steal much of your time.
I can follow you in all points, and I now understand why increasing complexity a bit here is a good idea.
The only critical point for possible issues then is the consistent usage of checkInWithinRetention function and traceLocationsWithinRetention property always and everywhere (but db cleaning), and not to mix up with allCheckIns, right? Could it then be helpful for future 'CWA newbies' to add a short comment on when to use allCheckIns and when to use checkInWithinRetention and traceLocationsWithinRetention to the basic repos (i.e., CheckInRepository.kt) to avoid confusion and mix up?

I'm very excitedly looking forward for release 2.0, pressing all thumbs and wishing it to become a great success!

[LukasLechnerDev]

@vaubaehn Thanks for your feedback. You are right, it's definitely useful to document these functions better. I have added a commit (see above 👆)

Thank you for your wishes! We are also very excited for 2.0 🚀

[mtwalli]

Thank you! 😊

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

93.6% Coverage
0.0% Duplication