Hopper for ISV’s – part I

I have been reflecting on the things Javier and I learned from our Hopper talk at MEDC and I wanted to thank everyone that attended our talk. I also wanted to give special kudos to those who took the time to fill out the evaluations – this post is your voice in action. The one theme that rang louder than all others is we did not properly address or set expectations for our ISV customers and how they can benefit from Hopper.

Most readers already know all Windows Mobile OEM devices must pass Hopper testing to receive their logo certification – this includes all inrom-ISV applications. However, applications installed after Logo are not covered by this requirement and can introduce stability risks to the end user.

The answer to this dilemma is to evangelize Hopper testing to all applications destined for the Windows Mobile platform – not just for those shipping on the device.

Why should ISV’s care about Hopper?

Hopper is good - Hopper will find bugs in your application that can affect the stability and usability of your device. Hopper is an input stress tool that randomly sends keystrokes to the device and will put your application through scenarios you likely haven’t though of. Who wouldn’t want to find bugs in the application they are trying sell?

How can ISV’s get Hopper?

If you are an ISV, this tool is provided automatically when you install the Windows Mobile 6 SDK.

How to run ISV-Hopper

Hopper for ISV’s is just like Hopper for OEM’s, the only different being the addition of a “focus app” customized to keep the intended application in the foreground. When your application is in the foreground, Hopper will test only it and not the rest of the system – the “focus app” is needed to bring your application back to foreground if Hopper tries to navigate away. The “focus app” blog and source code is described in The Cat Parade.

The specifics of running Hopper.exe on your device are documented in the readme.exe from the Power Toys directory and will depend on if you are running connected to a debugger (recommended) or not. The easiest way to run Hopper.exe is to simply copy the binary to your device and execute directly.

How can I debug application bugs found with Hopper?

This is really a loaded question and will depend on many factors, including whether or not you are connected to a debugger (recommended). If you have a debugger connected, exceptions and hangs should be easy to diagnose if you have correct symbols. If you are not connected (NOT recommended), then having current symbols and some way of capturing the debug output is a good start.

Luckily this question is the exact intent of the blog you are reading so each entry located on the HoppeRx site will help with this.

How many hours should my application survive?

It is entirely up to you and it depends on the complexity of your application, but 20 hours with a “focused Hopper” is a good goal. Anything longer than that will likely give you decreasing returns as the same code paths are likely being re-executed. But don’t feel limited by just “focused Hopper” – can you add additional stress elements to create interesting user scenarios?