Wireless Content Types
The Development Process
Developing a wireless Internet application is very similar to and at the same time, very different from, developing a desktop Internet application. It is similar in that they share a common architecture and often use the same technologies for content generation and enterprise integration. It is different in that the client interface and navigation, along with the hardware on which they are being executed, are not at all the same. When you add in the issues introduced by the wireless network, such as low bandwidth, high latency, and sporadic coverage, you end up with an entirely new set of technical and physical challenges that have to be addressed.
Complicating the process is the fact that you are often working with new technology and standards that are not well understood. This is especially true when it comes to the wireless communication protocols, markup languages, device types, and development environments. When creating wireless Internet applications, you will do most of the development and testing on your desktop, often using device emulators to simulate how the application will actually perform when deployed. Once you are comfortable with the simulated application, you will then need to establish the required network connectivity to test it on real devices, over the wireless networks on which you are going to deploy.
All of these steps require careful analysis and planning. In order to create a successful wireless application, you first will need a good understanding of what the application is supposed to do, then design it in such a way that it meets those requirements without being cumbersome for the end user. In this section, we will discuss the stages of the wireless Internet development process, which is depicted in Figure 12.1.
Figure 12.1: Wireless Internet application development cycle.
Needs Analysis Phase
The needs analysis phase may be the most important of the entire development process. This is where you determine the goals of the application. Based on the information gathered here, you can then move on to designing and implementing the application itself.
Questions to Ask When Researching User Requirements
Chapter 4, "Mobile Application Architectures," discussed the two main types of mobile and wireless applications: smart client and thin client. If you have not already determined the type of application required for your application, this is the time to do so. Based on this decision, you will be presented with different architectures, technologies, and development and deployment options. In order to make an informed decision, you will want to answer some key questions, namely:
-
Who are the end users of this application?
-
Do the target users have specific device requirements, or can the application provider dictate those?
-
What is the overall goal of this application?
-
What data integration is required? Does the user require data access at all times?
-
Does this application require wireless connectivity? If so, what type of wireless access does it require, in which geographies?
-
What are the primary usage scenarios for this application?
Finding the answers to these questions, along with others that will emerge, will allow you to determine the type of application that you should develop. Some of the key indicators that will help determine whether a thin client application is required are: the wireless data access, target users, and the typical usage scenarios.
Things to Consider During Needs Analysis
During the needs analysis phase of the development process, we are going to focus on topics related to developing thin client applications. If you are interested in the development process for smart client application, see Chapter 8, "Smart Client Development."
Once we gather information about the following items, we can make an educated decision as to the solution that is most appropriate, including the device type(s), wireless network provider(s), and development platform to use.
Wireless Access
Because thin client applications do not store any data on the client device, and because the content is downloaded dynamically, wireless connectivity is required to use the application. This should be one of the first items you investigate when developing thin client applications. You will need to determine which wireless carriers provide coverage in the area in which the application is being deployed. For example, in urban centers, you will most likely find that you will have several options for wireless access; but when deploying in some of the more remote, rural locations, you may have only one option or, in many cases, no options. In the single-option case, you will have to decide if it is acceptable; and if it is not, a smart client architecture may be more suitable for your application.
In addition to wireless coverage, wireless penetration may also be a concern. Often, in locations within areas that have coverage, the network cannot penetrate the physical surroundings. Examples include confined areas such as subways and office buildings, as well other places such as airports and train stations.
Finally, bandwidth of the network can become an issue. As discussed in Chapter 1, "Welcome to Mobile and Wireless," and Chapter 3, "Wireless Networks," pre-3G wireless networks have very limited bandwidth, restricting the amount of data that can be downloaded in a reasonable amount of time. When designing an application, you will need to keep this in mind, and keep the optional content, such as graphics, to a minimum.
End User
Who is the target audience for this application? Is the application aimed at the consumer market, where you will have limited control over the devices and wireless networks being used; or is it a corporate application, where the devices and connectivity are determined and provisioned by a central source? The target audience of the application will influence many decisions that you have to make. If you have some level of control over the technology the end user will be utilizing, it will make the development and testing process much easier. Trying to build a solution that will work on all of the device/network combinations is a daunting task, although there are many commercial solutions available to make this job easier, as covered in Chapter 14, "Wireless Internet Technology and Vendors."
If you are building an application for an audience for which you can influence the device being used, you will want to consider the users' level of technical background and comfort level with wireless applications. If the audience is not comfortable with, say, pen-based user input, you will want to target devices that have QWERTY keyboards or other data input mechanisms. Similarly, the geographies in which this application is going to be used will dictate which wireless network provider is best suited for proper coverage.
As stated in the introduction in Chapter 1, this book is primarily aimed at those developing m-business corporate applications, although much of the information also directly applies to the consumer market. In either case, keeping the requirements of the end user in mind will allow your applications to reach their full potential.
Application Goals
Determining the goal of the application will provide you with information on where you should focus your efforts. Most successful wireless Internet applications have a very specific goal. They are not often used for generic Web-surfing or information-gathering purposes. Determining what the desired functionality is, and producing an application that meets it, are important objectives. If the goal is to provide timely financial information, for example, the application should be designed to enable the user to access this information quickly and efficiently, without having to navigate through multiple pages. At the same time, if the application is designed for remote information gathering, a device should be chosen that allows for rapid data entry. In this scenario, a cellular phone most likely would not be adequate, whereas a Pocket PC or Palm device might be.
Beyond the user interface, other factors may come into play. The data being requested may reside in a variety of enterprise systems. At this point, the means of enterprise integration and security concerns will be of paramount importance. For each application being developed, you should have a clear set of goals against which the success of the application can be judged.
Usage Scenarios
Understanding how and when the application will be used will have a substantial impact on the device chosen and the application design. If access to the application and the data it provides is crucial to job performance, as in the case of a field service worker, then researching the options for wireless connectivity and running a pilot of the application are recommended. If the application is going to be used in an environment where it may get knocked around a lot, or where it can quickly get dirty, it may make sense to choose a ruggedized device with a suitable data input mechanism. In this case, a tablet-based device that does not have small keys would work well. Similar consideration should be given to the display of the data. If large amounts of data are going to be retrieved and displayed, a device with a larger form factor, such as a PDA or Tablet PC, will most likely be better than a WAP phone.
Apply the same type of logic to the level of wireless connectivity required. If the application is going to be used in a fixed location, implementing a wireless LAN solution would be more manageable and cost-effective than relying on a wide area wireless network.
Content Source
The primary goal of most wireless applications is to extend the reach of enterprise information to remote workers. For wireless Internet applications, this enterprise information is often in the form of an existing Web application. It is unrealistic to expect to be able to display an entire Web application on a wireless device; instead, the most useful parts of the application must be utilized. This is not a trivial task. Internet applications aimed at desktop users typically use HTML, as well as client scripting languages such as VBScript or JavaScript. Because most wireless microbrowsers do not support these languages, they have to be transformed to the appropriate language for the wireless client.
Existing Web content is not the only data being used for thin client applications. For many corporate applications, the wireless Internet application is developed with direct integration to the same business logic used by the Web application. By integrating at this level, the content for the wireless application can be customized specifically for wireless users, thereby avoiding the challenges of transforming desktop applications. Experience has shown that this type of development—that is, creating the wireless applications in parallel with the desktop applications—leads to a better experience for the wireless user and fewer headaches for developers.
Design Phase
Once you have completed the needs analysis, you will have a clear idea of the requirements of the ultimate solution. This does not mean that you will know exactly which device or network will meet your needs, but at least you will know what you are looking for. Ideally, you will have limited the choices to a few wireless devices, wireless networks, and markup languages that will meet your criteria. Predicting which technology will be best for your application will be very difficult if you have not had any experience using it. So at this point, you should keep an open mind when making the final decision as to which technology to implement. Typically, a developer may try a couple of possible solutions before feeling comfortable making a final decision. This approach makes sense. If you do not have experience developing a WML-based WAP application, for example, you will have difficulty knowing whether it is better suited than an HTML-based application. (To learn more about the leading markup languages used in wireless Internet applications, see Chapter 13, "Wireless Languages and Content Generation Technologies." There you'll find an overview of the leading wireless markup languages, as well as the content delivery technologies that are available.)
During the design phase of the development cycle, you have a chance to design each layer of your wireless application. You can focus on the issues that are often present in building these applications, such as creating an effective user interface for targeting multiple devices and microbrowsers, developing the server-side business logic, and integrating with enterprise data sources.
User Interface
The user interface is the most scrutinized part of a wireless application. Comments such as "WAP is dead" have led people to believe that the technology behind the wireless Internet is not sufficient for creating effective wireless applications. This viewpoint does not reflect reality. In most cases, wireless Internet applications have not succeeded as expected because of application design. True, limited devices capabilities, low bandwidth, and high latency of wireless networks have contributed to the slow adoption of wireless Internet applications, but even if these aspects were improved, the wireless Internet might not thrive if certain fundamental technical design issues are not addressed.
Latency
Anyone who has used a wireless Internet application has been frustrated by the wait time involved with downloading applications. Very often, this delay is incorrectly blamed on the low bandwidth of wireless networks; in fact, most often, network and application latency causes the delay. The amount of content it takes to fill the screen of most wireless devices is quite small, meaning that even slow wireless networks, with download speeds hovering around 14.4 Kbps can get the content within a few seconds. This amount of time seems reasonable. Unfortunately, the actual time that users wait for a given Web page may end up being in the tens of seconds, if not minutes, because of network latency.
In order to combat this delay, your application design will have to minimize roundtrip interactions with the enterprise server. Each request ends up traveling through the public Internet, hopping through random routes, before it reaches its destination. This adds latency. So keeping the number of requests low allows the user to interact with the application without having to constantly wait for new data to download.
Human Interaction
The best wireless thin client applications have very few screens to navigate, and can be operated with one hand. This ease of use allows users to operate the application while on the move. While one-handed operation is possible on WAP phones, it is usually not possible on PDAs, since the input is typically pen-based. In either case, one of the main design goals of your wireless application should be simplicity, especially for the user interface. Keeping the focus of the application on the content, rather than on images and graphics, usually helps to accomplish this goal. Also, make it easy for a new user to navigate through the application with minimal effort. In most cases, the user is using the application to solve a problem or accomplish a goal, not to browse. This is especially true for WAP applications. When the screen only has six lines of display, the human interaction with the application has to be streamlined. The point is to keep the application as simple as possible, allowing the user to perform the desired task without having to navigate through unnecessary pages or enter large amounts of text. If this goal can be attained, user satisfaction, hence adoption of your application, will increase dramatically.
When working with a device for which you have not created applications in the past, running a pilot program early in the development cycle can provide some invaluable insight into the usability of the application. And you will gain that knowledge at a stage when it can still be incorporated into the application design without too much additional cost.
| Note | If you are interested in learning more about the usability and design guidelines for WAP applications, visit some of the Web sites listed in the Helpful Links section at the end of this chapter. Many of the device and browser vendors, as well as the Open Mobile Alliance, provide excellent information on this topic. |
Device Independence
If you are deploying an application aimed at a broad audience, where you are looking for widespread adoption, supporting a large number of devices is a definite plus. This is especially true for applications that may be used in various modes by the same user. For example, if an airline deploys an application that lets users check flight arrival and departure schedules, it will want to make sure that people can access this data from the full range of wireless devices as well as desktop browsers. In this way, customers can check their flight times before they leave home, and again on their way to the airport, each time from a different device, using a different network for connectivity.
For corporate applications, such device independence may not be required. In this scenario, you may only be deploying to one or two targeted devices; nevertheless, you should design your application so that it can work with other devices that may be deemed necessary in the future. With wireless technology evolving at a rapid pace, the device of choice in the future could be much different from what you choose today.
Personalization
One way to minimize the content being downloaded, while still generating useful information, is to personalize the data. Personalization levels can be set at an individual user level or at a category of user level. In either case you end up with more specialized content that is of interest to the current application user. When a person logs in to the application, everything that is displayed to him or her from that point on has been predetermined to be of interest to him or her. All of the content can be generated dynamically, based on user specifications. Ideally, there will be a personalization application that can be accessed using a desktop PC application, allowing the user to set up specific requirements.
Other forms of personalization happen at the application level. Rather than creating one complex application for a variety of users with different roles, you can create separate, targeted applications for each function that needs to be addressed. In this way, you will be able to keep the user interface simple and minimize the number of screens the application requires.
Another application type that works very well with personalized content is messaging applications. A messaging application can provide a one-way stream of information, notifying the user when a particular event occurs. Using the flight schedule example, if a user is scheduled on a specific airline flight, he or she could be notified if the schedule changes, rather than having to navigate through an application to find the same information. Based on the notification, you can send relevant information directly to the user, such as a screen to rebook the flight, if necessary.
Enterprise Integration
Enterprise integration is a term used to describe any communication to systems that are not on the device. It encapsulates integration with enterprise databases, business applications, XML data, Web content, and legacy data, among other things. For the purpose of designing your wireless solution, you will need to determine to which enterprise systems you require access. All of the logic to integrate with these enterprise systems will be located on the server. The client device contains no business logic and, therefore, no enterprise integration capabilities.
Because wireless Internet applications are based on a distributed architecture, similar to desktop Internet applications, the enterprise integration layer should be very similar as well. At this phase in the development cycle, you will want to consider which systems need to be communicated with and how that communication is going to take place. For example, you may have an enterprise relational database and a corporate business application, such as SAP, to which you require access. You will then have to determine how that access will be accomplished. In the case of the relational database, you may want to use a native driver, ODBC or JDBC. When it comes to SAP integration, you have the choice to use a commercial adapter for SAP or to create your own adapter based on the APIs that SAP exposes. These decisions may not directly influence the wireless client, but they will affect the overall performance and capabilities of the application.
Once you have access to the data source in question, you are then required to adapt that data to a format appropriate for the wireless microbrowser. This adaptation can be accomplished in a number of ways, all of which are discussed in Chapter 13.
One other form of enterprise integration common for Web applications is Web services. This integration is accomplished using a defined XML interface, allowing you to incorporate a wide variety functionality and information into your application. The logic for Web services resides on a server, which can either be hosted in-house or be supplied by third-party vendors. (A summary of Web services and their role in mobile computing is provided in Chapter 18, "Other Useful Technologies.")
Business Logic
The business logic for wireless Internet applications is executed on the enterprise server (which is often a wireless application server). This logic is responsible for many wireless-specific features such as content generation, session management, and messaging. Each of these features is implemented with wireless applications in mind; however, not all of the logic has to be developed that way. If you have general logic that is responsible for data manipulation, enterprise integration, or processing other specific business rules, it should be shared across all applications within the enterprise. Avoid duplicating business logic, if at all possible.
In many corporations, separate teams are responsible for wireless Internet applications and for desktop Internet applications. This separation of responsibility often leads to duplication of efforts. Instead, because wireless Internet applications share an architecture similar to desktop Internet applications, it is more effective to design them to share the same business logic and enterprise integration modules.
Implementation and Testing Phase
It is during the implementation and testing phase of the development process when developers start to get excited, because this is when they start to see tangible progress. This is not to say that the needs analysis and design phases are not valuable; in fact, the implementation of the application will go much more smoothly if enough effort is given to the application design. Likewise, user-satisfaction levels will be much higher if the needs analysis phase is completed properly.
As most software developers know, creating an enterprise application does not happen in one step. Even at the implementation phase of the development process, many incremental steps have to be executed, and often repeated, before an application is complete. This is true for desktop Internet applications, and is definitely true for wireless Internet applications. The first step is often the development of a prototype. This allows the developers to obtain feedback on the application design and features early in the development cycle, when there is still an opportunity to make changes to the application. If you wait until the application is nearly finished before field testing, required changes will be very time-consuming, leading to additional costs and a later release date, not to mention frustration for the developers.
| HELPFUL TIP | The wireless client for Web content does not have to be developed separately from the desktop client. Designing and developing these applications together often results in a better-integrated solution that shares business logic and enterprise integration logic, reducing complexity and cost. Whenever possible, think about the wireless aspect of an Internet application at the design phase. |
Prototypes
Developing a prototype of your application will help you determine if the decisions you made during the design phase of your application are accurate. By field testing the prototype, you will acquire valuable information early on, saving you headaches and, more importantly, additional costs later in the development cycle.
During the prototype phase, you do not have to perform all of the testing using a real device on a wireless network. Much of the user interface, business logic, and enterprise integration can be tested using emulators. Only when it comes to determining the wireless coverage and penetration of a given network, or when evaluating the application's responsiveness and performance, do you actually require wireless connectivity.
The following is a list of questions you will want to answer during the prototype stage, before moving on to the final implementation. Some you will answer by using emulators; others will require the use of physical devices on wireless networks:
-
Which device is most suitable for your application? Take into consideration the means of wireless access, the microbrowsers available, the device form factor, means of data input, and, of course, cost.
-
Which wireless network is appropriate for your application, and does it perform as expected? Look at coverage for the geographies in which your application will be used. You may also want to factor in the time and effort required to get a connection to the carrier being evaluated.
-
Does the user interface provide the most efficient way for the user to operate the application? Does it match the device characteristics?
-
Does the application work properly on the device/network/browser combinations that may be used? Is there an optimal environment that should be recommended for most users?
-
Is the appropriate data available in the application? Is it hard to navigate to the core functionality that the application provides?
-
Does the enterprise integration layer work? Is it scalable to meet the needs for your application?
-
Have security concerns been addressed? Are there holes where corporate data is left unprotected? Depending on your security requirements, an on-premise gateway solution may be required.
-
Does the application provide an upgrade path for new features? Will it be adaptable for new wireless networks as they arrive?
The preceding questions are some of the major ones for which you will want to have answers during the prototype and initial testing stages of the application. Unfortunately, prototyping is often omitted from the software development cycle to save time and money. In reality, neither savings is achieved. The information gathered during this prototype phase will allow you to make modifications to your application before it is too late.
Keep in mind that a prototype does not have to be an entire application. You can simply put together a couple of screens that will represent the larger application, and execute a sample of the data source integration. Even this level of effort will result in huge dividends when you move on to the development and deployment of your application.
Development Tools and Emulators
Choosing a development tool for your wireless Internet applications is not an easy task. As you will see in the remainder of this section, there are many development tools available, all with various strengths and weaknesses. It is worthwhile to take the time to find a tool that fits your development needs, as well as personal preferences. You will probably spend a considerable amount of time using it during development, so you should make sure you like it.
Until recently, most development tools for wireless devices were provided by device or browser manufacturers, often free of charge as part of a software development kit (SDK). This situation is changing as leading Internet development tool vendors continue to add support for wireless markup languages and emulation environments to their offerings. Usually, vendors charge a licensing fee to use these tools, but the expense is often worthwhile, because of productivity gains achieved from the cross-device and browser capabilities of these tools. A third choice for development tools comes from wireless platform vendors. These vendors typically provide a tool that is tightly integrated with their platform, often taking advantage of proprietary extensions that have been developed within their frameworks. In most cases, you will be interested in using the tool only if you are using the other parts of the vendor's platform as well. For this reason, this discussion does not address tools from wireless platform vendors. Chapter 14, "Wireless Internet Technology and Vendors," covers this topic along with vendors that provide wireless software infrastructure.
In addition to the development environments, the tools also provide emulators to simulate how the application will look and feel without having to deploy it to a physical device. Simulation is often necessary, because, in all likelihood, you will not have every device/network combination available to you for testing. Even if you do, testing the application of every possible deployment combination is not practical or cost-effective.
The following sections provide information on the leading wireless device types and their corresponding development tools.
| Note | If you are interested in content-generation techniques, such as using Java servlets, JSPs, or ASPs, you can find information on these technologies in Chapter 13. |
Wireless Application Protocol (WAP)
There are more development tools and SDKs for WAP than for any other platform. All of the leading device manufacturers such as Nokia, Ericsson, and Motorola, provide development kits, as does Openwave Systems, which develops WAP browsers and gateways. The nice thing about these tools is that they provide emulation environments for their devices. Just make sure you test using the emulator for each device you are targeting, because the WAP implementation varies from device to device, and for browser vendors, from version to version of their products.
Table 12.1 lists the major WAP infrastructure providers, along with a URL where you can obtain the related development kit. In most cases, you will find that you can download the SDK free of charge.
| COMPANY | URL FOR DOWNLOAD | DESCRIPTION |
|---|---|---|
| Ericsson | www.ericsson.com/mobilityworld | The WapIDE 3.2.1 Software Development Kit enables you to develop WAP applications and test how they behave on different Ericsson phones. |
| Motorola | http://developers.motorola.com/developers | The Mobile Application Development Kit (ADK) provides an environment for writing, editing, and testing WAP applications for Motorola phones. It is also the legacy toolkit for development of VoiceXML/VoxML applications. |
| Nokia | www.nokia.com/wap/development.html | The Nokia Mobile Internet Toolkit provides developers with a PC-based testing and simulation environment in which they can create WAP and other mobile Internet applications, including those based on the eXtensible Hypertext Markup Language (XHTML), Cascading Style Sheets (CSS), and Multimedia Message Service (MMS). |
| Openwave Systems | www.openwave.com/products/developer_products/sdk/ | The Openwave SDK provides an integrated development environment and Openwave Mobile Browser emulator to enable developers to test their mobile applications on a desktop PC. This is one of the most commonly used emulators for WAP development. |
Figure 12.2 depicts the Openwave 4.1 and 5.0 emulators. It is a good idea to use the emulator that most closely resembles the physical device characteristics you are deploying on. For most of the current Web-enabled phones, the version 4.1 emulator is suitable.
Figure 12.2: Openwave WAP emulators.
Windows CE
Microsoft provides the leading microbrowser and development tools for Windows CE-based devices, including both Pocket PC and Microsoft Smartphone 2002. One nice feature of these devices is that they use Pocket Internet Explorer (PocketIE), which is a very capable Web browser that supports HTML, WML, cHTML, and client-side scripting. As these devices grow in popularity, expect to see more development platforms that target these devices.
The development and emulation environment is free to download from Microsoft's developer site. In addition, Microsoft supplies ASP.NET mobile controls (formerly the Mobile Internet Toolkit), which allows for cross-platform wireless development from a single environment. Table 12.2 lists the URLs where you can obtain more information on these products.
| URL FOR DOWNLOAD | DESCRIPTION |
|---|---|
| www.microsoft.com/mobile/developer/default.asp | Information on both Pocket PC and the Microsoft Smartphone 2002 is available on this Web site. You can also download development and emulation environments that allow you to test and debug your applications without using a physical device. |
| msdn.microsoft.com/vstudio/device/mobilecontrols/default.asp | ASP.NET mobile controls consists of a set of server-side Web form controls that allow a wireless developer to author cross-device user interfaces. These controls extend the functionality of ASP.NET. Microsoft has integrated ASP.NET mobile controls directly into the Visual Studio .NET environment. |
Palm OS
A variety of browsers and development kits are available for the Palm OS, provided primarily by the leading device manufacturers, including Palm and Handspring. In addition, browsers are provided by wireless Internet service providers (WISPs), including GoAmerica, Neomar, and AvantGO. More information on these browsers is provided in Chapter 14, where we discuss wireless technology and infrastructure vendors.
The standard browser provided by Palm is based on the Web-clipping model, using HTML as the markup language. WML browsers, as well as non-Web-clipping HTML browsers are also available. See Table 12.3 for a listing of development kits and micro-browsers available for the Palm OS.
| COMPANY | DOWNLOAD URL | DESCRIPTION |
|---|---|---|
| GoAmerica | www.goamerica.com/partners/developers/ | The Developer Zone gives you the tools you need to create a wireless Web-based application that can be accessed via the Go.Web browser. |
| Handspring | www.handspring.com/developers/ | The Development Kit for Handspring handheld computers is a collection of development software, documentation, and associated files. |
| Neomar | www.neomar.com/developers/index.html | Neomar enables the extension of applications and services to wireless intelligent devices such as RIM, Palm, and Pocket PC via open wireless standards (currently, WAP). |
| Palm | www.palmos.com/dev/tech/webclipping/ | The Web-clipping architecture includes client-side applications that run on a Palm OS-powered handheld, proxy servers for handling translation between the Web-clipping application format and HTML, and content servers. The client-side application is called a Web-clipping application (WCA). It is constructed in HTML and translated into the Web-clipping application format. |
Many current Palm OS-based devices have integrated wireless modems, or make it possible to add one using an expansion slot. These developments have made Palm devices more suitable for wireless Internet applications than they have been in the past, when wireless connectivity was cumbersome to obtain.
Symbian OS
The best place to get technical information for the Symbian OS is on the Symbian Developers Network, as listed in Table 12.4. Symbian is a joint venture between Ericsson, Nokia, Motorola, and Psion, so as you would expect, you can also find information regarding Symbian OS on these manufacturers' developer sites as well.
| COMPANY | DOWNLOAD URL | DESCRIPTION |
|---|---|---|
| Symbian | www.symbian.com/developer/index.html | Complete SDKs for developing Symbian OS-based applications, including wireless applications using C++, Java, and WAP. |
| Ericsson | www.ericsson.com/mobilityworld | See Table 12.1. |
| Motorola | http://developers.motorola.com/developers | See Table 12.1. |
| Nokia | www.nokia.com/wap | See Table 12.1. |
Research In Motion (RIM) BlackBerry
The BlackBerry devices from Research in Motion are primarily aimed at providing wireless access to corporate email; and because they have an integrated modem, decent display capabilities, and an effective data input mechanism, they are used for wireless Internet applications as well. The most common microbrowsers for the RIM devices are provided by wireless ISPs that supply wireless connectivity for RIM users. These browsers typically use WML as the markup language, making the application development similar to WAP applications.
| COMPANY | DOWNLOAD URL | DESCRIPTION |
|---|---|---|
| GoAmerica | www.goamerica.com/partners/developers/ | See Table 12.3. |
| Neomar | www.neomar.com/developers/index.html | See Table 12.3. |
| Research In Motion (RIM) | www.blackberry.net/developers/index.shtml | Applications can be created for RIM handhelds using the free SDKs available on the RIM developer site. |
General Web Tools
In addition to all of the device- and browser-specific SDKs, many of the leading Web development tools have added support for wireless application development. Very often, this support is accomplished using XSL stylesheets for transforming XML data into markup-language-specific content such as WML, cHTML, VoiceXML, or HTML, or by using XHTML. While having the robust capabilities of these tools is definitely a plus when creating wireless applications, we are not going to focus on these vendors since wireless is only a small part of their overall offerings.
That said, if you are planning on creating a Web solution in conjunction with your wireless offering, these tools may be exactly what you are looking for. Table 12.6 gives you the names of the leading vendors, along with their URLs, where you can find more information.
| COMPANY | DOWNLOAD URL | PRODUCT AND DESCRIPTION |
|---|---|---|
| Macromedia | www.macromedia.com/software/dreamweaver/ | Dreamweaver: A complete, easy-to-use environment for creating very sophisticated Web applications. Many wireless platform vendors have plug-ins for Dreamweaver for their wireless Internet development. |
| Macromedia | www.macromedia.com/software/homesite/ | HomeSite: A tool geared for Web developers who prefer hand-coding their applications. Homesite provides tools for creating fast, effective Web sites, as well as the ability to manage the development process. It also has support for XHTML, which is the base language of WAP 2.0. |
| Microsoft | www.microsoft.com/frontpage/default.htm | FrontPage: A general-purpose Web development tool with support for XML, which allows you to create content geared for wireless access. |
Physical Devices
Moving from an emulation environment to a deployment environment introduces two new variables to your application: the physical device and the wireless network. This is different from smart client applications, which can be tested on a physical device without requiring wireless connectivity. Since all of the business logic and content-generation technology resides on the server, a wireless connection is required to enable application access. Let us take a look at each new variable that real devices introduce.
First we have the device itself. You will need to obtain the actual devices that you plan on using during deployment. You will also want to make sure you test the application with the browser that you are planning on using. This is important because each microbrowser might display the content differently, and each device will have different display and navigation features. Some will have 12-digit numeric keypads; others will have alphanumeric keyboards; while still others will have pen-based input. If you are deploying your application for an audience that may use any number of devices, it is unlikely that you will have each of these devices for testing. As an alternative, try to get a good representation of the target devices and browsers, and test on those. For example, you might want to have one Palm device, one Pocket PC device, and one WAP device to test the major form factors and markup languages. If you do not have these devices available to you, at least test on the most widely used devices, since that will satisfy the majority of your target audience.
Testing with a physical device satisfies only half of the testing sequence. The wireless network is the other half. Wireless connectivity can introduce a lot of unknowns into the overall usability of your application. As discussed in Chapter 3, many different wireless networks may be used for deployment, including wireless wide area networks and wireless local area networks. Depending on the deployment requirements, you may need to test your application on one or both types of networks. Wireless LANs provide high-speed connectivity in a controlled environment. Public domain wireless networks offer coverage over a wide range of geographies, with less predictability. They may also introduce performance issues, due to the high latency and low bandwidth, and accessibility issues, due to coverage and penetration. Testing on actual devices over the targeted wireless networks is the only way to get an accurate assessment of the application's performance and usability.
Deployment Phase
Over the past several years, many corporations have moved away from traditional client/server architectures to distributed Web architectures. Many factors have influenced this migration, but the one that stands out is the ease of deploying Internet applications. With client/server applications, such as smart client mobile applications, a client component has to be deployed to each device that is going to use the application. Even with the software management and deployment solutions available, this still is a time-consuming and high-maintenance task. All of this can be avoided by moving to the Internet model, where only a Web browser is required on the client. All of the data storage and business logic is kept on the server, and is accessed in real time over a network. This same model applies to wireless Internet applications, although some additional work is required.
The first step in deploying the wireless Internet application is to set up the deployment environment. This can be accomplished in one of two ways: on-premise or hosted. Most companies run the required servers on-premise, so we will look at that scenario first. "On-premise" means that the entire suite of server-side software is going to be maintained by the corporation (as opposed to a third party), within the corporate firewalls. This includes the wireless application servers, Web servers, and enterprise data sources, as well as the hardware it will run on. For many corporations, the deployment configuration will mirror the configuration that was used for testing. For large-scale deployments, or those that are mission-critical, staging servers are set up, so that application developers can test the application in an environment with the same characteristics as the one being used for deployment. Once they are satisfied with the quality of the application, it is moved to the deployment servers.
If the effort required to set up and maintain the required enterprise servers is too large or too costly, or if a decision has been made to outsource this process, a hosted solution may be the answer. In a hosted setup, a third-party organization can host your application server and/or enterprise data sources for you. These companies usually charge a monthly fee for this service, which is dependent on the number of servers required and connections to the outside world.
In addition to setting up the application itself, wireless connectivity has to be addressed. As discussed in Chapter 11, "Thin Client Overview," this may require a wireless gateway to provide access to the wireless carrier. Fortunately, the wireless carrier provides this gateway service, converting the wireless protocol being used to HTTP, which is directly supported by wireless application servers. The only thing required of the enterprise is to have a listener on a port using HTTP or HTTPS, and make sure that port is open in your corporate firewall.
In some cases, when multiple wireless networks are being used, or when additional wireless optimization or security is required, a wireless ISP is used. Wireless ISPs can provide you with access to multiple wireless carriers from a single location, called a network operations center (NOC). The NOC then communicates with your enterprise over a secure HTTP connection. The benefit of using a wireless ISP is that you can communicate over multiple wireless networks and have all of the technical support, provisioning, and billing provided by a single company. In most cases, wireless ISPs also provide you with browser software for the devices they support, often with optimized wireless communication capabilities. (Information on the companies that provide this service can be found in Chapter 14.)
| Note | In some cases, for security reasons, you will also have the option to install the wireless gateway on-premise, within your corporate firewalls. This allows any decryption and reencryption to happen behind the firewall, protecting you against the WAP gap. More information on this issue and other related issues is provided in Chapter 6, "Mobile and Wireless Security." |
At this point, most of the tasks associated with deployment are taken care of. Once your servers are all configured, and the wireless network access is initiated, you simply let your users know the URL of your wireless Internet application. They then enter this URL into their microbrowser to gain access to your application.
|
|
EAN: 2147483647
Pages: 148