net developer's journal sneak peek - sys-con.com's archive of ...

FeatureEnterprise .NET for Smart DevicesIntroducing the .NET Compact Frameworkand Smart Device Extensions for VS.NETEVERYWHEREBY CHRISTIANFORSBERG& ANDREAS SJÖSTRÖMHOMEDESKTOPSERVER22if you want to extend yourexisting systems as wellas your knowledge of.NET development whilebuilding solutions for smart devices,the upcoming .NET CF (CompactFramework) and SDE (Smart DeviceExtensions) are definitely the way togo. In this article we provide anexample of how to implement amobile application that can work asan extension to your existing systems,and also show you how toextend your knowledge of .NETdevelopment.It’s perhaps more true than everthat mobile solutions rarely standalone. Most consumer-orientedapplications are created to work inan offline or disconnected mode,but for enterprise solutions theincreasing connectivity of newdevices opens up enormous possibilitiesfor online and “sometimesconnected” applications as well.When looking at real-world businessscenarios and the capabilitiesof current mobile devices, it’s obviousthat the options are greater thanjust offline or online. Specific userrequirements such as “how often?”and “at what bandwidth?” shoulddetermine where on the scale fromoffline to online we need to be (seeFigure 1).The more a mobile application isconnected, the thinner it can befrom an application logic and localstorage perspective. The less it’sconnected, the higher the demandon the application logic and localstorage. A typical online mobileapplication is a Web application targetedat smart device browsers likeInternet Explorer for Pocket PC.With a Web application there are nodeployment issues for the device, asthe browser is already in place.However, most other connectivityoptions (from “auto-connected” allthe way to “never connected”)require you to have a custom applicationrunning on the device.The need for connectivity alsoimplies that we’re most often talkingabout extending existing systems toanyplace. Many workers are currentlytied to a desk with a PC on awire. They would like to be free togo wherever they want, yet still beable to perform their duties. Is itasking too much to help those poorpeople out?Consider Some ExamplesLet’s take a simple scenario likereporting time. Many mobile workershave to specify how they spendtheir time during their work hours.This is a common task in an enterpriseenvironment, and many of usare familiar with the pain of “re-creating”the past week during theweekly reporting – late Sunday night– into our company’s central timereporting system. Why? Because wehave to wait until we find a PC that’swired to the company network.What if we could do it anyplace?And since we don’t need to do theactual reporting more than weekly,it would fall into the category “seldomconnected” (see Figure 1).What if we didn’t actually have to beconnected when we do it?Another issue is how we can helpthose workers get the new tools ofthe trade. What if we could use thesame knowledge that we alreadyhave in building our enterprisesolutions? In the not too distantfuture, most of those solutions usingMicrosoft technology will be developedfor .NET, and therefore itwould be great if we could extend.NET and .NET development skillsto build those solutions for mobiledevices. As you may already know,you’ll soon be able to do just that.Build a Business CaseIn defining how we can benefitfrom turning paper-based processesinto mobile solutions, the keywordsare speed and quality.First of all, since time is money,we want to save time. By savingtime we can get an instant paybackon the investment in most mobilesolutions. We can save time for themobile worker, and most probablyalso for the back-office personnelwho now enter submitted paperdata into a system. Perhaps mostimportantly, we could also save thetime between data entry and datausage. For example, if the timereported was submitted each dayinstead of each week, we couldexpedite invoices related to thattime.Second, we’ll collect the data at thesource, gaining speed in our businessand improving data quality. Writingdata on paper, then passing it tosomeone else to read and enter into asystem is probably the most certainway to achieve poor-quality data.Higher quality most often translates tosaved time, and also to improved relationshipswith customers, partners,and even employees.Preview Issue • dotnetdevelopersjournal.com