I am developing an iOS messaging app that uses Twilio to send and receive SMS and MMS. The tutorial on Twilio about the iOS client seems to only cover outgoing and incoming calls. I understand that sending an SMS/MMS would mean that I send a HTTP request to my server, in which my server sends the request to Twilio in order to complete the sending. However, how would I receive messages on my app?
I know that Twilio numbers have web hooks that execute when the number receives this message, but how would I get this message to my app. I don't believe that there are delegate methods included like the voice ones. The only solution that I could think of right now would be to use push notifications from my server to the phone. Is there any other possible way? Thanks.
I was recently in a similar situation to yours, but my app only cares about receiving a response within a 2 minute window while the app is opened.
Regardless, I would say that your best options include 1) push notifications, 2) sockets (probably via Socket.io), or 3) background polling. If you plan to have your application receive the message agnostic of its state (open, closed, etc), then I would highly suggest using push notifications. I'm using Parse as my Twilio backend and it makes creating and working with push notifications a breeze :)
Related
Can we integrate VoIP services through the new framework CallKit without using any server services or push notification?
I am really new to this concept, also checked the speaker box app as a sample app but didn't get much idea how it would be working.
Please, share your feedback if anyone has integrated CallKit.
Thanks
The CallKit framework provides programmatic access to VoIP functionality, as well as call blocking and identification. Apps can use CallKit to receive incoming calls and make outgoing calls using the native phone UI.
Reference for call kit.
Can we integrate VoIP services through new framework call kit without using any server services or push notification?
No we can't use it. You will need third parties like Twilio, Plivo, or ICELink and create your own server. Then provide CallKit the data required, it will handle the call and UI stuff. You can read the apple docs for more ideas.
If a CallKit app only intends to make outgoing calls, then it may be possible to not have a server component. But if the app intends to receive incoming calls while the app may not be running (e.g. when it is suspended), those incoming calls must be signaled via Push Notification, and those push notifications are typically sent by a backing server.
I am currently working on an iOS app that allows users to make calls and send messages to eachother, effectively it is WhatsApp with a few extras.
When one of the users is offline, I send an APNS to the other user that brings up a short notification. The notification that is shown works well for messages but when it comes to an incoming call, it would be nice if it stuck around on screen and the phone vibrated for an extended period.
From what I have read, you cannot alter the vibration pattern of an APNS. WhatsApp, however, has managed to do it and I was wondering if anybody had an idea of how they achieve this?
You should use VoIP Push Notifications (PushKit). These are special push notifications intended to be used for VoIP call notifications.
Some source to get started:
http://blog.biokoda.com/post/114315188985/ios-and-pushkit
http://pierremarcairoldi.com/ios-8-voip-notifications/
I am new to iOS development and started a tutorial on a simple messaging app using Parse as the server. The way they have it coded, the app queries parse every time a message is sent(to save the message) but seeing as Parse only allows 30 req/sec under its FREE plan how would one go about making a messaging app? Is it standard convention to save data to the server for each message? It just doesnt seem practical to have a substantial user base on an app that can only query the serve 30 times a second.
The question simplified is: what is the standard convention for the relationship with servers for a simple messaging apps? Does the app save each message to a server or is there a work around using push notifications? (But even with push notifications the app would have to be opened to receive them, at least thats from my limited understanding of pushes)
It is not practical to have a substantial user base for a messaging app with only 30 queries per second. Parse is running a business. They give you 30 API req/sec so that you can try out their service and see how it works. But if you are designing an app for a significant user base, you will surely have to pay, as you are expecting Parse to run the servers for you.
With that out of the way, it would be normal for a (typical) messaging app to make at least one API request per sent message to the server. The server is responsible for accepting, routing, holding, and delivering messages. It would also be normal for that sent message to result in a push notification, and an API request from the client app to retrieve the message. The general workflow would be:
User sends message
App uploads message to server
Server determines where message is headed
Server sends push notification to recipient
Recipient app queries server for pending message(s)
Recipient app displays message(s) for recipient user
That's two API requests and a push notification for each sent message.
Beyond that, depending on your messaging service design, the server may also store all messages so that later, on a different device, a user can open the app and it will download the history, so as to appear synchronized.
Now, surely there are ways to reduce the number of server API requests. Your app could batch messages locally, your server could batch push notifications, and your clients could batch queries (or you could do all three). All of these options could help dramatically reduce the number of server API requests you pay for, but they will also reduce the responsiveness and user experience of your messaging service.
You could also design a sophisticated peer-to-peer communication system (like Skype was in the past) removing servers from the messaging flow. However, you would have to design complicated authentication and verification systems, complicated routing systems, complicated storage systems, etc. A lot of work. And even if you did, I don't know if Apple would allow it on the App Store. A lot of time, work, and uncertainty to avoid paying the small cost for a server.
Regarding push notifications: Push notifications are sent from a server to a recipient client app. Your iPhone cannot push notification another iPhone. There will always be a server in the middle. Your app does not need to be open to receive a push notification. iOS will receive it, and then deliver it to your app. If your app is closed, iOS will (partly) open it in the background to deliver the message.
I want to send and receive text messages without showing MFMessageViewController from my application. Could anybody tell me how is it possible?
Not Possible , Unless you use 3rd party api for send/received sms.
you have to use Web service and Apple Push Notification Service for send message to other user without using MFMessageComposeViewController
You can't do it without MFMessageComposeViewController. Apple won't allow to send SMS without user interaction.
I've alternate solution of this, out of scope of iOS. Use web service API. Create a web service at server side that send a message to specific number(s) that accept numbers as parameters with request.
At specific time interval (according to your requirement) send a web service call with number as request parameter.
Web server can do it. It can send message to any device.
I want to create an iOS chatting app using APNS. If I have 10,000 active and they are continuing chatting, will apple block my developer account ? Is there any limitation regarding this?
I would discourage you from using APNS as a backbone of an "chatting app".
If you need fast chatting functionality you should write your own TCP-socket based server.
If every-few-second syncing is o.k. you can get away with a HTTP-based server backend (but all the pull-syncing can be hard on network traffic - so TCP-socket is still better choice).
You could however use APNS for fallback - when your app on certain device is not responding (i.e. is not connected to server) you can send an initial message trough APNS (to wake up your app & to notify the user there is a message waiting for him).
As soon as the user opens your app you should switch back to your TCP-socket or HTTP request based server communication.
As for your question: no, Apple would most probably (one can never know for sure) not reject your app just because of using APNS for chatting. But note (as the others said allready): messages between two users will get "lost" if they would interact too frequently - see the link Roman Barzyczak gave you.
"If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one."
more information: http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
but Apple wont block your developer account :)
You can use them for messaging but you are going to quickly find out that there is no guarantee they will arrive. This is known as the black hole of push notifications. ;-)
I like this answer here.
First try to use an APNS only solution.
Make your push notifications stateless (they only serve as "Hey you have some new stuff in the server").
So when the client gets a push notification it asks the server for new data (messages or other stuff).
Use OneSignal to simplify the code that sends push notifications (from the back-end). If a user in your app gets a message after 10 seconds he dose not care if you used TCP,socket.io or xmpp...
Even Whatsapp's messages can take couple of seconds to arrive.
A chat app is not a realtime game. A delay of couple of seconds will be acceptable by end users.