I’ve read several threads about the Local DB component and it seems pretty clear that there is no way to save the data from that structure. I find the Local DB to be a compelling storage component because it’s easy to set up (no Airtable account needed, etc.) and easy to use with the built-in Data Sources blocks (for CRUD).
I really wish we could save that data so that it was available as updated for new app sessions (e.g. if you quit and re-open an app).
What’s the purpose of the Local DB? I can see if for an unchanging data structure like something along the lines of a dictionary or list of possible chess moves but why then have blocks that allow you to update the value in a cell or delete a row as part of the Data Sources menu?
Which data storage type would you recommend for the following situation?
• Small data set (<25 rows, <10 columns)
• Infrequent updates (a user might do something that adds a row once a week or once a month)
• No login necessary, no privacy issues for the data
• Data is unique to each user/device
AirTable and Google Sheets seem possible but a little overkill for what I need. Multiple lists seem straightforward enough but they become a hassle when there are many of them (e.g. 2 columns require only 2 lists but 9 columns require 9 different lists).
One theory is to periodically sync to an external database, using Web API for example, or even Google Sheets.
You could even use the Web API to email a copy of the table perhaps as XML or even CSV, a bit complex, but do-able.
The thing is, that AirTable or Google Sheets, are perfect for little projects as well as large, because they are fast (location dependant) and secondly, they will always be there. The only reason not to use it is App speeds, or if the data is specific to that user (or very small lists) and doesn’t need to be in the ‘cloud’.
But for the sake of backups, and data corruption, storing that data elsewhere is at least a sensible option, even something as simple as a shopping list is potentially better on the ‘cloud’.
@appspark.uk so let’s take a shopping list as an example because that’s not too far from what I’m trying to do.
A local storage options seems like the ideal solution to me because it doesn’t need to be in the cloud but it does need to be unique to that device (or user).
Airtable and other spreadsheet options seem complicated when I throw in the fact that it needs to retain unique data for each device. Then I have to assign IDs and pair each row to that ID.
@drted that’s actually not a bad idea. I’ve done a lot with JSON parsing and Web APIs but I haven’t built and updated my own JSON objects. Maybe I’ll give that a go as a way of using a stored variable.
Edit: but then I don’t think I can use a custom data viewer list. Because that has to be tied to a spreadsheet object.
If you add the OneSignal module it will automatically assign the device a unique ID. I don’t think you need a OneSignal account, just add the module and it should generate an ID which you can get in the Blocks. I’ve actually used that before, with the Text Filter Block, to remove the hyphens and get a decent unique ID. A similar idea is to use the Seconds Since 1970 Block, remove the decimal point, and add some letters.
If you did happen to use Firebase DB and Authentication, you can create rules that allow users access to (read and write) only their own data.
Example:
// Checks auth uid equals database node uid
// In other words, the User can only access their own data
{
"rules": {
"list": {
"$uid": {
".read": "$uid === auth.uid",
".write": "$uid === auth.uid"
}
}
}
}
That would allow safely saving ‘list’ data in case the user clears their app data, but also the ability to sign-in on multiple devices
You should also be able to create an anonymous Firebase login if you don’t want users to do it themselves.
If you absolutely want to only store the data on the user’s device, you may struggle to find something that persists without storing it outside the app (i.e. on the user’s SD card or internal storage), which I don’t think Thunkable does.
I got clarification from @Jane, part of the Thunkable staff:
"The local DB component is a component that pre-dates the Data Viewer and Data Source features.
A Local Data Source is what is shown in the above screenshots, where you add a Data Source to your app, and choose to create a data source locally in your app, instead of connecting to a Google Sheet or an Airtable DB.
Data saved to a Local Data Source will persist between app sessions."
I am still not comfortable with the idea of using stores variables for storing large chucks of data on the phone.
My scenario is a quiz app, with 8 subjects and hundreds of rows of data, images inclusive.
Local DB works perfectly fine Offline, if you manually enter the data during design phase and the data is available permanently after installation.
However the challenge is , based on different schools , quiz questions do change over time and it may be necessary to update some questions or even delete some.
So Local DB does not have this capability, but WE WISH IT HAD .
I am thinking of how to do the update offline then just post an update on play store which updates the new questions and deletes the old ones, though it’s really taking us back to the stone age.
Remember that ,I insist on offline functionality because,
My community has internet only in the school compound.
Students have government provided laptops which the need to use at home for assignments
So I need a solution for tailored for offline connectivity
I am curious, what makes you uncomfortable with stored variables?
I was skeptical at first, but I have found them reliable. I now store permanent data in firebase, and only refresh if the device is online. You could also use this strategy with a Google sheet data source for permanent storage and refresh locally when online or on demand.
Stored variables work great. What about, if the students are coming to school on a regular basis couldn’t they check in on their app. When they check in on their app the app can check in with an online database. If there is a change in the database it updates the value is stored in the phone. Would something like that work for you?
