I am looking to create a chat app so that two iphones/mobile can chat with each other.
Can someone please head me in the right direction ?
1. Should I try to connect two devices directly using HTTP or TCP
2. Or should the communication pass through a server i.e. one phone sends the message to the server and server then push the message to other phone ?
If you can tell me any libraries/api that I should use, that would be greatly helpful too.
Or should the communication pass through a server i.e. one phone sends the message to
the server and server then push the message to other phone ?
That's the usual approach. A server with a known address is easy to find; mobile phones that move from one network to another and frequently change their addresses are not. Also, you can keep a server running all the time, so that when one device sends a message, the server receives it and stores it until the other device becomes available. If you were to try to run your chat program on the phones all the time, you'd quickly deplete the batteries.
Related
I am trying to understand the best practice for remote notifications on iOS when the user has a particularly poor network connection or no network connection.
The scenario is such:
The user gets some remote notifications and at some point in the future opens the app. At this point I wan't to let the server know ASAP that the badge count is now zero. I am using server side badge count management as the only way you can update the icon badge reliably is in the APNS payload. However the call to the server fails as there is no network connectivity. Then the user puts the app into the background so I can't make any further calls to the server if network came back. Subsequently a new remote notification comes in but the badge number is wrong because the server doesn't know it needed to be zeroed.
Am I missing something here? Any advice gratefully received as I haven't found any articles online dealing with this scenario.
Yes, you have implemented in right way. We can't do anything if there is problem in internet connection. Badge count is managed by server only. So, whenever you open application, application will update Zero to server. Now, if it is not properly updated to server then it is not possible to manage it from Mobile side.
I am facing an issue with the presence status, following the documentation and XMPPframework example code. I have written a chat application.
Problem : When the user 1 & 2 are online I get the status successfully and they can chat with each other. However when the user 2 goes physically offline via (Wifi OFF / 3G Off) User 1 is not getting the offline status from XMPP and hence what ever messages are sent from that instant of time are lost when the user 2 comes online.
It seems since the user 2 is not notified or stored as offline in XMPP and hence its not storing the offline messages to push back to user 2 when it comes online.
I have tried to resolve this by explicitly writing a [goOffline] call to XMPP, however the call is shown in 'SEND log' for 'user 2' but not received in 'RECV log' in user 1 from XMPP, due to which the message are lost in between.
Also tried with other sources replies.
Set status for presence available and send XMPP
priority changed with values non-negative
XMPPArchiving work but this is not what I wanted.
Server side Mod_zero push enables but get only first message push notification sometimes.
Setting limit on ejabberd.cfg file for users and offline message limit.
request for offline message pull.
Can anyone help me with this?
This is very typical situation where client losses network but server can't detect that it is offline.
To detect status of each client, server need to send PING packets to every client and wait for response.
If client responds then fine otherwise server will mark that client as offline and every other online client will be informed automatically.
Here is PING Module implementation for ejabberd XMPP Server (hope you are using ejabberd server):
mod_ping:
send_pings: true
ping_interval: 10
timeout_action: kill
ping_ack_timeout: 10
This has to be written in ejabberd.yml configuration file.
At client side also we need to enable ping module to respond to server pings as:
private var xmppPing: XMPPPing?
xmppPing = XMPPPing()
xmppPing!.activate(xmppStream!)
This code has to be written while we setupStream() for iOS.
For detailed info, please go through mod_ping documentations.
Sounds like your problem is at server level. The server thinks that the user is online so it sends the message but nobody gets it. This does not really have a simple solution.
1.
The best solution would be delivery receipts. Where basically when the message is sent to your client, your client returns a confirmation of delivery receipt. If the server does not get that receipt it would resend the message every n time. Depending on your XMPP server you might find a already made solution, of not you would have to roll out your own.
2.
A possible hack would be to have your server always store and deliver last 10 messages and then at client side you discard repeated... This also depends on your server implementation. XMPP MUC and PubSub have resources along these lines.
For a long term scalable solution, you'll need to deal with this both at server and client level.
i went through this question
Lost messages over XMPP on device disconnected
but there is no answer.
When a connection is lost due to some network issue then the server is not able to recognize it and keeps on sending messages to disconnected receiver which are permanently lost.
I have a workaround in which i ping the client from server and when the client gets disconnected server is able to recognize it after 10 sec and save further messages in queue preventing them from being lost.
my question is can 100% fail save message delivery be achieved by using some other way i know psi and many other xmpp client are doing it.
on ios side i am using xmppframework
One way is to employ the Advanced Message Processing (AMP) on your server; another one is to employ the Message Delivery Receipts on your clients.
The former one requires an AMP-enabled server implementation and the initiating client has to be able to tell the server what kind of delivery status reports it wants (it wants an error to be returned if the delivery is not possible). Note that this is not bullet-proof anyway as there is a window between the moment the target client losts its connectivity with the server and the moment the TCP stack on the server's machine detects this and tells the server about it: during this window, everything sent to the client is considered by the server to be sent okay because there's no concept of message boundaries in the TCP layer and hence if the server process managed to stuff a message stanza's XML into the system buffers of its TCP connection, it considers that stanza to be sent—there's no way for it to know which bits of its stream did not get to the receiver once the TCP stack says the connection is lost.
The latter one is bullet-proof as the clients rely on explicit notifications about message reception. This does increase chattiness though. In return, no server support for this feature is required—it's implemented solely in the clients.
go with XEP-0198 and enjoy...
http://xmpp.org/extensions/xep-0198.html
For a XMPP client I'm working on, the following mechanism is used:
Add Reachability to the project, to detect quickly when the phone is having connectivity problems.
Use a modified version of XEP-0198, adding a confirmation sent by the server. So, the client sends a message, the server confirms with a receipt. Later on, the receiving user will also confirm with a receipt. For each message you send, you get two confirmations, one from the server, one from the client. This requires modifications on the server of course.
When the app is not connected to the XMPP server, messages are queued.
When the app is logged in again to the XMPP server, the app takes all messages which were not confirmed by the server and sends them again.
For this to work, you have to locally store the messages in the app with three possible states: "Not sent", "Confirmed by server", "Confirmed by user"
I'm just starting to get into app development and have just been learning the uses of Xcode and Objective-C language. Just wondering how an app like snapchat or any other app can send data from one user to another. General answers would suffice just to better my understanding.
How do they test this functionality?
How can they connect peer to peer and send data from one phone to another? Is it all accessed in one database that the app connects to everytime that it pulls down?
When you sign up for an app like this with a registered account is that information stored on the iphone?
Well there are two ways data can be sent to a device. One is the device polls the main server periodically. This can be seen in a pull to refresh scenario. The other is the server can send a push notification to the specific phone and app which causes the data to be received by the device and displayed however the programmer wants. So device to device is essentially one person sending something through a web service call to your server. Your server them packages that information into a Json payload and sends a push notification to the recipient. It seems like its device to device because its so quick, but it requires that you have a server in the middle and of course your server is really sending the push notification to Apple's push server, so there really are two servers involved.
How do they test this functionality?
I would try to do this with real devices, and/or using a network sniffer tool to inspect the send packets.
How can they connect peer to peer and send data from one phone to another? Is it all accessed in one database that the app connects to everytime that it pulls down?
Someones sends you a snap
your app will ask the database every ...min or when you reload if there's something new to load, and gets it from the database if there is something new
When you sign up for an app like this with a registered account is that information stored on the iphone?
Connect to snapchat
get a snap from someone and wait till you can view it
start airplane mode and see if it loads, if it does there are files (temporarily) stored on your iPhone.
I have a project where I need to be able to send messages from a server running a web service to a specific iDevice. I have no idea how to do this, so any help is very appreciated.
The scenario: I have a web service which receives some message from an iDevice (could also be a Mac or PC, even an Android device). Depending on the content of this message I need to be able to send a message from the web service to another iDevice (I know the IP-address of the specific iDevice). I know how to use URLRequests to send a message from an iDevice to a server and collect the response from the server. In principle I could every 10 seconds send a request to the server asking if the server has any new messages to the sender (the iDevice sending the request), but I am pretty sure this is not the correct way to do it. Is there a way to have an iDevice listen for server communication on a specific port, so that the iDevice only does something active when it receives a message from the server to do something, e.g. display a message in the app listening for the server communication?
I guess I need to use something similar to the technology used for iMessage, but how is this done?
I am using XCode 4.6.2, iOS 6.1.
EDIT: Just to clarify my needs a bit more: The APNS seems to be TOO unreliable (at least that is what I have read in other threads regarding APN) as the web service in some cases can have the need for sending 2 distinct message to an iDevice within 1 minute (in some cases seconds), and as far as I have read in other threads this will simply not be possible because of how Apple's server handles ASPNS.
The app i am developing only needs to receive messages from the server when the app is active - is there any way, not using APNs, to do this, e.g. making the app listen for communication on a specific port?
Your scenario seems pretty similar to APPLE PUSH NOTIFICATIONs (APNs).
Ideally your server side should write a code in such a way that if there is any change on server side & need to be informed to all associated devices.
Then your server should post notification Apple server which will then send a notification to all the associated devices.
Refer this link
You already have but can use this code to identify the iOS/Mac deivce
NSString *identifierString = [[NSUserDefaults standardUserDefaults] objectForKey:#"myID"];
if (!identifierString) {
CFUUIDRef identifier = CFUUIDCreate(NULL);
identifierString = (NSString*)CFUUIDCreateString(NULL, identifier);
[[NSUserDefaults standardUserDefaults] setObject:identifierString forKey:#"myID"];
}
NSLog(#"%#",identifierString);
this code works till the lifetime of the app only.
After some search I have decided not to use the APNS, because it seems like people are having all sort of experience with it. I cannot use APNS because my project needs 100 % reliability and instant communication with the server.
I have decided to use tcp communication since my project only will be used in a local network. This will obviously mean more power consumption on the iDevices, but reliability is more crucial to the project.