I have created a SQLite database in my android app. I want the data of every user in a centralized database. How can i setup the server and the sychronization that will allow me to get the data from every user?
What are the steps that need to be followed ?
Data synchronization is very complicated process. In document above there are some sample patterns which you may use.
http://www.dre.vanderbilt.edu/~schmidt/PDF/PatternPaperv11.pdf
You need to know what kind of troubles you can meet and include solutions for them in your project.
E.g.
User1 and User2 have synchronized data. User1 is modyfying one row in table Data. In the same time User2 has deleted this row. Your job is to handle this case.
I guess replication is what you are looking for.
Replication is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency. Using replication, you can distribute data to different locations and to remote or mobile users over local and wide area networks, dial-up connections, wireless connections, and the Internet.
http://msdn.microsoft.com/tr-tr/library/ms151198.aspx
Related
I am struggling with creating Android database for my app. Below is the picture of the data I need to save/store based on the location.
On Device: I need to store sensor which comes at a frequency of 100Hz. User is going to use the app app for few hours which means there is going to be a lot of sensor data. If user is going to use the app multiple times (multiple session) after short breaks then I need to store data sensor data perssion wise on device.
What I was thinking: Create SQlite database and create a table and add column dynamically and add sensor data to that column. Each column is session. col 1 = session 1, col 2 = session 2 etc.
Is it bad to do like this then what you guys would suggest?
In cloud: Now, how should I go about creating database if this data is going to get stored on cloud (GoogleCloudPlatform specifically) per user per session wise sensor data.
Any suggestion is welcomed. Please don't mark it as broad question because I am looking for efficient method to achieve this.
Refer the image below for further explanation or ask me for further explanation.
I prefer to youse RoomDB as per your requirement and consider the facts. Because Room provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite.
Apps that handle non-trivial amounts of structured data can benefit greatly from persisting that data locally. The most common use case is to cache relevant pieces of data. That way, when the device cannot access the network, the user can still browse that content while they are offline. Any user-initiated content changes are then synced to the server after the device is back online.
Also, I prefer to use firebase realtime DB along with room for better efficiency and reliability. If you are using roomDb and firebase for cloud storage you can use a single entity for both firebase and roomDb. It will also help you write less code and better reliability.
Because Room takes care of these concerns for you, I highly recommend using Room instead of SQLite.
For reference, Please go through this link Save data in a local database using Room
I am developing an Android application to collect the store (Grocery) information.
The application have modules to create store, set it's attributes like address, lat lng, operating hours, manager details, building photos, etc.
Once the store is created user need to list down the assests of that store by clicking photos and providing it's details.
To store all this details, i have around 15 SQLite tables.
Now i want to implement feature of 'Synchronization', all this captured details need to send to server whenever connection is available otherwise detail should be stored locally and whenever connection is available it should move to server.
Also, please note that the number of tables may increase up to 40 as application grows.
I searched for the solutions/approaches for this on Google but in most of the article or example they have mentioned for small scale application having small data.
I have also implemented synchronization feature for small datatable (2 tables), where i checked for last updated timestamp on server and local and if it's different then we synchronize the data. I don't this i should use this approach for such large scale and large database.
I have one approach which doesn't depend on numbe of tables.
I am planning to have single table which store the following data
id
URL
request header
request body
Now let's say connection isn't available while sending request so it will be stored in table. Whenever connection is available it start reading the table and execute the request, on success it will remove the entry from table. With this approach we need only one table in SQLite.
The problem with this approach is when we want to retrieve data offline how we can do that? Do we need to have local database schema same as server?
Please guide.
Thanks
If you are syncing data with a server and you are removing local storage data ,which is incorrect as per my knowledge ,in this case your app does not work offline.So for that when you sync data to a server at that time maintain some flag which data is synced.And then next time just check flag status if it's synced then do not synced data otherwise do syncing.
I hope this solves your problem.
What I need the app to do is to store data in a database and let any user fetch the data. I am not sure how SQLite works but from what I know is that it is server-less. With the database being serverless, how do multiple users, other users, access the same data if it is not stored on a server?
look for backend and a service - parse.com or similar.
SQLite is installed on all android systems, and any app which wishes to create and use a database may do so. This however, is only stored locally on the device.
If you wish to share and synchronize data across multiple devices, that is a different issue all to itself. Indeed it will very likely involve a central server somewhere along the line.
Perhaps start your reading at d.android.com
I am working on an application that will, basically, allow people to create, join and manage groups of other people. The people within the groups can also message each other.
I have been wondering which path would be better:
Keep a remote database with all the information, including messages sent to and from users. And have the app query the server every time it needs information. Even information it has seen before.
Keep a remote database with all the information, including messages sent to and from users. Also keep a local copy of the remote database and just keep it synced with the remote database. Whenever the app needs to query for information, it does a query to see if the local table is up to date. If it is not up to date, it updates the table and runs the query on the local table. This way it will keep a local copy and the app will have fast queries when there is not an update to the remote table.
What is generally done with mobile applications and remote databases?
Would it be "bad practice" if i just did number 1?
From my point of view, in most cases, the database in the mobile is just a cache of the real database, the one in the server. So, my suggestion will be to keep locally all data that you need syncing with the server. This allows you to show information even when no connection and show something to the user while the info is updated.
Also, this approach makes the local data volatile without risk, as it's stored in the server. So:
All info is in the server
With a background process (service, thread, intentservice, whatever best suits you) you sync this information with the local database
UI is always showing info from local database
Of course, this is a very general approach, and needs to be examined for each case as different situations may need different approaches.
My base response is that I would keep the data in one place and access it remotely unless there is a major reason to keep it locally. There would have to be extenuating circumstances to mandate that I keep a copy of the data locally. Just make sure your queries are accurate and concise. Don't pull over more data than you need to.However, you can have a subset of data kept locally. Items that are specific to the user (like messages), but keeping data that is not relevant just adds overhead and bloat.
I'm about to build a GPS Spot Finder application with Android and I am trying to decide what requirements are feasible and what aren't. The app would enable users to essentially add different spots on a Google Map. One of the problems would be fetching the data, adding new spots, etc, etc. This, of course would mean the database would have to be online and it would have to be central. My question is, what kind technologies would I need to make this happen? I am mostly familiar with XAMPP, PHPMyAdmin and the like. Can I just use that and connect Android to the database? I assume I would not need to create a website...just the database?
What different approaches can I take with this? Be great if people can point me in the right direction.
Sorry if I don't make any sense and if this type of question is inappropriate for Stackoverflow :S
Create a website to access the database locally, and have Android send requests to the website.
If users are adding spots to a map that only they see, then it makes sense to keep the data local to Android using a built-in database (SQLite). That looks like
ANDROID -> DATABASE
You can read up about SQLite options here.
If users need to see all the spots added by all other users, or even a subset of spots added by users, then you need a web service to handle queries to the database: Connect to a remote database...online database
ANDROID -> HTTP -> APPLICATION SERVER -> DATABASE
Not only is trying to interface directly to a database less stable, but it may pose risks in terms of security and accessibility.
Never never use a database driver across an Internet connection, for any database, for any platform, for any client, anywhere. That goes double for mobile. Database drivers are designed for LAN operations and are not designed for flaky/intermittent connections or high latency.
Additionally, Android does not come with built in clients to access databases such as MySQL. So while it may seem like more work to run a web service somewhere, you will actually be way better off than trying to do things directly with a database. Here is a tutorial showing how to interface these two.
There is a hidden benefit to using html routes. You will need a programming mindset to think through what type of data is being sent in the POST and what is being retrieved in the GET. This alone will improve your application architecture and results.
Why not try using something that is already built into android like SQLite? Save the coordinates of these "spots" into a database through there. This way, everything is local, and should be speedy. Unless, one of your features is to share spots with other users? You can still send these "spots" through different methods other than having a central database.
And yes, you just need an open database, not a website, exactly. You could technically host a database from your home computer, but I do not suggest it.
If you are looking at storing the data in your users mobile nothing better than built in SQLLite.
If you are looking at centralized database to store information, Parse.com is a easy and better way to store your user application data in centralized repository.
Parse.com is not exactly a SQL based database, However you can create table , insert / update and retrieve rows from android.
Best part is it is free upto 1GB. They claim 400,000 apps are built on Parse.com. I have used few of my application typically for user management worked great for me.