Archive

Archive for the ‘Dev Tips’ Category

Windows Phone Power Tools 1.1

September 20th, 2011 Oren 1 comment

Grab them here

I received a fair amount of feedback about the first version of the Power Tools mainly focused around the UI (people like modern today) and around “bug #1“, which prevented files from uploading to the correct path in IsolatedStorage.

I’ve just pushed a major UI rehaul to something somewhat more Metro-ish, loosely styled off Zune. It uses a combination of custom styles that you can find in the source tree and MahApps.Metro. I’ve also fixed the upload bug and other miscellaneous bits of polish here and there. This probably should have been a 2.0 or a 1.5 but it seemed to soon :)

As always, feedback is welcome, though a reminder that this is not a Microsoft official tool.

Categories: Dev Tips, Windows Phone Tags:

Windows Phone Power Tools

September 13th, 2011 Oren No comments

Necessity may be the mother of invention, but it’s also often the mother of Open Source tools which are not really reinventing the wheel, but perhaps make our lives just that little bit easier (or more functional). A common pain point, especially as more and more developers move their apps to Mango is testing update scenarios and exploring the IsolatedStorage of a developer app, both extremely handy debugging tools to have that either don’t exist (updating developer apps is not really possible) or are very basic (the IsolatedStorage Explorer tool that ships with the SDK).

To this end, I’ve published a little Open Source app that I’m dubbing the “Windows Phone Power Tools” that allow you to do just that – update developer xaps, visually explore the IsolatedStorage structure of your apps and a bunch of other small, but handy, features.

You can check it out on codeplex: http://wptools.codeplex.com

Categories: Dev Tips, Windows Phone Tags:

Getting Started with Node.js and Mango (Sockets)

July 6th, 2011 Oren No comments

It’s been a while since I’ve found time to blog – but it’s not like I’ve left you in cold hands. Rohan has been doing a great job posting on the Silverlight for Windows Phone Performance blog (check it out if you haven’t yet).

On a completely non-performance related topic (we’ll get to those in the next couple of blog posts), I’ve been meaning to play around with Node.js for a while, and when a colleague posed a question about using it with Mango, I thought it might be a great excuse to polish off the Beta 2 tools (get them while they’re hot!) and do some Socketing!

First things first – grab 7zip (if you don’t have it already), and Node.js binaries for Windows (or build it yourself). Extract these to a convenient location and you should be good to go.

We’re going to use the Hello World sample ripped straight from the Node.js homepage, with one extra debugging addition (highlighted in yellow) and a practical change (highlighted in green – see “gotcha!” below):

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
 console.log('Sent message'); }).listen(1337, "192.168.2.125");
console.log('Server running at http://192.168.2.125:1337/');


Gotcha Warning!

A common mistake at this point is to stick with the sample’s use of 127.0.0.1 (locahost). This will work great from your browser, but not from the emulator or your device (regardless of whether it is connected to WiFi or tethered via Zune). This is because the emulator and the device join the network as *new* devices which means they get a newly assigned IP address and they act just as though they were a machine on the network. This leads to 127.0.0.1 pointing back to themselves, which is not allowed, leaving you with a “NetworkDown” network error. Instead, make sure to set your IP to your local LAN address (usually starts with 192.168.X.X or 10.X.X.X). You can find your exact IP address from cmd by typing “ipconfig” and looking for the address that corresponds to your local network.

Testing the Server

Now, save your modified script somewhere somewhere convenient (I saved it to c:\nodejs\bin\servers\helloworld.js) and then launch the server with a simple:

C:\nodejs\bin>node servers/helloworld.js
Server running at http://192.168.2.125:1337/

Note the use of UNIX style paths… If you see any errors at this point it’s most likely path related. Fix your path so it is relative to your binary and you should be good to go. Need to verify that everything is working? Fire up your browser and enter http://localhost:1337 and you should see “Hello World!”.

Note: When launching the server you may get the Windows warning dialog about a program accessing the network, feel free to set the settings to whatever you are comfortable with, just note that Node.js will need at least local network access so that you can talk to it from the emulator / a device over WiFi.

