Evolution of Mobile Development Frameworks and Tools
Introduction to frameworks and tools for mobile application development, focusing on addressing complexity, reducing development costs, and improving reliability. Discusses fully centralized frameworks for mobile applications and N-tier architecture in the context of evolving architectural techniques and mobility dimensions. Emphasis on how these tools aim to simplify mobile application development and enhance user experience.
Uploaded on Oct 08, 2024 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Chapter2: Introduction to Mobile Development Frameworks and Tools
Introduction The software is a set of instructions for hardware written in machine language. At a higher level, there are assemblers and higher level programming languages. There are frameworks, tools, and other methods of abstracting various aspects of software design that help us achieve one central goal: To handle complexity of software more reliability and faster The biggest problem with software design and implementation is complexity and this complexity leads into 1- High cost of development, and 2- Long development cycles, The existence of programming languages, frameworks, and other development tools is primarily to solve this very problem of software complexity.
Frameworks and tools for mobile application development are evolving based on the growth of architectural techniques and innovations that accommodate the dimensions of mobility. Although the purpose of any significant tool and framework used in mobile application development should be to reduce the complexity of the mobile application, all tools, regardless of their implementations, attempt to address the same issues. Today, there are many programming languages, frameworks, and tools designed to develop server-based and desktop applications. These languages, frameworks, and tools have matured through the years, becoming more efficient and more reliable as they get tested in real environments by real users. Along with the maturation of these tools has come the maturation of the process of software design and implementation.
Fully Centralized Frameworks And Tools Developing fully centralized mobile applications differs from other fully centralized applications by virtue of QOS, limited power supply, active transactions, and location awareness. Fully centralized mobile applications typically have custom-designed clients to perform specific tasks. So, the user interface on the devices used to access the centralized system is optimized to the task being performed. The software on such devices is typically embedded in nature and is designed to do only one thing. Also, because of this embedded nature of fully centralized mobile systems, resources of the device are not a concern in software development: The abilities of the client are known beforehand. Platform proliferation, once again for the same reason, is not a concern: Software systems in fully centralized mobile systems are all about the software on the fully centralized host; the client devices are dumb with little or no ability to perform dynamic computing tasks and what little software exists on them is embedded. Therefore, three of the dimensions of mobility namely platform proliferation, limited device capabilities, and support for a variety of user interfaces do not apply to fully centralized applications
N-tier architecture N-tier architecture is also called multi-tier architecture because the software is engineered to have the processing, data management, and presentation functions physically and logically separated. That means that these different functions are hosted on several machines or clusters, ensuring that services are provided without resources being shared and, as such, these services are delivered at top capacity. The N in the name n-tier architecture refers to any number from 1.the N-tier can be used to model both a web application and desktop application.
N-tier architecture The presentation layer. The presentation layer (tier) is the user interface. This is what the software user sees and interacts with. This is where they enter the needed information. This layer also acts as a go-between for the data layer and the user, passing on the user s different actions to the logic layer. The application logic layer. The application logic layer is where all the thinking happens, and it knows what is allowed by your application and what is possible, and it makes other decisions. This logic layer is also the one that writes and reads data into the data layer. The data layer. The data layer is where all the data used in your application are stored. You can securely store data on this layer, do transaction, and even search through volumes and volumes of data in a matter of seconds.
N-tier Clientserver Frameworks And Tools Client server architectures allow us to enable communication between two applications with one application acting as the server and the other acting as the client. For mobile applications, the server may have special needs, but it is typically powerful enough to run a wide range of applications. For mobile applications, there may be special logic that treats the dimensions of mobility. Client applications, in the case of mobile development, are typically those being run on mobile devices. Writing large applications for the devices to serve as the client is typically not possible, primarily because of the limited resources on the devices and the large variety of them So, more often than not, mobile applications are distributed. The state of the art, as of the date of authoring this text, in proven distributed computing systems are the N-tier client server architectures.
In general, there are two factors that are inherently opposite in nature. First, we need a layer of software, be it a virtual machine or otherwise, that abstracts us away from the specificity of hardware. This is the only practical way to write software rapidly for mobile systems. But the second, as software layers are added, performance is hampered and system requirements go up. More than ever, selection of the frameworks and tools depends on the requirements of the application. We can address this problem in three ways: Thin-Client Wireless Client Server: Thick-Client Wireless Client Server: Stand-alone Applications:
Thin-Client Wireless ClientServer: We can have some homogeneous browser specifications and implement the browsers for each device in a client server environment. The browser can then load markup code and render it or even load plug-ins. This model is implemented by having different families of devices and platforms with one corresponding browser for each. The Wireless Access Protocol (WAP) and its user interface markup language of WML give us a framework for building thin-client wireless applications with an N-tier client server architecture.
Thick-Client Wireless ClientServer: This thick client may communicate with the server, with the client executing some tasks and the server executing the others. Stationary client server architectures using thick clients typically use the client as a means of storing a small subset of the data for use of the application when disconnected from the network and performing business logic that does not need to be centralized. The platforms that allow thick-client development for mobile devices address this in two ways: 1- Some provide an operating system or a virtual machine that provides the application programmers with a platform that lessens the number of permutations for writing code. - J2ME (Java 2 Micro Edition) allows this through a small virtual machine that sits on top of the hardware. - Microsoft requires an installation of some flavor of Windows on the device (such as Windows CE) that allows the application programmer to write programs for Windows. - Symbian also provides an operating system for mobile devices. 2- Hardware manufacturers, such as Qualcomm and Texas Instruments, provide programming environments directly on top of hardware (ASIC, EEPROM, etc.).
Stand-alone Applications: We can build stand-alone applications for the devices using those same platforms that we mentioned for the thick-client client server-based systems. The only difference here is that stand-alone applications do not really need networking components. Many of the first applications for the Palm operating system were only downloadable through the cradle that attaches the Palm to the serial port of the device. From there, you can download an application and run it with no network connectivity.
Mobile Operating Systems and Virtual Machines Although Java tries to solve the proliferation problem by making the code portable between different platforms, there are other plausible approaches. One of these approaches is to create tools that make the applications native to one platform. Microsoft s.NET framework deploys such a strategy. The tools provided by the .NET framework allow the programmer to develop the application in a variety of languages supported by the framework. The individual applications are then compiled to code that can be executed on the same platform. Microsoft s creation of the .NET platform is spurred by economic reasons, namely to keep Windows as the dominant computer operating system. However, this does not imply that the tools provided by the .NET framework are either superior or inferior. It is simply a different technical approach whose merit should be judged by the implementing developers and the users of applications that use this platform
Mobile Operating Systems and Virtual Machines The principal technical difference between the .NET and Java approaches is that .NET generalizes by operating system and Java generalizes by programming language. So, with .NET, every device, be it a PC or any other type of computing device, is required to run some flavor of Microsoft Windows as its operating system Something important to remember as we go through various tools is that developing applications for mobile devices typically involves use of an emulator provided by the platform or device manufacturer. In this way, the unit testing and quality control of mobile applications differs from that of stationary applications: Everything is typically finished and tested on the emulator first and, then, tested on the actual device.
Hardware-Specific Tools and Frameworks One way to deal with device proliferation is to avoid it! Device manufacturers can allow the application programmers to develop code that directly takes advantage of the device features and functionality. The notion of an operating system, in such case, is much different than what we typically think of as an operating system. The services offered by the operating system are few and very low level. The downside here is a tight coupling to a platform that, in turn, can translate to heavy reliance on the manufacturer of that platform. This is the approach that Qualcomm offers in its BREW platform. BREW is a framework designed to allow application developers program applications for devices based on Qualcomm s CDMA technology. It is a physical layer communication protocol that offers very efficient use of the bandwidth available in a segment of the spectrum.
Java Java, as any other programming language, is a programming language that allows us to program a set of instructions. Perhaps just as importantly Java is somewhat of a vendor-neutral language-based platform. Java seems to have solved the problem that has plagued many other programming languages in the past: the lack of standardizing libraries. With C++ and many of the other programming languages, one of the biggest problems has been the lack of industry-wide standards in APIs, components, and tools. Different vendors have offered similar components and frameworks with no uniformity among them in their APIs and interfaces Vendors have done this to differentiate their products; however, this forces developers to rewrite code when moving from one component set or framework to another or even to completely redo the architecture of the system. Java has solved this problem by enforcing standard API interfaces to the components and frameworks and allowing for vendors to compete on the basis of the implementation of the APIs.
Java Today, it is widely accepted that Java as a programming language offers the most portable commercial environment for writing software applications. The success of Java has been mostly in providing standard Application Program Interfaces (APIs), a very thoughtfully designed infrastructure for OOP that prohibits many bad design and implementation habits such as multiple inheritance. Standard and open APIs offer a process of evolving a language that is open to many vendors. Furthermore, there exist implementations of the virtual machine and the native dependencies of the APIs for most popular operating systems. There are three major categories of Java APIs and virtual machines, namely J2ME, J2SE, and J2EE. Java offers three distinct features as a mobile application platform: 1. Java is an object oriented programming language. As any other programming language, it can be used to write applications. 2. Java offers complete code mobility and weak mobile agent ability. Java allows for platform-independent programming. 3. Java is a platform
BREW Qualcomm s BREW (Binary Run-time Environment for Wireless) gives application developers a new and different approach in producing mobile applications. BREW is built directly into the hardware. It is offered as an API to access the CDMA, GSM/GPRS, or UMTS chip sets that provide the support for it. But, it is primarily intended for the variations of CDMA, a technology owned and licensed by Qualcomm. BREW applications can be written on a PC using the BREW Software Development Kit (SDK). Once the application is developed, it must be tested, and then deployed. Deployment of BREW applications is a process done jointly by Qualcomm and telecommunications carriers and not just the developer
BREW applications 1- BREW MIF Editor: Every BREW module, defined as the classes that make up one or more BREW applications, has an associated Module Information File (MIF). MIFs are required. Every BREW module must have a MIF. 2- BREW Device Configurator: This is a stand-alone application that allows developers to make up their own handset by configuring a vanilla mobile phone and specifying the behavior of the keys, the look and feel of the screen, and other specifics of the device. This development tool addresses the large variety of existing devices by allowing developers to create their own device emulator and testing the application 3- BREW Emulator: For those who have designed and implemented any mobile application, it is obvious that one of the most difficult steps in the development process is the incremental unit testing. Although most platforms provide some sort of a generic emulator, most do not allow for custom configuration of a device (done by the Device Configurator) or using the custom configuration to simulate running an application. This is what the BREW Emulator does
BREW applications 4- BREW Image Authoring Tool: There is an image authoring tool that allows creation of images for BREW. This tool can use PNG or BMP files. 5- BREW ARM Compiler:Many mobile devices are based on the ARM or Strong ARM hardware platform (registered trademarks of ARM Corporation). The ARM Compiler enables the BREW developers to compile their code for the mobile devices that carry the ARM- based technologies. 6- Image Converter: The tool set provides an image converter to convert 4-bit bitmaps to 2-bit bitmaps as BREW only supports 2-bit bitmaps because of the limited resources on mobile devices. 7- Resource files in BREW are a collection of images, strings, and dialog look-and-feel components that allow changing the look and feel of the application for internationalization and similar purposes without changing the code base. The BREW Resource Editor gives the developers a GUI interface to manage the resource files
BREW Applications 8- BREW Pure Voice Converter: This command line utility allows the developers to convert wave files (audio) to Pure Voice files or vice versa. 9- BREW AppLoader: This tool allows the developer to deploy an application on a handset through a PC connector. This is a testing and not a deployment tool. 10- BREW Grinder: The Grinder generates a variety of inputs and tests the application. 11- BREW TestSig Generator and AppSigner: The TestSig tool provides the developer a mechanism to generate a test Class ID.
Window CE An operating system is the master control program that enables the hardware by abstracting it to the application via drivers [Development tools for Mobile and Embedded Applications 2002]. Microsoft s various products revolve around different versions of an operating system. The versions that concern us, the mobile application developers, most are Windows CE and Embedded Windows XP. Windows CE has been around since 1997 and Embedded Windows XP is being released at the time of authoring this text. These two operating systems are designed for two different purposes. There are different flavors of the Windows CE operating systems, of course, depending on the hardware platform. Some of these flavors are the Pocket PC, Windows CE .NET, and Pocket PC 2002. These flavors largely depend on the commercial bundling of different feature sets and hardware platforms with which they are shipped (such as Compaq s IPAQ). Embedded Windows XP, in contrast, is a subset of the desktop version of Windows XP components. Development for Embedded Windows XP is a bit more straightforward than developing for Windows CE.
Window CE Microsoft provides tools to build applications for each environment too. These are as follows: 1- Embedded Visual C++: This is a tool set separate from Visual Studio, the typical development environment for PC-based Windows applications. It allows for authoring mobile applications in C++. Emulators and a debugger are provided. 2- Embedded Visual Basic: This tool provides the ability to write applications using Visual Basic. Visual Basic applications can be developed faster but do not offer the developer the ability to tune and optimize the application for resourcestarved mobile devices. Therefore, Embedded Visual Basic is really not a suitable tool for developing large commercial applications, but it does well for proof-ofconcept and prototype application. 3- Smart Device Extensions for.NET: The .NET application programming platform, the newest set of tools for building Microsoft Windows-based applications, can be complemented with a set of extensions that allow developers to author .NET applications for mobile devices. 4- Microsoft Mobile Internet Toolkit: This is really a server-side framework.
WAP Wireless Application Protocol (WAP) is the single framework most used in building mobile applications today. WAP, which was initially intended to be as pervasive for wireless and mobile applications as HTTP has been for the Web, never achieved the level of success initially expected. However, to date, WAP has the largest install base of all open application development platforms on mobile phones, meaning that WAP is installed on more mobile phones than any other software. WAP shares some similarities to HTTP. From its inception to now, it has become more and more like HTTP. WAP 1.x and WAP 2.x are significantly different with WAP 1.x being the basis for nearly all the current installations in the market today and WAP 2.x being the target platform for WAP devices during 2003 and 2004 Let us go over some basics about WAP.
WAP 1- WAP is intended for thin clients. Much like HTTP, the designers of WAP 1.x were thinking about a thin-client technology: a case where nearly all logic is calculated on the server and very simple display instructions are bundled in some markup language to be displayed by the client. 2- WAP is built on its own lower level communication protocol. Whereas HTTP assumes the existence of TCP/IP (which in turn provides persistent connections), WAP is built on its own set of communication protocols that wrap around TCP, UDP, or a variety of other possible protocol implementations. 3- Typical deployment of WAP includes a proxy or a gateway. Wireless carriers (also referred to as bearer networks) like to have control of every single incoming and outgoing bit of data that travels on their network. This is understandable as usage time is the typical mechanism for billing. 4- WAP is a complete framework for mobile applications. Whereas most tools created for development of applications treat a part of the mobile application chain, WAP treats, or at least attempts to treat, all parts
