Slashdot Mirror
The Definitive Guide to the Compact Framework
The authors made Chapter 1 as interesting as the beginning of a computer book is going to get. The two best parts in the introduction, IMHO, are the discussions of the differences between eVB (eMbedded Visual Basic) and the Compact Framework as well as the differences between the full framework and the CF.
Chapter 2 is where the rubber hits the road, so to speak, and walks you through getting started and a Hello, World application. This is where the authors' attention to detail really becomes obvious. Instead of a standard such program that simply pops up a MessageBox displaying "Hello, World," the authors come up with a cool sample that gives you a good introduction to CF programming.
Chapter 3 talks about designing interfaces. Typically, a lot of developers may take this for granted (have you ever met a developer that didn't think they were a UI Expert?), but there is limited real estate on a PDA, and I think Larry's guidelines are excellent.
Chapter 4 is probably best described as "The last guide to CF controls that you'll ever need." It's packed with examples on how to use everything in the toolbox, and you can tell the authors really put some thought into coming up with interesting and useful examples. While experienced developers will certainly find this chapter helpful, beginning developers would be well advised to buy the whole book even if this were the only chapter. Although I really liked this chapter, the authors sort of skimped on one important area here, but it's not a big deal: If you want to write custom controls and have them placed in the Visual Studio designer, you have to jump through a few hoops. The authors tell you what these hoops are, but don't tell you how to jump through them. In all fairness though, if they covered everything to the level of detail this subject entails, the book would be 20,000 pages and take years to write.
Not every control that you have in your toolbox on the desktop is available here, and if you want to spice up your UI, you'll probably want to roll your own controls. Chapter 5 builds on the topic of custom controls, and delves into building your own. The next two chapters still concentrate on UI issues, mainly menu items and drawing your own graphics. If you intend to write your own control or do anything interesting with your interface, getting familiar with the graphics library is a must.
After discussing the UI, the authors veer off into the CF File System. By its very nature, the PDA has a different file system than the desktop, and is something that many new developers have a fair amount of headaches with. Roof and Fergus show you how to move around files and directories, and how to create a text file or binary. The first time I read the chapter, I was disappointed that XML wasn't discussed when writing files, but there's good reason for this; they dedicated an entire Chapter to XML later on.
With the UI and file system explained, the authors next move into the important area of data access. After all, unless you are simply playing games on the PDA, it probably needs to interact with a database somewhere and I can assure you, just about every common task that you may encounter is discussed in depth. The show you how to bind controls to data, retrieve it from a Web Service, retrieve it from a SQL Server on a local network, use SQL CE to take advantage of replication and using XML as a Data Access technology. Since a PDA may get its data from many different sources, the ability to manipulate XML is very handy. Every problem that I ever encountered regarding data access in the CF was covered here and they have some really interesting ideas on how to implement things.
The book moves on to networking. There were only two chapters dedicated to networking and I would have liked to see more, but they definitely address just about everyt task that you'll routinely face. In all fairness to the authors though, there's about 100 pages dedicated to mobile networking and web services, and it's certainly not glossed over.
Chapter 17 takes a turn into Unmanaged code and P/Invoke and is probably my favorite chapter of the book. Why? Well, because a lot of things aren't yet supported on the CF and many probably won't be. So using Interop is the only way to get stuff done. I've developed CF programs for almost a year now, and this chapter got me through two problems that I hadn't been able to figure out previously. Beginning CF developers may not find this chapter as interesting as I did because it involves API calls, but trust me, this part is a life saver! Then they go right into showing you a really practical example of using Interop and their examples address things that I constantly see asked in newsgroups.
I was impressed by the authors' discussion of some really popular 3rd-party tools. Microsoft has a POOM example, but it leaves a lot to be desired. The authors show you how to use many of its features, and then present a very popular POOM Outlook implementation that is about as cool as it gets.
The rest of the book is pretty much a wind-down. It shows you how to build a help system, create setup applications and HTML reports. However, the authors did something really cool and slipped in a chapter on configuration files and how to use them. Registry access in the CF takes some time to learn (and if you didn't read Chapter 17, good luck!) and traditional configuration files aren't natively supported. However, they create their own implementation and it's very easy to understand. I've thought about implementing a solution like this for a while, but never got around to doing it. Fortunately, Larry and Dan took care of it for me. This is definitely a solution that you will probably want to use over and over.
The last part of the book is the appendices. This stuff is thorough and packed with solutions to all of those little problems that are so pesky when you are first starting out. These serve not only to get you past a whole slew of common frustrations, but they reinforce what was presented in the book I think the degree of detail that they included in the end was another superb touch by two guys who really care about their readers.
In summary, this book is a must by for many reasons. It covers a very broad range of information and it covers the majority of it in great detail. They walk you through getting started, building cool applications and deploying them. They give you a complete arsenal or tools to help build solutions with, and I can't think of anything that they ignored. They also give you the appendices, which, as I mentioned above, will get you through a lot of common pitfalls after you've built your application. As of this writing, I have compiled and run all of the code through Chapter 15 and found it well documented and accurate, but Apress can always be counted on for this. Editorially, the content was interesting and well presented and I found the layout very pleasing.
Without a doubt, this book is really great and something that you'll surely want to purchase if you are going to write CF code.
You can purchase The Definitive Guide to the Compact Framework from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Amazon has this book for $41.99 ($6 less than bn) and with free shipping.
For more reviews of this book, check out verygeekybooks.com
For help with development on PocketPC some colleagues of mine and I have created a PocketPC-Development mailing list on yahoo groups:
.NET CF. There are also links to articles, useful utilities, etc.
PocketPC-Development
It is still in its infancy, but we have several whizz developers who know everything about WinCE and the
If you're interested in joining, click the link!!
When you say CF a lot of people think of Macromedia's Cold Fusion. That can get confusing.
SCO.com uses Linux
Incidentally, maybe it's just my browser (IE, I'm at work, I don't get a choice) but there's some creepy code breakage on the new releases page.
Froogle shows it for as low as $34.49.
And if you think tha's some kind of affiliate link, just go to froogle.google.com and search on the isbn: 1590590953.
The book is just short of 1,000 pages including the index, tables of contents etc. It's composed of 22 chapters and 6 appendices.
Subjects ranging from SQL CE, Embedded Visual Basic or XML, basically all the things that you want to embed only if the bed is very large.
In short, the book is the image of what it purports to describe : big and heavy.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
http://www.paulyao.com/cfbook/index.asp
Not finished yet but you can download all of the preview chapters of the book and send the authors feedback.
I write code.
For the experienced CF developer, you know there is a lot to learn and its constantly evolving.
How can you have a definitive guide to something that is constantly evolving? By the time the book prints, it will no longer be definitive...
Rewarding, I doubt it.
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
According to www.addall.com, Overstock.com sells it for $34.49+1.40 shipping or $35.89, $6.10 cheaper than Amazon and a whopping $16.09 cheaper than Barnes & Noble.
As usual, Slashdot reviews don't bother to write even a single introductory sentence about what the technology being discussed is about.
I guess the quickest way to answer it is as usual: What Java technology did MS rip off and hype under a new name today?
Compact... I'm guessing J2ME?
- LarsW
Ironically, Slashdot seems to currenntly render the preview page incorrectly for Firebird, so I had to start IE to post this...
Check out these gems:
If you are new to the .NET Compact Framework, you are about to embark upon a challenging yet rewarding path by writing CF applications. For the experienced CF developer, you know there is a lot to learn and its constantly evolving.
1,000 pages including the index, tables of contents etc. It's composed of 22 chapters and 6 appendices.
if they covered everything to the level of detail this subject entails, the book would be 20,000 pages and take years to write.
So, if I get this right, the Compact Framework isn't really that compact, and the authors encourage using unmanaged code to get around the unsupported things. And since it's constantly evolving, by the time I've mastered one version, the next will be out, and I'll have to learn that one too...
So I assume that this is unmanageably complex and still lacking in features. Why would I ever want to take the time to learn the 1,000-odd pages of this framework if I can roll my own in less time, and it will do what I want? And even if I do spend the time to learn it, it still won't do everything I need it to?!
I've learned other frameworks in the past - Java's Swing, MFC, Borland's OWL, the standard C library, etc. What I've come to realize is that the problem with frameworks is that they consume a lot of time overhead to learn, and even the more "complete" frameworks don't handle everything a developer wants to do. Frameworks are written for writing demo code and cookie-cutter applications - neither of which is useful in either the competitive software market, nor the business world.
So I've stopped learning frameworks. Most of the time, the problems I need to solve are specific enough that the cookie-cutter approach won't work - the client always wants some special functionality that the framework's architecture can't provide.
10 years from now, frameworks will be regarded with the same derision as GOTO, COBOL, and structured programming - yes, they solved the problems of the day, but they didn't do it well.
Not trying to troll, but this is the COBOL of the new millenium - it's big, slow, takes a lot of time to learn, and will be obsolete by the time you master it.
The society for a thought-free internet welcomes you.
Or does this review read as if it were written by the publisher?
The Definitive Guide to the .NET Compact Framework (Paperback)
by Roof, I.
18% off Amazon
Amazon Price: $41.99
(as of 11/17/2003 01:13 Mountain Time, excludes shipping)
List Price: $59.99
Price: $34.49
You Save: $25.50 (42%)
Edition: Paperback
Catalog #: 339468
Quantity:
Availability
In stock. Usually leaves our warehouse within 2-3 business days. Warehouse replenishment issues may stretch that period to 7 business days on some items. If you choose expedited shipping for your order, we will notify you if your order does not leave our warehouse within 3 business days.
Special Media Shipping
We only charge $1.40 for shipping a single media item, $2.80 for two media items, $2.95 for three or more media items. Continental US only.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Microsoft's had UI design guidelines for about 20 years. They continually change as new ideas come to the interface (e.g. now tabbed documents are preferred over MDI). But Microsoft has never completely followed them. Their own apps go against their own guidelines. For example, they always said to never defy the user's color settings when making a menu, and then Office XP came out with a custom menu. They say your apps should have consistent file dialogs, yet every app they create has a different dialog, sometimes changing from version to version.
They ask everyone to follow certain guidelines while they ignore them. I gave up on their suggestions years ago and instead follow general best practices depending on the situation.
Developers: We can use your help.
A 1,000+ page book entitled The definitive guide to the Compact Framework? Sounds pretty ironic to me.
I hate sigs.
I don't believe it's called "Embedded Compact Framework".
I do believe you are making an assumption though, and you know what that means...
No Comment.
I am really gettting tired of shameless plugs for MS related books by people who have no trace in the slashdot community. The review was a play by play that gave me little depth as to the quality of the book, and little reference to other books on the topic. And of course the author of the review came from a Compact Framework specific site, so what would qualify him to write a review of a book that introduces the Compact Framework?
.NET, and use it exclusivly everyday for development. But I want from slashdot real reviews, not MS marketing.. i have to sift through enough of that when i want details on upcoming technologies.
And before you call me biased, know that I love c# and
Ahoy- Anyone used the .NET CF on WinCE.NET 4.1? I have a device (Sigmarion III, 800x480 5" screen and a real keybard- mm mm good) which runs it. According to what I can find at msdn.microsoft.com
.NET framework translates to the Compact Framework? I think .NET is way cool, but if one was just restricted to VB.NET/CF and C#/CF I don't think I'd be interested. For me, it really is about the many-language inter-op. I would love to have some interpretable language- Smalltalk, Lisp, Perl, Ruby or even Python that had a .NET CF version with which I could play with making CE apps with the .NET API.
:)
.NET would be even cooler... I bet portability to the desktop version would be pretty good too. I don't even have a Windows machine to doing the development, I do it all on the PDA or on my Linux file server. But then again, I'm an anamoly; the Sigmarion III is pretty much my primary computer.
How much of the regular
I already have a number of languages on the Zaurus C760 and Sigmarion III. The Zaurus isn't as good as CE as far as having a lot of options for developing "real" apps on the device itself. I could probably compile GNU Mono for the Z pretty easily, but without the ability to create "native" apps for Qtopia, it's no fun.
I already do a lot of coding on WinCE (and Linux PDAs) in various languages, but using
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Thanks for the link, I'll keep an eye on it.
The microsoft mailing list is actually quite helpful I've found. You can google it here
OpenNETCF.org also has a great forum that has enough traffic that your questions usually get answered (which is something to say for Windows communities).
It's here
---- There is a fine line between sayings that make sense.
If you are new to the .NET ....
turn around and run!
MS still don't seem to understand the fundamental problems faced with making embedded applications. You can't just "get rid of a bit of functionality" - you either should have started with slimness in mind, or you've got to redesign a lot of code. I've worked on many a platform where some piece of Microsoft code had to be integrated. Usually it ends up being the make-or-break of whether everything fits or not. Usually it's a tight squeeze. Usually we need to ditch some of our functionality to fit it :)
Quite frankly Microsoft are stuck with the misfortune of designing only for x86 PC desktops. You end up assuming memory and CPU are infinite - both of which are in short supply in embedded systems. A laughably short supply in some cases: how about 64KB of RAM and 30MHz to fit an API into? How about not having a dynamic memory allocator? Yeah, no mallocs allowed! How about if your endian isn't little, your chars aren't signed, your shorts aren't short, and your ints won't work unaligned? Practically every piece of "portable" code I've used from a commercial entity completely ignored these problems.
The thing is - you can have your cake and eat it! It is entirely possibly to write compact APIs which don't lose anything when used on desktop system. They usually benefit from a thoughtful design. I hate to use Linux as an example (especially in the same context as Microsoft), but it really is a good example of thoughtful API design - especially in the sense that "x86 != world". It's not in the same ball-park as some embedded OS's, but it's compact enough to use in devices with around 1MB of RAM (with a bit of tweaking, granted). A much better example is Redhat eCos, which is great for anything from an MMU-less device with less than 100KB, to a full blown "desktop class" PC running a single application.
The thing which makes me laugh most from your post...
SQL CE, Embedded Visual Basic or XML
Yep - you couldn't even fit the parser for any of those in a large class of embedded systems, let alone the back end :)
It's no wonder Microsoft never managed to break into the mobile phone market... they were too busy integrating buzzwords.
Microsoft actually does a pretty good job of following its own guidelines. Not perfect, but fair. File dialogs aren't perfectly consistent (I hate the ones in Office 2000), but they're usually similar.
Apple is about the same in terms of overall compliance, but generally writes their guidelines to suit how they did it in their latest apps (PS: this is why their guidelines often seem senseless or arbitrary).
The most important thing is interface standards within individual applications. It's also important to use native widgets (as much as possible) and common fonts. This is where a lot of "amateur" software is horrible.
Let's not stir that bag of worms...
Pointless blather. Strange how Microsoft is dominating PDA sales, if they're so horribly idiotic when it comes to "embedded" applications, isn't it?
"If you are new to the .NET Compact Framework, you are about to embark upon a challenging yet rewarding path by writing CF applications."
You can't just hack some software together nowadays, everything's a goddamned quest with trials and tribulations.
At least now I know who does those fucking motivational posters.
I tend to agree; nevertheless, compact computing devices will continue to grow in capacity and speed. They will accomodate even the capacious appetites of Microsoft-engineered software. Developers learned to accept MS's engineering bloat on desktop/server operating systems, and it will be no different here.
Already handheld devices are at the performance level of desktops of the early-to-mid 1990s, albeit without rotating mass storage. But SD-Flash is in the multi-gigabyte range, which is more storage than we had on desktops in those days.
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
NO! One major factor in embedded systems is cost - memory and CPU are always sacrificed first. I suggest that MS should learn to accept that they cannot write bloated operating systems and expect embedded systems to bend over a barrel for them.
Already handheld devices are at the performance level of desktops of the early-to-mid 1990s, albeit without rotating mass storage. But SD-Flash is in the multi-gigabyte range, which is more storage than we had on desktops in those days.
Disproof:
- Multi-gigabyte SD cards are hideously expensive.
- The most you should expect from a PDA these days is about 400MHz of XScale, 32MB SDRAM, and 256MB flash. That's state-of-the-art.
- The current state-of-the-art PDA will NOT run (acceptably) the current state-of-the-art Microsoft desktop OS.
- If you put a faster processor in, more RAM, and larger flash, you would have a hideously expensive PDA that sucked for battery life.
An interesting thing is that while the power of portable devices has increased about 10x in recent years - the efficiency hasn't got better by more than about 2-3x. That's yet another thing to add to the list of "things people don't get about embedded systems": inefficient code leads to short battery life. Anyone who's programming an embedded system and doesn't understand that needs to be shot. Repeatedly.The handheld systems of today may be not up to scale of MS's software, however eventually they will be.
That, I believe, is why MS shoehorns in more requirement and code than needed or is reasonable -to get developers and users used to their presence, so that 5-10 years from now, when battery, storage and processing power are up to par, MS will be ready.
It's a strategy that dooms today's users to slow applications with technology bound inappropriately to the local machine (rather than on the server), but this appears to be MS's strategy. I don't condone it, merely observing.
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
all this carry on about large and unwieldy software for "embedded systems", Compact Framework isn't meant to run on a PIC like some tiny embedded OSs are, you're not going to run Linux on a basic stamp either, they're not designed with that in mind.
Compact Framework is designed for WinCE devices, WinCE devices meet a few requirements, you have to meet those or you won't run it... this bashing is somewhat pointless.
have you ever met a developer that didn't think think he was a UI expert?
Here I am!
Pretty much everything I write either implements the server side of a protocol, or reads from an input stream and writes to an output stream (maybe looking at some command line parameters).
(OK arguably the command line parameters constitute UI, but not in the spirit of the article)
I know a bad UI when I see it (and I'm vocal in my criticism when I do) -- but there's no way I could design good UI myself. Leave that to the experts!