I'm writing an xmpp ios chat app which connects with an openfire server.
The app needs to be able to download all the messages that were missed by the user while the app was closed. So I will need a way to save the missed messages sent on the server, does anyone know a good way to do this? Is there a plugin for something like this, or would this require a custom plugin or something else?
Openfire, like most other XMPP servers, already stores the messages sent by users, when the receiving bare JID was offline, so that it can send those message to the client when it (re-)connects.
See also:
XEP-0160 - Best Practices for Handling Offline Messages
XEP-0013 - Flexible Offline Message Retrieval (supported by Openfire)
Related
I am creating a chat application with Node.JS's Socket.IO and there is a couple things I need clarification on.
I am implementing offline messaging in my app meaning that when a user opens the app he will receive all the messages he missed when they were online.
This is my approach:
1) Client opens the app and is subscribed/joins a room
2) The client sends a message to Socket.IO
3) Socket.IO inserts the message in some kind of database/datastore
4) When client tries to retrieve the messages it is pulled from the database/datastore and saved on the users phone then it is deleted from the database.
Is this a correct approach?
I was looking at online and some people suggested using task/message queues like Google App Engines Task Queue but I am not sure how this works.
Your approach sounds OK, but I wouldn't delete messages from a DB, at least not immediately after the client receives them.
From your question it seems that you're not currently saving the messages to a database.
This approach has some drawbacks; for example, the user can't view their chat history on a device that was not connected when some of the messages were sent.
There are 2 ways I can think of to do it in a more elegant manner:
Save all messages to DB. on websocket connection and reconnections, fetch all messages newer than your latest message (This approach assumes no edit functionality in your chat, as edits will not be fetched this way). The latter can be implemented using either HTTP or WebSockets.
If you don't want to store the messages in your server, then you should implement some sort of persistent cache in the device used to send the messages. This is very similar to your original solution, except that instead of storing the messages in a database, you're storing them on the user's device. this does require some logic to detect when messages are received, and when the recipient reconnects, in order to trigger sending the missing messages.
The first approach is much better for the general use case in my opinion, but it depends on your use case.
I have implemented chatting application using XMPP iOS Framework with OpenFire server.
Fortunately, application is running successfully but I am facing one issue of internet disconnection in application.
When user is getting logout or went in offline mode manually then it sends stanza to his/her rosters. So his/her rosters knows that user went in offline mode.
Now when internet will disconnect from user's device at that time application is not able to send presence stanza to server due to internet disconnection. So his/her rosters won't get information about that offline user and user will be shown in online mode only.
I thought something like OpenFire server might be able to check connected users and whenever any user gets disconnected it should send presence stanza with offline status to his rosters so they can know that this user is on offline mode.
Can anybody please help me if there is any way through which I can implement this feature.
It will be very helpful for me to solve this issue.
Thanks in advance.
It's the core xmpp feature and Openfire must send unavailable to your contacts on your behalf. So it looks like a bug.
But there is a different problem - users with mobile internet may reconnect too often, and XMPP community developed a Stream Management extension, which allow server to "hibernate" client session when it quickly reconnect and restore it without presence changes. Summarize:
Check if Stream Management is active - in this case user will still online fixed amount of time (typically 5 minutes) and then go offline.
Check if Openfire implements any non-standard extension to maintain user session.
If you are sure none of extensions are "hibernating" user session - then it is a really bug. Try the same with different xmpp server - good candidates are ejabberd and prosody
How to transfer file when receiver is offline in XMPPP Protocol? Which extension have to use? Any sample code available for iOS?
You need to store file somewhere and send link as described in Out Of Band Data extension. Message will be delivered when recipient will be online.
You can check that your receiver is offline. So If receiver is offline than you have to upload your message to your server using web service. And your receiver have to get all offline messages using web service after xmpp stream connect.
This is best way for offline message. Please do like this and let me know if any problem.
A web application acts as a backend to process request coming from the iPhone. To send messages to iPhone from web application while processing a request(e.g., for payment), I want to send messages to iPhone when something interesting happens on the server or else if everything is successful, sending them transaction details. Which one is better to use PushSharp or SignalR? Does they both serve the same purpose? Either way, enlighten me on this topic. Its confusing to me.
SignalR is a great way to send real time information to a web client, essentially having server-side code push information to the client and call client-side code (i.e. javascript) in realtime.
PushSharp is a great way to send push notifications to native mobile apps. For iOS, this means using Apple's infrastructure. It also means that the message will be shown as a notification in the iPhone and not just inside the browser.
Essentially, if the iPhone request you mention is coming from a native app, try PushSharp. If it's a web app running in a browser, use SignalR.
PushSharp appears to leverage the native messaging for each platform. Azure Notification Hubs provide native messaging similar to what PushSharp appears to do. The native messaging platforms scale out very well, but do not give you direct access between client/server code, and messages can be delayed in some cases up to minutes. Messaging like this works really well when you want to send messages to millions of devices. Example: all users who want an alert when their favorite sports team wins a game - not time sensitive to the minute.
If you want your push message to be strictly between your server-side code and your client-side code, SignalR can achieve that. SignalR also has a .Net implementation, so it isn't just for javascript/web pages. SignalR is will leverage approaches like web sockets / long polling / etc. If you are sending a response to tell your client that a query has finished, or that a message was received, and it doesn't help to have that message arrive minutes later... SignalR may be a better approach.
I'm using Facebook Chat API in an iOS app. I already can send a message successfully to a Facebook friend. Now I'm wondering if a can send the same message to multiple recipients.
I don't know if it's technically possible or there's any limitation about that.
I know that I can create N messages for N users and send one by one. But depending on the number of Facebook friends that the user can select, it can take a long time until all the messages are delivered. If this is the only case, should I open one different thread for each message that is going to be sent with the XMPP stream?
I appreciate any resolution or clue for this question.
There's an XMPP extension XEP-0033: Extended Stanza Addressing which supports multicasting messages to multiple recipients. The extension has progressed to draft status, however few XMPP servers or clients support it. I doubt Facebook Chat does, and couldn't find any mention in the XMPPFramework source.
I don't think there's a better way than sending the same message to multiple recipients. Some servers may require you to pause between sending lots of identical messages, and I wouldn't be surprised if that were true of Facebook Chat.
Multi-User Chat is another way to accomplish this with XMPP, but unfortunately Facebook Chat doesn't support MUC.