Chris Tacke - Community

OpenNETCF.IO.Serial Library moved to Codeplex

Fri, 26 Jun 2009 14:24:33 GMT

As you may have guessed from some of my recent blog entries, we're making a push to get a lot of our shared source code out to the Codeplex servers. Our serial library is the latest one to make the move. It's now available at http://serial.codeplex.com. As with all of these libraries, if you have the desire to contribute, fix, extend, or whatever just let us know and we'll add you as a developer.

Managed Code in the Embedded World

OpenNETCF.Desktop.Communication library has moved to Codeplex

Thu, 25 Jun 2009 23:38:36 GMT

In an effort to clean up our servers, to make code easier to find, and to hopefully make it easier for the community at-large to contribute, we've moved our popular Desktop Communication library over to the Codeplex servers.

Visit the project at rapi.codeplex.com.

Managed Code in the Embedded World

OpenNETCF.Telephony library (TAPI) released under shared-source license

Thu, 25 Jun 2009 23:06:39 GMT

Over the past few months we've been working hard to consolidate the products we at OpenNETCF offer. What this means is that products that didn't sell well or that had high support loads compared to sales got dropped. Our Telephony library is one of those that we decided to discontinue. But that's good news for all! Instead of just letting it wither and die in the depths of our own source control server, we figure it might as well be thrown out to the community to see if it will flourish.

SO with that, we give you the OpenNETCF.Telephony Library, hosted over at Codeplex as tapi.codeplex.com. Enjoy.

Managed Code in the Embedded World

RAS, Windows Mobile and Windows CE

Fri, 20 Mar 2009 16:54:05 GMT

OpenNETCF used to have a product that provided RAS capabilities. Well Microsoft deprecated RAS in WindowsMobile - starting with WinMo 5.0 as near as I can figure - in favor of Connection Manager. That depracation actually broke RAS in some scenarios. FOr example, if you create a RAS connection and then try to use a managed TcpClient, it will try to create it's own connection through the Connection Manager instead of using the connection you created through RAS.

What this did was skyrocket our support incidents for something that we sold very, very few licenses for. In the interest of keeping our sanity, yet allowing people using plain of Windows CE to still use RAS, we made the decision to just make it a shared source project. It's now out on CodePlex. If you need support for it, we still offer consulting services, but everything is there to get you going.

Managed Code in the Embedded World

The OpenNETCF.IoC Framework: Items and Services

Tue, 10 Mar 2009 13:17:43 GMT

Articles in this series
Part I: Inversion of Control and the Compact Framework
Part II: The OpenNETCF.IoC Framework: Items and Services (this article)
Part III: The OpenNETCF.IoC Framework: Events
Part IV: The OpenNETCF.IoC Framework: Performance (TBD)

Downloads
Code and Sample available through CodePlex.

The OpenNETCF.IoC Framework

Since I don’t expect that everyone has used the SCSF and since the OpenNETCF IoC framework is a very small subset, let’s walk through what it is and how it works. First, the OpenNETCF.IoC framework is based on the concept of “Components.” A Component is simply an instance of a class and our framework has two flavors of Components: an Item and a Service. Generally speaking, the difference between an Item and a Service is that an Item is a uniquely-named instance of a Type (so you can have any number of them provided each instance has a unique name) whereas there can only be one Instance of a service per registered type (it acts somewhat like a Singleton).

Both Items and Services are contained as collections in a root container called the RootWorkItem (a name that comes from the CAB framework). Let’s take a look more in depth at each of these components and how you might use them together. For this example we’ll get a little more concrete that the Cars and People example from before, and instead look at classes more actual applications might use.

Items

As I mentioned, Items are simply uniquely named instances of objects. They can be of any Type – the Items collection doesn’t need to contain only a set of a specific type. The Items are contained, conveniently enough, in the RootWorkItem.Items collection. So exactly what advantages to we gain by putting our items in this collection? The primary benefit is that the RootWorkItem becomes an instance manager and, as we’ll see in a little bit, it can also be a factory.

Let’s assume that our application contains the following Forms: MenuForm, EntryForm and SettingsForm and to make things simple, we’ll assume that they are named with their type name. If we have these forms in the IoC framework, then any time we need to reference one of them we can simply do something like this:

desiredForm = RootWorkItem.Items[“EntryForm”];

and ta-da, we get the instance of the Form. We don’t need to pass around a reference to it or store it in some other application global location. So that’s pretty useful right there. But the RootWorkItem really is just an application global, right, so it must provide some other benefit. Well it’s also a factory. If we want to create the entry form we can use a basic create-and-insert mechanism like this:

EntryForm form = new EntryForm();
RootWorkItem.Items.Add(form, “EntryForm”);