Let’s get me some Windows Phone!

We’re up and running, so time to get our hands dirty with some C# code. Open Visual Studio and start a new C# Windows Phone application targetting “Windows Phone 7l.1″ (which is the code target name for Mango). The project that we create is going to do something extremely simple – it’s going to open the socket, send a request for data (it’s really a dummy request since this server isn’t really waiting for a real request) and then displays the response, verbatim, on the screen.

Once you have the project created add a button (btnStart), which will kick the whole process off, and a textblock (txtServerResponse) to contain the server response. We’re not going to use binding to simplify the sample, but you can certainly do that instead. Add a Click handler to the button by double clicking on it and add the following code to MainPage.xaml.cs. The code is heavily documented so should answer any further questions you might have. I’ve also stuck a zipped version of the project (including the mini-server) which you can use to experiment with.

private Socket _socket;

private void btnStart_Click(object sender, RoutedEventArgs e)
{
    // the message to send to the server
    byte[] message = UTF8Encoding.UTF8.GetBytes("GET / HTTP/1.1\nHost: localhost\n\n");

    // the address we'll be connecting to
    IPAddress address  = new IPAddress(new byte[] {192, 168, 2, 125});

    // an endpoint translates into the complete destination - address + port
    // you can also use a DnsEndpoint to look up an IP address from a hostname
    IPEndPoint endpoint = new IPEndPoint(address, 1337);

    // all socket operations are asynchronous on the phone so you must set up 
    // a SocketAsyncEventArgs object to let the socket know how to act
    SocketAsyncEventArgs args = new SocketAsyncEventArgs() { RemoteEndPoint = endpoint };

    // don't allow multiple clicks before the request finishes
    btnStart.IsEnabled = false;

    // create our socket, note that it isn't connected yet
    _socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

    // set up the call back to be called when we finish connecting to the socket
    args.Completed += new EventHandler<SocketAsyncEventArgs>(OnSocketConnected);

    // neat trick - setting the buffer of a socket before it connects will cause the socket to send
    // that data as soon as it connects
    args.SetBuffer(message, 0, message.Length);

    // boom! we're off
    _socket.ConnectAsync(args);
}

void OnSocketConnected(object sender, SocketAsyncEventArgs e)
{
    if (e.SocketError != SocketError.Success)
    {
        // don't forget that we're now on a background thread so anything that interacts with
        // the UI thread (MessageBoxes, updating UI etc) has to be dispatched back
        Dispatcher.BeginInvoke(() =>
        {
            MessageBox.Show("(Connect) Socket error! " + e.SocketError.ToString());
        });
        return;
    }

    // we're done with the connect + send, time to receive

    // create a buffer for the respone
    byte[] buffer = new byte[1024];

    // create the Socket event args for this receive
    SocketAsyncEventArgs args = new SocketAsyncEventArgs();

    // set a buffer for the receive - the size will be the maximum amount read
    args.SetBuffer(buffer, 0, 1024);

    // we have to come back somewhere after the receive completed
    args.Completed += new EventHandler<SocketAsyncEventArgs>(OnSocketReceive);

    // kick off the actual receive
    _socket.ReceiveAsync(args);
}

void OnSocketReceive(object sender, SocketAsyncEventArgs e)
{
    if (e.SocketError != SocketError.Success)
    {
        Dispatcher.BeginInvoke(() =>
        {
            MessageBox.Show("(Receive) Socket error! " + e.SocketError.ToString());
        });

        return;
    }

    // the response comes back as a byte array, so convert it to a string
    // Note: usually you would read from the buffer and then call _socket.ReceiveAsync(e)
    // again until e.BytesTransferred == 0 (signals end of the receive), for this example
    // we're going to keep it simple
    string response = UTF8Encoding.UTF8.GetString(e.Buffer, 0, e.BytesTransferred - 1);

    // we have our response now update the UI thread
    Dispatcher.BeginInvoke(() =>
    {
        txtServerResponse.Text = response;
        btnStart.IsEnabled     = true;
    });
}

