I’ve been avoiding the whole My Space / Facebook thing for a while now… but now I’m checking it out. A little part of me is afraid that a public ill-prepared for the communications onslaught of web 2.0 toys like Facebook will fall prey to it. It may lead to implants that allow people to have every thought cataloged for later analysis. Before you know it, we’ll all be Assimilated! (Resistance is Futile!)
Tag: Hobbies
Compact and Full .NET Frameworks
One of the things I’ve been intrigued by for a while now is the fact that code compiled for the .NET Compact Framework (all versions) executes very nicely on the full .NET Framework.
For example, my personal hobby project, “Jimmy Sudoku”, is written in C# for the .NET Compact Framework 2.0. There are actually two install kits. The first is a .CAB file for Windows Mobile devices. The second is an .MSI for Windows 9x, XP, and Vista. The desktop install kit even serves two purposes. First, it installs the program on the desktop. Second, it leverages ActiveSync to push the .CAB up to the Windows Mobile device.
It’s a .NET Compact Framework app especially for Windows Mobile devices, but many ‘Jimmy’ fans don’t have a Windows Mobile device to run it on.
The coolest part is the ease in which all of the components inter-operate. The .EXE and .DLL’s that are delivered to the mobile device are the very same as the ones that are delivered to the desktop. Like Silverlight to WPF, the Compact Framework is a compatible subset of the full framework, so interoperability is a given.
Even better, you can reference CF assemblies in Full framework assemblies. One immediate offshoot of this in my hobby project… the web service I built to service “Game of the Day” requests actually references the CF assembly that implements the game state model and game generator code. The assembly that generates games on Windows Mobile PDA’s & cell phones is the very same assembly that generates games in the ASP.NET web service.
Admittedly, there are some bothersome differences between the CF and the Full .NET Framework. The CF does not support WPF. The CF has no facilities for printing. Also, while the CF does supports some of the common Windows Forms dialogs, it does not support File Save and File Open dialogs on Windows Mobile Standard Edition (Smart Phone / non-touchscreen) devices.
These differences can be overlooked to some extent, though, for the fact that one compiled assembly can execute on so many very different machine types. Further, with interoperability, one can extend a CF-based core code with full-framework support. For example, I’m currently playing with desktop print functionality for my hobby project.
Something that I’d really love to see, some day, is a good excuse to develop a Windows Forms app for a client that had shared components between the desktop and a mobile.
I can imagine that this model would be superb for a huge variety of applications, allowing a fully featured UI for the desktop version, and an excellent, 100% compatible, very low risk (almost “free”) portable version.
I’ve often thought this would work great for apps that interface hardware, like:
field equipment,
mobile equipment,
vehicles of all sorts,
…simply plug in your PDA (via USB or Bluetooth), and it becomes a smart management device for the equipment, using the very same code that also runs on the desktop.
Compromise & Capitulation
There’s three different flavors of Windows Mobile in the 6.x line. Standard, Classic, and Professional.
Standard = Smart Phone, no touchscreen
Classic = PDA w/touchscreen
Professional = PDA / Phone with Touchscreen
One of the other interesting little gotchas is that the .Net Compact Framework 2.0 compiles the same for all three editions. Unfortunately, once in a while, you get a “NotSupportedException” out of the Standard edition.
A few days ago, in order to get my sudoku program published, I decided to simply avoid a problem I had with the Standard edition’s lack of a SaveFileDialog and OpenFileDialog. My avoidance manifested in a “not supported” message of my own, if the user tried to save / load a file in that environment.
Today, I capitulated… I implemented an alternative file save/load functionality which kicks in automatically when the program gets a “NotSupportedException” on the common dialogs.
It’s in 3.0.3, which I’ve re-published on PocketGear.
Jimmy SuDoku 3.0 Released
Those of you who have worked with me on a project in the past few years probably know of my hobby project. It’s an implementation of SuDoku. It’s made for Windows Mobile devices (cell phones, etc.), but it also runs on Windows XP (et al).
The old version, 2.5, had been published on PocketGear. This last update was published in January, 2007, just before I started with Edgewater.
I’ve been hacking at it here & there since then, but the project suffered from lots of maladies… most significantly lack of time.
So after more than a year and a half, I’m happy to finally announce Jimmy SuDoku 3.0!
3.0 has a whole new game state model, based on CLR classes rather than an XML DOM. This means the puzzle generator’s fast enough on hand-held devices that it doesn’t need a web service to do the work for it. Another side-effect of this change is a smaller run-time memory footprint, though I’m not sure by exactly how much.
I also figured out how to leverage the hardware controls on WM6.0 & 6.1 devices so that non-touchscreen devices can play, too.