Palmtop Computing
Download as DOC, PDF0 likes1,105 views
Palmtop and handheld computers, like the Palm Pilot and Windows CE devices, provide portable computing power. While smaller than desktop PCs, they are fully-programmable and can synchronize data with desktop systems. The Palm Pilot dominates the market with its small size and Palm OS operating system. Windows CE devices offer greater memory and compatibility with desktop apps but are larger and slower to synchronize. The document discusses the characteristics and uses of various palmtop and handheld devices.
Palmtop Computing
- 1. Palmtop Computing Gary Stark What is Palmtop Computing? Are they toys or are they tools? That’s a question that’s being asked in a lot of places these days. The topic of interest is the various types of handheld and palmtop computers that are available today. On the one hand there is the 3Com Pilot family, its badge engineered IBM equivalents, and the Handspring Visor family of devices. On the other there are the various Windows CE systems that are also becoming popular. Beyond the handheld device, Microsoft has other ideas. For instance, they have been targeting the CE operating system specifically at embedded devices, and there seems to be significant vertical market potential there. Consider if you will the various types of embedded devices that we see in our daily lives. From restaurant order taking systems, stock keeping and tracking devices, parking meters, bus and train ticketing devices, tv set-top boxes, gaming devices … the list is endless. Common household appliances, such as refrigerators, washing machines, stoves, ovens, tv sets, video players, coffee makers and even the humble toaster today come with embedded computing logic built in. And let’s not forget the modern car. Fuel metering systems, engine monitoring systems, air bags, active suspension, auto transmission and electronic gear changing today all rely upon some form of embedded computing technology. Microsoft wants to help there too, with the Auto PC. What are these devices, and what can they do? At the more obvious and consumer oriented level, these devices reside somewhere between the pocket organizer type of devices like Sharp’s Wizard, and desktop PCs. These are fully featured computer type devices, featuring some method of connecting and synchronizing their data with backup copies held on the desktop systems, and the actual connection and backup process can be quite a speedy and painless operation. Along with the way that they are able to synchronize their data they have one other feature that makes these pocket size devices potentially very powerful from our perspective. This is the fact that they are fully programmable. This means that as applications developers, we can write programs for them that we can also interface with our desktop applications, thus providing our users with a portable, friendly, alternate input medium. The Devices Let’s have a quick look at a selection of these devices. What they have in common is that they are inexpensive, they share a small and very portable form factor, desktop synchronization, and they will accept input from a stylus or pen type of device. At a pinch, even a finger can be used. They also provide some form of keyboard interface for the user. The now extinct Apple Newton probably fits within the context of the devices we are discussing today, I shall not be dealing with it within this session, as I have had no real exposure to this device. This too is true of the Handspring Visor, which at the time of writing is not yet available in Australia. The Pilot This one continues to dominate the market place. It’s now available in a number of different configurations, and it remains one of the hottest executive “toys” available. This is understandable as the Palm V remains one of, if not
- 2. the, the smallest and lightest of these devices. For its primary source of input it uses a modified form of text recognition that seems to be very effective. The Pilot uses a Motorola Dragonball CPU, which is derived from the 68000 chip that is used to power Apple’s Macintosh. Although it comes with less memory than the Windows CE systems, this is not a major drawback. The PalmOS that operates these devices simply doesn’t need as much memory as Windows CE. It carries far less overhead, and seems to be very well thought out and designed. The device is instantly available, as there are no boot procedures or delays to worry about. One of its original features is that it has several "on" buttons. The primary one just turns the unit on and restores it to the state it was in when it was last turned off. The others not only turn it on, but also instantly launch a predetermined application, such as the calendar or address book functionality. Combined with the fact that it fits easily into a pocket or purse, it’s consequently a very convenient tool to carry and use on a regular basis. Synchronization with the desktop occurs when you place it into the (supplied) cradle and just press one button. The process frequently takes less than a minute. The Pilot Palm OS System The Pilot is well supported with third party tools and software. Development tools are provided for both the Mac and PC, primarily using C, Assembler or Java Script. As already noted, the operating environment for the Pilot is a proprietary operating system called Palm OS. An API and SDK are available to assist programmers developing for this platform. The Palm VII Palm OS System
- 3. Other Palm OS devices are also available. The Handspring Visor uses the same PalmOS, and as already noted, 3- Com market several different models of their Pilot, with the Palm VII including wireless communication to the internet. IBM also market their WorkPad device, which is a badge engineered Pilot. Windows CE Systems Windows CE systems have been developed by different hardware manufacturers such as Casio, Compaq, HP, Philips, to name but a few, to utilize Microsoft’s scaled down version of the Windows operating system, Windows CE. Depending upon the platform selected, the systems come with versions of Outlook applets, Excel and/or Word scaled down to fit the smaller platform. A variety of CPUs is used on these devices, and these devices now come in a number of different form factors to accommodate different usage characteristics. These form factors vary from palmtop devices similar in size and design to the Pilot, called Palm sized PCs, through handheld PCs such as the Cassiopeia A10/A11, and into a larger form factor that approaches notebook PCs for their capabilities. The Cassiopeia E10 Windows CE System Typically, these devices come equipped with a greater amount of RAM than the Pilot, but their (Windows CE) demands are such that they have a greater requirement for it. They also synchronize with the desktop system through a cable or cradle, but this seems to be a slower process than the Pilot’s equivalent process. Not surprisingly, Windows CE systems have a typical Windows look and feel. Consequently the interface feels both comfortable and familiar, and if a user has been using Windows for a time, they will immediately feel quite at home on one of these. The handheld CE systems will also typically accept a type 2 PCMCIA card. This means that a variety of devices like fax modems can be easily installed. Palmtop CE systems accept industry standard Flash cards for expansion.
- 4. The Cassiopeia A11 Windows CE System Not surprisingly, devices from different manufacturers implement similar features in different ways: one device may have its buttons on the front, while another may put them along one side or the other. Similarly, the component quality varies from one manufacturer to the next, and this can affect the devices performance in many different ways. Obviously different CPUs and clock speeds will affect performance, but perhaps less obviously, the quality of the screen may be an issue too. Although we may initially view the screen only as an output device, in these devices it is frequently used for input too, and as such, it can and will affect performance. Given the same software on competing devices, the response of basic input functions such as handwriting recognition from one device to the next can be quite different. Operational Differences The most obvious difference between the handheld and palm sized systems is the absence of a keyboard on the palm sized devices. This gives the palm sized devices a unique look and feel, and in some instances provides an advantage over the handheld systems, and in other cases it leaves the palm sized systems at a distinct disadvantage. For example, both types of devices can be fitted with modems for communication. Some come equipped with a modem as a standard feature, and the Palm VII comes with wireless internet connectivity as a feature. As they also both have dial-up and email clients available, they can both be used while on the road for reading and writing email. However, my experience in using the palm sized devices for email has not been very satisfactory, as the interface – using the stylus and handwriting recognition to compose my message – is somewhat cumbersome. The handheld systems with their keyboards seem to be better equipped to handle this type of function. Similarly, the handheld systems are better able to utilize their (keyboard) input devices for tasks like word processing (and subsequent faxing) of your documents. This is an important distinction between these devices, at it may help define the platform that you will use as the target for your development work. For instance, if you decide that keyboard input is an essential part of your application, then the handheld systems with their keyboards may well be the way that you need to go. Conversely, if your need is for lighter weight and portability, then the greater weight and bulk of the handheld units might force you to develop with the palm sized devices as your target. Potential Uses But where these devices shine is that they are both light and portable, and they are capable of using their stylus (or a user’s finger) for point and click input. From our perspective, this makes them a potentially valuable tool that we can use as an alternate form of input for our desktop applications. As with any tool, the use and means of this needs to be carefully and thoughtfully considered, and naturally this will not be a one size fits all solution, but there are many areas where these could be used. Although I indicated earlier my personal preference that I not use these devices for such tasks as email, web browsing is potentially quite a
- 5. viable exercise. And with wireless web access, to perhaps a web based server application hosting a Jasmine ii application, all manner of application possibilities can be opened up. Consider for a moment some of the following type of applications: Online retail shopping Parts and inventory ordering Restaurant order taking and tracking. Optical and opthalmic examinations. Medical practitioner patient records. Dental charts. Rental property walk-through check-lists. In-store stock ordering Shopping list calculators Expense tracking Time billing Check-book balancing Police traffic citations Games To be considered as a viable application for these sorts of platforms, an application that has a need for in field gathering of data, preferably using a simple forms-based means of input, could be a candidate. The input might perhaps be in the form of a checklist, some push-buttons, or perhaps simply requires the input of simple data such as a few characters or numbers. Where there is a need for a great deal of custom input – such as name, address, phone number, SSN, etc, it may be a better approach to gather that data on the desktop. Show Good Form As we’ve seen, the individual types of units each have very different characteristics. Their form factors vary greatly, for example. As a result, when designing your applications you will need to bear in mind the form factor that your data input might require on the target device that you are developing for. For the palmtop side of your application, this is definitely a case of KISS: Keep It Simple, Stupid. To this end, you need to consider ways of simplifying the manner in which the data is gathered. What is the data that you’re gathering? From where does it come? What is done with it? What are its valid values? And most importantly, how is it gathered? In your analysis and design of the client application, it is important to consider the use of items that will simplify the input process for your users. Can you use a drop-down list? How about using a check-box for yes/no responses?
- 6. What about radio buttons for multiple choice options? If you can include these sorts of design elements in your palmtop application, then you will begin to simplify the process that your end users have to endure. The key is to minimize the work that they have to do. I think it is a fair comment to suggest that the less reliance they have on having to actually input their data, the better and more usable your application will be to and for them. A Trilogy In Four Parts. Well, in this case you really have very little choice but to write a number of different applications to make this happen. Because you’re writing an application that will run on at least two different platforms, you will need to write your application separately for each of those platforms. For instance, let’s say that you’re developing with a palm sized device as a target. Your two primary roles are to write an application for the palm sized device and a companion application to that one that will reside on the desktop system. If you’re also anticipating working with a handheld unit, then this too needs to be accounted for, and the different form factor needs to form a part of the system design. I have already mentioned that these devices connect very painlessly to a desktop system. They place their data into a backup repository on their host desktop systems. This process may be as simple as a single button press on the unit’s cradle. Once you have the data on your desktop though, you are faced with a problem. The devices – the handheld and your desktop PC – are by their very nature very different beasts. The data is stored in different manners and in different layouts. How are you storing your data at the desktop? Is your data being stored in a Jasmine ii database? Are you using CA-Visual Objects and native .DBF layouts? Consider that at some stage you will need to move the data from the handheld to the desktop. And back from the desktop to the handheld. Although the physical data transfer will occur during a synchronization session, you will still need to deal with the issues of translating the data from one format to the other. To handle this, you will need to write some form of data translation utility. This may be external to your business application functionality, or you might choose to embed it within one or the other, if not both, of the business applications. You might even choose to have it translate the data as a part of the communication function. And of course if you’re going to support both the Windows CE and the Palm OS platforms, then you need to do this for each of the physical device interfaces. The Trilogy: Book 1 The correct design of an application is never more important than it is with respect to these applications. We have, on the handheld devices, a limited amount of screen real estate within which we can design our application. Also, we have the situation where data might be updated on either the desktop, or the handheld, if not both. We need to ensure that the applications’ designs are correct before going any further. If there’s no clear specification of the tasks and the delineation of the applications’ respective relationships, then it may be pointless to proceed. A
- 7. clear understanding of the relationships between the various application components and how they relate to one another is vital. There are a few specific issues that require consideration when undertaking the design and development of the applications for the desktop side of the process. For instance, in order to maintain an appropriate set of data, relative to when and where (which environment) it may have been updated, the data records might need to maintain a record of this information. In the Palm OS, this is automatically taken care of for you, as it is an integral part of the design of the system. It tracks when fields are updated, so that it can synchronize data between the desktop and device based upon the most recently changed data. This occurs on both the handheld device, as well as within the companion desktop applications. However, this functionality is not a part of the standard database services that we use within our normal desktop applications. As a part of the normal database management methodologies, neither Jasmine ii, nor Visual Objects (within its native .DBF database services) provides this functionality. If this is a feature that you would like to implement, then you would need to design your database with this requirement in mind. While this may not be too difficult to do, it does need to be taken into consideration. And you would need to also consider the level of granularity within which to set your design parameters. Consider whether you might want to record (and therefore be able to track) updates at the record, or field, level. Once you’re aware of the issues that interfacing with your device entails you can then proceed to develop strategies by which the issues will be addressed, proceeding then with the development of your application for the desktop side as you would for any other application. The Trilogy: Book 2 This is where you will develop the application that resides on the handheld device. There are a number of tools available to assist you in developing your applications for these devices. For instance, Metrowerks CodeWarrior is available (and seems to be the product of choice) for developing applications for the Palm family of handhelds. Co- Pilot is a public domain emulator for the Palm Pilot is available, and it works extremely well. Microsoft has software development kits available for Visual Basic, Java and C++ to enable you to develop for Windows CE within the familiar Windows development environment, and leveraging your knowledge of the development tools available. Microsoft emphasizes the fact that you can utilize your existing Windows development knowledge and skills in performing development work for CE devices, and one has to admit that they do have a good point. If one is to look towards the embedded market as a target platform, then using VB as your development platform for your handheld product can make a lot of sense, but of course this does depend upon what your target platform will be. VB will get you nowhere when it comes to a Palm V. Microsoft also provides an emulation for the CE environment within the C++ kit for CE. This emulation only runs under Windows NT though, but it does support development under VB as well as C. So it is somewhat obvious that the choice of tools that you make will depend upon the target platform(s) that you select, and the environments in which you feel most comfortable developing within. One other tool that I want to mention is Pocket C. This is a very small compiler, that actually sits on the devices themselves. Using Pocket C you can write, compile and execute code directly on these devices. This product is shareware, and seems to me to have similar ease of use to the old GWBasic that came with DOS. It’s available to run on both the Palm and CE platforms. A major part of the key to developing a successful application will be how well you design and build the handheld’s application. If it is easy to use and provides good functionality, your users will want to use it, and this will be to your
- 8. collective benefit. And the key for this again comes back to your interface design: If you design carefully, utilizing the correct tools, design elements and metaphors on your palmtop system, then this will happen. Design the application poorly, such as using too much keyboard type data input when checkboxes or drop-down lists might be more appropriate, and the application will become a beast for your users to endure. If they don’t like using it, then they will surely find a way to avoid it. The Trilogy: Book 3 This is the area where you will need to deal with your interface issues. For example, you will need to consider which application contains the most up-to-date data? Is the desktop the source of truth, or is it the handheld? Perhaps both might be, with respect to different records. It may even be the case that one field on the handheld might be the source of truth, where a different field for the same data record may be more up-to-date on the desktop. Perhaps this may not be too important an issue for you, but this will depend upon your application’s specifications. With many turnkey applications I can envisage requirements dictating that the data will travel in just one direction – handheld to desktop or desktop to handheld - and in these instances this would not be a major issue. You simply download or upload the data and provide the mechanisms for translation from the source to the target. If, however, there is a need for two-way data synchronization, then you will indeed find that you have real issues to consider. You may need to consider implementing within your data structures a means of identifying, at least at the record, and perhaps even at the field level, the date and time at which certain (or all) data items were modified. Although the Palm OS provides for this to be tracked within its basic design, this has not generally been a part of the design of most desktop applications that I have seen. It needs to be dealt with, both from the storage perspective (where and how will it be stored) as well as the logistics of the actual data comparisons between the handheld and desktop data sources. It should be obvious that you will move the data between the different platforms at the time of connection / communication between the two systems. Less obvious might be the fact that if you don’t perform the comparisons, translation, and updating of the data as a part of this specific process, the data that you migrate between the applications and environments might not be what you expect. Consider the situation where you decide to validate and update the desktop’s data each time your users enter the desktop application. They go in, the application performs its validations and comparisons, and they do some work within it, updating some data in the process. You need to consider what to do with the now newly updated data, and formulate procedures to ensure that any such data is always available to the handheld at any time that communication is performed. This aspect really just boils down to what, specifically, will be the practical aspect of how the data will be taken from its back-up repository on the desktop into the desktop application? Or the converse: from the desktop application to the backup repository and thence to the handheld device. Should this be a separate standalone application, that can be run as an intermediate process, either prior or subsequent to the communication process, or should it be included in the desktop one? Perhaps it should be transparent to the user, or a separate option within your application, requiring user intervention? These are absolutely design questions that need deliberate and carefully considered responses. The decisions made will have a direct effect upon the integrity of your data, as well as the usability of the applications. The Trilogy: Book 4 If you’re really brave, then of course you will have decided to develop this application across multiple platforms.
- 9. On the handheld, you will be writing your applications to address a variety of platforms and form factors. You will be using CodeWarrior to create applications for the Palm devices, and one or more of the Windows CE development kits to develop applications for both the palm sized PC and handheld PC environments. For good measure – and probably because you’re a real masochist – you will even be writing your code to run on an embedded device that will have its own custom form factor. On the desktop things will be a little bit easier to deal with. You will be writing code in either Jasmine ii or Visual Objects, if not both, for your desktop application. Your desktop applications will need to deal - directly or indirectly - with the data conversion and timeliness issues. All of these tools are of course different, and while in many instances there are similarities, there will also be many areas where they will be either incompatible, and it is likely that you will need to duplicate some of your development effort across the various platforms and environments. You will also be dealing with different handheld and palmtop form factors, and perhaps custom embedded ones. This requires different form layouts and perhaps input methods. One other issue that I’ve not yet mentioned is that of different CPUs on the different CE devices. Not all devices are equal, and there are several different systems available. Although Microsoft provides compiler support for each of these devices, they do require the setting of different compiler switch settings for each such version that you wish to distribute. Such is the role of a developer. Jasmine ii Too. Jasmine ii has a very big part to play in your development efforts with respect to palmtop computing. Up to this point in the discussion, I have deliberately avoided too much discussion of the internet and web-enabled or web- deployed applications and how they affect, or are affected by, the implications of palmtop computing concepts. But it is obvious from the various development efforts, both at 3Com in their deployment of the Palm VII with wireless internet connectivity, and in Microsoft’s Windows CE products with both live and downloaded browser accessibility, plus email , that being web enabled will play a large part in the future life of this technology. With that in mind, we need to understand that with Jasmine ii, CA already have delivered to us an extremely powerful, and well focussed, technology solution to the issues at hand. Jasmine ii, out of the box, provides a robust, web enabled and fully object oriented development and storage solution. Given the right considerations, it will provide a perfect back-end business solution to problems presented to us, say, in handheld applications environments that demand web-enabled access to read or update your data. As an example, consider the typical shopping cart type of scenario. As we move into the future, more people will be accessing these types of applications from some form of handheld device. Our Jasmine ii applications are of course already supporting this functionality with respect to our more traditional desktop or laptop computing solutions, but, as already mentioned, the issues that relate to the different form factors of these devices assume significance to us as developers. And this is true from a number of different perspectives too. Although it is beyond the scope of this session to discuss in detail all of the web development issues relevant to palmtop computing, it is nonetheless appropriate to at least draw your attention to an issue that you need to be aware of. This will enable you, as you continue your Jasmine ii development efforts, to hopefully avoid some of the traps that await you. With traditional web development efforts it is essential that you at least test your development efforts across a closed intranet as well as the internet, and using not just different browsers (e.g. NetScape and Internet Explorer), but also using several different versions of each of these browsers. I have lost count of the number of times I have seen different – and unacceptable – results from organizations who should know better, but, due to their carelessness or laziness, they have not completed a few simple tests.
- 10. When developing web enabled applications for the palmtop, similar issues arise due to the different form factors that your clients to whom you will be serving your data to, have. To this end, you should already be querying your clients’ browsers to establish the type and version of their querying browser before formatting the data that you will be returning to them. For the future, you also should now be paying attention to this data and checking to see if, in fact, it might be a PalmOS, Windows CE Handheld, or Windows CE palm sized device, and formatting your response within Jasmine ii to suit the requested form factor. But Wait, There’s More. Let’s take this just a little further. Let’s consider the Palm VII, and perhaps our development within Jasmine ii of our corporation’s stock control, inventory, and warehousing system. Jasmine ii of course is an ideal platform within which such a development effort could be undertaken within the traditional client/server environment. Add the Palm VII, with its wireless interfaces, and a whole new sphere of development and application deployment opens. Now you have real time wireless data access and updating assuming real world potential as a very cost- effective solution to the problems that this type of development effort can generate. By placing the appropriate hooks into your existing Jasmine ii application, and by developing an accompanying Palm application with the appropriate communications protocols enabled, you now have a very effective warehousing solution using existing, and in-place, technology. The Future: It’s In The Palm Of Your Hand The market for palmtop devices is still very much in its infancy. The devices, as well as the languages and development environments, are still undergoing significant change. At the time of writing, the Pilot remains the market leader. Microsoft is not making the inroads into the market with Windows CE that it had hoped to, and is again repositioning some of its platforms and products. One cannot exclude the many other devices in this market either: they all offer functions and pricing that make them attractive to an end user. In attempting to predict where I might see potential uses for these devices, there really is no limit whatsoever in this regard. The CE devices already provide exceptional sound and graphics support. MP3 players are available for this platform, and I can foresee a time – not too far away - when solid state personal video players, for example, could be deployed on a Windows CE device. The technology to make this happen really exists today, but it’s more a matter of memory cost and availability that is preventing this from happening now. Web browsers of course are available for all of these devices, and the Palm VII provides a wireless interface to the internet. Wireless and paging interfaces are also available for Windows CE devices, and this is one area where I can foresee a great deal of potential for us, as application developers, in utilizing these devices in our development efforts. Jasmine ii and Visual Objects are both ideal platforms for development of the backend desktop partner and server applications that form the other part of the development effort equations for the deployment of the various types of handheld solutions that we can develop. If you’re developing vertical market software packages, it’s quite likely that within your sphere of expertise there are applications just begging to be written and deployed. If you’re an independent developer looking for a niche product, then it’s equally likely that with some creative thought you will be able to conceive and develop a
- 11. marketable product and bring it to the marketplace. In fact, if the vertical market is where you see that your business lies, there may well be some scope for you to investigate more fully the potential of embedded devices. The problem may well be one of choosing which horse to back, more than anything else. And that problem is yours. Gary Stark is a qualified accountant from Australia who moved into the world of Data Processing in the early 1980s. He has been using PC's for most of that time, and xBase since 1984, CA-Clipper since 1985. He has been consulting in the PC world since 1986, with projects completed for major Australian insurance companies and banks as well as for government and small business, and has also conducted training in Australia for dBase III, dBase IV and Clipper. In the US he has worked as a senior CA-Clipper analyst/programmer for the Gallo Winery, and for Dallas, Texas based Rent Roll Inc, a manufacturer of vertical market software for the real estate industry. He is currently based in Sydney, Australia acting as an independent software developer and consultant. He is a co-author of the SAMS publication CA-Visual Objects Developer's Guide, and has spoken at Technicons and DevCons in New Orleans, Birmingham U.K., Cologne Germany and San Diego, as well as to users groups in the USA, Europe and Australia. He has had articles published in Clipper Advisor and VO Developer Magazines, as well as numerous user group publications. He can be contacted on the Internet at gstark@RedbacksWeb.com. His home page URL is located at http://RedbacksWeb.com.