08-30-2002, 08:29 AM
|
|
Pontificator
Join Date: Aug 2006
Posts: 1,177
|
|
Connected Pocket PC applications
Chris Forsberg and I have just published two articles with source code that shows how to make use of the new kid on the Pocket PC block: XML Web Services. The first article, "Chart Shipping Rates with .NET and Pocket PC Phone Edition", explains the inner workings of a connected Pocket PC application that compares shipping rates and presents the results in a chart. Here at Pocket PC Thoughts, we recently discussed the ins and outs of thin vs fat Pocket PC clients. On that subject, Chris writes in the article:"The Web application hype taught us the benefit with online interactivity and up-to-date information. But the downside was the poor user interface and application navigation. With Pocket PC Phone Edition and XML Web Services, there is now an alternative to create applications with a rich Windows user interface while taking advantage of the benefits that online data bring. The creation of such applications have been made significantly easier with the new Smart Device Extensions and .NET Compact Framework."
In the second article, "Driving Directions using .NET and Pocket PC Phone Edition", I illustrate what cool things you do with a connected Pocket PC and XML Web Services. "If you know the phone number for the place at which you are, and the phone number for the place to where you wish to go, then you can use the sample application Directions Anyplace to get directions between the two places."
|
| |
|
|
|
08-30-2002, 09:59 AM
|
|
Pupil
Join Date: Jul 2003
Posts: 37
|
|
Very interesting...
thanks for the articles. very interesting reading. now i'll have to go and do some development of my own 
__________________
How much wood would a woodchuck chuck if a woodchuck could chuck wood?
|
| |
|
|
|
08-30-2002, 10:25 AM
|
|
Intellectual
Join Date: Aug 2006
Posts: 194
|
|
Andy,
Great material !!!
This is real-world use of the new technologies and just demonstrates how useful these technologies can be..
I have already downloaded the articles for reading.
Thanks for making the material public.
|
| |
|
|
|
08-30-2002, 11:30 AM
|
|
Ponderer
Join Date: Jun 2002
Posts: 102
|
|
Haven't read those articles yet, Andy, but I will do. I'm always interested in reading about working solutions.
After all the nice things I said about VS.NET in the other thread, I've just found out that the bastardos have shafted me again!
There's this really useful method in the .NET Framework, System.Enum.Parse. I use it a lot for reading encoded data from XML streams. Saves getting the reader code wrong.
It's not implemented in the Compact Framework!
So much for code compatibility across platforms!
|
| |
|
|
|
08-30-2002, 01:08 PM
|
|
Pontificator
Join Date: Aug 2006
Posts: 1,177
|
|
Easy, Ravenswing!
First, the .NET Compact Framework is still in beta. We know there are things missing, that will be show up this fall.
Second, the .NET Compact Framework is implemented in under 2 MB. I don't know how big the complete .NET Framework is, but it is at least twenty times bigger than 2 MB. Those extra MBs are certainly not pure fat... For example, COM Interop support in the .NET Framework is a huge memory consumer on the desktop / server side. Since COM Interop is not really a big deal in small devices it does not make sense to sacrifice many MBs just to say "cross platform".
Third, cross platform aspects must be seen in the light of the Common Language Runtime and the different .NET Profiles.
|
| |
|
|
|
08-30-2002, 02:01 PM
|
|
Ponderer
Join Date: Jun 2002
Posts: 102
|
|
Well, according to Add/Remove programs, the current .NET Framework racks up 1506MB. Just a little more than 2MB 8)
I understand CF is in beta, I'm looking forward to the next phase of that beta. Can't wait to get my hands on it. However, I have a feeling that this function will not be implemented in the next version because it's been left out as a space saving. I think that's a false economy.
Reduced COM Interop is only to be expected, after all Windows CE doesn't implement half of COM anyway. But if everyone using enumerations has to write their own code to do this interpretation, the CF is smaller, but the overall code size installed on PPCs gets bigger.
The only other example I've found (I'm sure there are others) is a variant on the System.Convert.ChangeType method. This seems to follow the standard CE API mechanism of stripping the API down to the bare minimum of entry points. The user is forced to do a bit more work supplying values for parameters that are defaulted normally, but that doesn't really result in increased code size... um, thinking about it, the same argument applies. Everyone's code size increases so that shared code size decreases. It only works if few people use the functions in question.
:?: Hey, a question for you... Don't know if you know the answer, but here goes.
PIM functionality is a key part of the operation of a PDA. The CF has two additional assemblies in it designed to cope with Infra-red transfer (but not Bluetooth :roll: ) and the pocket version of SQL server. These seem reasonable, but why not have an assembly to package POOM? As it is, you end up having to wrap POOM in a DLL and call DLL entry points using DLLImport. This complicates something that should be made easy on a device designed for this functionality.
Any thoughts?
|
| |
|
|
|
08-30-2002, 02:24 PM
|
|
Sage
Join Date: Jul 2003
Posts: 713
|
|
Man, it's great to see so much developer stuff showing up at PPCT.
Quote:
|
Originally Posted by ravenswing
Hey, a question for you... Don't know if you know the answer, but here goes.
PIM functionality is a key part of the operation of a PDA. The CF has two additional assemblies in it designed to cope with Infra-red transfer (but not Bluetooth ) and the pocket version of SQL server. These seem reasonable, but why not have an assembly to package POOM? As it is, you end up having to wrap POOM in a DLL and call DLL entry points using DLLImport. This complicates something that should be made easy on a device designed for this functionality.
|
I've been dabbling with the .NET cf for a short while now (still mainly dealing with eVC++) but it's my understanding that it doesn't have support for the native database format (cedb). Since POOM is based on that I can imagine that it went out the window with cedb. I also read (someone, somewhere) that a resource (time & people) decision was made to focus on SQL Server CE instead of cedb. I have wondered if this foreshadows the ultimate demise of cedb in favor of SQL Server CE, even for the POOM, etc.
On a side note, you PPCT guys are really making me jealous with all your PPC-PE articles and comments. My carrier won't even go digital! Not that it would help with our spotty coverage. Sometimes rural life is so irritating.
|
| |
|
|
|
08-30-2002, 03:49 PM
|
|
Ponderer
Join Date: Jun 2002
Posts: 102
|
|
Quote:
|
Originally Posted by BwanaJim
Man, it's great to see so much developer stuff showing up at PPCT.
|
Yeah, cool isn't it.
Quote:
|
Originally Posted by BwanaJim
but it's my understanding that it doesn't have support for the native database format (cedb). Since POOM is based on that I can imagine that it went out the window with cedb.
|
The datastores used for Contacts, Appointments, &c are cedb databases, but POOM doesn't have anything to do with those. POOM is a COM interface to the databases and its function is to hide the underlying database implementation from the programmer. Technically, if they moved the PIM databases into SQL Server CE, you should still be able to access the data using POOM.
I'm not actually sure about SQL Server CE. Is it actually a new database engine, or is it just an access mechanism that uses the basic Win CE database architecture under the hood?
|
| |
|
|
|
08-30-2002, 04:07 PM
|
|
Ponderer
Join Date: Apr 2004
Posts: 88
|
|
Thanks Andy. Very cool.
|
| |
|
|
|
08-30-2002, 05:08 PM
|
|
Pupil
Join Date: Aug 2002
Posts: 28
|
|
So has anyone compiled these apps ?
|
| |
|
|
|
|
|
Linear Mode
