I have created an android application with an SQLite database. However, I did not realize this was stored locally. Is there any way to connect the locally distributed SQLite database on personal devices to a global DB Server?
I need the database to be synchronized across all devices.
Depending on your requirements, there are several ways to achieve this.
Basically what you'll want is an API, which exposes the basic CRUD operations on your database. Your devices then interact with the API and store the data directly on the server.
The next step would be allowing the devices to save the data offline and sync it as soon as the device gets online. In this scenario, you'll need a local sqlite (or whatever) database in order to keep track of what changed on the device.
I would recommend you to read some stuff out there about synchronizing databases on mobile devices. Offline as well as online. You can find a basic explanation in this thread.
Related
I was using firebase till now and a friend recommended me to use Sqlite.. I was wondering if i setup a quiz in my app and it stores the data to my phone's sqlite... can others get access to it if my internet connection is fine? i used to use firebase for such a purpose but was wondering if sqlite can perform this function
Yes, others can get access to the data stored in that SQLite database. Here are just a couple of scenarios:
You store the SQLite database on external storage (e.g. a microSD card) and someone gets access to that microSD card. (E.g. you leave your phone unattended and someone removes the card.)
Someone gains physical access to your phone. (E.g. you turn it in for repairs without wiping the storage first.)
You store backups of your phone on your computer and someone gains access to those backups.
You store backups of your phone on an USB key and lose that USB key.
There is a security bug in Android that allows remote access to the phone's storage.
There is a security bug in the quiz app that allows remote access to app's storage.
These are just some of the ways in which someone can get access to that database.
Sqlite data is stored in your phone's storage (doesn't require internet) whereas firebase is cloud storage (requires internet). In both cases no one can see your data. If you are only making a quiz app i would recommend sqlite database as it will store the data in user's phone.
Sqlite database stored in internal storage of your app, so only your app can access to it. But if device have root, there are possibility to extract database.
Sqlite database was highly preferable if you are making a quiz app. Since it stores the data in user's device,I'm afraid that data can't be shared with other devices (until shared physically). And that won't be efficient for an application. I would prefer using parse server, for sharing those data over the internet with other devices.
So for my Android App which stores data of workouts I have been using a SQLite Database so far. Now I want to implement these features:
Offer workouts in real time (with Firebase Database)
Being able to access your data on other devices and maybe from an web app
later
I figured, that for this purpose Firebase would be a great fit. But switching from SQLite to Firebase would bring a few down sights in my opinion:
Every user would need to sign up. I think for some users this is a reason to
not use my app. There is no way to avoid having to sign up when using
Firebase to store the data for user, right?
I´m not sure how good the offline options of Firebase Database is. How long
will the data be accessible without a connection? Is the capacity and
performance comparable to a SQLite Database?
I thought an alternative way could be to use Firebase just for offering the workouts but keep the data about a workout (repetitions, weight, ...) in a SQLite Database. Then I could upload the Database File with Firebase and another Device could download and continue it. Could that be an option?
Any thoughts and advice are appreciated!
Every user would need to sign up. I think for some users this is a
reason to not use my app. There is no way to avoid having to sign up
when using Firebase to store the data for user, right?
Right. (Technically it is possible, however you will need to enable read / write operations to non registered uses which is a no-no and not recommended at all.)
I´m not sure how good the offline options of Firebase Database is. How
long will the data be accessible without a connection? Is the capacity
and performance comparable to a SQLite Database?
From the firebase database docs: Firebase apps automatically handle temporary network interruptions. Cached data is available while offline and Firebase resends any writes when network connectivity is restored..
So yes, you can continue writing to it even when offline and read the already cached data, but this does not solve your concern that users will have to register to use the app.
Possible solution
Use both SQLite and Firebase database:
For a registered user, always write in both SQLite and Firebase to keep them in sync (write in Firebase first and then SQLite). Another option is to write in SQLite and sync to Firebase every X minutes. Read data from Firebase when online and from SQLite when offline.
When the user is offline, you will to write data to SQLite. You will need to mark those records as non-synced so that next time it is connected you will write them to firebase.
Also, when reconnected, you'll need to somehow merge firebase data (that might have changed) and local SQLite data. The algorithm for this depends on your app.
For non-registered users, use SQLite only.
The downside to all this is that the complexity of your application increases a lot. It's up to you to decide whether it's worth it or not. :)
So far I think it's a security thing that you're not allowed reading/writing to an Android SQLite database outside of the containing app's process.
But are there advanced techniques or tools that can be used to achieve this?
For instance, I want to make a web interface with a textbox where the Android app would connect to and then I can run SQL queries via said interface to read the database or to insert records into it.
I'm writing this question because I'm really stumped. Usually my search gives opposite results which is accessing a remote database with an Android app.
You will have to develop an API backend. The mobile app ( client ) will communicate with the API and do the desired operation based on the response.
It's not possible to directly connect to the app sqlite database. You can send web request and get the info you want, handle it in your app to store it in the sqlite database
You will have to add security measures, so everyone can't access your API.
So far I think it's a security thing that you're not allowed reading/writing to an Android SQLite database.
Apps can read and write to their SQLite databases. Otherwise, the database would not exist.
I want to make a web interface with a textbox where the Android app would connect to and then I can run SQL queries via said interface to read the database or to insert records into it.
You are certainly welcome to embed a Web server into your app. For example, Stetho does this to integrate with Chrome Dev Tools, offering your SQL interface among other things.
However:
Doing this for anything other than a debug build of your app is very risky, as securing a Web server is difficult enough when it is on a traditional server environment, let alone an Android device
The Web server is only accessible by whatever can reach the device via an IP address, which means it's usually only useful on WiFi (where it could be reached by other devices on the same WiFi LAN segment)
I have been using SQLite as my storage solution for my android applications. I want to be able add synchronization functionality to one of my apps, Firebase looks like a good solution but the problem is that I need to know if I am to use Firebase to sync data with the SQLite database or Firebase can work and totally replace SQLite. I know Firebase has offline persistence but while offline can it hold as much data as SQLite and are the queries as powerful?
Clearly this depends on the business rules for which the options are considered. So there will not be the "right" answer to this.
At least one of our team members was thinking along these lines. Here is our solution:
Do all transactional data locally on the SQLite as we do not need transactions to be across devices.
Sync the rest using Firebase.
(1) makes sure that we don't misuse Firebase's non-persistent offline availability of its client.
The docs
Even with persistence enabled, transactions are not persisted across app restarts. So you cannot rely on transactions done offline being committed to your Firebase Realtime Database. To provide the best user experience, your app should show that a transaction has not been saved into your Firebase Realtime Database yet, or make sure your app remembers them manually and executes them again after an app restart.
(2) make sure that we use Firebase's persistent offline nature to synch non-transactional data across devices once connection is (re)established.
The docs, The Firebase Realtime Database client automatically keeps a queue of all write operations that are performed while your app is offline. When persistence is enabled, this queue is also persisted to disk so all of your writes are available when the user or operating system restarts the app. When the app regains connectivity, all of the operations are sent to the Firebase Realtime Database server.
This way we achieve a state acceptable within our use.
"can it hold as much data as SQLite and are the queries as powerful?" no and no if powerful is translated as "transaction across devices", by definition of Firebase being a remote database.
I see many people trying to connect an Android device directly in a database like SQL Server or MySql and the answers are always the same: Use a web service. Why not connect directly an Android device with a database? I'm using a local network with my Android application.
There are a number of reasons.
Security- If the user has direct access, they can get anything from your database. Plus they will have a password into your database. As a result, if the SQL server you are using has a flaw, then they can exploit it. Also, if your permissions are set up wrong, the could wipe your database.
Speed- If the users frequently use large queries, then it can bog down your system quickly and needlessly. If you go through a web interface, you can throttle it.
Accessibility- Web queries are supported by almost everything. It requires special clients to access SQL databases directly.
But if you trust your users completely, have the right libraries/drivers, then you could allow direct querying, and it might even be a bit quicker.
If your app connects directly to the database server you have to hardcode username / password which is very insecure. With some tools an attacker can decompile your apk and can access username / password in this way and can connect to your database with read (+write) access without using your app.
Another reason not to access database directly
Problem If you changed database architecture.
you have two solutions.
1- in direct access you will need to update every Client app
2- using service you only need to upgrading the service.
The reason is the connection
You're not sure how many time you'll have to maintain this connection, if it's stable and if you're not going to lost it
Secondly, web-service are optimized to retrieve an information and serve it beautifully with standarts. You can also cache the informations to spare your DB