07-20-2020, 09:54 PM
We do not recommend the method using two accounts. The only way to do this would be to use two projects for one app. You would have to hardcode your developer credentials in your code so you can use cdb_sdk() to switch between projects. This is a security vulnerability.
The desired behavior can be acheived by using separate tables in the same project. Let me explain.
A newly created project has 2 tables by default, the cdbBlobs table and the cdbUsers table. The cdbUsers table contains a record for every user of this project. In your case, it will have a record for every users of your book app.
Let's say we were to create a "universal" table in this project. When you export the toolkit to your app, the book app will be aware of all tables in this project, including the "universal" table and the cdbUsers table.
When a user signs in you can get their user record using function cdb_readUsersByEmail(pEmail) and store it locally so you can access their personal data whenever you want.
You mentioned the "universal" data would be updated often. You have a couple options for this: cdb_sync() with "local" reads or stricty "cloud" reads.
You can perform "cloud" reads on the "universal" table so your user always sees what's on the cloud. Using "cloud" reads will be the closest to realtime data but will be less performant. (This might be the best solution for you if you're ok with the performance of the "cloud" reads)
Or when a user signs in, you can use function cdb_sync(pRecordIDL, pTable, pSource, pAllowDeletes, pDetectCollisions) with "cloud" for pSource on the "universal" table. This will download the current data on the cloud so it can be accessed locally. Using sync with "local" reads will be more performant but there's a chance the user can see stale data if anything on the cloud changes after the sync is called. You can perform this sync as often as you like so your user doesn't see stale data but it will affect performance.
Your app will have both the universal data and the user data so you can use them both as desired when a page is flipped.
The desired behavior can be acheived by using separate tables in the same project. Let me explain.
A newly created project has 2 tables by default, the cdbBlobs table and the cdbUsers table. The cdbUsers table contains a record for every user of this project. In your case, it will have a record for every users of your book app.
Let's say we were to create a "universal" table in this project. When you export the toolkit to your app, the book app will be aware of all tables in this project, including the "universal" table and the cdbUsers table.
When a user signs in you can get their user record using function cdb_readUsersByEmail(pEmail) and store it locally so you can access their personal data whenever you want.
You mentioned the "universal" data would be updated often. You have a couple options for this: cdb_sync() with "local" reads or stricty "cloud" reads.
You can perform "cloud" reads on the "universal" table so your user always sees what's on the cloud. Using "cloud" reads will be the closest to realtime data but will be less performant. (This might be the best solution for you if you're ok with the performance of the "cloud" reads)
Or when a user signs in, you can use function cdb_sync(pRecordIDL, pTable, pSource, pAllowDeletes, pDetectCollisions) with "cloud" for pSource on the "universal" table. This will download the current data on the cloud so it can be accessed locally. Using sync with "local" reads will be more performant but there's a chance the user can see stale data if anything on the cloud changes after the sync is called. You can perform this sync as often as you like so your user doesn't see stale data but it will affect performance.
Your app will have both the universal data and the user data so you can use them both as desired when a page is flipped.