Is it a good practice to use messaging to notify the client of the state of the current file being uploaded? In my current application, every file which is uploaded goes through a series of checks on the server, for instance EXIF data checks, before notifying the client that this file is completely accepted.
You may hold FileUpload Request on server side till File Acceptance, and use this request reponse to Notify Flex, in FileRefrense Event COMPLETE
Hopes that helps
Related
I am attempting do the following
write a document to server.
wait for the success event and check for metadata to confirm if its written to server
if it is not written to server even after the time out (using a timer) undo the write operation.
this is for WEBRTC calls so if a user attempts a call but was offline and closes the app since it did not succeed. after a long time the receiver would receive a call and would be weird.
There are no undo operations in Firestore. The client SDK tries doesn't really give any way to discern if the app is online or offline - it simply tries its best to service the requests that you give it via the API.
If you want to perform some operation while only online, then use Cloud Functions to make an HTTP request to backend code that performs the actions you want. If the app is offline, the HTTP request will obviously fail, and you can decide what you want to do from there.
Firebase has great option of using their database and sending data to their db even if you are offline, and then when the connection is up again, it sends automatically the data to the db.
is it also possible to do it with the Firebase storage like send images even if the internet is off, and then when the internet is on again, it will send the images files automatically?
If so, how can I do it? If not with Firebase, any other option?
Yes. The Firebase Storage client supports resuming uploads.
See the Firebase Storage documentation for uploads (iOS, Web, Android).
From there for Android:
uploadTask = mStorageRef.putFile(localFile);
sessionUri = uploadTask.getUploadSessionUri();
//save the sessionUri to persistent storage in case the process dies.
And then to resume:
//resume the upload task from where it left off when the process died.
//to do this, pass the sessionUri as the last parameter
uploadTask = mStorageRef.putFile(localFile,
new StorageMetadata.Builder().build(), sessionUri);
Update (20160809)
One way to handle the sessionUri:
when you create the uploadTask, get the sessionUri and store it to the app's SharedPreferences.
when the uploadTask completes, remove the sessionUri from the app's SharedPreferences.
when the app restarts, check if there is a sessionUri in the SharedPreferences. If so: resume that upload.
Technically, the accepted answer is incorrect given the OP question, which is,
send images even if the internet is off
The accepted answer talks about resuming a download once started, which correct in detail but does not address the answer correctly.
The corrected answer is "no", you cannot upload an image to Firebase Firestore if the device is not connected to the internet, the upload will fail and there is no auto-restart of the upload operation.
As previously noted, you must be connected to the internet, at lease long enough to start the upload and get an uploadsessionuri URI from Firebase. Once the upload has started then you can resume the upload using this sample code or the code above.
As noted in the documentation, the resume URI is valid for about 7 days but it is the developer's responsibility to ensure that the file contents has not changed since the start of the upload.
I'm trying to understand what I will need to build on my server for Push notifications to work successfully.
My thoughts were:
The phone sends the notify URL to my server
The server stores the information in a Database
A separate process or PHP script will query the database and open continuous looping process for each device. (Each socket will be querying a 3rd party API)
When there is a change detected in the API for that device a push notification will be sent to the device's notify url.
Is this the right method on what needs to be done. Isn't this going to eat up server resources or is it the expected outcome of Push a push notifications server?
I've produced a simple diagram on all this below:
First of all, let's separate the process in the main stages needed for PUSH.
Device subscription.
Send the PUSH
Process the notification on device.
Subscription
For the subscription, your device (more specifically, your App) must call the PUSH api,for enabling PUSH notifications. This call to the push API will give you a URL that uniquely identify the device where your application is installed and running. You should store this URL on your database, the same way you store a user's email, or a user's phone number. No special black magic here. You only use it when you need to send a communication to a user.
Send the PUSH
For the push stuff, the same approach as for email, or SMS messaging here: "One does not simply make an infinite loop and send a message if any change is detected". What you have to do is, just send the PUSH message when your application needs to. So you have the user to which you want to send a message, instead of opening a SMTP connection to send ane mail, just build the PUSH XML Message and call the URL associated with that user. Some things to consider here are:
Network reliability (you need to retry if you can't connect to the server).
Response error code-handling (you don't need to retry if the server tells you that the phone has uninstalled your application, for example).
Scalability. You don't want to send a PUSH message from your PHP code, because you don't know how long it will take for the task to be completed. You have to make this thing asynchronously. So just queue up all the push messages, you can create a separate process (windows service, nodeJS service, cron job, daemon, etc.) to send the PUSH, handle retries and errors and clean the queue.
Process the notification on Device
So now that you are this far, you need to handle the notification on the phone. It depends on the type of PUSH notification that you are sending:
Tile. You will update the image, text and counter of the application tile, if the user has put your application to the start screen. On client side you need nothing to so, as all these parameters are part of your PUSH request.
Toast. This one requires a title, text (limited to some 35 characters more or less) and a relative URL inside of your APP. Your application will be launched (like when you click on a Toast notification from Twitter, for example) using the URI that you specify in the payload. So a bit of data can be already injected here. You may/or may not make a request to your server for new data. It is up to you.
Raw. This one is pretty much silent. Is not seen by the user if your APP is not running. As you might guess, this kind of PUSH is useful to live update your running APP, instead of continuously polling your server, wasting user battery and bandwidth and wasting your server resources. You can send anything (raw bytes or strings) up to the max size of the payload allowed my Microsoft.
If yo have any more questions, don't hesitate to ask.
Bottom line: separate the PUSH sending, make it async, don't you ever forget that...
Your PHP script that continually pings the database for changes...THAT is what will eat up your system resources. Push notifications go hand in hand with Event Driven Programming. This means that ideally, your code shouldn't continuously ping your DB. Rather, when something happens (ie, an "event"), THEN your code does something...like contact your phone via push notification.
Your steps for push notifications are more or less correct, but are incomplete. Step 4: the server contacts the client via the notify url (which you have). Step 5 is that the client then contacts the server to actually pull down the information it needs. That is: The new information is not provided to the client via the notify url. Once the client has its new information, then the program continues as normal (populates a list, downloads skynet, etc.)
Your third step is very wasteful and not practical if your app is installed on more than a few devices.
Instead, each device should be subscribed to types of server updates it cares about. Your server's DB will have a mapping from each type of update you support to the list of notification channel URLs of devices that care about this update type.
When your server detects an update of type X, it would send a notification to all devices subscribed to that type of update.
I've posted this in Firebase's google group but haven't received an answer so I thought I would try here.
Let me outline my current scenario
I have a global messages bucket that stores messages by room. So path messages/room_1/ would store a prioritized list of messages for room 1.
I want to stream the latest messages for all rooms so that I can send push notifications to offline users. So essentially I want to listen to the /messages path from a ruby or python backed server and send notifications to offline users.
My problem is that when I initially start listening to the /messages path I get the entire set of data, which can be millions of messages. After the initial bulk load, I get new incoming messages in real time. Is there any way to skip that initial bulk load of data and just get new messages from the start of the streaming connection?
Fyi, I'm using examples from this page: https://www.firebase.com/blog/2014-03-24-streaming-for-firebase-rest-api.html
I've been doing some research about secure tokens and Firebase JS, but I have ready some conflicting information, so I will just ask my question directly. Is it possible to handle secure sessions with Firebase using Javascript? For practice, I'm creating a little web game that will rely on Firebase to synchronize each client, and I'm wondering the process for doing so securely.
It depends on how you define a "secure session". There are two issues at play here.
Transport level security: The Firebase JS client communicates with the servers over HTTPS. Additonally, Firebase has a security rules system that lets you specify which clients can read and write which data.
Application level integrity: However, the client is free to make whatever changes it is authorized to, even if they are not triggered by your JS code. For example, in a web page, I can open the developer console and use the Firebase API to make data changes that aren't part of the web page's logic.
To tackle the latter, you'll need a server where you can run trusted code to enforce game state. For instance, every move made by a client in the game should be first put into a "pending" queue. A server process should monitor all pending changes, validate them and them move them to a "final" game state location which will be the authoritative game state.