Nadav and the wonders of the web

While looking for a full article about this I found out it won’t hurt to have another quick explanation about this process.

Sometimes when creating an application you want some sort of verification about which phone is accessing your service (service-client application). A good way to do this is to use the unique device id.

Now I will explain how we do it, we are going to get a 40 char string that is hashed with an AppString we will provide which will be unique to each and every device, and will be constant for this device and AppString.

First we define the P/Invoke signature:

[DllImport("coredll.dll")]
private static extern int GetDeviceUniqueID([In, Out] byte[] appdata, int cbApplictionData,
                                            int dwDeviceIDVersion,
                                            [In, Out] byte[] deviceIDOuput, ref uint pcbDeviceIDOutput);

Now we are going to define a private static member so we don’t go through the entire process every time we need this and then create it with a public static method:

private static string s_UniqueDeviceID;

/// <summary>
/// Gets the unique device id, this is an unique id of the phone
/// which is hashed with the AppString
/// </summary>
/// <returns>a 40 characters unique id</returns>
public static string GetUniqueDeviceID()
{
    if (string.IsNullOrEmpty(s_UniqueDeviceID))
    {
        // define AppString
        string AppString = "MyAppString";

        // get the byte array for the string
        byte[] AppData = Encoding.ASCII.GetBytes(AppString);

        // some parameters for the native call
        int appDataSize = AppData.Length;
        uint SizeOut = 20;

        // our out parameter
        byte[] DeviceOutput = new byte[20];

        // Call the native GetDeviceUniqueID method from coredll.dll
        GetDeviceUniqueID(AppData, appDataSize, 1, DeviceOutput, ref SizeOut);

        // check that we got something
        if (SizeOut > 0)
        {
            // build text from received bytes
            StringBuilder resultText = new StringBuilder();
            for (int i = 0; i < DeviceOutput.Length; i++)
            {
                resultText.Append(string.Format("{0:x2}", DeviceOutput[i]));
            }

            // set up result
            s_UniqueDeviceID = resultText.ToString();
        }
    }

    return s_UniqueDeviceID;
}

As you can see the AppString can really be whatever we want it to be. the rest is a little work in order to transform it all from bytes to string but that is why we do it only once!

The only important thing I can see about the AppString is that it won’t be null\empty and that it will be constant throughout your application and usage.

Hope this was clear.

Cheers,

Nadav

I guess this is quite the easy one but the fact is that while I was searching the web for this answer it was very hard to find.

This is something I knew and forgot so it is good that I will have it here for future quick reference.

Just use:

Environment.TickCount

This will return the time in milliseconds that has passed since the last boot.

Quick Note:

I have read here that this might overflow on systems running for a few days, they also give a solution. as I am using this for a Windows Mobile device I don’t have that option. (CF.Net being deprecated and all…)

Hope you found this faster then I did.

Update:

After further looking into this I have found a nice article about how to overcome the overflow problem, here is the solution:

public static TimeSpan GetTimeSinceBoot()
{
    long _newTicks = Convert.ToInt64("0x" + Environment.TickCount.ToString("X"), 16);

    int days = (int) (_newTicks/(1000*60*60*24));
    int hours = (int) ((_newTicks/(1000*60*60)) - (days*24));
    int minutes = (int) ((_newTicks/(1000*60)) - (days*24*60) - (hours*60));
    int seconds = (int) ((_newTicks/1000) - (days*24*60*60) - (hours*60*60) - (minutes*60));
    int milliseconds =
        (int) (_newTicks - (days*24*60*60*1000) - (hours*60*60*1000) - (minutes*60*1000) - (seconds*1000));

    return new TimeSpan(days, hours, minutes, seconds, milliseconds);
}

The ticks represent milliseconds and when I just call the constructor for TimeSpan it doesn’t treats it this way, that is why i am doing all of this.

Good luck,

Nadav

Every time I have a state where I need to use switch\if-else-irritation I can’t quite figure our which is the better choice. I am pretty sure there is no one answer to this question, but i did stumble upon an interesting test:

Link

This test shows that, as i suspected all along(Mu-ha-ha), the switch is faster, and in a significant way.

I’m sure that some people will still state if-else is more readable, but personally, i do not agree with that.

What do you choose when you face this issue? if-else/switch? or an entirely different mechanism?

Have a good one, =]
Nadav

As you might have noticed, what I do here in this blog is write about the things I look for, than, when I can’t find them or I find too complicated and evasive answers I write simple ones here.

So, let’s get to the reason we’re all here.

I will give here an example on how you can change the visibility of the keyboard and you will probably be able to figure out the rest.

the steps are as follows:

