Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Infinity scroll for old tasks #88

Open
Sanat-Jha opened this issue Dec 23, 2024 · 5 comments
Open

[Bug] Infinity scroll for old tasks #88

Sanat-Jha opened this issue Dec 23, 2024 · 5 comments

Comments

@Sanat-Jha
Copy link
Collaborator

Describe the bug
After a long period of using the app, the user will have a long list of complete old tasks and opening the app will load all the tasks from storage which is needless and will heavily slow down the app.

Expected behavior
There should be infinity scroll loading of tasks. Which means tasks should be loaded in a set of 50 to 100 tasks and the next set will be loaded only when the earlier one is scrolled till bottom.

@sommye-ctr
Copy link
Collaborator

Currently I don't think this is possible. Since we are using shared preferences to store the data (by converting the whole list of tasks into a json string), how would one implement pagination in this scenario?

@Sanat-Jha
Copy link
Collaborator Author

Currently I don't think this is possible. Since we are using shared preferences to store the data (by converting the whole list of tasks into a json string), how would one implement pagination in this scenario?

but we can just change the way of storing the task from a continous list to sets of list which SP key can be a index of the set.

@sommye-ctr
Copy link
Collaborator

Using SharedPreferences inherently has a limitation: it loads all the data from the disk into memory during initialisation. Once initialised, queries retrieve data from the in-memory cache, not directly from the disk. Therefore storing in whatever way, if the dataset gets huge shared preferences starts to become a problem.

@Sanat-Jha
Copy link
Collaborator Author

Using SharedPreferences inherently has a limitation: it loads all the data from the disk into memory during initialisation. Once initialised, queries retrieve data from the in-memory cache, not directly from the disk. Therefore storing in whatever way, if the dataset gets huge shared preferences starts to become a problem.

you are right but only when we are saving all our data in one SP instance, instead what I am talking about is saving the data in sets of tasks where every set is a different instance of SP.

@sommye-ctr
Copy link
Collaborator

sommye-ctr commented Dec 24, 2024

I still think deleting and editing would be a bit more hassle to do so for trade-off of negligible performance optimisation in comparison to using a room db itself. Anyway, it still can be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants