There are two things that are unclear to me about TwilioVoice for iOS, after having followed the quickstart demo.
First, I want my app to be only able to receive phone calls, and not to make some. So I want to know, do I really need to call TwilioVoice.register(accessToken)? Or something with CallKit would be enough?
My other question is about access tokens. In the quickstart demo, an access token is fetched every time the user enters ViewController, but since I only want to be able to receive phone calls, I was thinking of fetching access token only in the AppDelegate, but I wonder if I would have issues with the token lifetime?
Thank you for your help,
Yes, you still need register your device. When user A makes a call to user B, Twilio needs user B's device to be registered so they know where to send the VoIP push notification to. CallKit manages the local on-device call state, it doesn't provide the network side of the call. Twilio provides the network side of the call.
You're correct with this. In our application, we register any time application(_:didRegisterForRemoteNotificationsWithDeviceToken) is called since that's the method that provides your application with the device token you need to pass to Twilio.
I'd caution against taking Twilio's sample project as a good sample project. I had to rework most of what they did in their example when I built our implementation. There's WAY more state management that needs to be done to nicely integrate with CallKit.
Related
Currently building a mobile application that ideally would have functionality that allows one user to "nudge" another user, pretty much the equivalent to a Facebook "poke." For the sake of building quickly, we'd like to use as many third-party libraries/services as possible. So far we were looking into using pusher and expo, but to be totally honest, we are a bit confused as to how to architecture this.
From what I understand, the front-end (ios app) would subscribe (open a socket) to a specific channel/server and the server would then send messages to the client(s) that subscribed whenever necessary. How this works with users being subscribed to every other user they are friends with, I don't understand. What's the proper way to architecture this?
I also read that on the front end, when a user doesn't have the ios application open you can't have any websockets open to the server, so how does that work?
Additionally, how does one bundle notifications??
Really confused with this, any help would be greatly appreciated.
Chris
Well, push notifications now mostly are implemented with Firebase. This is a service inside most of mobiles, so you only need use these libraries to implement your client application.
From the server, you only need to consume a rest api of Firebase.
Now there are permissions to allow mobile applications receive push notifications in background. You do not need to implement a socket or websocket, that is a feature of Firebase.
Read more about this.
https://medium.com/google-cloud/push-notification-for-react-native-bef05ea4d1d0
https://dzone.com/articles/how-to-add-push-notifications-on-firebase-cloud-me
From all I have read here, creating a call tracking app on iOS seems impossible. However, after some investigation, I have found a couple of workarounds and would like to know if they are legal and would work at all.
So, at least, I will need one of these features:
access call log history. I've read that's impossible, but also I know that on many devices where iCloud backup is turned on, call history data is saved there, so using some API, for example, this, I can access it. Am I right?
receive notifications when the call is ended. I've read this is possible only in foreground, therefore makes no sense. But following this question, I see that you can initiate calls from the application, which allows at least to track outgoing calls.
Would this be enough or I am wasting time?
Unless you're running on a jailbroken device, the answer is no because there is no publicly available API that provides access to the call list and that is a good thing from a privacy point of view.
A quick search shows that CallKit is for integrating VOIP into the call list, so again the answer is no, CallKit will not be of any use to you.
The notifications are there so that your app can respond properly to calls that take place while it is active.
I'm trying to get into a new project, by creating an iOS application. But before I start I would like to understand some points:
is it possible to let an application make a phone call? So what I mean is, assumed we have a phone number and would like to call it. Would it be possible to use an (my) application to call this number?
is it possible to let an application speak during a phone call? So after the application started the call, would it be possible that some predefined statements are said in the call?
is it possible that this application hears, registers and analyses what the other person on the phone line is saying? (Leaving apart the privacy issue, assuming that the other person is willing to do that).
Could you please help me? If my question aren't clear, please tell me, I will try to explain it in another way.
Many Thanks
F.P.
iOS is very restricted in terms of the system behaviors third party applications can influence.
To answer your question bluntly, a third party application could prompt the user to initiate a phone / FaceTime call. Once the call is initiated however, your app would enter a background state and relinquish control to the system. The app would not be able to contribute or read any data related to the system phone / FaceTime call.
iOS 10 introduces a VoIP extension, CallKit, which allows third party apps to use the built in calling UI with a custom protocol. You could implement your own protocol (and host servers for handling the exchange of information) and build an extension to make it feel like a system call. You'd be responsible for all aspects of the custom call protocol and thus reading voices, contributing audio, etc. would all be possible (and up to your implementation).
Outside of iOS 10, you would have to built your own VoIP system and interface entirely from scratch.
For more info on CallKit:
WWDC Enhancing VoIP Apps with CallKit
CallKit Enabled Sample App
I am implementing the push notification in iOS for sending offers and deals. Right now I am working in the development environment. I see that some of the devices are not being notified. Could anybody explain possible causes? I have also read that if a push is sent to same device multiple times then APPLE disables them for that particular device? Could some one verify this or provide any documentation where I can find the issue. Any feedback would be appreciated.
Not directly answering your question, but what you asked about in the comments and an alternative. You could use a push-notification service such as Parse.
They allow you to send Push Notifications to Web, iOS and Android, also offer data storage and backend infrastructure. The best thing about Parse is that they're free. Unless you have one million unique recipients, which is rather hard to accomplish. Parsee allows you tons end Push Notifications in multiple ways, some including automatic messages based on their tables or other events. You can program those in their cloud code. You can do so using their REST API or their Java Script API if you have a website. You could also send from the Push window on their website.
Setting up is fairly easy. I'll give you the most important links below.
iOS Quick Start Guide
Rest API
PHP Guide
Hope that helps, Julian
If you are dependent on APNS then there is no guarantee provided regarding the delivery of the push notification. And regarding sending multiple notifications. Like if you send notification every min then many may not deliver. Else it will. This service is free and many including myself using it on a regular basis. It has been delivered regularly even though apple will not provide any guarantee. i'm using a php script on server side to send push notification. Refer the below link if you want to know how to send a push notification using php.
tutorial
I would like my app to receive updates to the logged in user's newsfeed without constantly polling for the current newsfeed to be returned to my app.
I see a lot of questions that are close to what I'm asking for but the one's I've checked are either never answered or have answers that are merely generalities providing no details nor pointers to where details can be obtained.
I'v heard that Facebook uses Comet and/or ajax push for its chat implementation but can it be made to use this for pushing newsfeed updates to my app? If so, is there some place where I can find examples of the use of the facebook API to accomplish this?
Yes, This is possible by creating Push Notification app from the Facebook developers site. Create an app for pages and then u can connect to the pages using Graph API editor and also configure the notifications received by this application to be forwarded to a callback URL. Read The Real Time Push Notification document on Facebook developers.
Short answer, no. The Facebook Graph API does not support push notifications. You have to poll. The one alternative seems to be for Blackbery devices that recieve push notification of facebook updates. But i believe that is because RIM is doing the polling themselves and then pushing the notification to the device.
To the best of my knowledge, the only way to get info from the Graph API is to pull and poll.
Yeah i don't think this would be possible yet, given HTML is stateless, there's no way the server can post back to the clients, as the clients only get responses to their own requests from the server.
You'd need something that can establish a connection and listen on a port, that's the sort of length you'd have to go to (non-html based, embedded in the page)
I wonder if you could stagger out and slow down a server's response to an ajax request, so for example, the server doesn't finish responding to an ajax poll request for 30 seconds, but if during that time something happens, it has the ability to respond immediately... something to think about. I'm not sure how long a browser will wait for the response to come back, but you could exploit that by polling only once per time-out period.