I'm looking for a way to detect if links have been shared in an iMessage conversation. I'm not sure if this can be done with MSMessage, as it looks like it only receives events from messages created by your iMessage app.
Does this mean there is no way to access the conversation outside of the scope of messages created by your iMessage app? Any help is very much appreciated!
Your suspicion is correct. You can only access your own extension's messages.
Quote from the documentation for MSMessagesAppViewController.didReceive(_:conversation:):
You only receive notifications about messages sent using
your extension. You cannot interact with messages from other
extensions.
At the moment you can only access messages that come from your app AND :
that were selected by the user. Meaning that any previous message
sent via your app won't be accessible unless the user tap it.
that were received during the app runs
Note that we are only at the third beta test (at the moment I'm writing) of that new feature. As an "enhancement" were open for this feature, apple developers may allow an app to access messages (of course messages sent via this app, Apple is really worry about all that confidentiality stuff ;) ) in the future
Related
I read the documentation for facebook messenger bot but I can't find anywhere if it is possible to make two different FB bots(one test bot) and connect to the same Facebook Page(to use the same webhook. Does someone know if this is possible and is it aginst FB rules?
You're going to want to investigate the Handover Protocol (Beta). This will allow you to subscribe two or more apps to the same Facebook page. One of the apps will be configured as the "Primary Receiver", which will have control of any new conversation thread by default. All other apps will be configured as "Secondary Receivers". Any app can pass thread control to another app, but only the Primary Receiver can forcibly take control from another app.
When an app is in control of the thread, it will receive messages on the standard messaging channel. When an app is not in control, it will instead receive them on the standby channel. Standby messages look just like regular messages, except that their entry items contain a "standby" field rather than a "messaging" field.
Here's the kicker: apps are allowed to send messages whether or not they have thread control. This means that you cannot rely on the handover protocol to automatically sort out when your bot can and cannot talk. Instead, your bot will need to keep track of whether or not it has control and only respond at the appropriate times. To accomplish this, the messaging_handovers webhook will be helpful.
Facebook has provided a new version of their page Inbox which supports the Handover Protocol. When configured as a Secondary Receiver, new conversation threads will automatically be filed into the "Done" folder. If one of your apps passes thread control to the Inbox app, the conversation thread will be moved to the "Inbox" folder. When a human page manager clicks the "Done" checkbox on that conversation, the thread is moved back to the "Done" folder, and thread control is passed to the Primary Receiver.
One thing to be aware of, at least as of November 2017, is that the interaction of postback messages with the Handover protocol is a bit unintuitive and possibly even buggy. The postback documentation indicates that an app will always receive its own postbacks on the standard messaging channel, even if it does not have thread control. From the description of the "title" field of a postback event:
Title for the CTA that was clicked on. This is sent to all apps subscribed to the page. For apps other than the original CTA sender, the postback event will be delivered via the standby channel.
As the description of the "payload" field indicates though, the standby version of a postback message omits the payload:
payload parameter that was defined with the button. This is only visible to the app that send the original template message.
I suggest that this is unintuitive because it seems to me "standby" has a different meaning for regular messages than for postback messages. I mention that it might be buggy because I have found my apps often receive their own postbacks on both the messaging and standby channels. (I have taken to ignoring postback messages on the standby channel for this reason.)
Hope this helps.
Yes you can subscribe more than one app to the same Page. You will need to designate one as the Primary Receiver role in the page settings, then use the Platform's handover protocol to pass control of the conversation between that apps.
i am developing fb chat bot, and i want to mark the message as read so that when the moderator of our fb page view the message part, they won't see so many unread messages even though the fb chat bot has already replied that user and they don't need to click that message just to mark it as "read".
How can i achieve this? I am trying to use this API: but it doesn't work.
https://developers.facebook.com/docs/messenger-platform/send-api-reference/sender-actions
You can not mark message as read (as of now), but the best way I deal with this is to use Handover Protocol
When your bot reply the message, it won't appear in INBOX, but it goes to DONE box instead.
When bot cannot answer, you can let your bot pass thread to INBOX. Then the moderator of page manually answer it. (and mark as DONE afterward)
Follow the instruction here to set it up:
https://developers.facebook.com/docs/messenger-platform/handover-protocol/pass-thread-control
(Note: You can pass thread to page inbox and then take thread back immediately. I will notify to INBOX, but your bot can still work with users.)
When you use the API you sent here (Facebook's Send API), you only mark the message as "seen" from the bot on the Messenger Chat that you have with your users. This doesn't affect the messages inside your Page's inbox.
Unfortunately, there is no way to mark messages as read inside your Page's inbox.
Is this new feature of fb bot? Thanks btw! I will try to check this.
Is there any side effects in Marking the message as done ???
To answer your question:
There are some bugs within the Inbox/Pages Manager mobile app. You won't see the messages in DONE folder if your admins are using Pages Manager mobile app for now.
I've reported the issue and working with them to solve it. However, you can still see those messages in DONE folder if you use a computer and go into your page's Inbox.
NOTE: It seems that messages moved to Inbox will be marked as seen (not bolded). This may be a little confusing if your admins don't mark each conversation as DONE after admin finishes conversation with the users.
I searched all already asked questions here on Stack Overflow, and all of them deal with "sending" an SMS programmatically to another phone and that is NOT what I want.
I want to just add an SMS to the inbox, without using the cellular network or any other service and write a from "my_company_name" etc. Basically I want to avoid making the user or my company pay for the SMS. I know about push notifications and I will use them as well, but I need SMSs.
I thought about that maybe, if the user sends the SMS to himself it would be free of charge, but that "seems" to be not true at all.
The Messages app (and its notification UIs) only displays messages that come in over SMS or iMessage. What you're looking for isn't possible with public API.
As there is no public API available to do this (I guess you already now that), you'll have to go for the private APIs.
You might want to take a look at the source code of BigBoss's WifiSMS. This app allows one to control the iPhone's SMS system thru your computer. I haven't tested it myself yet, but BigBoss is a pretty credible application creator when it comes to jailbroken devices.
We are developing an iPhone application that allow users to send messages to others via Apple Push Notification Service when the target user have installed our application or SMS when haven't.
We want to get notified immediately when our app is uninstalled so that we can decide how to send the message to the target user.
We find the APNS feedback server have a long time delay that doesn't agree with our requirement. So we use another way: when our server recorded the target user have installed our application, we send him message via APNS, if he haven't read the message in 30 minutes, we believe that he has uninstalled the application, so we send the message via SMS.
Is there any way better?
As Oleg said, there is no way to accurately detect if your app was uninstalled.
The APNS feedback service returns a timestamp and a push token for messages it was not able to deliver. Sometimes, this indicates an uninstallation but it can also simply indicate a user that was simply offline at that moment. The Feedback service does have some lag so can not be used for time-sensitive intel gathering.
Based on your requirements, I'd say you're doing it right.
One suggestion that may or may not work for you would be to include a link (via url handler) to your app when you resort to sending an SMS. If it makes sense for the user to return to your app, clicking on that link should launch the app and you'll have a trace on your server if you make a simple call. If, however, after sending the SMS the user is not detected as coming back into the app, chances are highly likely that the app was indeed uninstalled or that the user is offline for an unusually long amount of time which may require some other type of action on your part.
Until yesterday I thought that it was not possible to send background SMS without using the IOS SMS interface (Which many people here assure also). However, today I downloaded a new app called SmartSender, which schedules your SMS and then sends it automatically.
I tested it and the SMS is not actually sent on background, but a local notification appears and when you click on it to bring app to foreground, the SMS is sent automatically.
How could this be achieved?
Maybe Apple approved the app because the interface is very clear on what you are doing and what you are sending, but how can you send SMS without showing the interface?
Update: The scheduled SMS appear on my phone Messages app as sent, so I don't think that they are using another service to send SMS, also the receiver phone is indicated that the SMS was sent from my phone.
Update 2: OK I'm using and watching the app doing this, so IT IS POSSIBLE without showing the default interface, I'm not asking whether this can be done or not. I am using it with all internet connections turned OFF, and the message is sent from MY PHONE so it appears on the MESSAGES APP. So the app is not using any third party service.
Update 3: I will accept my own answer, in fact it is not possible; however it was when the question was answered. The App in question has now specified in its description that it won't work in iOS 6, so I think Apple patched some bug that could be exploited to achieve this functionality.
Having tried the app, I can verify that it does send SMS programmatically, without showing the SMS interface. And it clearly doesn't happen through a third-party service, since the message gets sent as an iMessage when possible.
It's also clear from all the other answers that there aren't any public APIs for sending SMS programmatically, so the developer must have used a private API and yet somehow snuck this app through the approval process.
Specifically, it seems he used the CoreTelephony API. This post on SO describes the procedure. Apparently you'll also need to get your hands on the CoreTelephony header files somewhere.
I've been looking into the SMS send/receive limitation on iOS for a few days, using iOS 6 and XCode 4.5 (latest as of writing). I was curious about this SmartSender application so I purchased it.
I don't know if it's because I only tried it on iOS 6, but I get the standard message controller (MFMessageComposeViewController) to send messages. I have tried delayed send - I get the message controller at prescribed time and have to manually click on Send. I have tried immediate send - that pops up the controller and I also have to manually click on Send. If I click on Cancel, the app actually loops me back into the message controller (I can't cancel unless I kill the app!)
So true, this allows entering messages from a custom UI, but then the message itself is copied into the MFMessageComposeViewController and that is what sends the SMS. So App Store approved, but nothing like what we're all looking for!
You can not send SMS programmatically in background, you can use following third party API to send the text message (SMS).
http://www.twilio.com/
http://www.nexmo.com/
https://www.tropo.com/
I would suggest nexmo, its easy to use and support international messages also.
In fact it is not possible; however it was when the question was answered.
The App in question has now specified in its description that it won't work under IOS 6, so I think apple patched some bug that could be exploited to achieve this functionality.
You can use:
[[UIApplication sharedApplication] openURL: #"sms:+3912345678"];
it doesn't work on simulator... and you cannot send programmatically sms!
Tested on iOS < 6.
There is no way to send SMS programmatically. You may want to investigate a 3rd party service service for sending SMS like Twilio.