Tags

Archive

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.

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.

Probably not, but just in case you do ever need to reverse lookup a Windows Phone’s app name from its GUID, you can grab App Lookup. It’s also Open Source (i.e. not official Microsoft), so feel free to grab it, fork it and send through pull requests!

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!

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):

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:

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;
privatevoid btnStart_Click(object sender, RoutedEventArgs e){// the message to send to the serverbyte[] message = UTF8Encoding.UTF8.GetBytes("GET / HTTP/1.1\nHost: localhost\n\n");// the address we'll be connecting to
IPAddress address =new IPAddress(newbyte[]{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 responebyte[] buffer =newbyte[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 simplestring 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;});}

Woo! All registered Marketplace should have gotten their regular newsletter which this time comes packed with goodies:

Free app submissions ramped from 5 to 100! The assumption here is that this is submissions and not actual apps (so if you fail an initial submission you lose a token), but updates are still unlimited.

You’ll no longer fail certification if you don’t include support contact information. I honestly think this is a bad move (how hard is it to setup an email?) but there if you have it – at least people will no longer fail certification because of it!

Now that we’re out of the woods with the unlimited free app updates policy being clarified, it’s time to go back to our Marketplace roots and clear up some misconceptions around the different statuses that your app can have as it passes through certification.

“Submission In Progress” – this is an app that you’ve started the submission progress for, but have not completed, so the app will not be ready to submit until you go through the full submission form. To do this, click “View details” (under “action” on your dashboard), then click “Edit Submission” (again, under “Action”) and run through form. Note that you may encounter a stage where the current form is complete but the “Next” button is not activated (I get this a lot on the screenshot page), simply refill on of the fields (for example, add a dummy screenshot and then remove it).

“Ready for Testing” – You’ve successfully passed the first hurdle in getting your app onto the Marketplace, your XAP has been submitted and is (duh!) “Ready for Testing”. It will soon be picked up and your status will move to…

“Testing in Progress” – Your XAP has moved along and is currently being tested. The amount of time it takes to have an app go through will vary depending on the app. I have found that it will tend to come back to you quicker when failing (i.e. as soon as there is a problem) otherwise it usually finishes certification within a couple of days to a week.

“Ready for Signing” – Congratulations! You’ve passed testing, your app is certified. It’s now going to go through the last technical stage where the XAP is signed and prepared for the Marketplace. This is largely automatic and should be finished within a few hours.

“Published to Marketplace” – Break out the champagne! Your app is in the marketplace and you’re now ready to move on to vNext or appNext. Note that it can take up to 12 hours for your application to show up in the search index, so don’t fret if it takes a while.

“Certification Failed” – oh oh, an issue was found in your app while running through the certification process. On the submission details page you’ll find a testing report in the drop under “action” which will detail exactly what was wrong, and the steps to repro the problem. I’ll admit that I was impressed with the reason for one of my failures (clicking multiple times, very quickly, on a button caused the app to crash) and with the way the report detailed the exact problem so that I could find it, fix it and resubmit asap. That said, sometimes there are mistakes made or unclear reports and in this case the support team are your friends.

How long does certification usually take?

Certification shouldn’t take more than 7 days, with the average being a lot lower than that. My record is currently 13 hours (submitted at 2am, on the marketplace by 3pm), though the average that I see reported is 3-4 days.

What should I do if it’s taking more than 7 days?

First, DON’T PANIC. That said, if you’re app is taking more than 10 days, log a support request to find out what’s happened. There’s a possibility that there was a problem with the file upload which will require you to resubmit your xap, but at least you’ll know that things are moving!

Logging a Support Request

To log a support request login to create.msdn.com -> My dashboard -> Windows Phone and then hit the “Support” link on the left menu. You should get an initial response within 24 hours (if you haven’t gotten a response after 48 hours, log another request).

Run into any marketplace tips / tricks? How about some annoyances? Drop me a comment and I’ll see if I can address them in a future blog post (before I head back to writing about perf!).

I’ve signed up for the Windows Phone marketplace and submitted my apps. They’re selling well – but I’m not actually planning on doing any more development, so I don’t think I need to renew my subscription. What happens if I don’t pay the Marketplace renewal fee at the end of the year?

The Answer

You’ll get a couple of warning emails at the end of the year, but after those if you choose not to renew your subscription your apps will be removed from the Marketplace.

Will people still be able to use my apps?

Sure. Microsoft won’t revoke the apps from people’s phones, but they will remove it from the Marketplace – so no one new will be able to purchase the app (and, obviously, no more revenue for you if it was a paid app).

Yup, you get 5 free submission credits a year, so every year you could potentially submit another 5 free applications to the marketplace (not to mention the unlimited free updates to existing free applications).

Can I see how many submission credits I have left?

Not at this point, though I hope to see this soon. For now, if you can’t remember where you’re up to, submit a support request and the team will get back to you asap (usually within 24 hours) with an answer.