Actually I've an app with some local data, and I used Realm to store them. Today I would like to update it, and switch to Room.
The thing is that some user already have data stored with Realm, and for now, my app only store the data locally, there is no cloud of something. This means that if I just switch from Realm to Room, some existing user will lost their data.
I made some search, and I thought about, when the user will open the app, make a query of all the Realm data, and switch them to Room, keep it for few weeks, and then delete Realm.
The thing is that I made a test project to see if it's functional, but I noticed that I will have to create the model twice (the existing one with Realm and the new one with Room).
Does someone have a better idea or way to do it, or it's my only way to go ?
Related
I use the ObjectBox in my kotlin project. Users can erase the database by clearing the application Data from the Android settings.
I want to prevent database removal or change ObjectBox Store mode to SQLite!
thanks
In case you want to make user data persistent you definitely should save and check DB copy on your server.
First of all, as you probably know, this is "normal" behavior on Android. When you delete an app's data, you have to start from scratch. E.g. all local data lost and log-in again etc. I'd guess that 0.01% of users would actually know about it and actually do that.
Anyway, yes, the question is if you want to extend data scope to cloud/server... That's a different topic though. ObjectBox will offer data synchronization later this year.
Alternatively, there's also Android's backup function: https://developer.android.com/guide/topics/data/autobackup.html
I'm a self taught android programmer so sorry if this is a newbie question. Does anyone know if there's an easy way to merge two realm database files into one combined realm database? The databases contain the same realmobject types and are mutually exclusive (no overlaps of identical objects).
My goal is this: I have a realm database of a workout "session" that is comprised of a list of objects that the user adds to using a wearable. When the user saves the session, I want to send those saved objects to the phone where it can be combined with all past sessions in a realm database stored on the phone.
I'm able to send the database file from wear to phone as an asset and simply replace the file on the phone (using this sample code https://gist.github.com/tajchert/dc30560891bc6aee76fb), but it seems wasteful to send the entire database every time, and I don't want to lose everything if the wear database gets deleted somehow. I'd rather save only the new data from the current session and then clear out the database on the wearable when a new session is started. That way, I'm only ever sending new data to the wearable data layer.
In general, it is not possible to move Realm objects between Realms. You can use copyFromRealm() and copyToRealm(). Of course, you will need to keep track of which objects, which are already been moved (either my marking them somehow or deleting them).
Another option is to use Realm Mobile Platform (https://realm.io/products/realm-mobile-platform/) which can help you to keep all your devices in-sync.
I am currently running into some issues regarding the realm database and I don't know what the best practices are to tackle this problem.
So I have setup an app which communicates to a server and gets Post Objects through Retrofit stored into my Realm. This post feed is a core part of my app and I want to keep things locally to stay attractive while being offline. The thing is that I cannot store the entire feed list locally as this would be a massive chunk of memory. But I want to make sure that the User gets this content while scrolling through a recycler-view.
The recycler-view currently only shows local Posts and updates them if refresh is forced. I want to implement a load on scroll mecanism that loads Post objects into it while scrolling but this scroll objects should not be stored locally when the app closes.
I thought of creating an additionally in-memory Realm but there is another problem: A Post Object contains a ForeignKey to a UserObject. When I download this dynamic PostObjects and a UserObject changed over this time on the server I want to be able to reflect this changes to every other User on the local persisten Realm too. (To avoid having 2 different UserObjects for the same User)
My best idea i came up so far is to have a
Boolean field on the PostObjects set to true or false to indicate temporary state or not. After the applications closes I would drop all the temporary entries. Is this a viable solution or do I miss anything? I hope you understand my problem and can help.
Edit: My Realm Database contains two relevant objects:
User
Has a name (primarykey), id (global from server), imageUrls etc..
Post
Has a User who created it, again an id and its data (text, date, images...)
Edit2 : What I really need is a type of in-memory Realm that allows me on start up to clone another realm that is used to have data in case of no connectivity. Before the in-memory realm gets deleted I would then override the offline realm with the 5-10 last post entries of the temporary realm. Is such a thing possible?
In my app I have SQLite db. I want to introduce sync between devices of my users. Firebase DB looks like an acceptable solution, but Firebase DB is cloud db at first. So, I can't use it as local db if user will reject auth dialog and let him use app, but without cloud-sync.
Now I think about combining my local SQLite db with cloud Firebase db.
For example, when user adds new row to local SQLite db, my app will also put data into Firebase DB. Other devices of this user will catch this event and update their local db. When the user uses authentification and installs app on new device, I want it to download all rows and put them into local SQLite db. That's my idea: use Firebase DB only for synchronizing data, not for storing it at device. Main reason for it is to let user use my app without authentification&synchonization. The second is that Firebase DB is not designed to be used as local db.
I'm right? Is it okay to use Firebase DB with another local DB?
Related question:
link He want the same as I want:
my plan is to offer the user the option to stay offline
If your firebase structure is not too complex you could also make a interface which defines methods like
void addData(Data data);
Data getData(long id);
void editData(Data data, long id);
void deleteData(long id);
then create 2 classes implementing that interface, one using Firebase the other using SQLite.
DatabaseImplementation
FirebaseImplementation
Inside your Firebase implementation, you would publish the data like normal, and publish one new node to something like root/requestUpdate/userId/push/ and push would contain information on where you request an update, and what deviceId published it.
Then have a ValueEventListener tied to that mentioned node, and if it gets a new child, have it look whether the deviceId is the same or not. If it is not, have the FirebaseImplementation getData using the information you got, and then use the DatabaseImplementation, to addData.
That would make sure that whenever a change is made, any other logged in client will know to update its firebase. If the client is not online, the next time he will be online he will do it as ValueEventListener triggers when it is attached. Make sure to loop through all the requested updates to make sure all are made. Also store the push keys of any updates you did complete on a local database that way you dont end up updating more than once.
Basically the firebase will always be up to date and store any changes a user made on a seperate node which is listened to by all clients.
Obviously this solution still has many problems you would need to fix, like figuring out when to delete the requestUpdate node. Logically after every user has synced but how do you determine this? ...
As for the first login, you would need to write a populateDatabaseFromFirebase() method which will do a whole lot of getDatas and addDatas. How you would do that will depend on how your DB looks. You then would store that the user has already logged in with SharedPreferences and the firebase UID.
That all being said, this will only work if your firebase is pretty flat. If you have a complex database, then everything becomes much more complicated and entangled and then it might be worth looking into an external library.
Some options for HTML5 hybrid apps
This is not what the OP asked about, but hopefully useful to some seekers.
You can use any combination of client and server database to implement storing remotely-maintained data in the device so it will be available when offline.
Some client options :
SQLite
(which is using the "native" browser database, works on iOS Safari
and Android webkit browsers)
IndexdDB
(another "native" option, but not supported in early Android, or
fully supported for iOS - so NOT a good option)
JayData
(which provides an abstraction layer from the underlying native implementation)
Lawnchair
(another popular client abstraction - I found the documentation lacking and have not used this for that reason)
Some server options :
MongoDB
RethinkDB
MySQL (for an SQL DB on the server)
and, of course there are many many more.
I am building a mobile app to allow for real time messaging, befriending users, creating groups to both chat and share images with, as well as creating events where users can invite one another.
I have chosen to use Firebase as the online back-end. But, given Firebase uses a NoSQL data model, while Android SQLite uses SQL, when saving data offline in Android what is the conventional way to handle this? Is there a simple way to convert or simply save from NoSQL to SQL, or do I need to build a converter?
(This is especially important for the events, as once created, they must be scheduled in the AlamManager, giving users alerts upon event time)
While you could implement your own solution, truth is, you do not need to build anything from scratch.
There are free Android libraries which could help you. I would recommend you:
SimpleNoSQL
The transition from Firebase to SimpleNoSQL is pretty straight forward, and is mostly the same as if you were using any form of SQL:
1) You get the data from your remote db: you can get this trough a request to your remote server, it doesn't matter what language you are using as long as it can return a response you can catch.
2) You save said data to your local NoSQL db: once you have the information requested, it is up to you what to do with it. You could save it to a TXT file, a SQLite db, NoSQL db, save it to the SharedPreferences, etc.
Hope that helps.