Browse DevX
Sign up for e-mail newsletters from DevX


Heed the Siren Call of Wireless Development : Page 3

You're about to be drafted into the mobile development army. Users' and organizations' needs are outflanking IT's defenses. Why is this happening? And when the battle comes to your regiment, will you be armed for success?




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Why Hasn't the Shift to Wireless Already Happened?
Given that these capabilities are already available and that users are ready to consume the functionality, why hasn't this need for wireless applications happened sooner? (See the sidebar "Holding Wireless Back: Top Failures of the Wireless Industry".) There are several reasons:

Perception. IT departments and organizations, while often tolerant of PDAs and phones, haven't assumed responsibility for them as they have with traditional PCs. That's a mistake, because these devices are not just phones or contact managers any longer—they're full-fledged computing devices, with the attendant support and security risks, and should be treated as such.

Accessibility. Wireless coverage has not, until recently, been available in many areas of the country, and it's still spotty. Gartner Vice President Nick Jones says that "you should expect to have multiple sorts of wireless networking in your organization," and that "50 percent of organizations will find themselves using at least five different types of short-range wireless networking by 2007." Wireless providers have, so far, not delivered the access and bandwidth to back up the wireless hype. "Through 2007," Jones says, "WAN capabilities will continue to deliver improved data throughput and location precision, but advertising and hype will cause service providers to fail to meet user expectations for speed, cost and capability." That's backed up by UPS's experience. Rolling out their wide-area delivery applications required a large number of contracts with wireless providers across the U.S. and Europe to get the coverage it needed.


Speed. So far, wireless hype has promised more than it has delivered; still, the bandwidth available for wide-area wireless connectivity is moving beyond the current abysmal speeds. Although access to high-speed connectivity is currently both limited and expensive, it can support full-featured applications as opposed to simple text messaging. For applications that need only short-range mobility, WLAN connections provide 11Mbps of bandwidth or more. (See sidebar "WLAN Quick Start: Getting up to Speed on 802.11 Wireless LANs.") While that's considerably slower than the typical 100Mbps corporate network, it's fast enough for all but the most demanding applications.

Applications needing wide-area connectivity are burdened by slower-than-dialup wireless data connections. That means you still need to design applications differently when clients can't connect to your network through a WiFi hotspot. But there's hope. Faster connections are slowly coming online, although they're still very limited in coverage—for example, you might be successful with a wireless application within a specific city or portion of a city, but you may not be able to count on that provider to supply the same level of coverage or service across a state.

Standards. Standards, while improving, are still in flux. Although the network protocols—wired or wireless—should have only minimal impact on developers, they have a huge impact on application performance and interoperability, because the different standards provide different coverage ranges and speeds. The time when developers can ignore the protocol in use is still a distant dream.

Cost. The price of wireless data transmission is dropping but is still high compared to wired applications. Worse, there's no standard billing plan, so users who cross from one provider's coverage area into a different provider's coverage area, for example, may pay different prices for the exact same service. On the flip side, if you're planning to sell (rent) application functionality to the end-user market, there's also no standard billing model for users to pay for them, and their access costs are also high. (See the article "Value-based Billing for Wireless Java Applications.")

Despite these problems, the need for wireless applications by users and organizations is steadily increasing, and your job, as a developer or application planner, will be to deploy wireless applications while accommodating their inherent restrictions.

Downtime. While wireless networks are improving, they have a long way to go before wireless connectivity is as consistent and dependable as wired connectivity. Weather, distance, physical barriers, device failures (such as loss of battery power), and connectivity failures (as simple as driving through a tunnel) all conspire to make wireless applications less robust than wired versions. For critical applications, you must design your applications to expect failures, and implement an alternative way for remote workers to submit and receive data, even if that means creating a paper-based fallback plan. According to Gartner Research Director Bill Clark, critical wireless systems that don't have a fallback "are a recipe for disaster in 2003."

Device Capabilities. Until recently, wireless devices have been relatively slow with limited capabilities. Organizations implementing corporate wireless applications have relied on specially designed hardware used for vertical applications. However, as the computing, display, and connectivity power of wireless devices increases, they become commensurately more able to support corporate applications. The newest devices are just now reaching that point. Device capabilities are still a barrier to general purpose applications, but that barrier is diminishing rapidly.

Development Tools. The tool sets haven't yet reached the point at which developing for wired and wireless devices in tandem is completely transparent, but that's changing. The split between the wireless and wired worlds is going to disappear, and, in fact, we're already seeing clear signs of that happening. For example you can create both wired and wireless applications in VS.NET (see "Developing Mobile Applications Using the Microsoft Mobile Internet Toolkit" and "Developing Pocket PC Applications in Visual Studio.NET"), in JBuilder, in WebSphere, and in other major development environments. All these, to some degree, hide or simplify the differences between the various client devices.

Audience Positioning. The wireless industry has focused the vast majority of its marketing effort on consumers and ISVs. While there are certain obvious strategic reasons for doing so (mainly the size of the audience and the accompanying size of the revenue potential), the effect is that wireless development has not reached the corporate IT mainstream as quickly as it should have.

Despite these problems, the need for wireless applications by users and organizations is steadily increasing, and your job, as a developer or application planner, will be to deploy wireless applications while accommodating their inherent restrictions.

Thanks for your registration, follow us on our social networks to keep up-to-date