Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 8    August 16, 2000 Be In the News August 14, 2000 OS Alternative is Causing All the Buzz, GCN.com August 10, 2000 Be Readies Internet Devices, InfoWorld August 7, 2000 Solving The Filetyping Puzzle: How BeOS Knows A File Type, BYTE.com August 4, 2000 Open Letter to Be Community, Be Inc. Be Press Releases August 16, 2000 Be Incorporated Announces Support for Compaq Computer Internet Appliances August 9, 2000 Be Incorporated and Arima Computer Corporation Join Forces to Develop Internet Appliances return to top Sub-PC vs. Appliances by Jean-Louis Gassée We look at the Internet today through the eye of the PC. That is, the vast majority of devices connected to the Web are personal computers running Microsoft Explorer in the Windows or MacOS version. There are other good browsers, including Opera's, which we like so much we use it for BeOS and BeIA. For todays Internet browsing, though, it's pretty much a Microsoft world. This de facto monopoly influences the way we think. There is a tendency to equate IP-enabled appliances with a subset of the PC life form -- sub-PCs. This is not a new argument but it acquires more substance when we look at a genre of appliances loosely called "PDAs" or "organizers" and particularly, connected organizers. The most successful ones are based on the Palm platform, with Handspring (from the creators of the Palm Pilot) and Palm Inc., recently spun off by 3Com. (This, by the way, removes an earlier conflict of interest: while I'm still associated with 3Com, I no longer have a Palm connection -- other than my happy use of a Palm VII.) In contrast to their Windows CE-powered competition, Pocket PCs honestly deserve the name. In the CE device -- such as the Cassiopeia E115 I just purchased -- the sub-PC view from Seattle is very much in evidence. It is a powerful device, priced around $600, with a great color screen and a better battery than the previous model. It offers a Compact Flash II slot with a sweet detail: the machine comes with two little stickers you can affix to your CF II cards, which makes them much easier to extract for klutzes like yours truly. I could go on with various "buts," such as handwriting recognition and synchronization, but one big "but" overrides them all: Microsoft tried to cram the features and UI of a PC inside a PDA. Making a virtue out of a vice, or preempting comment, MS marketers call this kind of connected organizer a Pocket PC, informing us what to expect in terms of manageability, ease of use, and roach-motel tactics with other MS products such as Outlook. I won't dwell too much on the contrast with Palm because the difference is well known. Palm's success is built on the fact that it was designed as an organizer, not as a sub-PC, hence the simplicity and the agility -- now with an antenna and lower prices. There are other worthy examples of connected devices without the shackles of PC-ness. We see IP-enabled cell phones emerge in this country and in Europe, with arguments around the performance of WAP (Wireless Access Protocol) riding on an aging cellular circuit-switching technology. In Japan there are the more modern DoCoMo packet-switched I-mode phones, successful beyond NTT's dreams. Closer to home and to PDAs we have the newest Blackberry devices. Initially, these were seen as fancy text pagers but, one software revision led to another, and they now synchronize addresses and appointments with your desktop PC, send and receive e-mail using the BellSouth wireless network, and get more Web information through third parties such as Oracle Mobile. In the past few months, I've seen them pop up around conference rooms like Palm Pilots used to, and Compaq just announced that it will brand and distribute a Blackberry device. Score another success for an independent, legacy-free approach to the Internet and connected devices. As hard as it might be to drop the PC model when addressing the opportunities of the Web Appliance space, more and more players are looking at the Internet through new eyes. return to top The Be Line There is no Be Line this week. return to top Godzilla vs. BArchivable: Armageddon in Menlo Park ByAdam Valjean Haberlach, Quality Assurance Engineer I stuck my head into a private IRC network long enough to say "I need a title for a newsletter article" and used the first one I could sneak past the censors. Luckily, it has something to do with the topic of discussion. Long ago, before I came to work at Be more than two years back (quite a while to be working at one company here in the valley) I decided to write a CAD program to use for personal hardware projects. My degree is in Computer Engineering, and I pledged to use my knowledge for good, not evil. Or at least to make neat toys. Alas, I haven't managed to create anything more exciting than a few Non-Maskable Interrupt cards for Be. But the long and short of it is that I set out to write a simple program that would allow me to draw a simple electrical diagram, organize it, label it, and print it so that I would have it as a reference while building hardware. Feel free to download the sample code here. To get the basics working, I built a custom view class that handles drawing "CadItem" objects and their children. I used a model similar to the BListView, in which a List contains objects and draws them by calling their Draw() function and passing a pointer to the view in charge of the drawing. The neat part is that I got a file format and the tools to read and write it for free. When it's time to save the file, my program can simply take the entire view, archive it, and flatten it to disk. Luckily, this can be done in reverse to load a file. The BArchivable protocol is fairly simple. An archivable object must have a constructor that takes a BMessage and an Archive member function that stores the object's data into a BMessage. First, I had to override the default ones from BView and make sure they worked with my CadPictureView. We'll cover the Archive half of the process first. The function takes a pointer to a BMessage and a flag you use only to archive an object without storing its associated information. As you can see, we just jam the object's member variables into the BMessage. When it's time to store the list of CadItems, we iterate through the list, archive each one individually, and store their messages within the archive. /*********/ status_t CadPictureView::Archive(BMessage *archive, bool deep = true) { int result; archive->what = BECAD_DATA_MESSAGE; /** this is important **/ result = BView::Archive(archive, deep); archive->AddBool("fGraphState", fGraphState); archive->AddFloat("fGridSize", fGridSize); archive->AddFloat("fZoomFactor", fZoomFactor); if(deep) { CadItem *thisItem; BMessage *thisMessage; int index = fItemList.CountItems(); while (index > 0) { thisItem = (CadItem *) fItemList.ItemAt(index-1); thisMessage = new BMessage(); thisItem->Archive(thisMessage, true); archive->AddMessage("CadItems",thisMessage); index--; } } return (result); } /*********/ This results in a BMessage which should contain everything we need to create a working copy of the object elsewhere. When it's time to unpack the object, we call its constructor with the associated BMessage, like this: /*********/ CadPictureView::CadPictureView(BMessage *archive): BControl(archive) { long int index=0; long int numPoints; BMessage thisMessage; BArchivable *thisItem; CadItem *thisCadItem; type_code typeFound; archive->FindBool("fGraphState", &fGraphState); archive->FindFloat("fGridSize", &fGridSize); archive->FindFloat("fZoomFactor", &fZoomFactor); archive->GetInfo("CadItems", &typeFound, &index); while (index > 0) { archive->FindMessage("CadItems", index -1, &thisMessage); thisItem = instantiate_object(&thisMessage); if (thisItem) { thisCadItem = dynamic_cast<CadItem *>(thisItem); if( thisCadItem) { fItemList.AddItem( (void *) thisCadItem); } else { printf("thisCadItem == NULL (could not cast)\n"); } } else { printf("thisItem == NULL (could not instantiate)\n"); thisMessage.PrintToStream(); } index--; } } /*********/ The interesting thing here is the call to "instantiate_object" which, given a pointer to a BMessage, attempts to turn it into an instance of a BArchivable object. This works by checking for the name of the class that was stored in the BMessage by the call to BArchivable::Archive() -- you do remember to call a parent class's member functions when you override them, right? After that, we check to see that instantiation worked, giving some debug information if it failed. Otherwise, we try to cast it as a CadItem and complain on failure. If everything works correctly, we just add it to the PictureView's list of objects. In addition to the list of objects, we pull out the rest of the state information for the View: grid sizing/visibility and zoom factors. Voila! We now have a copy of the CADPicureView just as it was when we stored it. This saved me a lot of time -- I didn't have to come up with a flattened file format to store lists of points and other objects. I've intentionally created it so that it can be extended by creating other subclasses of CadItem. I'll leave it as an exercise for the reader to find the "Archive/Flatten" and "Unflatten/Instantiate" calls elsewhere in the sample code. I even threw in the beginnings of a ToolBar class for good measure. return to top Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission. The BMessage Copyright (c) 2001 by Be, Inc. All rights reserved. Be, Inc. 800 El Camino Real, Suite 400 Menlo Park, CA 94025 Tel: (650) 462-4100 Fax: (650) 462-4129 Web: http://www.be.com/ Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved. The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.

About Be, Inc. | Be Products | World of Be | BeOS Support | Jobs | Developers | Press | Partners | Investors

Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!