To increase Hopper awareness and help prove how simple Hopper really is, I have developed a bare-bones sample that embodies the essence of Hopper. My main motivation for sharing this tool is to provide a simplified, Hopper-like tool for our general Windows CE customers and figured the HoppeRx readers might also be interested in Hopper “under the hood”.

To make the topic easier to understand and to enable a framework upon which you can customize, I abstracted many details that will be left to reader to complete. The code snippet will build and run as-is, but you will quickly see that more sophistication will be needed for a mature tool capable of increasing device stability.

There are several meta-level abstractions intentionally left in the code to provide clarity in what the tool is actually doing.

1. Input Section: Define your inputs. Does your device allow keystrokes? Screen taps? You want to include all possible inputs in this key structure - this is the superset of all possible inputs the tool will send to your device. If you are developing a headless device for example, you would replace the VK_ codes used in the sample to whatever will be sent to your device.
2. Logging Section: Currently the sample simply outputs to standard debug out, but could easily be change to log to a file, storage card, display, etc. It is left to the user to determine the best way store important logging information while the tool runs. As your tool matures (and your device becomes more stable) you will likely want a way to optimize logging since each message printed will affect the timing of the device.
3. GetNextInput Section: Logic defined here will determine the next input sent to your device. I have introduced a system of “weight” which allows you to include inputs that should be called less often than other keys. What weight any particular input should carry is left up to you and will likely be tuned when you can start observing runs.
4. DoAction Section: Perform the input selected in the previous step. The sample contains simple keyboard events but can be easily customized to send screen taps, network packets or whatever your device needs.
5. Thread Section: The sample spins up a simple thread that controls execution and should contain validation code such as logic to detect device hangs and other stabilization issues. It would be beneficial to add additional threads that monitor device health and possibly watch for certain events that may halt execution, but this is left for you to complete and customize.

You might be asking: what possible good could come from having another Hopper-like tool during development? Isn’t one Hopper tool enough? The answer will depend on exactly what you are faced with – if you device is passing all your stabilization metrics then your answer is easy, but for the rest of us …