1. Add a reference to Microsoft.WindowsCE.Forms.dll
2. Create our new class:

   using Microsoft.WindowsCE.Forms;
   
   namespace Environment.Keyboard
   {
       public class Keyboard
       {

3. Create our private InputPanel member:

   private static InputPanel m_inputPanel = new InputPanel();

4. Create the property to check if the Keyboard is open:

   public static bool KeyboardOpen
   {
       get { return m_inputPanel.Enabled; }
       set { m_inputPanel.Enabled = value; }
   }

5. Were done!

It’s that simple. the Enabled property in the InputPanel signifies if the keyboard is currently open or not.

Check out this link for a more comprehensive article.

See you next time,

Nadav

When we come to write unit tests we stumble upon many different problems with many different parts of our code, because no matter how hard you try, your code is never as simple as the examples around the web. If it’s singletons, static methods, private members that need mocking, or even events that need to be checked.

lately I spent some time writing unit tests and fumbled around with many of this problems. There are many articles around the web telling you the problem is not that you don’t know how to test this parts, it is that it shouldn’t exist in the first place. I really don’t like this answer, saying I shouldn’t write my code this way because there is a better one is a valid argument, but telling me I HAVE to change my code in order for it to work is usually not true. Some places don’t say this but still, most don’t give you a solution.

After this brief intro I will go into saying that I will try in a few different posts to clear up some of the problems in unit testing, mainly the ways to overcome them.

Lets start =]

As the title states, in this post I will show how to unit test events.

What we are going to do here is use an Anonymous delegate in order to catch the event inside our test.

The code: (look afterwards for the explanation and break down)

[TestFixture]
public class SettingsFixture
{
    [Test]
    public void ChangeSettingFiresSettingsChangedEvent()
    {
        // success variable
        bool success = false;

        // new setting
        string key = "SomeKey";
        string value = "SomeValue";

        // set a new instance
        SettingsManager settingsManager = new SettingsManager();

        // register to the event
        settingsManager.SettingsChanged += delegate(object sender,
          EventArgs e)
        {
            // event raise, test successfull
            success = true;
        };

        // update a setting to raise the event
        settingsManager.UpdateSetting(key,value);

        Assert.True(success);
    }
}

So what we have here?

We have a TestFixture with a single Test called:

ChangeSettingFiresSettingsChangedEvent

Change Setting Fires SettingsChanged Event.

First, we setup the success variable which we will commit later as the test’s result.

Second, set up our "new" setting, if we would use a special Type to submit to the UpdateSetting method, ISetting lets say, this will be the place to Mock(Mocking will be discussed in a future post, I will link to it then) it.

Third, setup a new instance of our SettingsManager.

Fourth, register to the SettingsChanged event as we usually will, with one big difference. instead of using a new instance of the right delegate we use an Anonymous delegate, look at the code for the syntax, it is very simple.

Fifth, call UpdateSetting with our "new" setting so the event will be raised.

Sixth, commit the result, hoping that it all went as planned ;].

Seventh, show off to your friends and go home, it’s late! (somewhere in the world…)

Hope it was clear enough.

A nice post about this:

Just to clarify: I am using C#(if you haven’t noticed yet) with NUnit.

See you next time =].

Nadav

This topic is one I have been spending some time studying.
How do you get your program to the foreground when a certain event accurse ?

The answer is quite simple actually, you just need to call a UI component. like:

MessageBox.Show("Show Me");

And it will show the top most form in your application. Another thing you can do is call a form with Show().

Now, for a little bonus I have for you the…

How to send it back to the background!

What we need to do here is to call Hide() on all the visible forms in our application, this will essentially cause all our UI to go to the background and will bring back the last active application.

A little hint, you might want to use what you learned, and combine it with the previous post ;].

Nadav

Sometimes we want to be notified of different events that happen in the operating system, even when we are not “looking”. the State and Notification broker is built especially for this.

I will give an example of how to be notified when the current active application changes and how to handle it.

First create the correct SystemState member:

SystemState _activeProgram = new SystemState(SystemProperty.ActiveApplication);

Now set the event handler on your program initiation:

_activeProgram.Changed += new ChangeEventHandler(_activeProgram_Changed);

Now handle it ;]:

void _activeProgram_Changed(object sender, ChangeEventArgs args)
{
    MessageBox.Show(((string)args.NewValue));
}

You would want to know a few interesting things:

1. The NewValue string is formatted in this way:

   PreviousActiveProgramNameCurrentActiveProgramName

   So, you might want to use StartsWith\EndsWith methods in order to check them ;].

2. It seams that every UI involved action(MessageBox, Form, etc.) causes your own application to come back from the background(if it was there) and show itself ;]. while other non-UI related actions does not cause this. This only a major “feeling” i got from my little workings with this so far, i checked this with a Thread.Sleep that did not cause my application to come to the foreground.

Hope this helps.

Nadav