I’ve just checked in new code changes and rolled a full release for the OpenNETCF ORM. The latest code changes add transaction support. This new release adds a load of features since the last (the last was way back in February), most notably full support for SQLite on all of the following platforms: Windows Desktop, Windows CE, Windows Phone and Mono for Android.
In my push to get our fundamental libraries up and working on Mono for Android we’ve added support for OpenNETCF Extensions and OpenNETCF IoC. What that means is that now you can have a common code for a lot of application infrastructure that works on the Compact Framework, the desktop, Windows Phone, MonoTouch for iOS and Mono for Android. So you can now create a single, common code base for your applications that includes data access, event aggregation, dependency injection and inversion of control.
We’ve been heavily dogfooding the IoC project (and others) lately and I finally took the time today to back-port the fixes and updates to the public code. This is being used for a solution that runs on both the desktop and the compact framework, so it’s been heavily tested under both of those environments. The new release (1.0.11235) is now available on Codeplex.
Like most people, the more projects I work on the more I find myself reusing common bits and pieces of code. For the past year or so I’ve been collecting these pieces into a library I called OpenNETCF.Extensions. The name was becasue they originally started as a set of extension methods that helped me to compile one code base for Windows Phone, the Compact Framework and the full framework, but it eventually started expanding in scope. I added a fairly robust set of method for validation, a set of classes for helpiing make REST clients, a class for a circular buffer (FIFO) and generally anything I found myself using on multiple projects.
Since many of those projects are already open-source, it started becoming a pain maintaining a single, controlled source for these helpers. So in an attempt to centralize it, I’ve created yet one more open source project. My plan now is to have all of the consuming projects only use binary releases from this project.
So, with that said, go ahead and check out the new MIT-licensed OpenNETCF Extensions project over on Codeplex.
I’ve again refreshed OpenNETCF’s MTConnect Managed SDK with a few changes, including:
- Added support for some current and sample filtering (not all filtering is supported, but I’ve added device name and data item ID filtering)
- Added AgentInformation to the EntityClient so you get information about the agent returning a data set for a probe
- Miscellaneous bug fixes and refactoring
As always, if you find a bug or would like me to work on implementing a specific feature from the specification, add it to the lists over on the Codeplex site.
OpenNETCF’s MTConnect Managed SDK now has Common and Client projects supporting Windows Phone 7. This means you can now consume MTConnect-published data in your Phone 7 projects. I’ll also be publishing and open-sourcing an MTConnect viewer for Phone 7 in the future, but if you want to get started on your own, you now have the tools.
Windows Phone 7, at least on the Silverlight side of things, is very heavily biased toward asynchronous API calls. While that’s all well and good, it makes porting existing code assets to the Phone a bit more challenging.
One place I recently ran into was in making synchronous calls to HttpWebRequest.GetResponse and GetRequestStream. These methods don’t exist in the Phone 7 SDK – instead you should use BeginGetResponse and BeginGetRequestStream. Well my code was written to use the synchronous versions and is shared with CF and FFx applications, so rewriting the calling code isn’t terribly appealing. Instead I simply added the following extensions to the project:
public static class HttpWebRequestExtensions
private const int DefaultRequestTimeout = 5000;
public static HttpWebResponse GetResponse(this HttpWebRequest request)
var dataReady = new AutoResetEvent(false);
HttpWebResponse response = null;
var callback = new AsyncCallback(delegate(IAsyncResult asynchronousResult)
response = (HttpWebResponse)request.EndGetResponse(asynchronousResult);
public static Stream GetRequestStream(this HttpWebRequest request)
var dataReady = new AutoResetEvent(false);
Stream stream = null;
var callback = new AsyncCallback(delegate(IAsyncResult asynchronousResult)
stream = (Stream)request.EndGetRequestStream(asynchronousResult);
I’ve published a new release of the OpenNETCF.ORM library. Some notable additions are:
- The ORM can now detect added Entity fields and automatically add the underlying columns to the store
- A new Select override can now filter result sets by multiple fields
- I’ve added a skeleton for a SQLite/Windows Phone 7 project with some implementation
If you have a desire to help me get the WinPhone implementation completed, I really could use the extra help. I’m pretty busy, and without external help on this I don’t see it getting implemented any time soon (unless we get hired to do a WinPhone project of course).
If you’re not up on what the OpenNETCF ORM library is, in short it’s an open-source ORM that actually works on the CF (NHibernate and Entity Framework do not).
I’ve made a small update to the ORM library. I’ve added a SQLite assembly and started implementeing the SQLiteDataStore class. Note that I say “started” meaning that it’s not done and ready for use (far from it in fact). I did do a rough pass for store (database and table) creation. The idea is that it gives at least some seed code for anyone interested in getting ORM up and running on their Windows Phone using SQLite. If you are interested in doing this, please let me know. I don’t really have the time to devote to getting this done, so I’m looking for a capable developer who would like to take this on.
Let me lead off by saying I’m a bit of a luddite when it comes to phones. I like my phone to be able to make a call and occasionally send a text message. If I need to use a browser, I have a 30-inch Dell monitor and a PC that I can actually read web pages on. If I need to find a location, I have a nice Nuvi that doesn’t require men to fiddle with a phone and that has a better interface that any other phone I’ve used. If I need to listen to music I have a Zune that lets me do that.
As far as phones go my favorite, other than that old StarTac that I still pine for, is my HTC Snap (also known as an HTC Ozone, Dash 3G and probably a few other names). Ironically it’s also the target of my wrath over the last few days. As a user experience as far as a phone goes, it has everything I like, but if you need to actually create an application that does what you want on the thing, I think you’re going to need divine intervention. And this, at its core, is why I think Windows Mobile, at least up through 6.5 just plain sucks.
My goal was simple – or so I thought. Create a simple application that collects GPS data at all times (yes, I know about battery life, blah, blah – let’s assume that it’s not an issue for this app). I know that a Smartphone never actually puts the processor fully to sleep and that even when the backlight/screen is off, I can still run code so this should be simple, right? Hardly.
The first thing I found, which was not a surprise, is that when the phone enters the “screen off” power mode, it shuts off the GPS receiver – or that’s what I assume anyway. The GPSID driver stops giving me data anyway.
I know from cruising around the device’s registry that the driver prefix is “GPD0:” and I know that WinMo is supposed to allow you to adjust power schemes through both API calls and some registry settings. “Supposed to” being the key here. I spent well over an hour going through and modifying the registry keys adding just about every combination I could think of along with soft resetting the device all with zero effect.
This is the first strike against this platform. Microsoft has documented that this is how the device is supposed to work, yet in a real-world scenario, it doesn’t.
I know a bit about how Windows CE works, and my assumption is that these registry settings simply tell the Power Manager to set some driver device states under certain conditions. There should be no reason I can’t do that manually, since I’m dealing with a pretty finite set of drivers (one) and states (two).
In order to manually alter the power state of a device, I need to know when the system itself changes state. For example, I need to know when the device goes into Unattended mode so I can then manually call one of the power management functions. To get notifications, we P/Invoke RequestPowerNotifications and pass it in a queue handle where it will send those notifications. Another hour of development later and I came to the conclusion that the device simply isn’t sending out notifications for power state changes. I tested this in both C# and C to just be certain. Strike two.
Maybe I could just do something simple and just tell the Power Manager to never shut off the GPS. SetPowerRequirement should do that, but more testing proved that this, too, had no effect on this platform. After several hours of work and lots of frustrating tests that failed I was beginning to question the power manager altogether.
If the device wasn’t going to tell me when it changes state, then I figured I’d just handle all of the state changes myself. I’d have the application periodically call SystemIdleTimerReset, implement my own application idle filter and dim the backlight myself. We’re getting into some serious hack territory here, but some days you have to do what you have to do to solve the issue.
I implemented the timeout filter and used a call to SetDevicePower to shut off the backlight. The idea here is that I’d just never let the device go into the BacklightOff or Unattended mode and just turn off the backlight myself. I ran the test and ,surprise, my code had zero effect. By zero effect I mean that the backlight shut off and the GPS turned off.
I spent some time debugging to try to determine why I was able to shut off the backlight but not keep the GPS on and I finally realized that I was actually not turning off the backlight – the device still was. For the first time ever I was seeing a call to SystemIdleTimerReset succeed (i.e. return a success) but not actually reset the timer. Strike three, and this was a huge one.
I continued to muck about with other APIs like PowerPolicyNotify to try to keep the backlight on and even some proprietary HTC calls I found online, all to no avail. I went back to basics and tried even the simplest of code in C and re-verified all that I had seen.The device appeared to completely ignore any call that had to do with the Power Manager while always giving me a successful return value.
All I can conclude from this is that HTC, in their infinite wisdom, decided to implement their own power manager to handle turning on/off all of these devices. and to make the WinMo platform itself happy, they just stubbed out all of the Power Manager calls to return success.
In the end, I told the customer that the phone they selected will never be able to do what they want and it looks like they’re going to opt for another phone running a completely different OS.
This is a classic case of why I hate developing software the Windows Mobile platform, and one of the big reasons why the platform has been pretty much an abject failure. How can a software vendor even hope to develop an application that will work on multiple devices when the devices don’t even follow Microsoft’s published rules? The test matrix would be astronomically large and the costs, both in terms of the hardware you’d have to keep on hand and the time required to run the tests is simply prohibitive.
So is this HTC’s fault? To a degree, sure. They should have followed the API’s documented by Microsoft, but I still only place about 10% of the blame on them. Developers will, after all, always try to do things “better”, and by better I mean that anything not designed in-house is obviously inferior.
But the real problem lies in Redmond. Every Windows Mobile device that ships gets a Windows Mobile logo. To get that logo they have to run the device through a set of Logo Certification tests (also called the LTK). The fact that a device can pass those tests with these obvious and fundamental variances shows that either the tests themselves have really poor coverage or the OEMs are getting waivers for these test failures.
Which it is doesn’t matter because the end result is that Logo Testing is completely meaningless. The idea behind Logo Testing should be that when an ISV gets a device, they can depend on it to behave in a specific, predictable way. This device certainly doesn’t. And this was just one device and just a small handful of APIs that I was attempting to use. Extrapolate that out to all of the device models that have been shipped and all of the APIs that any given application might call and you begin to see why this is so difficult (and very likely one of the reasons Windows Phone 7 is a complete redesign all the way back at to base Windows CE OS).
Personally, I don’t do a whole lot of Windows Mobile development. I tend to focus on embedded Windows CE solutions where the hardware, OS and API set are fixed, finite, manageable and testable. When I see something wrong, we get the OS fixed – we don’t path over the top of it (at least whenever we can). It’s these little forays back into the Windows Mobile platform that reinforce and remind me of my utter distaste for it.
Hopefully Windows Phone 7 will have valid platform testing and a meaningful certification program but the reality is that I, and likely many, many other developers have been jaded by bad experience after bad experience with these and it’s going to take a whole lot of work to gain our trust back. I’m not saying it’s an insurmountable problem, but I certainly don’t think Microsoft is going to get many more chances.