So as I discussed in previous blogs, at work I have been doing mobile development using .Net 2.0 and the Compact Framework (CF). For the most part I have found the compact framework fulfills about 90% of our needs. However the remaining 10% of our needs causes a lot of headaches for our team.
I understand the need for the CF to remain compact but it is surprising some of the things that were left out of it. A great example of this is form and control loading. In a WinForms project using the full framework; Forms and UserControls inherit from Control. Control implements a Load event. So this causes Forms and UserControls to have a Load event that is fired shortly before the control or form is loaded on the screen. So if you are creating your UI dynamically at runtime, you have a way to set properties before displaying but after construction.
In the CF, Control does not implement Load. Load is only implemented on the Form. Controls have a Paint event that can be used to do the setting of properties. Most people will say see the CF still allows you to do what you need, but here is the rub.
Besides not being consistent, let's say this dynamic UI needs to be somewhat portable so that it will run on a mobile device and on a PC. the code will run nicely on the hand held device, but on the PC you get this flickering coming from the controls because the use of the Paint event.
So to solve this problem what I did was rather simple, but really tedious. Since in CF you do have a Load event on the Form, I decided to use that. Every UserControl that can be placed dynamically on a form sets the Load event. This was a bit harder than I thought it would be because my natural thought was to do the following in a method that could be called during setup of the control but before loading of the form...
Parent.Load += new System.EventHandler(Control_Load);
or
((Form)Parent).Load += new System.EventHandler(Control_Load);
Since the parent is really a Control type, and casting it as Form could be dangerous because the controls parent could be a TabPage or a Panel, I ended up setting the form as an attribute on a base class of all these dynamic control and ended up setting the event like this...
this.ParentForm.Load += new System.EventHandler(Control_Load);
This solution will allow for this dynamic approach to work both on mobile devices and PCs.
There are other places in the CF where the implementation differs greatly from the full framework. For example threading, but that is a discussion for another day.
With this blog I will try to post observations from all sorts of topics. These observations are just my interpretations of what I read, see, hear or do. Some may agree some may not, but hopefully it will spark good conversation.
Showing posts with label handhelds. Show all posts
Showing posts with label handhelds. Show all posts
Friday, January 19, 2007
Friday, December 15, 2006
Handheld Development
At work I have been doing quite a few hand held device projects. Although these project are fun, since they are different from the ordinary, however having to work with the Compact Framework (CF) is challenging.
The CF is really a subset of the .Net framework. What make it tough is the fact that things you expect to be in the framework are sometime missing. The example that took me by surprise was the Threading package. If you look at the two packages, you will notice the threading in the CF is rather lite. Some methods one would expect to find are missing, causing the developer (me) to have to find new ways to do tasks.
I don't want this to sound like the CF is crap, because it isn't. I am sure the reason the CF scales down is because of the devices it has to run on. Hand held devices have limited memory resources and processor speed. These limitations are what causes the CF to be scaled from the regular framework.
There are other things that cause this type of development to be challenging, but I think I will save those for another day.
The CF is really a subset of the .Net framework. What make it tough is the fact that things you expect to be in the framework are sometime missing. The example that took me by surprise was the Threading package. If you look at the two packages, you will notice the threading in the CF is rather lite. Some methods one would expect to find are missing, causing the developer (me) to have to find new ways to do tasks.
I don't want this to sound like the CF is crap, because it isn't. I am sure the reason the CF scales down is because of the devices it has to run on. Hand held devices have limited memory resources and processor speed. These limitations are what causes the CF to be scaled from the regular framework.
There are other things that cause this type of development to be challenging, but I think I will save those for another day.
Subscribe to:
Comments (Atom)