Log in

View Full Version : Connected Pocket PC applications


Andy Sjostrom
08-30-2002, 08:29 AM
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, <a href="http://www.businessanyplace.net/?p=shipchart">"Chart Shipping Rates with .NET and Pocket PC Phone Edition"</a>, 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 <a href="http://www.pocketpcthoughts.com/forums/viewtopic.php?t=3180">recently discussed</a> 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."<br /><br />In the second article, <a href="http://www.businessanyplace.net/?p=directionphone">"Driving Directions using .NET and Pocket PC Phone Edition"</a>, 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."<br /><br /><img src="http://www.pocketpcthoughts.com/images/ba_ws.gif" />

schwuk
08-30-2002, 09:59 AM
thanks for the articles. very interesting reading. now i'll have to go and do some development of my own :)

heliod
08-30-2002, 10:25 AM
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.

Ravenswing
08-30-2002, 11:30 AM
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!

Andy Sjostrom
08-30-2002, 01:08 PM
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.

Ravenswing
08-30-2002, 02:01 PM
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?

Jimmy Dodd
08-30-2002, 02:24 PM
Man, it's great to see so much developer stuff showing up at PPCT.

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.

Ravenswing
08-30-2002, 03:49 PM
Man, it's great to see so much developer stuff showing up at PPCT.


Yeah, cool isn't it.

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?

Mobile Bob
08-30-2002, 04:07 PM
Thanks Andy. Very cool. :)

yellow1
08-30-2002, 05:08 PM
So has anyone compiled these apps ?

Andy Sjostrom
08-30-2002, 06:42 PM
SQL Server CE is a "new" database engine. I've wished for a long time that Microsoft would throw out the midieval CEDB and instead use SQL Server CE as the local data store. The POOM would best be re-written to native .NET code.

Jimmy Dodd
08-30-2002, 07:05 PM
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?

OK, I didn't word my thought very well.

What I attempted to say was that since cedb isn't directly supported in .NET cf, and since POOM currently uses cedb as it's underlying data storage facility, that they probably saw no point in implementing a native .NET cf POOM that served as an API into a non-native-supported technology.

I am hoping (just as you suggested) that their thinking is to re-implement POOM as a native .NET API into a SQL Server database underneath. My fingers are crossed (but I'm not holding my breath) that this will be in the actual release. There may, of course, be size constraints to argue against this, since SQL Server CE is not tiny and would have to be in the ROM of every device. Only time will tell...

As for SQL Server, it is a new database engine and supports "common" SQL commands, multi-table databases (my condolences for anyone else who has tried to implement a multi-table solution with cedb) , etc. In other words, a "real" DBMS. It also supports replication with a server database which is nice for enterprise (and enterprising) developers.

Ravenswing
09-02-2002, 01:40 PM
What I attempted to say was that since cedb isn't directly supported in .NET cf, and since POOM currently uses cedb as it's underlying data storage facility, that they probably saw no point in implementing a native .NET cf POOM that served as an API into a non-native-supported technology.

Yeah, but the wole of the CF is essentially a native .NET API serving as an interface to non-native-supported technology. Well, I guess the forms engine is native .NET technology and I assume that's a component of the CF, but even that has to use the OS-level constructs to create what you see.

I am hoping (just as you suggested) that their thinking is to re-implement POOM as a native .NET API into a SQL Server database underneath. My fingers are crossed (but I'm not holding my breath) that this will be in the actual release. There may, of course, be size constraints to argue against this, since SQL Server CE is not tiny and would have to be in the ROM of every device. Only time will tell...

I guess the thing to do would be to take a look at the CE4 Platform Builder and see what native database technology is installed. That might give some idea of what's cooking. I'll try to remember to take a look sometime soon.

Ravenswing
09-05-2002, 11:37 AM
FYI, the CE.NET database model is pretty much identical to the previous versions. SQL Server CE appears to still be an add-on. I can't even discover a mechanism for adding it into the ROM, though, of course, Microsoft might come to arrangements with specific vendors.

I'm not surprised. Even if the API is a pain to use (I never had much trouble, but then I've never done anything very complex), the storage system is efficient and flexible. I always thought it was quite a nice system.