I have an Android app I wrote that uses a sqllite database,(the app is used for the reservation) now I want to write the same app for iPhone and I want to use the same database I used in Android app. My question is can I use the same database in IOS.
If yes, then how can be used and where I place the sqllite database (I mean what folder)? and the users must be online to see the update in the database ?
Can I use an sqlite database created for android in IOS?
Yes, an SQLite database is a a file (or potentially 3 files if using Write-Ahead logging). It's simply a matter of copying the file(s).
Typically (i.e. if not specifying otherwise) an SQLite database is stored in data/data/your_package/database/the_database_name
where your_package is as per the App and the_database_name is the file name (may or may not have an extension).
Note if the database uses Write-ahead logging then 2 other files may exist, these being the_database_name-wal and the_database_name-shm. If they exist and are not empty, they need to also be copied.
However,
and the users must be online to see the update in the database ?
Is a completely different matter though. SQLite is not suited to a client/server situation, as you would have to write all the code to provide this functionality. See Appropriate Uses For SQLite.
Firebase may be an option if you don't mind Google's policies reqgarding information privacy. Otherwise you are likely then looking at something like MySQL/MariaDB.
Related
(I'm new to android development)
Say android app-1 created a database hello, via roo.
Then could android app-2 created a database hello, on the same phone?
My guess is yes, since room use sqlite, each app may start a new sqlite instance, and may store its data in private space, otherwise it's too easy to get conflict. But I'm not sure.
The questions are:
Will 2 app share the same sqlite instance, or each app will start a new sqlite?
Is the database's name app scoped?
I guess the data of a database is also private to the application?
(I've searched about this, didn't get a confirm.)
By default, Room databases are stored in internal storage, and each app has its own internal storage. You can have two databases named hello, one per app, without a problem.
Really SQLite is a set is a set of file handling routines (more complex than just simple writes and reads though).
Android devices come with the routines built in (albeit different versions of SQLite which are typically backwards compatible).
Room is a wrapper around SQLite and thus the routines and caters for an object orientated approach to accessing the data (file(s)).
Unlike, for example, MySQL, SQLite it is not a server that manages transactions from extrenal sources, so SQLite is not a running instance background app/service. (The command line interface would be though)
A device can have many Apps that use the routines to access and update the underlying file (3 files if using the default WAL (Write-Ahead Logging, the core database file, the wal file and a third file the shm file a WAL file for the WAL), (2 files if using JOURNAL mode).
with WAL changes are applied to the WAL file which are then committed at times to the core/master file. Likewise for the shm file in regard to the WAL file. This allows a rollback to simply effectively delete/empty the WAL file.
JOURNAL mode the journal is a record/log of the changes made to the core database. A rollback is accomplished by reversing the changes according to the JOURNAL.
WAL is typically more efficient.
Typically this is all handled by the SQLite routines.
An App can itself access multiple databases if need be. SQLite even caters for accessing multiple database by ATTACHing databases to another.
By default the database is stored in the App's protected data storage area and thus is unique to the App. What you couldn't do, by default, is have the same database name twice within an App
you could say have two hello databases in different locations e.g. data/data/the_package/databases/hello and data/data/myotherdatabasesfolder/hello
note sure how you would go about this using Room though, certainly feasible using just the SQLite API.
So App1 and App2 could have the same hello database as the files will be in separate App specific locations (data/data/the_apps_package_name/databases by default).
I am working on my capstone and I need to create two programs using two different languages that use a single local database. I am making a chore manager that will be a windows program and an android app. I figure out how to use sqlite for the windows app, but I cannot wrap my head around using an existing database with android studio. I need the app to be able to read existing data and display it and then based on some conditions edit the data.
If I add the database as an asset will the data a user changes using the app be usable by another windows program?
Here's my opinion: "Don't use SQLite for this." Use a regular shared database that you can (securely ...) access from both environments.
SQLite databases are files, accessed through the file-system. They are most commonly used where the data won't be shared, because, like any "shared file" database of aeons past, they are always subject to corruption if someone (or the operating system, or the network ...) does anything wrong. Whereas a conventional client/server database doesn't have these problems because it controls the data while it talks to you.
SQLite is a marvelous tool for storing structured information on a device. I've deployed many dozens of "boutique" websites which store their page-information that way. But, I think, it's not the right tool for this job.
I am building one android application where I want to maintain certain details in the sqlite database. I am using SQLiteOpenHelper interface in order to maintain single instance of the database for all the threads accessing the database.
For security reasons I want to encrypt my database because if the database file is not encrypted, it is possible to view the database file on rooted android devices.
To avoid this I want to encrypt the database file.
I have gone through SEE, wxSQLite, SQLiteCrypt and botansqlite3 but they all require cutomized distribution of SQLite to be shipped onto android device.
I want to secure my database file with the normal distribution of SQLite that is shipped with Android.
Also I tried to use SQLCipher but it increases my application's total size by 8-10MB. One more reason for not using SQLCipher is that it doesn't support mips architecure (but this could be built later on with some modifications in the source code).
Also my database will be accessed and updated by many threads and will be loaded all the time by a service so decrypting database at the time of loading/opening and encrypting at the time of unloading/closing will not work for me. It should be possible to fire queries on encrypted database only or there should be some alternative solution like creating temp database, decrypting it and performing operations on it.
Can anyone suggest me a light weight solution for encrypting SQLite database on android devices?
Thanks in advance.
I have a huge set of data that I want to insert into the sqlite database before the user is able to do anything inside my application. Right now I have all my data stored in CSV files, then I parse those files and use DatabaseUtils.InsertHelper to do a bulk insertion, but this is taking to long to complete.
I stumbled on this tutorial some time ago and I'm wondering: is it safe to distribute a pre-generated sqlite file? Can I run into problems due to different versions of SQLite on different devices?
I'm planning to support Android 2.1 and higher.
I suppose it depends on your definition of safe. It is certainly possible as long as the database conforms to the metadata table spec Android expects, which is what that tutorial you stumbled upon is showing you. You won't have to worry about version conflicts with SQLite as that is a package built into the core platform and isn't something OEMs add to or implement anything on top of.
However, if by safe you mean "protected" you would need to take special steps to ensure that your database is not externally readable if that is a concern. If you simply place the preconstructed DB into assets/ and copy it over, anyone who can properly deconstruct an APK file can view your database data. This may or may not be an issue for you.
The best approach is to populate this data in the database, keep the database in assets & then copy it to the device ... You can follow this complete sample code here.
I am currently developing a simple info app on various university campuses. I want the app to operate predominantly in an offline state thus I want to store all my information locally. The data within the app will not be subject to any change thus I was wondering what the best (practice) method was to store such data? Basically should I be storing the info in a SQLite db, java file or xml?
The answer depends on your requirements, but because of the built-in integration with SQLite, the easiest will probably be to just use SQLite, plus you get the benefits of a relational database. You can refer to the Notepad tutorial for a start.
It depends on the data you have. If it is largely text I would store it in an android string resource file. If it is somehow structured and has IDs and relations store it in a database.
We had a University project requiring a local database on an android phone. What whe did was to use SQLite to write on a database stored on the memory stick. (We couldn't find the right permissions to write directly on the file system)
Check the API website for the android.database.sqlite package first.
And here for a nice tutorial :
http://www.devx.com/wireless/Article/40842