Mobile device programming by itself can be a serious test of software engineering skill, where coders are usually forced to work with a fraction of the resources available compared to the full .NET Framework. Screen area, processor speed, memory, and disk space available stand at a fraction of what one would generally get with a desktop computer. In fact, the .NET Compact Framework implements only thirty percent of the full .NET Framework, doing away with a large subset of the classes deemed to be unsuitable for the small footprint required of a mobile application.
In such a resource-tight environment, the wrong design decisions can often lead to an underperforming application, a clunky interface that irritates users, or worse—grinds to a halt when deployed in an enterprise scenario where hundreds of instances of the application need to exchange and sync data in synchrony.
As you progress through this book, you will find that the three-tier model recurs throughout all chapters. In each approach, you will learn how to think a few steps ahead and adopt designs that allow the various components you are building to fit in together elegantly.
We start this first chapter by exploring an overview of game developer Tomorrow Inc. and CRMLive.NET, a mobile customer relationship management suite that we will be building for this company. By the end of this chapter, you will obtain:
A first-hand look at how the end product you are developing will look
A general overview of the functional scope of CRMLive.NET
A look at the various designs undertaken in CRMLive.NET and why they work best in each scenario
An understanding of the various classes in CRMLive.NET and their interactions
An overview of the various .NET Compact Framework technologies you are going to use along the way
Tomorrow Inc. is a cutting edge gaming company of about 5,000 employees based in New York with branches around the world. They have recently developed a technology that immerses the gamer in a virtual world and are planning to launch their first MMIG (Massively Multiplayer Immersive Game), titled 'Rabbits from Hell' at a road show in New York and Tokyo at the same time.
The products include a virtual reality chair, simply known as 'The Chair,' which is basically an interface to the game that allows full unrestricted physical motion from the player. Used together in conjunction with a set of Virtual Reality goggles, it brings gaming realism to a whole new level by immersing the player completely in the game. The Chair is about the size of an armchair and after purchase, a visit will be typically arranged by Tomorrow Inc. technicians to deliver and install the product in the customer's home.
The road show is the biggest ever launch in the history of Tomorrow Inc., stationing about 100 salespersons at the event itself and another 50 on the streets for a total duration of three weeks. Tomorrow Inc. needs a suite of mobile applications: CRMLive.NET to cater to the needs of three different levels of staff—the salesperson, the boss, and the technician.
Tomorrow Inc. needs a mobile sales force application that will allow its salespersons to capture and manage leads, opportunities, and customers at the event. Before we proceed with the technical requirements, let's explore Tomorrow Inc.'s business a little further in detail.
A 'lead' is a sales term that applies to someone who shows an interest in the product, but how genuine he or she is about buying it has not yet been ascertained. It is usually the intention of the salesperson to convert a lead (a curious prospect) into an 'opportunity' (a serious potential buyer) and eventually into a buying customer.
At any one time during and after the launch of the game, there will be a mix of people from all three categories. There are the curious onlookers at the road show who casually enquire about the game. These people fall under the leads category. Then there are those who have been hounded by salespersons for weeks. They have the money and do show a genuine interest to buy, but need a little more coaxing. These are 'opportunities'. Finally, there are the frenzied young kids who have camped outside the road show hall since 2 a.m., having saved up their entire life savings anticipating the game release. These are undoubtedly buying customers.
Tomorrow Inc. is forecasting a huge flood of visitors to its road show, and has placed a strong emphasis on a lean UI design that can streamline quick data capture and access. The following list highlights the core requirements of this application in brief:
Capable of lead, opportunity, customer, and task management
Must have quick and responsive UI
Must support offline access to stored information (when a network connection is unavailable)
Must support strong personalization features
Must be highly secure—Tomorrow Inc. is anticipating the possibility of lost mobile devices and wishes to protect locally stored information
Must be capable of fast full-text search (searching within file attachment content and the entire database)
Salespersons may decide to share leads at any point in time. The application must be able to transfer leads from a mobile device to another easily
Must have dual database support—due to incredibly poor IT budget management, half of Tomorrow Inc.'s servers are hosted on Oracle, with the other half hosted on Microsoft SQL Server Enterprise. Extending this to the mobile device, this means that Oracle Lite Edition and Microsoft SQL Server Compact Edition support will be necessary
Authentication must make use of Tomorrow Inc.'s existing ActiveDirectory setup
Must provide Japanese-language support for users at the road show in Tokyo
The boss of Tomorrow Inc. travels across country frequently by train; his trips usually take him through areas with little or no Internet connectivity. His requirements are primarily centered on a mobile dashboard application that allows real-time monitoring of sales figures and Key Performance Indices (KPIs). His requirements include:
Must provide customizable dashboard views
Must have real-time access to the latest data from the server
Must be able to display information visually in the form of interactive charts and gauges
After the customer purchases a game account, the Tomorrow Inc. technician will need to make a visit to the customer's residence to install and deploy The Chair. Before that can happen, the following series of actions will first take place:
1. A data entry clerk at the Tomorrow Inc. office will create a job at the server.
2. Once a job is created, it will be broadcast to all technicians on the field over the Internet.
3. The technicians can then choose to accept a job via the mobile application. The accepted job is subsequently removed from the list of jobs at the server.
The core requirements for this application include the following:
Must be able to broadcast/push new jobs to individual mobile devices over the Internet even if these devices are offline
Must be able to propagate the technician's actions back to the server
Based on the requirements outlined in the previous section, we can roughly summarize the data flow of CRMLive.NET in the succeeding diagram. CRMLive.NET comprises three separate and distinct applications that tap into the same central data source.
The sales force application is the key application that provides data to fuel the rest of the system. You will notice from the diagram that mobile devices running the sales force application can also share data directly with each other. This is because salespersons at the event may decide to transfer their leads and opportunities to their colleagues. At the end of the day, all data entered through the sales force application is eventually synced up to the central database.
The support case system will make use of information captured from new customers, such as their residential addresses and phone numbers, to generate new jobs for the technicians.
The mobile dashboard on the other hand will periodically retrieve sales-related data (keyed in when new customers are created) directly from this central database every minute. This sales data is converted into visual charts for display on the mobile dashboard.
Each of these three applications access data in a different way. In all three scenarios, the central database can be accessed over the Internet as well as over an Intranet. We will also explore the different ways to protect data transmission and access throughout CRMLive.NET in the later chapters of this book.
Tomorrow Inc. is a cutting edge gaming company of about 5,000 employees based in New York with branches around the world. They have recently developed a technology that immerses the gamer in a virtual world and are planning to launch their first MMIG (Massively Multiplayer Immersive Game), titled 'Rabbits from Hell' at a road show in New York and Tokyo at the same time.
The products include a virtual reality chair, simply known as 'The Chair,' which is basically an interface to the game that allows full unrestricted physical motion from the player. Used together in conjunction with a set of Virtual Reality goggles, it brings gaming realism to a whole new level by immersing the player completely in the game. The Chair is about the size of an armchair and after purchase, a visit will be typically arranged by Tomorrow Inc. technicians to deliver and install the product in the customer's home.
The road show is the biggest ever launch in the history of Tomorrow Inc., stationing about 100 salespersons at the event itself and another 50 on the streets for a total duration of three weeks. Tomorrow Inc. needs a suite of mobile applications: CRMLive.NET to cater to the needs of three different levels of staff—the salesperson, the boss, and the technician.
Tomorrow Inc. needs a mobile sales force application that will allow its salespersons to capture and manage leads, opportunities, and customers at the event. Before we proceed with the technical requirements, let's explore Tomorrow Inc.'s business a little further in detail.
A 'lead' is a sales term that applies to someone who shows an interest in the product, but how genuine he or she is about buying it has not yet been ascertained. It is usually the intention of the salesperson to convert a lead (a curious prospect) into an 'opportunity' (a serious potential buyer) and eventually into a buying customer.
At any one time during and after the launch of the game, there will be a mix of people from all three categories. There are the curious onlookers at the road show who casually enquire about the game. These people fall under the leads category. Then there are those who have been hounded by salespersons for weeks. They have the money and do show a genuine interest to buy, but need a little more coaxing. These are 'opportunities'. Finally, there are the frenzied young kids who have camped outside the road show hall since 2 a.m., having saved up their entire life savings anticipating the game release. These are undoubtedly buying customers.
Tomorrow Inc. is forecasting a huge flood of visitors to its road show, and has placed a strong emphasis on a lean UI design that can streamline quick data capture and access. The following list highlights the core requirements of this application in brief:
Capable of lead, opportunity, customer, and task management
Must have quick and responsive UI
Must support offline access to stored information (when a network connection is unavailable)
Must support strong personalization features
Must be highly secure—Tomorrow Inc. is anticipating the possibility of lost mobile devices and wishes to protect locally stored information
Must be capable of fast full-text search (searching within file attachment content and the entire database)
Salespersons may decide to share leads at any point in time. The application must be able to transfer leads from a mobile device to another easily
Must have dual database support—due to incredibly poor IT budget management, half of Tomorrow Inc.'s servers are hosted on Oracle, with the other half hosted on Microsoft SQL Server Enterprise. Extending this to the mobile device, this means that Oracle Lite Edition and Microsoft SQL Server Compact Edition support will be necessary
Authentication must make use of Tomorrow Inc.'s existing ActiveDirectory setup
Must provide Japanese-language support for users at the road show in Tokyo
The boss of Tomorrow Inc. travels across country frequently by train; his trips usually take him through areas with little or no Internet connectivity. His requirements are primarily centered on a mobile dashboard application that allows real-time monitoring of sales figures and Key Performance Indices (KPIs). His requirements include:
Must provide customizable dashboard views
Must have real-time access to the latest data from the server
Must be able to display information visually in the form of interactive charts and gauges
After the customer purchases a game account, the Tomorrow Inc. technician will need to make a visit to the customer's residence to install and deploy The Chair. Before that can happen, the following series of actions will first take place:
1. A data entry clerk at the Tomorrow Inc. office will create a job at the server.
2. Once a job is created, it will be broadcast to all technicians on the field over the Internet.
3. The technicians can then choose to accept a job via the mobile application. The accepted job is subsequently removed from the list of jobs at the server.
The core requirements for this application include the following:
Must be able to broadcast/push new jobs to individual mobile devices over the Internet even if these devices are offline
Must be able to propagate the technician's actions back to the server
Based on the requirements outlined in the previous section, we can roughly summarize the data flow of CRMLive.NET in the succeeding diagram. CRMLive.NET comprises three separate and distinct applications that tap into the same central data source.
The sales force application is the key application that provides data to fuel the rest of the system. You will notice from the diagram that mobile devices running the sales force application can also share data directly with each other. This is because salespersons at the event may decide to transfer their leads and opportunities to their colleagues. At the end of the day, all data entered through the sales force application is eventually synced up to the central database.
The support case system will make use of information captured from new customers, such as their residential addresses and phone numbers, to generate new jobs for the technicians.
The mobile dashboard on the other hand will periodically retrieve sales-related data (keyed in when new customers are created) directly from this central database every minute. This sales data is converted into visual charts for display on the mobile dashboard.
Each of these three applications access data in a different way. In all three scenarios, the central database can be accessed over the Internet as well as over an Intranet. We will also explore the different ways to protect data transmission and access throughout CRMLive.NET in the later chapters of this book.
There are four different ways to deploy a mobile application, each with their own benefits and downsides. Before you decide on the type of model to use in your applications, let's take a look at them in further detail.
Applications deployed on a thin client model are accessed through browsers on the mobile device, called mobile browsers or alternatively, mini browsers, or wireless Internet browsers. They are essentially scaled-down versions of a full-blown browser. For instance, the default preinstalled browser that comes with the Windows Mobile operating system, Internet Explorer Mobile, is a mobile browser.
In the thin client model, application code and data are not stored on the mobile device. Just like traditional web-based applications, all the work is done at the server, and each page is served up on-demand as they are accessed from the mobile device. Thin-client applications, therefore do not require the installation of any additional software other than the mobile browser.
Thick clients run entirely on the mobile device and store both code and data locally. It must be installed on the mobile device prior to usage. Thick clients typically utilize a mobile database installed on the same mobile device such as Microsoft SQL Server Compact or Oracle Lite. It is common for thick clients to transfer its data from the local database to a remote and central database periodically so that it can be shared with other units. This process is called data synchronization.
The basic set of features you would find common across thick clients include:
A responsive and interactive UI
Ability to store data locally in a mobile database
Ability to synchronize data with a database on a remote server
A smart client, sometimes known as a rich client lies somewhere between a thin client and a thick client. Code is still stored locally on the mobile device, but data is stored on a remote server. Data (commonly in the form of XML) is retrieved from or updated to the server in an on-demand fashion whenever needed. There are various ways over which this data exchange can take place, the most common being web service calls, made over the SOAP (Simple Object Access Protocol) interface.
As smart clients still render the UI of the application locally, it has the benefit of a responsive and rich interface. However, smart clients do not have to worry about data synchronization as all data manipulation is done in real time (via web service calls). Smart clients are suitable for projects where:
Lastly, messaging-based mobile applications make use of services such as SMS (Short Messaging Service) and e-mail to drive the interaction between the user and the application. Like the thin client model, it does not require installation of any specific software other than the messaging application itself.
For example, a stock price enquiry service may involve the following actions:
A mobile user sends an SMS containing the stock symbol of the desired stock to a special number
This incoming SMS is processed by the server-side application, which then queries the database and retrieves the corresponding stock price for the symbol.
The stock price is then sent back to the user via SMS
The following table summarizes the various strengths and shortcomings of each type of mobile application:
|
Feature |
Thick client |
Thin client |
Smart client |
Messaging |
|---|---|---|---|---|
|
Requires installation/stores code locally on the mobile device |
Y |
N |
Y |
N |
|
Requires live network connection to the application server |
N |
Y |
N |
N |
|
Stores data locally and requires database on the mobile device |
Y |
N |
N |
N |
|
Allows application to access low level device functions |
Y |
N |
Y |
N |
|
Middleware requirements on the mobile device |
|
|
|
|
|
UI responsiveness |
|
|
|
|
|
UI richness/interactivity |
|
|
|
|
|
Ease of development |
|
|
|
|
|
Security |
|
|
|
|
|
Ease of application update and maintenance |
|
|
|
|
|
Ideal for high transactional volume |
Y |
N |
N |
Y |
|
Ideal for data transactions that are large in size (example : file attachments) |
Y |
N |
N |
N |
|
Ideal for complex input data (example : forms involving multiple field input) |
Y |
Y |
Y |
N |
|
Ideal for complex data input methods (example : digital signatures, barcode scanning) |
Y |
N |
Y |
N |
|
Application data latency |
|
|
|
|
|
Support for different operating systems/devices |
|
|
|
|
We will first take a look at the mobile sales force application and try to decide on a suitable client model. Looking at the earlier chart, a thick client model would best fit the requirements of this application due to the two key requirements of a responsive UI and offline access support.
You may have also considered the smart client model for this task, but there is no requirement for real-time data transactions in this application. A local database works better in this case because it eliminates network latency that would otherwise be present on the smart client (due to remote database access). Furthermore, a smart client model would not work well in areas without a network connection.
In the following sections, we walk through the main functionality of the application and outline the various .NET Compact Framework technologies that will be used in the process.
Tomorrow Inc. is anticipating a very large turnout at the road show; your users will need 'at a glance' access to key information as well as easy navigation across the various data entry windows.
To cite an example of a screen design that is the product of objective thought, consider the following Lead Details form:
You might be used to the idea that phone numbers, street addresses, and e-mail addresses are related and should all go together under a single Contact Details tab. Thinking objectively though, the salesperson would likely spend more time trying to follow up on a lead making phone calls rather than holding face to face meetings at the lead's address. In this case, it makes for a better design to have the phone number and not the address on the first screen.
When we build this application later on in the book, you will encounter other similar examples and learn how you can minimize the need to switch between tabs by placing the most commonly used fields in a single screen.
We will also extend the idea of objective design to the toolbars and menus in the application, covering best practices and how efficient use of these controls can help reduce on-screen clutter.
You may have also noticed from the previous screenshots that we have placed various icons next to the phone number fields. They allow the user to initiate a phone call or send an SMS directly using the number in the adjacent text box. This control, called the PhoneNumber control (shown in the following screenshot), is one of the various Usercontrols that we will build and reuse throughout this application.
You will also learn how to implement a simple checklist such as the Interested product(s) checklist shown in the succeeding screenshot using the .NET Compact Framework's Listview control.
To make things interesting, we will also feature a dynamic product list that can change any time at the remote server end. We will explore how a sync in the opposite direction (from server to mobile device) can be used to update global lists like this in your application.
As this is the first section dealing with data retrieval and manipulation, we will also get a first-hand look at the ADO.NET libraries and how we can make full use of the library to execute SQL queries against the local database to retrieve and manipulate sales force data.
We will cover data access and ADO.NET in full detail when we build a generic data layer inChapter 2 ,Building the Data Tier.
Transferring data between one mobile device and another is a common requirement in most enterprise scenarios and our sales force application is no exception. At any point in time, a salesperson may decide to hand over a lead to another colleague, possibly because he or she is not interested in following up on that lead.
Passing the lead to another person means that the receiving party needs to have the lead details and all other relevant data transferred to his mobile device. There are a few different approaches to data transfer, which we will cover in detail when the time comes, but for this application we will concentrate on using both Infrared and Bluetooth technology to transfer a lead record (in compressed XML format) directly from one device to another.
One of the reasons for building a task management module in this application is to allow the salesperson to manage tasks that are lead and opportunity specific. We will choose to implement the task listing using the .NET Compact Framework's DataGrid control due to its rich set of data formatting and data binding capabilities.
You will also learn the basics of using the DataGrid control in this section and how to get around its limitations. We will also cover the following subtopics:
How to data bind an ADO.NET data source to the DataGrid control
How to implement data paging at the SQL level
How to create columns with multiple sorting
How to handle data and cell formatting in the DataGrid control
Being able to search within the content of a file and entire databases via an incredibly simple UI comprising a text box and a button is indeed very attractive to any mobile user.
We will build a similar search engine for the sales force application. It will be capable of searching within file content, file names, and database records all at one go.
Microsoft SQL Server Compact and Oracle Lite needs to operate with a small footprint and, unfortunately, does not provide any full-text search feature. We will take it upon ourselves to create a simplified version of the full-text search service of our own. You will learn how to do the following from this exercise:
How to handle wildcard and binary searches (the ability to combine multiple search phrases with AND and OR conditions)
How to create column indices in Microsoft SQL Server Compact and Oracle Lite to improve the performance of full-text search queries
The following screenshot shows what the search results listing will finally look like in your application:
The mobile device is usually packed with useful hardware and operating system features like telephony, GPS, SMS, and Bluetooth, just to name a few. You can use the libraries in the .NET Compact Framework and the open source Smart Device Framework to access a large range of such functionality from your application.
Looking at an example of how this can work with your sales force application, consider phone number displays in your application. As you saw earlier, you will be creating a reusable PhoneNumber usercontrol that allows users to easily place a phone call or send an SMS message.
You will learn how you can call the Windows Mobile classes in the .NET Compact Framework libraries to achieve this. Most of what follows in this section refers to application features discussed earlier.
We will in fact extend this functionality further using the .NET Compact Framework Message Intercept classes to detect incoming phone calls and SMS. You will see how you can use these events to automatically generate historical log entries for every lead. This allows the salesperson to see a comprehensive history of all correspondence with a particular lead.
If you recall, we had to implement a lead and opportunity-specific task list in this application. What is also unique about this task list is that a copy of the tasks will be automatically pushed to the Windows Mobile Calendar. This allows you to tap into the reminder services in Windows Mobile to remind the user of an impending task. You will learn how to integrate with the Windows Mobile Calendar and Contacts services using the .NET Compact Framework libraries to achieve this functionality.
The benefits are twofold. In addition to not having to reinvent the wheel, this sort of integration opens up a host of functionality behind the scenes. For instance, by placing a copy of the lead- and opportunity-specific tasks in the Windows Mobile Calendar, the user will be able to eventually sync them to Microsoft Outlook on his desktop PC via ActiveSync. This feature is immediately available to your users without having to write any additional line of code!
We will also explore how we can transfer the lead details from one device to another directly using both the device's Bluetooth and IrDA (Infrared) capabilities. You will learn how you can efficiently package and compress XML-based data for transmission across these channels.
When new buyers sign up for a subscription to the game, Tomorrow Inc. needs their signature for record purposes. We can implement signature-capturing functionality using the Smart Device Framework's signature control. The signature will be captured as an image and saved together with the customer record in the database.
Note
InChapters 3 and6, we will cover more ground on file attachments and how they can be alternatively stored outside the database in the local filesystem. You will also learn of the different options available to the developer to sync files to a remote server.
Data synchronization for the sales force application is a mix of bidirectional (between mobile device and server) and unidirectional synchronization (mobile device to server only). The synchronization process is closely tied to the database systems that we are deploying for the application. For instance, Oracle Lite uses mSync technology while Microsoft SQL Server Compact uses the Microsoft Sync Framework.
InChapter 6, Data Synchronization, you will learn how to set up a mobile device and a server for data sync on these two databases. We will also go through the various approaches available to handle data concurrency and integrity during the sync process.
As part of Tomorrow Inc.'s requirements, we will ensure that our sales force application can support both the Oracle Lite 10g and Microsoft SQL Server Compact mobile databases. These two databases differ considerably in terms of their data types, SQL syntax, and synchronization processes.
As we've covered earlier on in this chapter, one of the biggest disadvantages of a thick client is the deployment process. Any subsequent updates to the application need to be redeployed to all devices.
We will mitigate this drawback by building and integrating a network-aware Auto Update service into our sales force application. You will learn how to create a service that can periodically check and download the latest updates from a remote site on its own without the need to cradle the device.
Our second application, the mobile dashboard, will be used by executive-level decision makers in Tomorrow Inc. on the move. The mobile dashboard will need to pull real-time data off the server over an Internet connection, which is then collated and presented on the dashboard in the form of a graphical chart. New data is periodically pulled down from the server every minute to refresh the chart displays.
You can see how a smart client model would probably work best in this scenario; a smart client allows you to render the charts you need on the device while keeping data on a remote server. The real-time nature of the data received will also ensure that your charts always display the latest information.
With "on the move" scenarios, you can probably expect Internet service to be choppy or simply not available in some areas during travel. We will therefore use stateless web service calls to the remote server to access data in real time. Using stateless connections in our application allows our dashboard to resume from where it left off after an Internet service disruption without having to request the user to perform any additional action (such as a re-login). The mobile dashboard service will appear seamless to the end user.
Note
A stateless web service call is a web service call that does not maintain any state information in between calls.
Web service calls are also, by default, blocking (synchronous) calls. What this means is that when a call is made to the server to retrieve data, your application will ignore all user input until the data is returned. This is certainly not acceptable, especially on a smart client!
InChapter 10, Building the Dashboard, when we build the dashboard, we will explore how we can make use of the multithreading features of the .NET Compact Framework to create asynchronous web service calls.
The planned dashboard design will look roughly similar to the following screenshot:
You will create the following charts in this application:
This line chart sums up the total revenue collected from the road shows on a daily basis. The process of building this chart will introduce the basic drawing tools in the GDI + API that you can use in your application for visual data display.
Our third and last application, the mobile support case application, involves tighter real-time collaboration between the server and the mobile units. We will use the .NET Compact Framework's messaging controls to build a messaging backbone across the server and the connected mobile devices so that Tomorrow Inc. technicians on the field can be instantly alerted when a new task is created in the server.
As all job-related data is stored and managed centrally on the remote server, the smart client model would be the best fit for this application. We stop short of using the thin client model because the construction of the messaging backbone will require client-side coding.
This application is also unique in that it can be regarded as 'push' technology, whereas the earlier two applications were not. 'Push' technology, similar to the common meme 'push e-mail,' is proactive and means that newly available data is automatically pushed to the mobile device without the mobile device requesting for it.
Part of Tomorrow Inc.'s requirements for this application include instant notification to all mobile device units when a new job is created on the server.
Note
MSMQ(Microsoft Message Queuing) is a technology that allows an application to send a message to another application (not necessarily on the same machine) even if the other application is offline. These messages are stored in a queue and delivered when the targeted application resumes operation.
As you start building this application inChapter 11, Buliding the Support Case System you will learn more about the intricacies of the MSMQ service and how you can write code to send and receive messages using the Messaging APIs.
From this chapter we've learned that there are four common client models used in mobile development, each with their own strengths and weaknesses. In this book, we will build three applications that cover the two models that utilize the .NET Compact Framework—thick and smart clients:
The mobile sales force application is a thick-client application that allows users to key in data offline and to sync it with a remote server at a later time.
The mobile dashboard application is a smart-client application that will utilize stateless web services for data retrieval due to the limited availability of its Internet connection.
The mobile support case application demonstrates how a common messaging backbone can be built on top of the MSMQ framework to provide instant notifications to mobile devices.
Your journey through this book will also ultimately walk you through three important aspects of mobile application development:
Learning the various methods of data transmission between the mobile device and a remote server and between mobile devices themselves
Learning the various ways to integrate Windows mobile and the device itself to provide an interactive and seamless solution
Designing an adaptable three-tier and MVC-based solution that makes future maintenance of the application easier.
With this overview, we have enough context to begin building the application. We will start by creating the data layer for the mobile sales force application in the next chapter.