(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).
Related
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.
Im creating an app but when i start to create the database clases (sqlite) and it works , now the sqlite files are different in android 9, in anothers versions you go to /data/data/packageapp/databases and you found database.sqlite and database.sqlite-journal, now i found this and this files cant open on sqlite administrator or similars... But the databases works i dont know what happen, i want to create the last files
Check the photo
https://imgur.com/oSiiGqZ
With Android 9 SQLite by default it now uses Write-Ahead Logging mode (WAL) instead of the journal mode due to it's potential for increased performance. Which is why you see the the -shm (Shared Memory file) and the -wal (Write Ahead Logging file) files.
Temporary Files Used By SQLite
However, you should be able to open the actual database file (yonuncafrases.sqlite) elsewhere in tools that support opening SQLite Databases. Compatibility WAL (Write-Ahead Logging) for Apps
i want to create the last files
If need be you can force using journal mode by using the SQLite disableWriteAheadLogging method, noting that this must be done outside a transaction, and then Journal Mode would be used and that the -journal file would then be created as necessary.
I'd suggest overwriting the onConfigure method and calling disableWriteAheadLogging in that overridden method. Alternatively you could use the journal_mode pragma (which I believe is what disableWriteAheadLogging does anyway)
You may wish to read Write-Ahead Logging
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.
In Android, entering data in SQLite uses more time and more lines of code than in .txt file.
Saving data in .txt and use FileReader is convenient to get the data.
What is the advantage of Using SQLite rather than File ?
Advantages of SQLite Databases over File Storage
If you have related pieces of data, regular files don't let you indicate their relationship; SQLite databases do.
SQLite lets you store data in structured manner.
SQLite has higher performance.
SQLite databases can also be queried and the data retrieval is much more robust.
The android.database and android.database.sqlite packages offer a higher-performance alternative where source compatibility is not an issue.
Android-databases created in Android are visible only to the application that created them
There is no file parsing and generating code to write and debug.
Content can be accessed and updated using powerful SQL queries, greatly reducing the complexity of the application code.
Extending the file format for new capabilities in later releases is a simple as adding new tables or new columns to existing tables.
Diverse content which might otherwise be stored as a "pile-of-files" can be encapsulated into a single disk file.
The content can be viewed using third-party tools.
The application file is portable across all operating systems, 32-bit and 64-bit and big- and little-endian architectures.
The application only has to load as much data as it needs, rather than reading the entire application file and holding a complete parse in memory. Startup time and memory consumption are reduced.
Small edits only overwrite the parts of the file that change, not the entire file, thus improving performance and reducing wear on SSD drives.
Content is updated continuously and atomically so that there is no work lost in the event of a power failure or crash.
Applications can leverage the full-text search and RTREE capabilities that are built into SQLite.
Performance problems can often be resolved using CREATE INDEX rather than redesigning, rewriting, and retesting application code.
A federation of programs, perhaps written in different programming languages, can all access the same application file with no compatibility concerns.
Multiple processes can attach to the same application file and can read and write without interfering with each another.
Cross-session undo/redo can be implemented using triggers.
In many common cases, loading content from an SQLite database is faster than loading content out of individual files. See Internal Versus External BLOBs for additional information.
Content stored in an SQLite database is more likely to be recoverable decades in the future, long after all traces of the original application have been lost. Data lives longer than code.
The main reasons which immediately spring to mind, which SQLite gives you and a simple file does not:
http://en.wikipedia.org/wiki/ACID
A standard API: SQL
Theoretically better performance (say, O(log n) rather than O(n))
No wheel reinventing
and plenty of others
Note that trying to solve any of these problems with using a flat file yourself is going to start moving into database territory – but of course you really don't want to write that sort of thing yourself.
I am seeing some strange behavior with my application and the state of its database file after running some tests that close the database, delete it, and replace it with a test fixture. When I examine the database file with a tool on my debugging PC, it doesn't match what the application itself seems to be reporting. It's possible that this strange behavior is related to this bug.
I noticed that there are two files with the same base name as the database (with the normal .db extension.) The file extensions are .db-shm and .db-wal, and each is newer than the .db file's timestamp.
I assume that these are some type of temporary files. However, I am wondering if the application is terminated, shouldn't they be deleted? More importantly, I assume whatever data is stored in them is updated inside the .db file before the application is terminated by the operating system. Is this correct?
You are correct, these are temporary files created by SQLite. If you are manually deleting the main db you should probably delete these too. From what I can gather the WAL is a replacement for the rollback journal that enables SQLite to rollback changes when a transaction fails. How SQLite uses them and why they are kept around for so long is up to the authors of SQLite but in general SQLite seems pretty rock solid so I wouldn't worry too much about them. For more info take a look here:
http://www.sqlite.org/fileformat2.html#walindexformat
These files are a new feature of SQLite 3.7. I'm not sure if their existence relates to the bug you point out but the bug report suggests a work-around anyway.
UPDATE:
Better documentation about the WAL is here:
https://www.sqlite.org/wal.html
The contents of the WAL are periodically moved to the DB file but this is not guaranteed to occur each time the process exits. Thus when WAL is enabled each SQLite DB consists of two files on disk that must be preserved, both the .db file and the .db-wal file.
The .db-shm file is a shared memory file that contains only temporary data.
I do not yet have enough reputation to just add a comment to satur9nine's answer, so I'll pile on here.
As per the SQLite docs, the DB-SHM file is a Shared Memory file, only present when SQLite it running in WAL (Write-Ahead Log) mode. This is because in WAL mode, db connections sharing the same db file must all update the same memory location used as index for the WAL file, to prevent conflicts.
As for WAL file, as hinted above, it is a write log/journal, useful for commits/rollback purposes.
Make sure that you have closed cursor properly into SELECT operation. Sometimes SQLiteOpenHelper creates .db-shm and .db-wal extensions database due to unclosed Cursor.