Page 1
Page 2
Page 3
GAPI
GAPI is still the same, but the difference
is that the 2003 emulators for both SP and PPC support it
now. You have to deploy gx.dll to the device, and then you
can directly pInvoke it and run your app on the emulator.
Along with the sample
by Alex Feinman, there was an
article that came out while I was playing around
with this. My code is real simple and just randomly
draws black dots to the screen.
i control the horizontal
and the vertical
Web.Services
Of course I also went digging for any
changes regarding web services support, and found a nice
little surprise! For auto-generated web-service proxies,
we now can override GetWebRequest() on the SoapHttpClientProtocol
to get access to the actual HttpWebRequest object that will
be used to send the SoapRequest. I consider this a big deal! It
lets us add Headers, set KeepAlive, and so forth. I'm sure
this will make a lot of people happy so that they can add
Cookies to keep a session between ASP.NET web service
requests ... although I promote using a <Session/>
SoapHeader instead because SOAP works on other protocols
than HTTP. Prior to this change, you had to either do cookieless
web services and munge the URLs, or build the SoapMessages
manually and use the HttpWebRequest / Response classes.
a session-enabled web service would
look like this:
[WebMethod(true)]
public int GetSessionCount()
{
int iSess = 0;
object oSess = Session["count"];
if(oSess == null)
{
iSess = 1;
}
else
{
iSess = (int) oSess;
iSess = iSess + 1;
}
Session["count"] = iSess;
return iSess;
}
and you have to add the following overrides
to the autogen'd proxy. NOTE I recommend creating a
new class, inheriting from the autogen'd proxy, and adding
the following code there (so you dont lose changes when
updating the web ref). Then call the web service as you
normally would using the subclass, and the web service
will retain state between calls. NOTE PPC 2003 does not
have SP1 in ROM, so this will not work without that addition.
Not to mention that the current SP1 does not auto integrate
with VS .NET
using System.Net;
private static string sessCookie = null;
protected override WebRequest GetWebRequest(Uri uri)
{
HttpWebRequest hwr = (HttpWebRequest) base.GetWebRequest (uri);
if(sessCookie != null)
{
hwr.Headers.Add("Cookie", sessCookie);
}
return hwr;
}
protected override WebResponse GetWebResponse(ebRequest request)
{
HttpWebResponse hwr = (HttpWebResponse) base.GetWebResponse (request);
if(hwr.Headers["Set-Cookie"] != null)
{
sessCookie = hwr.Headers["Set-Cookie"];
//"ASP.NET_SessionId=g3exyaihxpmbkr55rhfxwq45; path=/"
}
return hwr;
}
Now for the bad news. Although WSE (Web
Service Enhancements) 2.0 is now a technical preview and
Soap 1.2 is now a recommendation, we still have no word
on getting a client-side version of the WSE for mobile clients
to support WS-Security, DIME, WS-Routing, WS-Policy etc...
not to mention WS-Reliablity which should ultimately find
its way into the WSE and would make perfect sense for devices
that can constantly lose their connection. My only hope
is the new Messaging model introduced in WSE 2.0, which
begins to decouple the WSE from ASP .NET. With
this break, it seems like the best chance we have for ultimately
getting the WSE for the .NETcf. My guess is that
the decoupling of WSE from ASP .NET will kill off the SoapFormatter
in System.Remoting as well? I'm holding my breath to find
out what 'Indigo' is ...
Security
I dont have an actual phone, so I do
not entirely understand this ... but it is something to
be aware of. SmartPhones follow the CE module security scheme.
The device can be either a One-Tier or Two-Tier devices.
One-Tier devices treat access to all parts of the device
as needing the same security, while Two-Tier might provide
access to some functions, but restrict others. A privileged
certificate would be required to access those restricted
Two-Tier functions, and can be obtained through programs
such as MS Mobile2Market. As well as being 1 or 2-Tier,
the devices can be in different modes: Open, Locked, Prompt.
The apps ability to run will then depend based on 3 things:
- whether it is a 1 or 2-Tier
device
- what mode it is in: Open, Locked,
Prompt
- if the app is signed with a privileged
certificate, unprivileged certificate, or not at all
The emulator is 1-Tier and Open by default
... meaning you dont have to worry about this when using
it. NOTE this security model is different than
Code Access Security with the full framework, which
does not exist for the .NETcf. Also related to Security,
the CryptoApi does exist on the SmartPhone and can be pInvoked.
NOTE The high encryption pack rsaenh.dll exists on the emulator,
but coredll.dll is what should be pInvoked. Did not see
rsabase.dll at all.
SqlCe
SqlCe does not exist for the SmartPhone.
So I asked on the MS smartphone.developer newsgroup what
should be used instead. Peter Foot felt it should be replaced
with the built-in XML support (e.g. DataSets and / or WebServices)
and / or the CSV lib from opennetcf.org. Another option
might be pInvoking the low level CE DB data store. Some
combination of the above seems like it will work for a lot
of apps.
APIs
There are some interesting APIs that
can be pInvoked as well. The ones I took note of included
Bluetooth, Vibrate, Connection Manager, and Speech Recognition.
The documentation even explicitly points out 3 that also
exist on PocketPC Phone Edition (TAPI, SMS, and SIM).
Questions
These are just random thoughts
that popped into my head and I did not have time to look
into.
- With Speech .NET Beta 3, we get
a Pocket IE add-in for Speech, will the SmartPhone PIE
get the same add-in for SALT'ed web sites?
- From a newsgroup posting, a person asked
about getting DirectPlay for SP. The last drop was DirectPlay
for PPC 2002. This is relevant to me, because I wrote
an article on how to pInvoke DirectPlay for
PPC from a combination of managed and unmanaged code.
- When do we get Flash for SmartPhones?
- e911 - forget privacy, I want Location
Based Services
- MMS, SyncML, SVG?
Conclusion
The SmartPhone 2003 SDK allows for managed
coders to begin developing apps for the SmartPhone. It will
be an easy transition for those already familiar with the
.NETcf and developing for the PocketPC or CE. Cannot wait
for the actual SP 2003 hardware to become readily available
to consumers. Later.
Previous Page