I would like to know the difference between the structure of database on mobile (Eg; SQLite) and the structure of database on web.
For example, on mobile app development, the database table related to
user will only have one row. But, in web (back-end), there would be
many row for user table. So, even though we only have one row, we
still keep creating the user table in SQLite ?
In my App, all the data are coming from Web Services. And I would like to support full offline support. So, it is like i need to create SQLite structure and tables for everything I received from web services.
The other data are making sense. But, for user, there gotta be some
logic in here to for that specifically. I need to store every data I
am storing in my web-services. But, still, it feels wrong to create a
user table which will only have one row in any given situation.
Let's say in Facebook App. News Feeds are storing in database table. But, how they store the logged in user info for offline ? By creating a user table with only one row ?
NO, If I was to do something like that, then the db on the app would be quite different from what is on the server.Things to consider:
On server your user db stores many different users details like name, age, location, phone number etc. While on app you really don't need all the users, but just the current user's details.
If it was something like facebook then On server I would have users tables, photos, friends, posts, etc. On server all the users posts, comments, photos would be saved BUT on the apps end I would only have the currently logged in user details. The tables doesn't need to be the same, you could have less tables on the app.
Related
It's not a code problem but it's just by my curiosity.
I am making an application that can be logged in by social login, and also email login.
In my application, I plan to use some SQLiteDatabase to save simple datas.
However, when I just save it with A account and login with different account, won't there be conflict because its the same device and server is not intervened with it? How do you know it's different account when its the same device, one application?
Think its sort of a silly question maybe, but if there's a way that everyone uses to solve it, I would like to know.
There can be two cases -
You want to use same database for different users -
In this case, there is no problem as your SQLite database gets saved in your app's /data/data folder which will be always accessible from inside your app.
You want to use different database for different users -
In this case, you have to add user_id column in all the tables of your SQLite database, and based on your user_ids, you can do your database actions like query, deletion, etc
My app needs to use data from different websites. On these websites, there is a search with different chemical ingredients.
How can I programmatically copy this data from website to my realm database?
This database on Realm needs to be saved as a table which has 2 columns: ingredient name, description.
First of all, create an ID for each ingredient, receiving ID, Ingredient, Description. It's the best way to avoid conflict.
Second, you need to assemble a crawler, and this goes beyond your android application, maybe a network service that can be done even in java, identifying the information on each site and inserting into your database. So doing turn your android application get this information from the site.
I'm a little confused as to how SQLite works in Android development. I know it can be used to store data but is this internal data only? It will write to a .db file on the phone which is just a test file. But say I insert a few records on my phone. When a different user logs in and views the database will they see the records I just inserted or are those records only going to display on my phone? If it's the latter what's the best way to have all the data be stored in a single database so all users can add / delete from the same pool of records? Would it be a web service callout to a cloud db like MySQL?
Also, extra credit question: if I'm making an iOS app that will need to read from the same database as the android app should I even consider SQLite or should I use something else?
I know it can be used to store data but is this internal data only?
Yes, if I understand what you mean by "internal data".
When a different user logs in and views the database will they see the records I just inserted or are those records only going to display on my phone?
Well, that depends entirely on what you mean by "logs in".
If you mean "a different user uses my phone, just by swiping to unlock", the phone cannot tell you apart from this other person, and therefore that user sees the same data that you do.
If you mean "a different user uses my phone, but I set up two user accounts on the phone, and that user has logged into my guest account", then that user will get a separate database (and separate everything: apps, etc.).
If you mean "a different user uses their phone, but uses the same app", then that user will get a separate database, because it is a separate device. This is not significantly different than the user having different word processing files on their computer compared to your computer.
From the standpoint of the Android SDK, the SQLite database is a file on the device.
If it's the latter what's the best way to have all the data be stored in a single database so all users can add / delete from the same pool of records? Would it be a web service callout to a cloud db like MySQL?
I would not consider MySQL to be a "cloud db", but, yes, your app could communicate with a Web service that stores its data in its own central database.
I'm trying to learn the best way to control the data a user sees within an application.
As an example I've set up a database that has a table for a bunch of parks that each have separate fields
DBSchema
Now I will have multiple users using this application
I don't want them to be able to see all of the parks available
I will manually create users and select which fields they see, this
will be the only way to get an account.
What is best practice when dealing with this situation? How should I set up the users table in the database in a way I can control what parks are visible to them?
I am currently exploring some possible solutions
Send a pre packaged SQLite DB with the application, and use HTTP Post
calls to alter the DB depending on which user signs in.
Store the entire SQLite DB on the server and make a call to it when a user first signs in.
I am somewhat stuck with my development at the moment because I don't know how to handle this.
The applications functionality is complete in its current state, having multiple users see something different from the same database is something I have never done and should really know.
Any tips on what I should be researching or general guidelines for this would be great.
Currently I have developed an android application that uses a local sqlite database per installation. The database comes pre-populated with static tables, and the entire point of the application is to allow the user to assign dates/comments with the pre-populated information in each table.
I am looking to bring this online, and move the database to a mysql format, allowing access via desktops and other mobile devices. Is the best way to handle this to assign each new user a new database?
I would strongly avoid creating multiple databases, and instead add relationships to the existing database structure you have with a users table. Each user has an association to each existing object. Keep in mind sharing with other users in the event that you may want to allow one user to see another user's info.
My suggestion is provide an update to the app where after the first launch after updating it pushes their information to your MySQL database and inform the users that they can access their data via other methods now.
how many user to you expect? I would use only one database with a user table instead of hundreds/thousands of databases.
One table for all users (only with user info like id, email, password, etc).
Another table with comments (with user id and his comment), so that you can add as many comments per user as needed. If dates are related to comments put them on this table, else another table for dates as well.