I'm trying to make a chat application. For that I'm using firebase database. And to show messages using FirebaseRecyclerAdapter.
mNewAdapter = new NewChatRecyclerAdapter(
ChatMessageItem.class,
R.layout.message_item,
RecyclerView.ViewHolder.class, ref.limitToLast(300).orderByChild("timestamp"), isAMod, publicroom, Fusername, booIsPrivateChat, chatid, otheruser);
And for syncing,
ref.limitToLast(300).orderByChild("timestamp").keepSynced(true);
But everytime I reopen the app it takes 3-5 seconds to load all new messages.
So how can I fix this problem..
Thanx in advance...
The Firebase Database only synchronizes data while there is an active connection to the server. This normally only happens when the app is active, since Android closes the connection when the app is inactive.
While there is a connection, the Firebase SDK normally only synchronizes data in a location when you have an active listener in that location. When you call keepSynced(true) on a location, it will also synchronize when there is no active listener in the location.
Calling keepSynced(true) is most useful for the main list in your app, such as the data you show in your main activity. By keeping that synchronized, it will also be updated when your users are in a different screen. That way, when they come back to the main activity, the data is immediately available.
To reduce the time the user has to wait when restarting the app, you can tell Firebase to store its cache to disk by calling setPersistenceEnabled(true). Since loading from disk is typically faster than loading from network, this may speed things up.
Enabling Offline Capabilities so as your app will cache those data
FirebaseDatabase.getInstance().setPersistenceEnabled(true);
Enabling Offline Capabilities
Related
I use the Parse.com Cloud service in my Android app to sync data between devices.
I use the app mainly offline and use the local DB
Parse.enableLocalDatastore(getApplicationContext());
I would like to use PinInBackground() to store the data locally and sync once every day by hitting the sync button in my app.
Now if my app crashes or the device restarts - how do I know which objects are stored only locally so I can sync them with Save()?
pinInBackground() will not save to the cloud eventually. The only action that does BOTH is saveEventually(), which will pin your objects locally if your network is down so that you can still query them even though you are still offline.
More in the Parse Android guide
I have built a simple application that accepts data entered by the user and saves it to the local sqlite database. If wifi connection is available it will transmit the data to a REST service hosted on a remote server.
I have done the above part and it is working pretty fine. If WIFI is not available it will just move on and will expect new data from the user.
When the wifi becomes available, i have registered a broadcast receiver which will hit my database and get the values stored and send them to the remote server.
I would like to know, while the broadcast receiver is trying to query my database, if the user is entering data at the same time and it is being saved in the same database, will it fire a SQLException.
As i recall, only one service can access the SQL instance at a time. If it will pose a problem what shall i do to overcome it. I have looked at ContentProviders, would that be the solution?
I am fairly new to android. Please advice.
You may want to take a look at this.
What are the best practices for SQLite on Android?
For me, I would suggest to always create a ContentProvider together with DatabaseHelper when you need Database, no matter you need to provide your data to external application or not. It is actually not difficult to do, the best reference I used to build my ContentProvider is DeskClock, the official app from Android.
Edit:
As a side note, you should consider to create a IntentService to be called by your boardcast receiver to do the work, as broadcast receiver should not be used for long running task, like sending things to server.
BroadcastReceiver#onReceive
When it runs on the main thread you should never perform long-running
operations in it (there is a timeout of 10 seconds that the system
allows before considering the receiver to be blocked and a candidate
to be killed).
I'm developing an Android app that talks to a Play-framework app, the two apps are passing user data between one another using Volley requests, my question is this:
Is it desirable to have the Android app sync with the Play server constantly to check for changes to the user profile? (like syncing during a fragment change)
Or is it better practice to have the user on the Android app logout and back in before that changes occur.
Or is there some alternative solution that only syncs with the server if a change occurs?
I think the last option would be the most efficient and desirable, but I fail to see how could do the check without sending a request first to the server and if I'm sending a request to check for changes anyway, wouldn't it make sense to have the changes in the response.
You should not sync whenever a fragment changes. It is a waste of the user's battery and data. You also most likely don't want to force a logout/login all that often as it becomes inconvenient for the user.
If you are expecting very infrequent changes to the user profile, it might be better to send a push request from the server using GCM to inform the app that it should invalidate its local cache. Then query the server for new profile information.
If using push is unfeasible for some reason, you might want to look into using a SyncAdapter and syncing infrequently. In most cases, it should be okay if profile information is potentially behind unless the user is specifically checking the profile settings, in which case you might want to check the validity of your cache when they check their settings.
I see that there's an onDisconnect() firebase method, however it looks like that method is intended to update other client devices that the current client device has gone offline. For me this isn't very useful. All of our API calls are coming from a central server which handles updates to our other client devices.
Basically, I only have 1 client device communicating with the firebase server... ever. So my question is, when that single device loses connection how will I know? This is probably the most frustrating part of all, Not only do I not know when I lose connection, but I'm still making calls as if each command is successful.
Offline Behavior
Every client sharing a Firebase maintains its own internal version of any active data. When data is updated or saved, it is written to this local version of the Firebase. The Firebase client then synchronizes that data with the Firebase servers and with other clients on a 'best-effort' basis.
As a result, all writes to Firebase will trigger local events immediately, before any data has even been written to the server. This means the app will remain responsive regardless of network latency or Internet connectivity.
Once connectivity is reestablished, we'll receive the appropriate set of events so that the client "catches up" with the current server state, without having to write any custom code.
Take a look at Detecting Connection State in the Firebase Guide. It describes the magic data location /.info/connected that you can monitor for changes in the client's authentication state.
Note: For version 3.0+ see onDisconnect
I have two threads, each of which handle syncing data one way either from the server or to the server. The thread for getting data off the server needs to run once a day. The other sending data to the server needs to run every 15 mins. I am currently using an Alarm Manager to create repeating alarms for each of these threads. This is then received by a BroadcastReceiver, from which i call an activity, which then according to the data passed into the activity either runs the to server syncing thread or the from server syncing thread. I am using the activity to display a dialog box, to prevent the user from using the application until the syncing has been completed as they both access the database required by the application. Is this the correct way to accomplish this task, or are there better alternatives?
Thank you in advance
This question is not really fit for SO... This is more a debate without any details on how your app works.
Anyway I would use an Android Service to do so. You do not need to bother the user just to upload data. Also why block the use of the app for uploading? Since for uploading you only need to read, just make a snapshot of the current data and upload it. Any changes the user is making right now will be uploaded in next upload, so that's not a problem.
For downloading, you most likely do need to block the app use, but maybe not. This depends on how the app works. You could start DB transactions to avoid doing that.