But that really isn’t all that interesting. Where it gets interesting is that you can let the framework do the construction for you by simply giving it a Type and name (the name is actually optional, as the framework will assign it a GUID if you don’t provide one):

RootWorkItem.AddNew<EntryForm>(“EntryForm”);

That’s handy. No need to call the object contructor to get an instance and then stuff it into the collection. Less code is always a good thing. But what else can it do (right now I’m feeling a bit like Ron Popeil)?

Well that’s not all! Where it gets fun is in its ability to do injection. This requires a little more complex of a scenario. Let’s assume that the MenuForm requires an instance of both an EntryForm and a SettingsForm. Something like this:

class MenuForm
{
public MenuForm(EntryForm entryForm, MenuForm menuForm) {…}
}

Well the OpenNETCF.IoC framework can actually do these injections for you – all you have to do it provide it a little direction with attributes. If we simply decorate the constructor with the InjectionConstructor attribute, the framework will search the Items collection for existing items of the proper type to inject. So the MenuForm looks like this:

class MenuForm
{
[InjectionConstructor]
public MenuForm(EntryForm entryForm, MenuForm menuForm) {…}
}

And construction now looks like this:

RootWorkItem.AddNew<SettingsForm>(“SettingsForm”);
RootWorkItem.AddNew<EntryForm>(“EntryForm”);
RootWorkItem.AddNew<MenuForm>(“MenuForm”);

And the magic of the OpenNETCF.IoC framework will inject the first two instances into the third. An interesting note here is that the Injection Constructor does not have to be public. The OpenNETCF.IoC framework looks for internal and private constructors as well so you can actually create objects that can only be generated via injection if you wish.

Of course the framework also supports Injection Methods as well, in the event that an InjectionConstructor doesn’t meet your needs:

class MenuForm
{
public MenuForm() {…}

[InjectionMethod]
void InjectEntryForm(EntryForm entryForm) {…}

[InjectionMethod]
void InjectSettingsForm(SettingsForm settingsForm) {…}
}

But wait, there’s more! In the examples so far the RootWorkItem.Items collection must contain the SettingsForm and EntryForm before the MenuForm is created. Well what if we are lazy and don’t even want to do that? Well the OpenNETCF.IoC framework can handle that too. Just add the CreateNew attribute like this:

class MenuForm
{
[InjectionConstructor]
public MenuForm([CreateNew]EntryForm entryForm, [CreateNew]MenuForm menuForm) {…}
}

And the framework will create a new instance of the Type if it can’t find it in the Items collection. Construction of all three objects and injecting them now looks like this:

RootWorkItem.AddNew<MenuForm>(“MenuForm”);

Extremely simple and clean.

Services

The RootWorkItem also contains a collection of Services. A Service is very similar to an Item except for the fact that there can only be one service of any given registered type (we’ll covered what “registered” means in a moment). The collection provides a very similar set of methods and attributes as items. Again, let’s consider a more concrete example. Assume your application has a class that handles reading and setting configurations. There really would only be one instance of this class and in a lot of classic cases people would use the global-wrapped-in-a-new-name called a Singleton.

In the OpenNETCF.IoC framework this would be a service. Since there can only be one pre registered type, there’s no need to name a Service – the registration type becomes the identifier. So as a simple construct/add/retrieve a Service operation would look like this:

Configuration config = new Configuration();
RootWorkItem.Services.Add<Configuration>(config);
…
Configuration retrievedConfig = RootWorkItem.Services.Get<Configuration>();

As with the Items collection, there is a lot more power and convenience in the framework. First, we can have the framework do construction for us:

RootWorkItem.Services.AddNew<Configuration>();

Like the Items collection, InjectionConstructor or InjectionMethod attributes can be used to control which constructor for the service class gets called.

The OpenNETCF.IoC framework also offers lazy loading of services, so the service instance isn’t actually created until it is first accessed (instead of when it’s added).

RootWorkItem.Services.AddOnDemand<Configuration>();

We saw earlier that the OpenNETCF.IoC framework would walk the Items collection looking for instances to use during injection. Well what if an object depends on a Service rather than another Item? The framework also provides a mechanism for that as well using the ServiceDependency attribute. So to inject a Service into a consumer class using Constructor Injection it would look like this:

class ServiceConsumer
{
[InjectionConstructor]
public ServiceConsumer([ServiceDependency]Configuration config) {…}
}

And of course there is a way to do setter injection instead of constructor injection. Here it injects into a property instead of using a method like the Items collection:

class ServiceConsumer
{
public ServiceConsumer() {…}

[ServiceDependency]
public Configuration Config { set; get; }
}

