1) With a Free Gmail account were unable to get the MessageLabelsChanged event to fire. We're assuming this should occur when you take a gmail message and add or remove a label from it.
At the same time, we ARE able to get the Idle, CountChanged, MessageExpunged and MessageFlagsChanged events working..
We are calling it on the Service.Inbox object.
We found this link https://github.com/jstedfast/MailKit/issues/208 about wrong event raised. Our labels are very uniquely named, therefore we believe, they should not be confused with events?
2) What is the ImailFolder.Subscribed method do? Should this be called to solve issues #1???
Many thanks Jeffrey!
I should probably remove the LabelsChanged event from ImapFolder because GMail is not very good about sending those notifications to the client (in fact, I'm unable to get GMail's IMAP server to send them either).
I've mostly kept it for completeness in case GMail's IMAP is ever fixed to reliably send those notifications.
Related
so this is something I've been trying to think through for about 16 hours. I am coding with PHP / CuRl / etc - the bot works and everything is fine. My current issue is figuring out how to disable the bot and allow a human to begin chatting with the customer/sender.
Has anyone successfully, created a route for this ? I mean it's pretty hard from what I see, you'd have to disable etc etc. A lot of effort for my clients.
Thanks for any input.
Facebook has rolled out a "Handover Protocol" which is supposed to facilitate a combined human/bot Messenger implementation.
https://developers.facebook.com/docs/messenger-platform/handover-protocol
It is a little unclear what actually occurs in step 5:
Pass thread control: At some point in the conversation, a user may choose to do something like interact with a live agent. To handle this, pass thread control from the Primary Receiver to the Secondary Receiver. The Secondary Receiver will receive a messaging_handovers webhook event to notify it that is now controls the conversation.
This doesn't actually disable the bot (as the OP requested), and isn't in the control of the Page owner but rather of the user. It seems FB envisions the user typing something like 'I would like to chat with a human' triggering the bot to pass control...but it would be nice to let the page owner simply put the app in standby and handle the messages herself.
Once you recognize someone wants to speak to a human, set a flag that disables all actions of your bot to on.
Then, have your bot message you, or whoever will respond, that a user ID needs responding to. Have your bot continue to send all messages received from them back to you until you enable the bot again.
Create some sort of way for your bot to interact with you that allows you to send a message to a specific user, and a way to once again enable the bot interaction with the user.
Probably something like "sendMessage104012301230'Hi, sorry you couldn't find [etc]', and enableUser104012301230
There may be a better way, but those are some thoughts on how I'd do it
If you enable messages echo, whenever a human respond using the page, a echo post is sent, and inside entry->messaging->message there's no app_id.
You can use that information to disable bot replies for a certain period, or disable indefinitely until you enabled is with some admin command (that's how I'm doing)
I thought a solution could be to label the message as "unsolved". Another solution could be to have the bot mark the conversation as unread. Does anyone know if it is possibile to add a label to a conversation or mark as unread through API?
I have a situation where I would like to programmatically (re)send a confirmation (opt-in link) email to a member who has unsubscribed.
I know I cannot directly re-subscribe them, but I was hoping there would be a means of at least sending a confirmation email.
Is it possible to trigger the confirmation email for an unsubscribed member in vs 3.0 of the API?
I know I can resend it from the Web UI but I'd really like to accomplish it via an API request when a user who has previously unsubscribed performs some action on the website indicating they'd like to be added again.
Deleting and Adding the member is a last resort, but I would prefer to keep the original account (and its data) in place.
Re-sending an opt-in email for someone who is still in a pending state isn't supported AFAIK, but once the user is unsubscribed, I think if you set them back to pending it will resend the email.
Alternately, I've not found deleting and resubscribing to cause much data loss (if any) so you might try that out too, if the above doesn't work.
I want to know whether I can send text message on desire time automatically. The sending time of message and receiver mobile number is set by user some time before.
Please give me some code or links if it possible any way...thank you.
You can't do this with the official SDK, since you have to display the MFMessageComposeViewController.
If you would do it server side you would be able to do it, but you would most likely have to pay for the SMSes you send.
I heard that push notification is not reliable. What could be the alternative for this?
The use case I am trying to handle is:
1. I have a app which will be shared by three kind of groups. Each group contains certain set of persons.
2. A request is submitted by first kind of group and it will be serviced by second kind of group. So, all persons who are part of second group should be notified and no one apart from them should get the notification.
3. Similarly, A request is submitted by first kind of group and it will be serviced by third kind of group. So, all persons who are part of third group should be notified and no one apart from them should get the notification.
4. Even second group persons can submit a request to third group.
Please provide your thoughts as how should I handle these scenarios.
Push notifications rely on the network (3G/WiFi) presence to deliver the notification. Also, there is no response back from the Apple Push Notification Server which guarantee the delivery of the notification. Having said all these things... iPod touch is higly unreliable for delivery of notification because one, it do not have 3G; second, for saving battery its notifications are internally turned off for some time....
One Alternative to this is to keep polling the server in a background thread for any modification. But this will work only when app is running.
Another Alternative can be writing our own APNS kinda infrastructure.
you're right to say Push Notifications are not reliable.
For one thing, if the device is not connected to the internet, APNs only keeps one push notification to be sent when the device connects again (the last notification sent from the provider). Since there's no way to determine if a notification has been already sent or not after your servers sent them to APNS, you can't even try to queue the notifications on your end.
Other than that if your app depends on PN the user can easily break it's functionality by turning notifications off.
So you're absolutely right, if the data you want to send is critical, then you shouldn't use Push Notification. But I believe there's really no solution to your problem. you simply can't rely on them for your app to work.
I think the best approach would be like the email app for example, where you can download your emails when you start the app wether you have PN turned on or not, and the PN just notify you of new email, even though it's not guaranteed you'll get it at all.
There is no alternative, since Apple does some very low level communication. You would need to work together with the mobile providers to build something like the notification services.
That said, I don't think the service is not reliable. Maybe you should check your implementation.
You are right that APNs does not guarantee delivery: From their docs, they say that:
Important: Because delivery is not guaranteed, you should not depend
on the remote-notifications facility for delivering critical data to
an application via the payload. And never include sensitive data in
the payload. You should use it only to notify the user that new data
is available.
So, 'Litmus', a web app for testing emails and webpages across browsers and email clients, has a proprietary method that they claim is able to track not just opens, clicks, browsers, etc (standard with an embedded image and pass-through link tracking.)
What's unique is they claim that they are able to track what actions the end user took, how long the end user read it for, and if they deleted or forwarded the email. They claim they do this without JavaScript, and purely using embedded images. They claim that the method works across most major email clients.
What could they be doing to track this? Obviously, if they're doing it with third party applications that they don't control, whatever they are doing should be replicable.
I'm thinking that they realized that when an email client forwards or deletes an email, it 'opens' the email in a different way then normal, creating a unique user string on the server log of some kind? I'm grasping at strings, though.
http://litmusapp.com/email-analytics
Details here http://litmusapp.com/help/analytics/how-it-works
EDIT: It also looks like they track Prints. Maybe they do this by tracking calls to the 'print' css?
It's all done with good ol' image bugs. Breaking down how they find out...
Which client was used: Check the user-agent
Whether an email was forwarded: Done by attaching image bugs to divs that are loaded only when the message is forwarded.
Whether an email was printed: bug attached to print stylesheet
How long it takes to read an email: A connection that's kept open, as pointed out by Forrest (this is also how Facebook tracks(ed?) whether or not you are online on chat).
Whether an email was deleted: Check If a message was read for a short period of time or not opened. In fact, they group "glanced" and "deleted" together.
Of course none of this will work if email clients disable images in emails.
EDIT: Here's another question on this:
The OP actually has their tracking code, and this answer here explains how it works.
One way I can think of doing that is having an embedded image that loads from a script on a server. The script would not return anything or maybe send data really slowly to keep the connection open. Once the email is deleted the connection would be closed. This way they could know how long the email was open. Maybe they just assume if it's open for less than 10 seconds it was deleted?
Another way is tracking the referrer - this would give a lot of data on what a webmail client is doing, but I doubt it would be useful with a desktop client.
They know when the email is opened (it's when the image is called from their http server).
They also know what the user do and when since they can easily replace all links with their own tracking URLs redirecting to the original link.
There is nothing exceptional here. They are just a bit more advanced than their compatitors. There is no magic.
I have only one doubt: how they track delete. Technically, there is no way to know what happened to the message after it was read.
I suspect that a "deleted" mail is a mail that is never opened.