Creating dynamic folders on Pocket PC OS read... (299 hits)
Eight previous NAVTEQ Global LBS Challenge® participants have received venture capital funding and nine past LBS Challenge winners have launched commercial applications on major wireless carriers.
Register your non-commercial LBS application in the 2007 NAVTEQ Global LBS Challenge in one of three regions: Americas, Europe-Middle East-Africa (EMEA) or Asia-Pacific(APAC). You could win a share of $2 million in prizes. This could be your year. Dream.Develop.Win.
Communicating with a connected device
is quite distinct from communicating with other desktop
macines or a server. Considering that PDA's use a different
OS and a different processor, this revelation is hardly
surprising. In this regard, there's some good news and some
bad news. The bad news is that it takes a little more work
than you may acustomed to in order to communicate with a
device. The good news is that 1) it's possible 2) Once you
understand what's going on, it's fairly straightforward.
The primary mechanism for desktop to
device (d to d) communication is knows as
RAPI. RAPI is code for using any of the functionality
exposed in RAPI.dll which resides on the desktop machine.
Currently, there's no native managed provider to access
RAPI, so you are going to have to delve into the unmanaged
world. Opennetcf.org has an implementation which wraps the
functionality of RAPI in an easy-to-use library and if you
aren't familiar with their work, I highly encourage your
to visit their site.
But how does one use RAPI and what can you do with it?
Let's say that you wanted to programatically
activate myProgram which resides on the PDA from the desktop.
A natural assumption might be that you somehow make a connection
with the PDA and then use a mechanism like Shell.Execute(@"MyPath\MyApp")
or Process.Start or some similar mechanism. When I first
started CF programming, this was my assumption. But I quickly
learned that there is no Shell.Execute functionality provided
in the CF. As such, it idn't take long for me to realize
that any career in Compact Framework will be riddled with
P/Invoke. So before I go any further into the mechanics
of RAPI, let's take a look at how we'd start an application
on a PDA.
The first thing you'll need to do is
include a reference to System.Runtime.InteropServices. This
is the namespace that provides the fundamental interface
for dealing with unmanaged code. And without striking up
the all too belabored debate on VB.NET vs C#, I actively
use both C# and VB.NET but greatly prefer C# when dealing
with unmanaged code. C# Supports execution of unsafe code
blocks and VB.NET doesn't (which isn't due to the language
as much as the implementation) hence making it much better
suited for Interop tasks (at least from my point of view).
Next, we need to take a look at the CreateProcess API. A
typical invokation looks something like the following:
Now, we'll need to define a structure to accomdate the last
argument of the API Call:
[StructLayout(LayoutKind.Sequential, Pack=4)]
public struct ProcessInfo{
public IntPtr hProcess;
public IntPtr hThread;
public int dwProcessId;
public int dwThreadId;
}
At this point, we've done all of our ground work and we are
ready to test things out. Here's a shell of a C# desktop program
which assumes the above code has already been incorporated:
At this point, it should be fairly evident that Rapi can do
some pretty cool things for you but this type of implementation
isn't intended as a solution for many problems. After all,
how many times do you really need to programatically invoke
a program on a connected PDA? In most instances it might be
a lot easier to grab the damned thing and just start the program.
But that's not really the point. Mainly, what I hope I've
conveyed is that Desktop to Device communication is not only
possible but not all that complex. Sure, you'll be P/Invoking
up a storm, but that's the nature of Compact Framework development
these days.
RELATED Resources: Opennetcf
Communicating w/ the Desktop
