I'm working on outlook web app add in. Is there any way to catch event when email is sent?
Currently, this is an unsupported scenario. However, we are working on new APIs all the time, and this may be supported in the near future. Keep an eye on our announcements and check dev.outlook.com for updates!
Related
My system is sending mails to my clients when they apply for position. Part of that mail is:
We would like to invite you to take the next step
For Gmail users, it displays well, but in Outlook Web App my users see this sentence underlined and on click it shows suggested event.
Is there some escape character or some other way for me to disable this option? I want that sentence be plain text, not the event suggestion.
This is a feature of Outlook Web App that helps your recipients create events in their calendars easily. Could you please help us understand why is it a concern for your case?
More and more clients (especially on mobile devices) highlight meeting suggestions or meeting times and allow users to create events easily.
As a sender, you can't "disable" it. But the recipients can disable it via gear->manage integrations settings, if they do not like it.
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
I'm working on a SOS app that is supossed to send emails and/or sms when the user needs it to. This will happen using the contacts that the user added to the app. At the moment the user can add 4 of these contacts, regardles of the type (email/sms).
I'm already able to send sms OR emails using
await ChatMessageManager.ShowComposeSmsMessageAsync(chatMessage);
or
await EmailManager.ShowComposeNewEmailAsync(emailMessage);
The problem is doing both things, one after the other.
If I call both of this functions at the "same time", only one of them will show the respective page. Since OnNavigatedFrom and OnNavigatedTo events do not fire in these conditions, is there any other kind of event that fires when it comes back from the pages or some other way to wait until one of the pages is dismissed?
Thanks
Ok I've found the solution
Window.Current.VisibilityChanged
fires in this case. I'm able to figure out when the application is getting visible again and assume that the SMS was treated, launching the email at this stage.
I just start listening to the event before composing the SMS and release it when it comes back. It seem so simple now..
(Still don't know why OnNavigatedTo doesn't work)
Launch 2 SMS Compose tasks in Windows Phone 8.1 RT App pointed me in the right direction.
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.