wger-project
Save exercises in local database
At the moment, the exercises are loaded from the server and the JSON dump saved to local preferences. Among other things, shared_prefs should not be used to store data. It would be better to use something like drift to properly store them in a database which then could be bundled as an asset, further speeding up the startup process (with some kind of update process built on top of this). Since this is a regular sqlite database, it would be perhaps easier/faster to create it on the server and download it on demand.
Having this database would also make it easier for feeel to use the exercise database, but in this case it would be perhaps better medium term to move everything out to a separate package.
Also please note, that having a text field were we simply dump the exercise JSON we get from the server is perfectly ok, then we don't need to add yet another import logic
https://pub.dev/packages/drift https://gitlab.com/enjoyingfoss/feeel
Hey, @rolandgeider right now we are using shared_preferences in a scattered manner to currently dump our app data. What I want to suggest is we use shared_preferences in a more inclusive manner by combining the data we want to store into a class like this:
// Use this as the central cache manager
class AppData {
SharedPreferences? _sharedPreferences;
// We can initialize these lists at the splash screen or
// as the user progresses in the app
List<Exercise> exerciseData = [];
List<Equipment> equipmentData= [];
List<Muscle> muscleData= [];
List<ExerciseCategory> excerciseCategoryData= [];
List<NutritionData> nuritionData = [];
Future<void> initSharedPrefs() async {
_sharedPreferences = await SharedPreferences.getInstance();
}
// .. Helper getters and setters below
}
Instead of making multiple requests for the cached data we will store them as one JSON key-value pair like this:
{
"excerise_data": [],
"equipment_data":[],
"muscle_data":[],
#... so on
}
At the startup the server can return such a JSON for particular user id and we can simply refresh our cache at startup itself.
You mean as a partial refactoring before moving the stuff to the database?
Umm not exactly, what I am suggesting is that we use shared_prefs as our database itself. Because I wasn't able to found another viable alternative for it...
A thing we could do is save the data in a .json file in local storage which will store our cache. But then we have to ensure data confidentiality and read/write speeds at our ends.
I see what you mean. Yes, moving to a real DB is going to be quite a bit of pain, but we might be able to use some of the code that the developer of feeel is doing in the drift branch later on.
In any case, I agree with you that having everything in one class is much better. I'd suggest moving the discussion to a new issue, so we can keep this one more focused on the db aspect.
Hey @rolandgeider, I am really sorry to tell you that I won't be able to work on this issue, due to college and placements. Lots of love to the project 💚