Develop Reference

IsNetworkavailable property always returning true

How to find weather my windows phone internet or network connection is on in c# code? For me, isnetworkavailable returns true always.

You may try to use GetIsNetworkAvailable which returns a result based on the network interfaces available. Like this:
bool isNetworkAvailable=NetworkInterface.GetIsNetworkAvailable();
if(!isNetworkAvailable)
{
//your code
}

The only way to find is to subscribe to the event DeviceNetworkInformation.NetworkAvailabilityChanged.
Once you have received that event (which is guaranteed on happen on changes of the network), then you will know whether you are connected or not by querying the various apis here.
There is a sample code that will exactly tell you how to do so.
You can also check what kind of network you are on with NetworkInterface.NetworkInterfaceType, however be careful as calling this API might freeze the calling thread (or the UI if you're running off the main thread) under certain circumstances (connecting to a wifi for instance is one of them).
You should be fine however if you follow the examples, once again !

Retrieve a List of Calls made Through Twilio

For a call tracking application I'm developing, I want to maintain local database.
As it stands, the application searches for new records in Twilio and inserts them into my database every time it loads. This is very time consuming.
In order to avoid that runtime expense, is there a way I can use usage triggers in Twilio to automatically populate my database in real time? Or even just daily?
If not, how can I achieve something like this?

Since Twilio is already calling your servers (unless there's some way to use it without doing that, but I don't think there is), can't you implement logging there? For instance, before you feed back your greeting, pop in a logging routine to note that you've received a call?
I'm not sure if they offer any other sorts of APIs or callbacks, but I really don't see why anything like that would be necessary. It'd just tie up your servers with more requests at no additional gain. I was just going through their documentation and I don't see anything like this. I could be just totally glossing over it, but again it just seems redundant. The entire Twilio system is based effectively on event hooks, so having separate ones wouldn't serve much additional use.
On the other hand, if for some reason you have absolutely no access whatsoever to the code or people behind the code that serves TwiML back, unless someone else is seeing an event hook API, you might want to just set up a scheduled job on your server (or in Azure, or whatever you're using) to query Twilio daily, since I know you mentioned that that would be sufficient. You could also, of course, set it more frequently. But that really seems like a waste of resources and effort when they're already telling you everything about every call through the massive list of query parameters they pass with every request.

3rd party dll raising events

I use a third party dll to get some data from their servers. There is a void method that I call and then i subscribe to an event raised by the call to this method. The event raised returns the data through its parameters.
so,
call to : void getdata(id)
raises: void onReturn(object) --> which returns an object that has the data.
This WORKS everytime when there is a single call to getdata(id)
The problem is when i loop through the list of ids, and inside that loop call getdata(id) for that list, the corresponding events are not raised properly.
Say for a list of 10 ids, there are 10 calls to getdata(id) but only few onReturns are raised.
The returned object also returns the id that was passed to getdata(id) so I can match the data i sent and the data that i receive.
Is there a way to make sure that all events get listened to? So if I send 10 ids by getdata(id), I want to make sure that the 10 onReturns are processed.
And i'm using c#, .net 4.0
Thanks

If it's a third party DLL, there's no telling how they've implemented it. When you step through in Debug mode, do you get past the call to getData() before the onReturn() listener is called? If so, it might be using threads (or at least asynchronous listeners) internally, and calling multiple getData()s too close together might cause it to stomp on pending responses.
The only way I could think to try and get around this is to use multithreading yourself, e.g. with a Mutex that waits after the call to getData() and releases in the onReturn() event. This way you'd only have one outstanding request at a time, which seems to be the condition that works for you.
Edit: Have you talked to the third party vendor about this yet? I'm guessing their support isn't the best if you thought of us first, but it might be worth a shot.
Edit the second: When you say it gets data from their servers, does this mean it makes requests over the network? If those requests aren't encrypted, perhaps you could reverse engineer the protocol and make a new API for yourself instead of relying on a proven buggy black box.

Looking for best practise for writing a serial device communication app

I am pretty new to serial comms, but would like advise on how to best achieve a robust application which speak to and listens to a serial device.
I have managed to make use of System.IO.SerialPort, and successfully connected to, sent data to and recieved from my device. The way things work is this.
My application connects to the Com Port and opens the port.... I then connect my device to the com port, and it detects a connection to the PC, so sends a bit of text. it's really just copyright info, as well as the version of the firmware. I don't do anything with that, except display it in my 'activity' window.
The device then waits.
I can then query information, but sending a command such as 'QUERY PARAMETER1'. It then replies with something like:
'QUERY PARAMETER1\r\n\r\n76767\r\n\r\n'
I then process that. I can then update it by sending 'SET PARAMETER1 12345', and it will reply with 'QUERY PARAMETER1\r\n\r\n12345\r\n\r\n'.
All pretty basic.
So, what I have done is created a Communication Class. this call is called in it's own thread, and sends data back to the main form... and also allows me to send messages to it.
Sending data is easy. Recieving is a bit more tricky. I have employed the use of the datarecieved event, and when ever data comes in, I echo that to my screen. My problem is this:
When I send a command, I feel I am being very dodgy in my handling. What I am doing is, lets say I am sending 'QUERY PARAMETER1'. I send the command to the device, I then put 'PARAMETER1' into a global variable, and I do a Thread.Sleep(100).
On the data received, I then have a bit of logic that checks the incoming data, and sees if the string CONTAINS the value in the global variable. As the reply may be 'QUERY PARAMETER1\r\n\r\n76767\r\n\r\n', it sees that it contains my parameter, parses the string, and returns the value I am looking for, but placing it into another global variable.
My sending method was sleeping for 100ms. It then wakes, and checks the returned global variable. If it has data... then I'm happy, and I process the data. Problem is... if the sleep is too short.. it will fail. And I feel it's flaky.. putting stuff into variables.. then waiting...
The other option is to use ReadLine instead, but that's very blocking. So I remove the data received method, and instead... just send the data... then call ReadLine(). That may give me better results. There's no time, except when we connect initially, that data comes from the device, without me requesting it. So, maybe ReadLine will be simpler and safer? Is this known as 'Blocking' reads? Also, can I set a timeout?
Hopefully someone can guide me.

Well, Thread.Sleep() is blocking too. Much worse, actually, because you'd have to specify a sleep time that is always safe, even if the machine is under heavy load. Using ReadLine() is always better, it will be quicker and it cannot fail.
Note that your example doesn't require the client code to wait for a response. It can simply assume that the command was effective. All you need is an Error event to signal that something went wrong.
If there is a command that requires the client code to get the response that you should offer the option to wait as well as get the result asynchronously. That gives the client code options: waiting is slow but easy, async is difficult to program. It is a very common pattern in the .NET framework, the asynchronous method name starts with "Begin". Check the MSDN Library article about it.
You also should consider delivering asynchronous notifications on the thread that the client code prefers. The SynchronizingObject property is a good pattern for that.

If you do all of your reads on a background thread, then I don't see any problem with using ReadLine. It's the simplest and most robust solution.
You can use the ReadTimeout property to set the timeout for read operations.

You may want to read this Serial Port

2nd call to Device.Reset in DirectX throws an InvalidCallException

I've been working on a DirectX application in C#, and I noticed that when I lock the workstation, the DirectX "Device" becomes lost. After looking up the information about what to do upon when a device is lost (and when a DeviceLostException is thrown by Device.Present), I re-wrote the code to reset the Device. This simply meant that I made a call to Device.Reset.
Calling Device.Reset recovered the Device. No problem. But when I lost the device a second time (for example, when the computer was locked, went to sleep, or activated a screen-saver), an exception was thrown by Device.Reset.
The exception was InvalidCallException, which (according to the documentation) means something went wrong with the call. So I assumed it was a problem with the arguments to the function. So instead of passing the same copy of PresentParams that I used to create the Device, I created a new instance of PresentParams (at first using the copy constructor, and later by re-creating without it) and passed that to Device.Reset.
Doesn't work. Device.Reset still dies with the InvalidCallException. Oh, and the message of the exception? "Error in application." Not helpful.
Can you point me in the direction of either a solution, or some documentation about how to get more debug information out of DirectX?

OK, I know how silly is seems to answer my own question, but I figured someone else might need this, eh?
The answer is: there were too many calls to the Dispose method of the VertexBuffers in the scene. The reason being that the internal Device reset-handlers were calling the Dispose method. And why was that happening? Because I had neglected to read the .NET DirectX SDK documentation regarding the Pool Enumeration, and was allocating the VertexBuffers using Pool.Default instead of Pool.Managed.
So obviously, after a few thousand badly done allocate-and-release cycles, something went wrong.
Oh, and how did I discover this? I attached a listener to VertexBuffer.Dispose which incremented a counter that I displayed on-screen. Imagine my suprise when I noticed this counter kept growing as I resized the window!