Develop Reference

How to Keep Mobile and Server in Sync during a Transaction?

I am committing a transaction to database. If the client loses wifi connection during transaction but after after commit it will not know the transaction completed. The problem is that the server should only commit the transaction permanently if the mobile app agrees and the server knows that the 1) mobile app has agreed and also 2) mobile app is aware that the transaction has been completed. The solution would seem to be for the mobile app to send a confirmation message that it confirmed the transaction, but what if a disconnect issue occurs after its confirmation is received on the server but before the server sends the 200 back? Now server thinks mobile app is aware but mobile app does not know for sure that the server got this message. This almost seems like handshake of some type because both sides must know what is on each side. The problem is how to handle transactions in unreliable networks where the server needs to know that the client both accepts the transaction and is aware that the transaction has completed before making the transaction permanent.

This is a Two General's Problem, and as such is unsolvable. A confirmation's confirmation is just yet another message to confirm and thus given finite time going back and forth you'll never perfectly confirm the original message is sent and both parties know it for sure.
In practical life, you will have to pick what kind of risk you accept. On low-risk messages like friends agreeing to meet each other, one confirmation reply is usually enough for them to proceed, despite the chance that the reply never actually made through. Now think about paying through GPRS-based EDC. There's always a possibility the connection gone off right after completely delivering the payment instruction and doesn't come back before the customer decides to leave. Without the confirmation receipt printed, the store will usually treat the payment as never completed, only reverting the transaction later. Both the store and the customer accept this risk.
The "Your Coffee Shop Doesn’t Use Two-Phase Commit" post is a really good read when designing your system. Consider the requirements. Is rollback unacceptable? Is there a certain level of inconsistency that's tolerable, or even expected? Maybe you can even reduce the client's role to merely attempt to send the command and then read-back from the server, discarding it's own.

How to know which offline data has been synced to firebase Realtime Database

I'm writing a chat application with the help of firebase.Here I have a problem , if the device is offline the data is stored in cache and when device is back online the cache will be synced , but how to know which data is synced and which not (User may have poor internet connection , so syncing may be delayed).How to notify user that message has been sent or sending , and that too we need to manage a huge list of messages
Thank you!

There are two ways:
Using a completion listener as shown here: Firebase Android - how to tell if node has been synced This approach works as long as the app stays active. Completion listener don't survive an app restart, so it won't work if the app is restarted.
Using a sentinel value. Writes to the database from a single client are guaranteed to be executed in order. Using this knowledge, you could write a sentinel (think: dummy) value when the app is restarted, or the connection is restored, and detect when that one is written. Once the sentinel value is confirmed, you can be certain that all older messages have also been handled by the server.
Also see:
Firebase synchronisation of locally-modified data: handling errors & global status

Realtime Database show if data is still hasn't been uploaded

so I'm working with realtime database and I'm trying to make a chat app for practice.
I want to add the message to my list then let the message item inside the list upload the message to the server, I'm also showing an indicator that tells the user if the message is being uploaded, there are other approaches to apply this but I want to go with this one, anyways.
there isn't any problem when there is an internet connection. the problem is when there isn't any internet connection, the message is added to the list and the indicator appears, when the internet connection returns everything works fine still.
but if I send a message (while offline) and then leave the chat room and return to the chat room, the messages will get loaded and the indicator won't appear altho it isn't uploaded to the server (the data is cached now).
I want to find a way to tell if the data has been uploaded or not? I don't want to check the server to see if the node exists, I can't do that to every message it will cost too much, thank you.

If you enable disk persistence, Firebase keeps all of its pending writes in its disk cache. When the app restarts, it reads those pending writes and starts trying them. This is usually the right behavior for your users.
Unfortunately there is no built-in way to persist completion handlers for the Realtime Database. So upon a restart it becomes impossible for you to detect when the pending writes have been committed on the server.
So this typically means that you need to do something custom to detect the situation, and will have to determine for yourself whether the use-case is worth the effort.
If your messages are in some way ordered/timestamped (for example, if you add them by calling push()) you can keep track of what the last message is for which you received a confirmation from the server. That way you will know when the client restarts, which messages may not have been sent to the server yet.
Your onDataChange or onChildAdded will be called for those unconfirmed message straight away though when your app restarts, so you'll need an additional mechanism to detect when those unconfirmed messages are written on the server.
The best approach I know if is to write a "dummy" message when the app starts. Since the pending writes are treated as a first-in-first-out queue, your new dummy message write will be sent to the server after all the pending writes from the previous run. So when your completion handler gets called for this dummy message, you can be sure that all messages before it have also been committed (or rejected in case they violate your security rules).

Firebase cloud functions fires an onFinalize event when a file has been uploaded to the storage. So you could probably write a cloud function like this.
exports.uploadedServer = functions.storage.object().onFinalize((object) => {
const filename = object.name
//mark this filename or filekey as upload complete
return
})
You should be able to find more explanation here.

Message queuing from android considering unreliable network

My architecture will use ActiveMQ on the server and have Android clients send and receive messages.The network situation will be very unreliable; possibly hours of missing connection. Is there a framework that will allow me to queue up the messages on the android client and deliver them reliably once the connection is back?

You can efficiently implement one yourself, I don't think anyone will provide you this service, and if they do they will certainly charge, Here is what I can suggest for an optimal solution.
Design a db using SQLITE to hold you message, once a message is ready for deliver from android client, you can perform the following
a. If network is avaibale, then you can directly deliver message to your web clinet
b. If network in not present, then cache it directly to you local android db
Design a Sync logic, you can achieve it by network listener, so when user device comes back into network,
you can write a logic to query from databse and posting to your webclient, deleting local data subsequently
upon successful posting into server
You can strengthen you logic, by caching message everytime into local db first, then a Sync logic which will commit your local changes to web server in bulk, thus improving upon processing time.
Hope this answer your problem.

When SyncAdapter runs synchronization on android?

Let's say, my application implements SyncAdapter functionality and doesn't define periodic syncs. When synchronization will happen in such scenario? First scenario I may think about is local ContentProvided/database content change.
What is about server changes? How SyncAdapter will know about that?

If you have no periodic sync setup, Sync will happen if your code explicitly calls ContentResolver.requestSync(Account account, String authority, Bundle extras) with your account and authority.
Also, if your ContentProvider insert or update or delete functions call ContentResolver.notifyChange(Uri uri, ContentObserver observer, boolean syncToNetwork), if the bool syncToNetwork is true (the default), it will also trigger a sync. There's a short delay induced here, to ensure that a batch of database changes only causes one sync, not one per change. Note that your code should be calling notifyChange because it's how Android signals your UI to update after Content that the UI is reflecting had been changed.
If the server database changes, your app won't know, because sync isn't happening. Two options:
Use periodic sync. This will be cleaner if your server API implements etags or the if-modified-since http headers to filter the data you sync so only the updates come down.
C2DM (Cloud 2 Device Messaging) Essentially, push notification for Android. Requires some server components -- You tie a device ID to an account on the server and when the server changes, it has to explicitly send a message to the device to tell it to update. This is custom code work on the server to support android specifically, but once you invest the time, it's great. C2DM is how Android gets gmail to show up on your device 10 seconds after it arrives in your inbox, rather than at the next 10 minute periodic sync. It's also more battery efficient since you only turn on the radio and sync when you know there's new data to get.