I needed to make a bunch of webservice calls from a WinMobile 6 device. None of the calls are particularly heavy, but I wanted to give some feedback that something behind the scenes was going on, otherwise the user gets confused about why he can’t click on things.
My first iteration was this ugly custom Form that took two callbacks as parameters. The first call back did the real work, the second was called after completion so that the UI thread could do something with the results. It was verbose, ugly, unreadable, and confusing. Don’t do that.
Furthermore, it turns out all that marshalling data around between UserWorkItem threads and the UI thread made the service call appear to be taking far longer than it really was. Color me unsurprised.
Duh. Windows has had this ability for over a decade: the WaitCursor.
On a Mobile device, at least the model I’m using, this is rendered as a colorful spinner in the center of the screen. Moral of the story? Read the docs.
I didn’t feel like wrapping all the Service Calls with:
This question comes up all the time, and 99 times out of 100, the methods in question are not even close to the real bottleneck in the application.
If you’re asking about a string concatenation operation on the far side of a 250ms database query, son, you’ve got bigger fish to fry. Your time is better spent throwing a where clause on the end of that thing and moving on to fixing your IE6 compatibility.
I intend to write a lot more about this, because its so obnoxiously prevalent in my industry, especially among the hacks that call themselves PHP developers. There is just something frightfully absurd about PHP devs asking inane performance questions and posting ridiculous micro-benchmarks as “proof” of their concerns. PHP was designed to be easy to develop against. It was not designed to be the most performance driven programming language. You don’t get both.
Create the new repository. I had to use my hosting provider’s control panel.
If you were naive, you might think to just zip up an export of your project directory, move it to the new location, and check that sucker in.
But you would be wrong.
That would make you lose your revision history, which kind of defeats the purpose of having version control. Instead, you’re going to want to move the repository itself.
You’ll need to dump the source repository to a text file for later import. Windows, which lacks a lot of cool things out of the box, doesn’t give you the svnadmin tool. But no matter, if you’re using VisualSVN Server (which, if I recall, is about your only option on this platform), its included as part of the installation. You’ll need to change directories to the installation folder before running the dump command.
Oh, and you’ll need to be using an Administrator command prompt. If you can’t figure out how to open one, you probably shouldn’t be trusted with the company’s source control infrastructure.
On VisualSVN, by default, the repositories are all stored in C:\Repositories\ We’re going to dump the “project” repository to file.