What does it look like?


Questions?

Feel free to leave comments below – Good Luck!

Download the solution + js file

Categories: Dev Tips, Silverlight, Windows Phone Tags:

SL WP7 Toolkit Pro Tip: Set a background on your LongListSelector so that it scrolls correctly

January 16th, 2011 Oren No comments

Got a LongListSelector in your project? Notice that if you try to scroll in blank areas (where the background shows through) it won’t react?

Set:

Background=”{StaticResource PhoneBackgroundBrush}”

or to whatever colour you prefer and all your problems should go away.

Categories: Dev Tips, Windows Phone Tags:

WP7 Silverlight Gotcha: Using the ListPicker from the Toolkit may cause you to fail certification

January 9th, 2011 Oren No comments

Applies To: Anyone using the current iteration of the Silverlight Tookit from Nov 2010

Toolkit Link: http://silverlight.codeplex.com/releases

Quick Bits

A Toolkit ListPicker control that has less than 5 items in it will display inline (expands) but will not collapse when you press the back button (like the native control does). This can cause you to fail certification due to an erroneous interpretation of the certification guide.

The Fine Print

According to section 5.2.4c the following applies to the use of the Back Button:

If the current page displays a context menu or a dialog, the pressing of the Back button must close the menu or dialog and cancel the backward navigation to the previous page.

The Setup

You have a ListPicker with less than 5 items in it, using the standard Silverlight Toolkit library.

The Sting

The Toolkit ListPicker doesn’t listen for the back button when the ListPicker is in mini mode (i.e. it doesn’t pop up the full screen list picker), so when you press back normal navigation occurs.

The Solution

There will be an update to the Toolkit coming out sometime this month that will address the issue, but if you want a fix now you basically need to either fix the Toolkit or listen in on the navigation event (and then check if a ListPicker is expanded and if so collapse it). I prefer the first option, since it’s easy and you don’t need to write redundant code if you have heaps of ListPickers.

To this end, you can download a patched ListPicker.cs file (replace this within your Toolkit Source project), or a built Toolkit DLL (unzip and replace your Toolkit installation under C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.0\Toolkit\Nov10\Bin), with one change – the ListPicker will now respect the back button.

Does It Really Matter for Certification?

Actually, no. My reading of the certification guide doesn’t indicate in any way that this is the expected behaviour, not to mention that I (and a bunch of other people) have other apps that were approved with the same control!

So, I fought the good fight, and lodged a support request (complaint) and got the following response:

Dear Oren,

I am sorry for the inconveniences you experienced! It seems that there was a little misunderstanding during certification testing. Dropdown list or list control does not need to be collapsed at Back button press and instead its previous screen can come up or if the back button was pressed from the application’s first page, it can exit the application. Please add a short tester note while submitting it explaining that the list control is not dialog and does not need to be closed.
We will also instruct our test team to correctly apply different expectations for list controls.
Thanks,
Windows Phone Marketplace Certification

I was impressed (I don’t think they even knew I was from within Microsoft)!

WP7 Dev Tip: Detecting whether or not the user is playing music in the background

December 1st, 2010 Oren No comments

Applies To: Silverlight & XNA

Quick Bits

Microsoft.Xna.Framework.Media.MediaPlayer.GameHasControl

The Setup

Your app does some sort of music playing that doesn’t make sense to blend into any already playing background music (for example, you’re going to stream your own music) or you simply want to show a video.

Why You Care?

If you just start playing music you will fail certification according to section 6.5.1 of the certification guide if you don’t ask the user if you can stop the background music, but how can you stop the background music if you don’t know it’s playing? Hence, you care!

The Solution

Query Microsoft.Xna.Framework.Media.MediaPlayer.GameHasControl (it’s a bool) – if you have control, then you’re good to go. If you don’t have control, then there is something in the background and you need to prompt the user before continuing.

Silverlight Note: you’ll need to link in Microsoft.Xna.Framework.dll for this to work, but make sure you don’t distribute this file with your XAP by mistake (or you’ll also fail certification for redistributing phone assemblies)