Team Fly |
Page 644
To get a sense of the limitations you must work within when programming under the Compact Framework (CF), consider the Button control. If you look in Help under ButtonBase members, you see the properties and methods available to the base class from which various button-like controls inherit (RadioButton, CheckBox, Button). In the list of members, you see 68 total properties, but only 25 of them are described as ''Supported by the .NET Compact Framework."
You find that properties such as AllowDrop are unavailable (dragging and dropping cause difficulties, serious bandwidth problems, if the mobile client expects to see an animated illustration as they drag). Also unavailable are TabIndex, Image, Dock, FlatStyle, and others. Here's a list of the properties supported for Button controls running on the CF:
BackColor | BindingContext | Bottom |
Bounds | Capture | ClientRectangle |
ClientSize | ContextMenu | Controls |
DataBindings | Enabled | Focused |
Font | ForeColor | Height |
Left | Location | Parent |
Right | Size | Text |
Top | TopLevelControl | Visible |
Width |
|
|
Writing for mobile devices presents several problems to a programmer. For one thing, PDAs and phones vary widely in their screen resolutions, color capabilities, input technology, and so on. Some mobile device programming platforms have "solved" this incompatibility issue by stripping down the features to the lowest common denominator. But clearly someone owning a nice color PDA doesn't want their applications in black and white.
Microsoft addresses this issue by promising to provide class libraries for the .NET Compact Framework that will target the capabilities of types of devices as well as individual models. There's only so much you can do with this approach, however. For example, when you're creating a word processor application for a color-capable screen, you make design decisions differently than you would for a black and white screen. You employ different visual cues than you do with the more restrictive environment of a black and white screen.
With mobile computing there's another major issue a programmer faces: where should the actual programming execution take place? In the mobile device, in the server communicating with it, or shared between the two locations? And, if shared, should the client mobile device remain in continuous contact with the server during application execution? This is one aspect of what's called the connectivity problem.
The connectivity problem was solved by ASP.NET and ADO.NET—information to be detached from databases, for instance, and sent as an HTML package to users' browsers. This way, a continuous
Team Fly |