And if you want the framework to construct the service if it doesn’t already exist, you simply set the EnsureExists member of the ServiceDependency attribute like this:

[ServiceDependency(EnsureExists=true)]
public Configuration Config { set; get; }

The only other aspect of a Service that an Item does not have is a “registration type”. This allows you to register a service instance as a type other than its actual base type. For example you may have a Configuration class that you want to register as a service, but you want to register it as an IConfiguration (this would allow consumers to extract the service by the interface type without ever knowing about or having a reference to the concrete implementation).

Up next: The OpenNETCF.IoC Framework: Event Publication and Subscription

Managed Code in the Embedded World

New Article: Determining Form and Process Changes in Windows CE

Wed, 13 Aug 2008 22:14:58 GMT

Today I saw two separate posts on pretty much the same question. How can you determine if the foreground window changes in a WinMo application? Moreover, how can you determine if the new foreground window is your own, or in some other process? My initial thoughts were to do some work in the Form's Deactivate event, but that would lead to having to plumb it into every Form, and then you'd still need special case handlers for MessageBoxes and Dialogs and it would be an unmaintainable pain in the ass. I decided to put some time aside this afternoon and see if I could come up with a better solution, and what I came up with is outlined in a new article entitled 'Determining Form and Process Changes in Windows CE'.

Managed Code in the Embedded World

New Community Article: GDI Performance

Mon, 19 May 2008 16:27:16 GMT

We've published a new article on the OpenNETCF Community Site titled "Native vs. Managed Code: GDI Performance"

http://community.opennetcf.com/articles/cf/archive/2008/05/19/native-vs-managed-code-gdi-performance.aspx

In it, I look at the performance differences between native and managed code making GDI calls.

In case you missed them, our other recently published articles include:

- Performance Implications of Crossing the P/Invoke Boundary

- An Introduction to WCF for Device Developers
- Getting a Millisecond-Resolution DateTime under Windows CE
- Using GDI+ on Windows Mobile
- Sharing Windows Mobile Ink with the Desktop
- OpenNETCF Mobile Ink Library for Windows Mobile 6
- Improving Data Access Performance with Data Caching
- Developing Connected Smart Device Applications with sqlClient
- Debugging Without ActiveSync
- Image Manipulation in Windows Mobile 5.0
- Don't Fear the Garbage Collector

All of our articles are available online at:
http://community.OpenNETCF.com/articles

Managed Code in the Embedded World

New article on P/Invoke

Tue, 22 Jan 2008 22:12:07 GMT

It took me 5 months to actually get it out the door, but I've just published a new white paper on the performance implications of P/Invoking in the COmpact Framework. Check it out here.

Managed Code in the Embedded World

WCF For Device Developers

Thu, 29 Nov 2007 19:40:14 GMT

We just published a new article on using WCF from device applications on the Community site. Read it here.

Managed Code in the Embedded World

Getting a millisecond resolution time in CE

Thu, 29 Nov 2007 16:20:53 GMT

In case you missed it, I published a new article on our community site last week on how to get a DateTime.Now equivalent with the milliseconds field filled in. Read it here.

Managed Code in the Embedded World

CleanSweep update

Tue, 16 Oct 2007 20:17:30 GMT

After receiving a 16MB zip file of a native solution from a customer today, I've updated CleanSweep to clean out a lot of the crap created by the native build process (the last version was mostly for managed code).

I've also added very, very basic command-line support. Right now if you provide no command line, it will clean the directory it is run from. If you want to clean another folder, you pass the full path to the foilder to clean as the command line.

Managed Code in the Embedded World

October Coding Competiton: Got Game?

Wed, 03 Oct 2007 18:24:27 GMT

So we've announced this month's coding competiton theme (get your keyboards fired up).

Last month's competiton didn't have quite the effect we wanted: we only got one submission. Still if you consider that the goal of the competition is to get cool code out to the developer community as a whole, then the FlowFx submission alone made the competition a success. But still, we'd like to see a bit more diverse set of entries. In an attempt to improve things this month we're offering prizes for multiple places (first, second and 3 runners-up) so that no one will get discouraged and abandon all hope if they see some crazy-cool submission early in the month (like I suspect happened with FlowFx).

Any other thoughts on how we can make the competition more successful (short of giving away an X-Box 360, a copy of Halo 3 and a 60" plasma TV to play it on - that's just not in our budget)?

Managed Code in the Embedded World

New article: Smart Devices with SQL Client

Thu, 20 Sep 2007 22:19:52 GMT

In case you've missed it, the OpenNETCF Community Site publishes articles relevent to mobile and embedded developers. We just published the latest entitled Developing Connected Smart Device Application with SqlClient. Check it (and the previous articles) out.

Managed Code in the Embedded World