When making the decision to code for mobile, developers
face a wide variety of choices in a fast-changing marketplace.
The maturation of Windows Mobile as both a platform and as a
dominant force in the mobile market coincides with the debut
of some of the coolest devices on the market. Today, you have
the Blackjack, the Q, the Dash, the CN3, the JAQ, the Treo,
and a
ton more. You know the opportunity is
there, but do you really want to learn yet another language
and platform? Well, you'll be surprised and delighted to know
that, whether you realize it or not, you already have all the
skills you need to code mobile apps.
In other words, if you're a Windows programmer and use
Visual Studio 2005 to do your work, then you have both the
skills and the tools necessary to be a mobile programmer. And
what you don't know now, you can easily learn. To prove it,
I'll go through the skills you're likely already using that
are directly applicable to mobile development, and then
describe what works a little differently. Then I'll share a
few tips for extending your desktop skills to mobile.
One caveat: your approach, tools, and skill set will differ
greatly depending on whether you code client apps or Web-based
mobile apps. So I'll cover both angles.
Client Apps: What You Already Know
If you're
coding an app intended to run directly on a mobile device,
then your primary coding tool will be Visual Studio 2005 plus
Windows Mobile 6 SDK. (Note: the
technical refresh will debut at MEDC 2007.) Released on March 1, 2007,
Mobile 6 goes even further than 5 in simplifying development
and deployment across multiple platforms at once. The SDK
includes documentation, code samples, headers, libraries, and
emulators, all of which you'll either need or want when coding
mobile apps.
If by chance you've already worked with a previous version
of Windows Mobile, you'll notice that the terminology has
changed with version 6. Here's a side-by-side comparison, with
laymen's terms if you're new to all of this:
| Windows Mobile 5.0 |
Windows Mobile 6 |
In other words… |
| Windows Mobile 5.0 for Pocket PC |
Windows Mobile 6 Classic |
Touch screen device with no cell phone |
| Windows Mobile 5.0 for Smartphone |
Windows Mobile 6 Standard |
Non-touch screen device with a cell phone |
| Windows Mobile 5.0 for Pocket PC Phone Edition |
Windows Mobile 6 Professional |
Touch screen device with a cell
phone |
Visual Studio 2005
First of all, take a look at
your friend Visual Studio 2005. When you download and install
the Windows Mobile 6 SDK, the first things you'll notice are
your new Project options (see Figure 1).
The second thing you'll notice is a very cool design view for
your starter Form (see Figure 2).
Figure 1: Windows Mobile Project
Types |
Figure 2: Windows Mobile Standard
Form Design |
Figure
3 shows a side-by-side of your form in design view
compared to the emulator so you can see how beautifully
accurate the emulator is. As a bonus, if you haven't seen the
new Windows Mobile 6 UI, check it out in Figure 4
where I've closed the form and gone back to the "desktop" or
Today screen.
Figure 3: Windows Mobile 6 Design
View vs. Emulator |
Figure 4: Windows Mobile 6 Standard
Emulator |
This portal and MSDN both have a ton of resources for
getting you started in mobile development, so I won't go any
further here. What you can take away is that all the starter
code you expect is already in place and behaves as it does
when building a Windows form. You also get several bonus
features, such as the ability to preview your work in one of
several mobile emulators, which can be selected from the IDE
workspace directly, as well as access to mobile-specific
controls, such as Device Components, Device Containers, Device
Menus and Toolbars, etc.
.NET (Compact) Framework
As with your Windows
apps (hopefully), Windows Mobile devices run on a version of
the .NET Framework 2.0. In this case, you'll be using a small
footprint version known as .NET Compact Framework 2.0. While
the Compact Framework keeps most namespaces, classes, and
functionality from the larger .NET Framework, it obviously
drops a lot of syntax that isn't needed or doesn't make sense
on devices.
Just as an example, when using the
System.Windows.Forms.Menu.MenuItemCollection
collection to build a menu, you can't call the
AddRange method to add an entire collection of
sub-menus at once. Instead, you'll need to add each menu item
individually using the Add method. But before you
scowl, consider that you'll likely be rewriting your UI code
anyway, especially the menu. So, changes like this shouldn't
pose many limitations for you.
If you want to deploy your apps to both desktop and mobile
clients, try to use syntax shared between .NET Framework and
.NET Compact Framework. This allows you to extend a single
code base across multiple target clients, one of the few
things both Marketing and Engineering can agree is a good
idea. Read the "Fundamentals of Microsoft .NET Compact
Framework Development for the Microsoft .NET Framework
Developer" to learn about specific differences between the
two. This documentation dates back a ways but still covers
helpful essentials. If you want to get serious about the
topic, Daniel Moth will cover this in much greater detail at
MEDC in a breakout called "Sharing Assets Between the .NET Compact
Framework and the .NET Framework."
Also, for the absolute latest on the upcoming .NET Compact
Framework V3.5, be sure to attend David Kline's MEDC session,
"What's New in .NET Compact Framework v3.5."
Language Choice
When it comes to choice of
programming languages, keep using what you're using. Because
of the .NET Compact Framework, your managed code compiles the
same, whether it's C#, VB.NET, etc. You even analyze the code
for your mobile apps the same way, using Visual Studio's Code Analysis tool. Native
code works, as well, assuming you use the correct APIs. Now, as to using both at the same
time, you can make it work. But rather than get into it here,
your best bet would be to attend Chris To's Hands-on Lab
called "Incorporating COM Objects into Your .NET
Compact Framework Application."
Bridging the Gap
As you can see, you already have
the tools and coding skills you need to build mobile apps. If
you're new to this platform, though, you'll quickly discover
key design differences, mostly around UI. Here are some tips
for moving your desktop apps to mobile or starting entirely
new mobile apps.
- The UI will be your biggest change. Dimensions for your
target devices range from 176x220 to 480x640. And with
Windows Mobile 6, add to that a new "medium" DPI, a 320x320
display form factor. The device emulators included with your
SDK will help you develop and test on multiple devices. But
depending on your app, you may need to detect screen size
and adjust accordingly, especially if you're using
non-vectorized assets. Fortunately, Windows Mobile forms
include control anchoring, auto-sizing, and other features
that help you adjust on the fly. For more information on
adapting to variable displays, read "Adapt Your App."
- UI differences especially affect your ability to
leverage a single code base across multiple devices.
Fortunately, Visual Studio 2005 goes further than any
previous version of Visual Studio in separating UI code from
functionality. So you should have no problem architecting
your project appropriately.
- Because you're dealing with a much smaller screen space,
you should review all of the features of your app and decide
what absolutely must stay and what can be eliminated. Mobile
apps are not really intended to be full-featured versions of
your desktop programs (though by the time we're all wearing
holographic display buttons on our shirts, that may
change—no doubt that's coming soon from the embedded group). Believe it or not, your
customer service department will actually play a big role in
helping you define what to keep and what to jettison for the
sake of simplicity. Ask your support staff. Canvas users.
Prioritize features and include just the essentials.
- Along those lines, reduce clutter. Remove menu options.
Remove UI controls. Simplify wherever you can. On a Windows
Mobile Professional device (formerly known as a Pocket PC),
for example, you have a total of two main menu options—one
for the left button and one for the right. These can have
flyouts, which can spawn more flyouts. But obviously the
more intricate your menu tree, the more thumbling you'll be
asking of your unappreciative user. (Thumbling: from
thum-ble [v.], to fumble with one's thumb.)
One last
thing—as you can guess, MEDC 2007 features an entire track on
this very subject called "
Application Development," with 77 different
sessions, including breakouts, instructor-led labs, and
hands-on labs.
Mobile Web Apps
As a mobile user, you've probably
begun bookmarking mobile-friendly Web sites. So you know the
benefits of designing versions of your site for mobile, or the
drawbacks of neglecting mobile users. The question then
becomes how to do it.
Unlike mobile client apps, which are based on .NET Compact
Framework, your Web apps will be developed and deployed just
as they are now, with one key difference: again it comes down
to UI. You have smaller real estate, lower resolution, lower
color depth, and less client-side functionality. At least
that's the case today.
Fortunately, the ASP.NET page framework includes three
namespaces specifically for developing mobile sites:
- System.Web.UI.MobileControls.MobilePage
- System.Web.UI.MobileControls
- System.Web.Mobile
These server controls help you
target a variety of mobile devices and function pretty much
the same way as the controls you use now. For example, a
TextBox is still a TextBox. Currently, these are the controls
you'll be using:
- AdRotator
- Calendar
- Command
- CompareValidator
- CustomValidator
- Form
- Image
- Label
- Link
- List
- MobilePage
- ObjectList
- Panel
- PhoneCall
- RangeValidator
- RegularExpressionValidator
- RequiredFieldValidator
- SelectionList
- StyleSheet
- TextBox
- TextView
- ValidationSummary
Mobile Page Coding
TipsWhen designing your mobile page, here are a few
things to keep in mind:
- For testing, you can use the emulators in the Windows
Mobile SDK. But testing for non-Windows devices can be a
little trickier and may involve installing emulators from other device
manufacturers.
- Use the MobileCapabilities class to detect the
capabilities of your visitor's device. This allows you to
discover browser type, screen dimensions, GPS awareness,
color depth, and much, much more. You can also filter
functionality based on your findings. Read "Mobile Device Capabilities" for more
information or review the MobileCapabilities Members list.
- Simplicity is key! Carefully consider why visitors will
be coming to your site and design your mobile pages
accordingly. For example, if you have a news site or blog,
just give them headlines and links. They don't need to see
your precious 100k graphics, especially not when they might
be paying by the k. The usual 2- or 3-column layout doesn't
translate well, either. As an example, compare Figure 5,
www.yelp.com as seen in IE 7, to Figure 6,
which is mobile.yelp.com as seen in the Windows Mobile 6
Professional emulator. This is how it's done right.
- Lastly, it almost goes without saying:—if you're not
browsing on a mobile device, then start as soon as possible.
You'll quickly compile a list of pet peeves of your own that
will help you avoid irritating your mobile visitors. You may
even come up with the next wildly creative innovation.
![]()
Figure 5:
www.yelp.com |
Figure 6: mobile.yelp.com
|
Where to Go from Here
Just as you already have
abundant skills at your disposal, you also have abundant
resources. If you want to jump into mobile development feet
first, you can do no better than to attend MEDC 2007. But between now and then, this
site will get you started with basic and advanced mobile
coding techniques. In addition, here are a few more resources
from MSDN:
DevX.com 
Print
Justin
Whitney is a regular contributor to DevX.com and
Jupitermedia. He currently lives in San Francisco, where he
consults for leading high-tech firms and writes about emerging
technologies. 
Dzone.com
Digg.com
Slashdot.org
Reddit.com
Del.icio.us
