This is the setup:
The App has only one screen, a form, that uses a single row database with all “User Specific” columns.
When you submit the form, a public post is created in a second database, and that post is shared by the user, using a link to current screen as a “sharing link”. The link will take you to a detail screen created from the row of that post.
The App will be public without users nor sign in. And it’ll work more as a website than an app (although you’ll be able to “install it” if you want).
The user’s journey will be simple: You open the app, fill the form, see the detail screen with your post, and share the post with someone or in social media.
Let’s imagine that 1.000 posts are created by many users. Or let’s say 10.000. Those posts will live in the second database.
HERE’S MY QUESTION:
Are those 10.000 posts being downloaded in the background to the user’s local app every time a user enters the “fresh” app to fill the form and create a new post?
I’m trying to create a fast and light weight app. If the scenario is that one (all the posts are always downloaded in the background), I don’t think this is the right approach.
I’ve been thinking in an alternative: creating a second app for storing the posts and displaying them publicly, and managing a system to populate the posts’s database of that app, from the first app (the one for the post creation).
I’m in a pro plan, the 99 USD one.
Thanks in advance for the assistance and sorry for the long explanation.
Cheers!
I believe that once info from your Posts Table is displayed somewhere in the current App, all 10,000 rows of data from that Posts Table are downloaded onto the Users device.
If that is indeed the case, then you’d be better off having the one app to just collect the form data and using the second App to display your post data.
I’d let someone else chime in to confirm.
Last I heard, Big Tables queries only the necessary data. So not sure if you want to show a single row, that it will only query that single row , making load time faster. My assumption is that it would be because Big Tables can store up to 10M rows, which would take a long time to show only 1 row.
If someone else can add more info on this stuff I’ll be grateful.
I think that If the supposed 10.000 posts are downloaded to the user’s device ONLY when the user finishes creating his present post (and in order to display THAT POST the app calls the 10.000s) I think is not such a big deal. My concern was that the App could call all that data from the 10.000 post at the beginning, when the user was opening a fresh instance of the App to create a new post.
Of course it would be better to only download the post the user just made (and not ALL the posts to filter by the relation that shows only that one post) in order tho display it.
Probably the answer could lie on using Big Tables as the POSTS ARCHIVE database and maintain everything in the same App . But honestly I’ve never learned what Big Tables are, and what are the pros and cons of using those instead of regular Glide Tables. But I’m just a Google search away of that knowledge…
Well Big Tables are brand new and require going up to a Business Plan, so there is a cost involved. In addition, it is my understanding that each Big Table query will cost 1 update vs Glide Tables = 0 updates to display the data.
Also, I believe with normal Glide Tables, that the data is downloaded NOT when / if a user actually views a screen or component attached to that table, BUT if any part of your app calls that data.
So for example, if your first Tab is the form and a second tab displays posts, even if the user never accesses that second Tab, because it still displays all your post data, all of it will still download. I think its to help the app run faster than having to wait to load data every time you switch screens/tabs.
Big Tables however will query data only when requested.
Using 2 different apps could be your solution, but if you want to redirect the user to see posts after they finish, they would be sent to a new App in a new window, unless you have a Business Plan where you could embed one app inside another.
Thanks for the fast response and the complementary info!
My App doesn’t call the posts archive from start.
Btw no one can access the whole archive of posts.
The user only can access his own recent post just at the end, when he post it, and a new record is added to the archive.
Just then the app calls the archive to show the user his recent post (using a relation between the app’s single row database and the posts database) in order to him to share it with someone. I guess is then when the App downloads all the archive to the user’s device.
It’s a kind of virtual postcards stuff (not exactly that…)
You create your own, post it to the intern archive database, and then share the “link to this screen” with someone. That someone and you, will only have access to THAT post, without being able to see other posts created by others (unless you modify the shared url with random characters until you find the right combination and see another person’s post, but it won’t be sensitive information at all. Just silly stuff.
