Poor performance due to missing caching #72
Comments
We also need a mechanism to detect if the user enabled the token to access the calendar. And remind the user to enable it. |
The calendar is the only thing being cached so far. Exactly for this reason. It's stored in an xml file. And updated in 7 days |
@mathiasquintero If the user forgets to enable calendar access on the first app launch does he have to wait for 7 days to get a calendar? |
Not a problem. The Manager checks the last modified date of the file. If there's no file or the date is older than 7 days: it tries to fetch the calendar again. |
Ok my calendar might have another issue then... |
I'll check it anyway. Maybe the API has changed somehow |
yea, we should cache all the things! |
I personally think caching should have a lower priority. Let's finish the features. Then we can start working on a new caching layer for every manager |
sure |
If you gonna spam the TumOnline API, they will turn it off for good. @xsrf right? ☠️ |
I would move this to the release after 1.1. It's still High Prio. But it will require rethinking our architecture to add a caching layer without too much copy and paste |
So from what I've tested the app does not seem to cache most of the data. Most noticebly it happend several times that the app was unresponsive due to load some data (10-20 seconds in the case of the calendar).
We will run into problems with the TUM. Especially the calendar uses a lot of resources on their mainframe. That should be updated once every 7 days or so at the very most! (Ask @xsrf for more details on this)
Please take a look at the Androids caching mechanics: https://github.com/TCA-Team/TumCampusApp/blob/master/app/src/main/java/de/tum/in/tumcampusapp/managers/CacheManager.java
The text was updated successfully, but these errors were encountered: