I have a Windows Phone application that can receive push messages. How can I know that user didn't open some push messages that he had recieved? (I mean that messages that user didn't open via TOAST)
UPDATED
Is there any other way to understand if user has recieved a push message and did't open it (did't clicl on TOAST)
Push messages are fire and forget and thus cannot be enumerated as you describe.
The only thing I can recommend is to append a server ID to the NavigationUri of each message so the application can communicate back to the server to mark the message as read. Listing unread messages would fall on you, however, as they would need to come from your services.
However, there are several limitations to this approach:
The user may ignore the message
The application might be running (toast push messages aren't displayed)
The user may have poor connectivity
In the above cases, the ID would never be marked as read. You could still probably use this information to list messages from your server though.
EDIT FOR UPDATED QUESTION
No, there isn't
Related
I am using SignalR in my application to send messages to different users in a group.
We have the capability that messages can be added/edited or deleted and the same action is sent to all the users in that group via SignalR hub.
All that is working fine.
The issues is one could miss other people actions (message add/edit/delete) which happened during the time when his connection was lost/ internet disconnected or his laptop/machine was off.
After getting connection back or opening the laptop again that user must receive all those missed messages, missed actions which occurred during the time he was offline.
We are storing all clients (client id) of all users in database.
Can anyone give the pointers how to do that?
One solution can be to poll last message id (which has come to ui) to server check if any new message is there but that won't serve the purpose because message could have been edited/deleted at server from other user.
I have already gone through following links
Can SignalR handle missed messages?
Can a SignalR message loss be detected server side?
How to do guaranteed message delivery with SignalR?
Signalr client to retrieve missed messages on reconnect
https://github.com/JabbR/JabbR/issues/699
but none of them is covering the aspect for the entire history which happened during the time user was offline.
For example if you are disconnected in Skype and comes back say after few hrs it pulls all the history of all actions (message added/edited/deleted) that occurred during that time and update it to end user
Since SignalR doesn't povide any guarantees of message delivery - one should solve this by himself.
There are several approaches:
The first is to use message queues (ex: RabbitMQ).
This is the most efficient way to guarantee that message is delivered to client.
But in your case you'll need to combine message queueng with pub/sub way of communication. That can be tricky.
The second way is described in the answer to one of SO posts, that you referenced: Can SignalR handle missed messages?.
Don't send data over signalr, only notifications; then get the data update from the server.
That is my favourite way of client-server notification/update scheme. And I'd choose it in your case.
One solution can be to poll last message id (which has come to ui) to server check if any new message is there but that won't serve the purpose because message could have been edited/deleted at server from other user.
To overcome this you can poll not the last message, but history of actions made in conversation (add/update/delete message actions) since last updated and apply it on the client side.
I want to make windows based Whats App bulk messages sender application.
I tried WhatsApi (http://github.com/perezdidac/WhatsAPINet/) to do that, but I found too many limitations and problems.
I want to ask that, I there another way to send bulk whats app messages?
Sending bulk messages are against WhatsApps Terms of Service Agreement. WhatsApp offers users functionality to send broadcast messages, but with a maximum of recipients AND recipients will only receive your message if they have already saved your number in their contact list.
WhatsApp's Terms of Service Agreement states that you may not use the service to send bulk messages (in other words more messages than a normal person would be able to send during a specific time). This keeps their servers from being overwhelmed and keeps advertisers from abusing WhatsApp messages. You can, however, try to write a function to select x number of contacts and send the message, then repeat the function until all intended recipients have been messaged.
I made a simple notifier command line application in C#. Basically I use the windows task scheduler and set it up to run this command line application at a certain time.
When this time is hit the command line application is ran all notifications are grabbed from a database(using linq to sql) formatted and sent by smtp to the right people.
Now how should I handle these scenarios
A database error occurs
Solution: Send a email to the admin to notify them that it failed and to check it out.
A smtp error occurs
Solution: ?????
So these are really the two things that could go wrong. There could be different combination's of this.
Database error might occur and and smtp might occur too, Or only one or the other might occur.
So how to get this information to an admin or someone so they can fix it. I highly doubt that an admin would go and check every single day to see if the notification thing worked or not.
So basically how to make it fail safe or at least make it so that if something goes wrong a admin can come fix and it and just run the notifier manually and get everything back in sync.
You have a couple options.
Write the error information to a log. Make it a procedure for some operator to check the log every so often.
Have it call some other service?
However, if the database is used by more than just your app, it's entirely possible that someone else will notice. Same thing with the email server. If it's down, then I bet a lot of people will be making phone calls. Note that your situation precludes lost network connectivity (like a dead switch or misconfigured router).
Incidentally if it detects SMTP is back up, then it should notify someone that it was down for a given time period. Same thing about the database server.
Finally, ALL error conditions should be written to your system log. It's pretty trivial to write to the windows event logs. If your system administrators are following commonly accepted protocols they should be monitoring those pretty often anyway.
Logging an Error to the EventLog could also be an option, providing that the Admin either checks the EventLog regularly or that you have monitoring systems that aggregate those errors.
You could use an SMS gateway or attach a cellphone to the server and have it send a text message to an admin when something has gone horribly wrong.
But you can take this even further:
What if you lose network connectivity
(a switch or cable gone bad for
example)?
What if the power goes down
(when is the last time you tested the
UPS)?
Depending on your needs (and the business cost of not sending out these notifications in short notice), you may need a full-fledged monitoring solution.
So the main problem is that you do not know how to notify the admin in case of an SMTP server failure. You have several options, assuming the admin's e-mail account is not residing on the same server.
First option: You could set up a cgi mail script on another server and contact that via http to send the e-mail.
Second option: Use an smtp client and set it up to contact the receiver's smtp server for sending the e-mail directly (instead of going through the local smtp server).
BTW: Some e-mail providers offer text message notifications for e-mails originating from a certain address. That's very handy if the server goes down while the admin is away from his desk.
For your DB errors, you could hardcode in a (set of) email address for DB errors to be sent to.
As for the SMTP errors, you can either do a "send email when smtp recovers", or you have to have an alternate method for alerting your admins. This could be a backup SMTP server, a SMS gateway (as someone else mentioned), or even something such as someones desktop in the network popping up an alert if it doesn't receive some type of "everything is ok" alert/message from the box running the script.
How do you 'verify' that a message sent using MSMQ to a private local queue was actually delivered? I'm especially thinking of a scenario where the listener (a C# service in my case) is not running and therefore delivery can't be successful.
You can only guarantee that it can get to the queue without taking extra steps. To deal with the "not running receiver" scenario, you would need to code the receiver to send a message back to the server when it processes the message. The original sender would be responsible for tracking the sent messages and verifying that the client has recieved them.
That's one of the decisions you should be taking when deciding whether or not to use MSMQ as opposed to a remoting or a web service scenario. For example, we had a project used for notifying all of our retail locations when an emergency occurred (such as a product recall/food safety issue.) We needed to know immediately if the store's listener was running so we chose remoting, and when the sender received an error indicating one of the listeners was not listenting, we would need to pick up the phone and call.
Just something to keep in mind.
Edit - clarification
I was really giving out two options above.
Code the client to send a message back to the sender when it receives a message.
Use another option, such as remoting, where you can detect if the client is running and receives the message.
It's always sent to the queue.
If your service isn't running to receive it, it just sits there, waiting patiently, until someone receives it.
You know it's been sent to the queue because .Send() returns without crashing.
You can probably pull this info out using administrative queues
When you send a message you can specify the AcknowledgeType which will allow you find out (through positive or negative acknowledgement) whether the message reached the queue and/or was received from the queue. Acknowledgements are sent as messages, by MSMQ, to the AdministrativeQueue so make sure you assign that property on the Message object.
You can check the administrative queue for acknowledgements by correlation ID which is ID of the original message.
I have a job that runs which sends out emails to our users to which starts off a work flow process in our company. Periodically, a user will swear up and down that they didn't receive the email - though, when we go to the mail administrator to pull an exchange report, 10 times out of 10 it's in their deleted items. :P
I'd like to be able to programmatically verify that messages sent via .net C# (System.Net.Mail I think) reached the user's mail box.
It's exchange 2007 and all messages are internal.
You can't with System.Net.Mail. You'll have to dig through Exchange's APIs to determine if an email is present in someone's email account.
http://support.microsoft.com/kb/813349
Set an account for catching all bounce backs. In this way you will know which ones reached and which ones did not. This is the best way to ensure emails reached.
Alternatively you can add read reciepts via message headers(by setting the Disposition-Notification-To). but again, user can chose not to read it...
I see two ways to do what you want:
Send emails with "delivery confirmation" On (not "read receipt", this can be dismissed by the user as CoddeToGlory said). Then it's jut a matter of monitoring the mailbox that receives these confirmations via any way it's appropiate to you: Exchange Web Services, Outlook+COM or VBA, MAPI, ...
Use the powershell interface to Exchange and capture the output of Get-MessageTrackingLog looking for StoreDriver + Deliver events.