So I am creating this application where there are lots of personal information and data which shouldn't be persisted in the device to avoid security issues. When learning about Room, I came across this Room.inMemoryDatabaseBuilder() which as the documentation states:
Creates a RoomDatabase.Builder for an in memory database. Information stored in an in memory database disappears when the process is killed. Once a database is built, you should keep a reference to it and re-use it.
I was wondering whether this would be a perfect usecase for my situation. Since the data will only exist in memory and not stored in the device.
It seems like a good idea. My only concern is that I haven't seen an implementation of this in an actual application yet. The only usecase which I saw this Room.inMemoryDatabaseBuilder() used was for testing (so then you don't have to worry about database clean-up on each and every test run).
Can anyone offer some advice? It would be much appreciated.
Thank you very much.
I posted this same context question in #Florina Muntenescu Blog here
Her answer was:
Hi,
Yes, it can be used for any use case that requires the data to be kept in memory only. Testing is one of them.
So basically, Room.inMemoryDatabaseBuilder() can be used for other use cases where data should only be kept in memory.
Room.inMemoryDatabaseBuilder() has been designed mostly for testing purposes. I would never use it in production because you can't know when the process is killed by the system, so any use which goes above an advanced structured cache or similar is probably not a good idea.
I think you have a lot of options to solve the problem without relying on this API.
You can use one or more of the following options:
Encrypt Room database using SQLCipher and store it in application private folder.
Use the Android Keystore to store private information or passwords to access personal information.
Block some sensitive part of your application if the device is rooted using SafetyNet api
Don't store sensitive data in database at all, but ask for them to the server at runtime only when explicitly requested by the user.
Related
i converted my android app from mapdb to objectbox, i've seen on github a few people reporting database corruption with objectbox and the solution has always been to call usePreviousCommit in case of problems.
since the objectbox core is close source I wanted to know what usePreviousCommit does internally
are there 2 physical copies of the database? and calling usePreviousCommit reverts to the previous copy?
or does it work in a more complex way? (if yes i wanted to know how)
i opened this question because i want more information from objectbox before i continue to use it in production.
The key word is multiversion-concurrency. Think of a B+ tree with copy-on-write. The previous root tree (aka the previous commit) is preserved, so you can use when opening.
I am building a social media application which requires local storage of table data entities. This data must also be connected to a server to retrieve and update information to and from users. Our team has built an iOS client using core data, though we are looking for storage options in android. Is using SQLite the way to go? Any thoughts would be greatly appreciated.
You should take a look at Realm, it has clients for Objective-C, Swift and Android.
Description from their GitHub repository:
Features
Mobile-first: Realm is the first database built from the ground up to run directly inside phones, tablets and wearables.
Simple: Data is directly exposed as objects and queryable by code, removing the need for ORM's riddled with performance & maintenance issues. Plus, we've worked hard to keep our API down to very few classes: most of our users pick it up intuitively, getting simple apps up & running in minutes.
Modern: Realm supports easy thread-safety, relationships & encryption.
Fast: Realm is faster than even raw SQLite on common operations, while maintaining an extremely rich feature set.
If you're familiar with RxJava, you will probably want to check SQLBrite, wich is Square's solution for this.
Yes, Sqlite is a default storage solution for android. Howevere there is a wrap around it called ContentProvider. ContentProvider can be used with Loaders and provide async data loading. ContentProvider may be used to modify contats and merge accounts, see this guide. However ContentProvider may seem tricky and if you prefer ORMs you can use ORMLite or GreenDAO which are using sqlite as well.
I am relatively new to app development and core data, so take it easy on me. I have been working on an app (currently for iOS, android in the future too) which stores the user's data locally using core data.
The data has relationships across entities. User can create, update, delete data.
Now I need to integrate some kind of syncing solution. My requirements are:
Data should be accessible offline (right now I am testing queue operations for that)
Data should sync to cloud storage when network is available (on iOS I have tested out reachability for this)
Cloud storage needs to be integrateble to both my current iOS and future android version.
Relationships (or some other way of linking parent-child, i talk about it later) need to be maintained.
Core data on ios should be used, not third party replacement.
I have messed around with many solutions so far:
I setup my own rethinkdb database on a server and used PHP and REST to get things going. This was very messy.
I tested parse.com and afnetworking http requests (instead of parse's library) - this was better, but i couldn't seem to be able to manage the relationships from core data. And my syncing algorithm is complicated (it works but I am not sure if there are holes in it when it may fail)
I tested dropbox datastore api. I have only tested the iOS sample app they provide, seemed pretty good (still need to understand the workings).
My questions are:
If I were to use dropbox datastore api, how does it work with android? of course core data is not available there, so how does that work (sorry I don't have android dev experience yet)? ALso how does it handle relationships between entities?
If I go with Parse.com, do you think my this idea will work-
Instead of using relationships, I can use identifiers? my relationships are all 1-to-many, so on the parent (1) I can have an id A. On all the children I can point their parentid to A. Also since my children can have grandchildren too, on each of the children I can have another id which the grandchildren can point to. So on... does this make sense as a replacement of relationships? If yes, then what's the point of relationships in xcode?? other than having automatic cascade option maybe.
Are there any better solutions available for syncing cross platform?
I know my question may seem a bit asking for opinion, but I would like to see what everyone else has already tried. Past week of switching from one solution to another and designing the syncing algorithm has fried my brain.
(I work at Dropbox and will address just that part of the question.)
The Dropbox Datastore API doesn't use core data and thus works exactly the same way on Android. Why is core data a requirement?
As to relationships, what you describe for Parse is exactly what I would suggest for use with the Datastore API. I believe you're right that the reason for modeling relationships in databases and in code is to get automatic cascading operations and enforcement of relationship invariants.
I'm currently developing an app that has the potential to create a very large database. I had planned on installing the app on the SD card to allow for some extra room. Recent dealings here have warned me that that might not be a good idea. Are there any steps I can take to mitigate the danger of this course of action? Or are there any better alternatives?
This is a comprehensive post on the subject (I'm not the author).
I think, overall, it needs to be communicated that SQLite is just a SQL mechanism for accessing a file. It appears that the current market limit is 50mb for the entire APK. When installing to internal memory, you require 2x your APK size. Installing to sdcard requires just the stated APK size.
Here is what you will be working against:
1.) Since SQLite is just a abstraction over your file, when you do selects, inserts, updates, etc, you will be incurring sdcard read write costs
2.) I've seen mention of a soft limit of 10000 records based on performance. This article is a bit old, so its likely gotten better.
Other then that, you'll probably have to set up some tests to see what is feasible. Cursory search of google did not show any benchmarks to date.
As pointed out previously, SQLite has the functionality that you're looking for, packaged in a small library. It's designed to replace simple file access with reliable, recoverable, transactional data access via a SQL API. There's a great summary on their main page.
There are literally thousands of projects that are using SQLite. If your data set is going to be very large (more than 100-200MB), then you might want to consider using Berkeley DB as an option. Berkeley DB recently introduced support for a SQL API, which is completely SQLite compatible. In addition to the functionality that's provided by the SQLite SQL parser, query planner and executor, you also get the reliability and scalability that Berkeley DB is well known for. We have several customers who happily started out with SQLite. When they realized that they needed additional concurrency, scalability and reliability that not available in SQLite, they replaced the SQLite library with the BDB library, recompiled their application and had it tested and running on Berkeley within a few days.
I'm one of the Product Managers for Berkeley DB, so I'm a little biased. :-) However, we implemented the BDB SQL API so that we could offer users the best of both worlds: the ubiquity and ease-of-use of SQLite combined with the concurrency, reliability and scalability of Berkeley DB. Especially with larger data sets, Berkeley DB can make all the difference in application performance.
As mentioned above, you can use Berkeley DB (not the Java Edition) on Android. I described the steps of the cross-compiling process here since it requires minor tweaking.
I noticed that a DropBoxManager has been introduced in Android API since FroYo (API 8).
It looks like an alternative logger capable of logging not only text but also files or byte arrays, but I could not find any detailed doc anywhere about how and when we should use it.
The latest android dev blog post introducing StrictMode talks about it, StrictMode can append data to the DropBox, and we are given a shell command to retrieve these data.
Please share here your knowledge about this! Why has it been implemented in addition to the usual logcat? Can we use this to share data across apps? What kind of apps use it?
There are basically three logs on the system:
Log:
for short, textual data
in-memory ringbuffer, fast
ephemeral (you'll lose it on a crash, or the ringbuffer scrolls)
intended for app developers
EventLog is:
for short, binary data
in-memory ringbuffer, fast
ephemeral (you'll lose it on a crash, or the ringbuffer scrolls)
intended for platform developers to collect statistics
DropBox:
for long text or binary data
persistent, written to disk
kinda slow (disk)
meant for platform developers too, mostly to collect crashes & large statistics
subject to limits, deleted by tag if a tag's count and/or size get too large
DropBox is what we used during development to capture all the StrictMode violations in Gingerbread.
You can use DropBox for one-off debugging, but it's not really recommended. It's definitely not recommended as a way to share data between apps. It's not reliable enough, and you can't put permissions on the data. You should just use a shared userid and use the normal filesystem with appropriate permissions.