Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

GPRS and 3G Wireless application - Anderson C.

Anderson C. GPRS and 3G Wireless application - Wiley publishing , 2001. - 356 p.
ISBN: 0-471-41405 -0
Download (direct link): gprsand3gwirelessapplica2001.pdf
Previous << 1 .. 76 77 78 79 80 81 < 82 > 83 84 85 86 87 88 .. 125 >> Next

The service network management functionality is out of the scope of most applications developers. The owner of the service network is the one who maintains and handles this feature.
Page 201
Figure 9.13 An application server’s main cabinet.
Team-Fly®
Page 202
Summary
Traditionally, the mobile networks have been closed, and it would have been hard for third-party application developers to create products for them. Applications were designed with one specific network in mind, and it was difficult to create an application that could run over several bearers. One of the most important aspects of the 3G networks is that the architecture now is layered horizontally. In other words, applications can be designed to run independently of the underlying networks and still interface with the control and transport functions. The open APIs that facilitate this process are specified by Parlay and 3GPP and make it possible to add features to the applications (such as positioning, call control, and personalization).
Page 203
ne of the biggest open issues for developers of wireless applications is that no one wants to tell them what future devices will look like and what accessories and properties they will have. Because many software developers are used to working with hardware developers who show hardware years in advance, this transition is difficult. One example is the people from the interactive entertainment and gaming industry. Sony, Nintendo, and Sega have been very generous to their closest developer affiliates for many years and have sent detailed descriptions and software development kits (SDKs) long ahead of their commercial launch. This relationship is a must, because it takes quite some time to get used to a new platform and to learn to develop efficiently for it. Consequently, there has been a very high correlation between the success of a hardware/software platform and the amount of available software. Mobile telephones have traditionally been closed platforms with just a few applications per device. Manufacturers of mobile phones and PDAs are not accustomed to this kind of openness that the software industry is used to, and both sides probably have to adjust.
What then is the information that developers need in order to be able to get great applications out on the market quickly? The tricky part is that the fresh information is of the highest importance to developers (for example, what are the properties of devices that will come out one year from now?), but this is also the most confidential information. When we describe the properties of the devices of today and tomorrow, we will use a generic approach that will apply even years after this book’s publication. As a result, the developer will be better positioned toward making decisions about future products, and it will be easier to use the up-to-date information that manufacturers provide through SDKs.
Page 204
The question is, ‘‘How much does a wireless application developer need to know about upcoming devices?”
Devices Now and in the Future
In fall 2000, I attended a panel discussion in San Francisco about the future of mobile devices. The audience consisted of designers who, at that time, mostly worked with Web design and publishing on desktop PCs and who were interested in designing for the mobile Internet. I could see the crowd becoming increasingly weary as we talked about the devices of the future and how the form factor would evolve but would still be limited. Almost everyone could agree that the mobility would always limit the size of the device (until we invent screens that you can fold like maps), so that point was acceptable to the crowd. Then, someone wanted a bit of comforting from me and asked whether we are working on a way to standardize the screen size and other output properties in order to make life easier for designers. I felt like I kicked someone who was already lying on the ground when I said that things will only become worse for designers in the future. The more features that become available, such as high-speed access, more powerful hardware, and better screens, the more diverse the mobile devices will be. There will be no “one-size-fits-all” device that has all the features available and still is the smallest and most power efficient.
The industry always tries to standardize the things that it can standardize, but there are many components of these devices that it cannot standardize fully. The closest that we come to standardization is the MExE framework (described later in this chapter), which enables devices to divide into different classes depending on their capabilities. In addition, platform developers like Symbian have developed frameworks (Quartz, Pearl, and so on) for device families. Using those frameworks, you can develop for several devices that use the same operating system and device family. The application should not despair, because there are ways to design applications that will work on multiple devices (as we will discuss later in this chapter).
Previous << 1 .. 76 77 78 79 80 81 < 82 > 83 84 85 86 87 88 .. 125 >> Next