What we’re trying to to do is to create a basic app in which you can input information and then recall or change that same information later. We are using lua. We know how to create different views and buttons and make regular text boxes. We want to have a place where someone can put in some information then later the information can be displayed when a certain set of conditions is present. This information shouldn’t be lost if the app is closed, but it should be saved. Any ideas of how to do this?
There are three ways to go about this.
1. Store your information in flat files inside your app’s sandbox (protected area only your app can access)
2. Store your information in a database (we have SQLite3 available)
3. Store your information in an online database or file server.
Each has it’s pros and cons. For instance the first option is good for loading and saving Lua tables using JSON. There are several “save settings” type routines in the community code for that purpose. But when you read it back in you read the whole table and save the whole table. For large volumes of data, or data that has relationships, this isn’t very practical. But for smaller data sets where you’re really keeping it all the data in memory, it works pretty well. (You can have multiple files!)
The internal SQLite3 database also stores its data in your sandbox, but it does it using a database engine. You can have multiple, related tables and using query strings only retrieve the data you’re looking for, like only one record or everyone with a zip code of 23456. The bulk of the data stays on the devices file system and you only work with little chunks at a time. For large data sets, this provides the most efficient way to manage the data (assuming you’re not loading it all) and lets you set up relationships between tables. The downside is, well it’s complex. You need to be pretty good with SQL, understand relational databases and have a more complex code base to manage retrieving and updating data in the database.
The third option can be either one of the 1st two, but you’re choosing to store the data online (in the Cloud as everyone likes to say today). You can manage simple flat files through various things like FTP or using network.upload() and network.download() to move all of your data at once on a file by file basis. Or you can do SQL type database access with various services or your own webhost.
Of course this adds the complexity of you having to manage getting data to and from the online service where the data is kept, which could involve writing some server side code in a language like PHP, but the benefit is that it will survive them deleting your app and it’s possible to share the data with other people. All benefits that may be worth the extra hassle of dealing with online data.
There are three ways to go about this.
1. Store your information in flat files inside your app’s sandbox (protected area only your app can access)
2. Store your information in a database (we have SQLite3 available)
3. Store your information in an online database or file server.
Each has it’s pros and cons. For instance the first option is good for loading and saving Lua tables using JSON. There are several “save settings” type routines in the community code for that purpose. But when you read it back in you read the whole table and save the whole table. For large volumes of data, or data that has relationships, this isn’t very practical. But for smaller data sets where you’re really keeping it all the data in memory, it works pretty well. (You can have multiple files!)
The internal SQLite3 database also stores its data in your sandbox, but it does it using a database engine. You can have multiple, related tables and using query strings only retrieve the data you’re looking for, like only one record or everyone with a zip code of 23456. The bulk of the data stays on the devices file system and you only work with little chunks at a time. For large data sets, this provides the most efficient way to manage the data (assuming you’re not loading it all) and lets you set up relationships between tables. The downside is, well it’s complex. You need to be pretty good with SQL, understand relational databases and have a more complex code base to manage retrieving and updating data in the database.
The third option can be either one of the 1st two, but you’re choosing to store the data online (in the Cloud as everyone likes to say today). You can manage simple flat files through various things like FTP or using network.upload() and network.download() to move all of your data at once on a file by file basis. Or you can do SQL type database access with various services or your own webhost.
Of course this adds the complexity of you having to manage getting data to and from the online service where the data is kept, which could involve writing some server side code in a language like PHP, but the benefit is that it will survive them deleting your app and it’s possible to share the data with other people. All benefits that may be worth the extra hassle of dealing with online data.