Pocket PC magazine, Apr/May 2004

by MS Reader version $5. 99

  It is clear that mobile technology is not going to go away. Mobility has arrived and neither device users nor security professionals can ignore its impact on corporate infrastructures. But mobility does not need to be feared, or limited by security concerns. Organizations can ensure the safety of their information in the wireless world by following industry best practices and enforcing a comprehensive mobile security policy (Fig. 2). With today’s rapid adoption of mobile devices and the growing number of unprotected public hotspots, the sooner you adopt a handheld security strategy, the safer your prospect list—and your job—will be.

  (above) Fig. 2. Bluefire’s Enterprise Manager centrally controls devices, defines security policies, and deploys security rules.

  * * *

  Tom Goodman is VP of Operations for Bluefire Security Technologies and has more than 25 years of information security and wireless expertise. Contact him at tom@bluefiresecurity.com.

  DIRECTIONS

  by Chris De Herrera

  Windows Mobile Wish List

  What is needed in the next release

  Lately I’ve been thinking more and more about what Microsoft needs to focus on when making additions and improvements to future Pocket PCs. As part of that, I thought that a list of the most nagging issues affecting Windows Mobile deployments in the enterprise would help users understand the limitations of these devices. Also, I hope Microsoft considers these issues in future developments for the Pocket PC.

  Support for additional Calendar, Contacts, and Tasks folders: Every major corporation has a public folder for each employee’s Calendar, Contacts, and Tasks information. Also, there are many executive assistants and other staff who need two calendars. Right now there is no support in Windows Mobile for synchronization of these additional folders.

  Native support for Exchange: If you want the Pocket PC to be adopted in the enterprise, make it as easy as possible to access Exchange. Right now the fact that the overworked Information Technology staff needs to configure both the Exchange server and the Pocket PC client means that unless the Pocket PC is viewed as a real strategic asset, the configuration won’t get done. Even having a simpler online client that did not require reconfiguration of the Exchange Server would allow many users to maximize their Pocket PC’s capabilities.

  Built-in printing support: Right now, Pocket Word, Pocket Excel, and other applications on the Pocket PC know nothing about printing. So in order to add printing functionality to their applications, third-party developers have to decode these file formats and then write their own proprietary print engines and drivers. Moreover, with built-in printing support, salespeople could more easily print orders in the field to meet customer needs.

  Support for seeing and editing Office documents: Pocket Word and Pocket Excel are poor substitutes for the desktop versions. I’d love to see the option to view desktop Word and Excel documents (including tables and graphs) on the Pocket PC so that you could read e-mail attachments when you were away from your desk. Also, all business users need to edit documents on a regular basis. Currently, a .doc or .xls file can lose vital formatting information when edited and saved in Pocket Word or Pocket Excel.

  Support for Acrobat: Adobe’s Acrobat format dominates common forms in the enterprise. Clearly Microsoft needs to include in-ROM support for viewing Acrobat files to meet enterprise customers’ needs.

  Better Web browser support: Users need to use their Pocket PCs to access their bank and stock Web sites. Windows Mobile still supports an older version of Internet Explorer. Also, the implementation of JScript is weaker than it is on the desktop. The ideal functionality would be such that the Web designer did not need to do anything extra to support both the desktop and the Pocket PC in the enterprise for both intranets and extranets.

  Fix ActiveSync: It just has to work the first time and every time! And there needs to be a way to control what employees put on their devices. The Pocket PC can’t be let loose in the enterprise without controls over which files, e-mail, calendar, contacts, and tasks users put on their Pocket PCs. Right now there is no easy way to control this, either by preventing users from changing ActiveSync’s settings or by permitting the administrator to control it centrally. We also need useful error messages, logging of synchronization, and a list of unresolved items from ActiveSync so we can understand what’s going on under the covers.

  Management tools: How does IT centrally apply patches and install applications as well as ensure that system controls are in place? Without third-party software, someone has to touch each Pocket PC to ensure it is configured correctly. Yes, there is support for configuring network connections, but that’s just a fraction of the settings that need to be configured on the devices. Furthermore, there is no option to prevent users from changing the settings. Without this level of control, additional support calls for the Pocket PC will be inevitable.

  Networking tools: How could I go through this list without mentioning the lack of networking tools? Currently users cannot easily confirm connectivity with their network or Virual Private Network (VPN), and they need to be able to do this to use the Pocket PC effectively. There really needs to be a Pocket PC utility like the Zero Configuration utility in XP, which allows for the release/renewal of an IP address and the ability to see the TCP/IP settings. Ideally, Ping would be ported to allow confirmation of connectivity.

  Versions coming every year. There needs to be stability in the software so that it is not would not be necessary to upgrade both the Pocket PCs and ActiveSync on the desktop PCs and retrain everyone every year. Ideally, all users should be kept at the same software version for two to three years and still get new equipment as needed. It’s really disruptive when you’re working on a custom development project to have to install additional software to deploy programs such as Visual Basic.

  As always, these represent my personal opinions and do not represent any indication of what Microsoft may be doing in the future. These are my musings on what I see missing in the Pocket PC for enterprise customers. If Microsoft implements these recommendations, the Pocket PC will be the most complete client for the enterprise. n

  * * *

  Chris De Herrera is a special correspondent and contributing author for Pocket PC magazine. He maintains one of the best Windows CE sites (http://www.cewindows.net) and discussion boards (http://www.cecities.com). Chris is a Microsoft PocketPC.COM Contributor on Microsoft’s Windows CE Web site. Chris is a Microsoft Most Valuable Professional for Windows CE and writes articles on Windows CE for his own Web site and for other mobile computing publications. Chris regularly participates in various newsgroups (including Microsoft.public.windowsce). You can reach Chris at TechEd@CEWindows.net.

  How Much for the Beemer in the Window?

  How to create a car lease payment calculator for the Pocket PC using .NET Compact Framework

  by Russ Nemhauser

  I’ve learned (the hard way) that knowledge is power when you go to lease cars. For the past couple of years I have been tooling around town in my wife’s Turbo Beetle (head ducked down low and trying to look as cool as possible) because we became a one-car family and ditched the more expensive one. We still have thirteen more months left on the lease, and by the time it ends we will have sent in almost 90% of the car’s purchase price—for a four-year lease. Looking back on things now, we could have saved ourselves about $70 per month if we’d only gone to the dealership prepared. Having a lease payment calculator that you can take with you to the dealership can be a useful weapon...I mean, tool.

  Normally when you walk into a dealership and choose your model and accessories, the salesperson will draw two intersecting lines on a piece of paper (if they’re not already pre-printed there) to make four boxes, each of which represents an aspect of the deal: cash down payment, trade-in value, price of the new car, and monthly payment. Each one of these is a way for the salesperson to lead you into a deal. It is very important that you fight for every cent in each of these four boxes, but you’ll do best t
o base your fighting position on fact. Remember, the salesperson (usually) knows what you know. For instance, it won’t do you much good to tell them that you can trade your car in down the street for $15,000 when the Kelley Blue Book Web site (http://www.kbb.com) lists its value as $12,000 in excellent condition. The salesperson can use the Blue Book too! To get an edge, you need to know what the salesperson knows—and surprisingly few lease customers do.

  Writing a simple .NET CF app

  The .NET Compact Framework opened the door for .NET developers to start writing applications for smart devices. I had a Pocket PC sitting in its cradle for months because I never found it necessary to have my entire contact list or calendar on my person (unlike people in other industries, such as sales). When I downloaded the Compact Framework and started writing my first application, I began to realize how useful the dusty device could become. I was already familiar with VB.NET and C#, and deployment was a breeze. That reduced the learning curve enough for me to be productive with it very quickly.

  Those who do not own a Pocket PC can also develop applications based on the Compact Framework if they have Visual Studio .NET 2003. It comes with a configurable emulator that allows you to run your application just as if it were on a real device. The emulator’s memory size can be jacked up by going to Visual Studio’s Options dialog, so you have the potential to run some pretty hefty applications. By making use of SQL CE you can run database applications as well.

  To show just how easy it is to write useful applications for mobile devices, we’ll create a lease payment calculator for the Pocket PC using Visual Studio .NET 2003. Start a new Smart Device Application project in Visual Studio. Call your application LeaseCalculator. Be sure to choose Pocket PC as your platform and Windows Application as your project type in the wizard that follows.

  By default you should have one Windows form in your application called Form1. Change its file name to frmPayment.vb; then use the form’s Properties window to change its name to frmPayment.

  The next thing we’ll need is the calculator engine itself, so add a new Class to your project called Lease.vb. This will be a very simple class and will definitely not contain all the properties and methods necessary to represent a car lease, but we’ll encapsulate the lease payment logic in its own class anyway to make it easy to extend its functionality later if you choose. You may also want to provide a different user interface for your payment calculator in the future and having the calculation logic in a class makes it very portable. The properties we’ll be creating are by no means intended to be representative of the best way to code but rather just to work. Validations and error-checking have been purposely left out for simplicity’s sake.

  There are five variables used in the formula I have chosen for this application. These are:

  Net Capitalized Cost: The “final, final” price after all down payments, trade-ins, concessions, specials, and incentives.

  Money Factor: What some people refer to as the interest rate, since you can multiply this number by 2400 to arrive at an annual percentage rate.

  Residual Amount: The value of the car at the end of the lease term.

  Term: The number of months in the lease.

  Sales Tax Rate: Your area’s sales tax percentage.

  We’ll represent each of these variables as a property in our Lease class. Add the following code to your class.

  Private mCapCost As Single Public Property NetCapitalizedCost _ As Single Get Return mCapCost End Get Set mCapCost = Value End Set End Property Private mFactor As Single Public Property MoneyFactor As _ Single Get Return mFactor End Get Set mFactor = Value End Set End Property Private mResidual As Single Public Property ResidualAmount As _ Single Get Return mResidual End Get Set mResidual = Value End Set End Property Private mTerm As Integer Public Property Term As Integer Get Return mTerm End Get Set mTerm = Value End Set End Property Private mTax As Single Public Property SalesTaxRate As _ Single Get Return mTax End Get Set mTax = Value End Set End Property

  The next few properties we’ll add will be ReadOnly. They’ll be the results of calculations necessary to calculate our payment. The first portion of the payment comes from the depreciation of the vehicle. That’s why we needed the Net Capitalized Cost and the Residual Amount. We’ll create a new property called MonthlyDepreciation.

  Residual amount can sometimes be difficult information to beat out of a salesperson. When I went to help my mother-in-law lease her new car (after I smartened up, of course) the salesman told us that the residual after 48 months was a required 50% of the car’s suggested retail price. I ran the numbers using this lease calculator and found that the monthly payment he was trying to sell us was about $35 more than what it should have been for a residual of 50%. I asked why that might be. He then tried to tell me that actually the residual could be 46 or 47%! I reminded him that a half hour earlier he had said that the residual was going to be 50% or there would be no deal. He finally came back with a payment only $2 or $3 higher than my calculation.

  Public ReadOnly Property MonthlyDepreciation As Single Get Return (mCapCost - _ mResidual) / mTerm End GetEnd Property

  The next portion of the payment is based on the interest that is charged. It is calculated by taking the Net Capitalized Cost and adding (yes, adding) the Residual Amount. This total is then multiplied by the money factor to arrive at our interest payment. We’ll call this property MonthlyInterest.

  Public ReadOnly Property MonthlyInterest As Single Get Return (mCapCost + _ mResidual) * mFactor End GetEnd Property

  The third and final portion of the monthly payment is the sales tax. This amount is equal to the sum of the two previous portions of the payment we already calculated times the sales tax rate. Call this property MonthlySalesTax.

  Public ReadOnly Property MonthlySalesTax As Single Get Return (MonthlyDepreciation + _ MonthlyInterest) * mTax End GetEnd Property

  The sum of these three amounts should be fairly close to what a car dealership would calculate based on the same input variables (except Ford, which uses a more complex formula which normally results in slightly higher payments). The last property we’ll add to our Lease class will return this amount. We’ll call it MonthlyPayment.

  Public ReadOnly Property MonthlyPayment As Single Get Return MonthlyDepreciation + _ MonthlyInterest + MonthlySalesTax End GetEnd Property

  Creating the user interface

  Now that our engine is complete we’ll need a way to interact with it. Open frmPayment in design mode and add the controls as listed (Fig.1).

  (above) Fig.1: List of controls to be added to frmPayment.

  When all is said and done your form should look similar to the following image. For the sake of appearance you might want to give your form a caption (Text) property of “Lease Calculator” or something other than Form1, as I have done here.

  What our form needs now is a Lease object associated with it. That way we can easily apply the input values from the user. Add the following code to the declarations section of your form (for example, right below the declarations for all the controls we just added):

  Private myLease As New Lease

  There are different approaches we could take here. We could add code that would update the properties of our Lease object as the cursor left each TextBox. This approach would also allow us to validate the data entered by the user (e.g., check that a number was entered where a number was expected). In the interest of getting this bad boy up and running, we’ll just add code to our button’s Click event that will do all the work, and you can decide later if you want to polish this thing off in your own way.

  That said, add the following code to your Form. We will assume (just for the sake of this article) that all input by the user is valid and that we can simply return our calculation to the lblResult.Text property.

  Private Sub btnCalc_Click(ByVal _ sender As System.Object, ByVal _ e As System.EventArgs) Handles _ btnCalc.Click myLease.NetCapitalizedCost = _ Convert.ToSingle(txtNetCapCost. _ Text) myLease.MoneyFactor = Co
nvert. _ ToSingle(txtFactor.Text) myLease.ResidualAmount = _ Convert.ToSingle(txtResidual.Text) myLease.Term = Convert. _ ToInt16(txtTerm.Text) myLease.SalesTaxRate = _ Convert.ToSingle(txtTax.Text) lblResult.Text = myLease. _ MonthlyPayment.ToString() End Sub

  Golden rules for killer deals

  If all worked as it should, you are now enjoying the fact that you can calculate fairly accurately what you should be paying for an automobile lease based on the five common variables. Your Lease Calculator application should look something like the image below if you run it inside the emulator.

  It is, of course, of little use unless you use your bank, the Kelley Blue Book, the NADA Guide, or one of the common automobile informational Web sites to find out what a fair price for your trade-in and for your new car would be.

  It took me a while to learn how to stand up for myself when doing a car deal, but since I finally started doing that I have closed some really killer deals for friends and family. There are three golden rules to keep in mind when you’re ready to deal:

  Remember that everything that comes out of the salesperson’s mouth is always geared toward maximizing the dealer’s (and the salesperson’s) profit. Sometimes they are more lenient on the last day of the month, but that doesn’t change the nature of the beast.

  Know your numbers. Know precisely how much your car and the new car are worth.