UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Using AspectJ to build a software product line for mobile devices Young, Trevor J. 2005

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2005-0718.pdf [ 6.5MB ]
Metadata
JSON: 831-1.0051632.json
JSON-LD: 831-1.0051632-ld.json
RDF/XML (Pretty): 831-1.0051632-rdf.xml
RDF/JSON: 831-1.0051632-rdf.json
Turtle: 831-1.0051632-turtle.txt
N-Triples: 831-1.0051632-rdf-ntriples.txt
Original Record: 831-1.0051632-source.json
Full Text
831-1.0051632-fulltext.txt
Citation
831-1.0051632.ris

Full Text

Using AspectJ to Build a Software Product Line for Mobile Devices by Trevor J. Young B.Math, University of Waterloo, 1999 A THESIS S U B M I T T E D IN P A R T I A L F U L F I L L M E N T OF T H E R E Q U I R E M E N T S F O R T H E D E G R E E OF Master of Science in T H E F A C U L T Y OF G R A D U A T E S T U D I E S (Computer Science) The University of British Columbia August 2005 © Trevor J. Young, 2005 Abstract Software development for mobile devices has become very popular in the last few years. There are hundreds of programmable micro devices on the market, each having different properties in terms of memory capacity, screen size, networking protocols, audio/video support, peripheral extensions and software platforms. Despite the technical differences of these devices, people use them in a similar fashion for communicating, organizing and interacting with their personal data. For a mobile software developer, it would save a great deal of time and effort to program an application in a way that allows it to run on all of these devices without modification. However, the variability of hardware in these mobile phones, P D A ' s or music players has led the vendors to provide additional levels of software support for different devices. For example, with the Java programming language, vendors and standards bodies have introduced optional, device specific libraries (APIs) that only run on certain hardware devices. A software developer can thus not rely on standard programming practices to build an application that can run on multiple platforms and still offer features that take advantage o f unique functionality that is only embedded in specific devices. We call this the device A P I fragmentation problem. One potential way to ease the development of a common application for a variety of devices is using Aspect-Oriented Programming (AOP) techniques to build a software product line. The basic idea is to modularize features into aspects and to use the weaving technology in aspect-oriented programming to bind features into different instances of the product line. In this thesis, we evaluate an approach for building a software product line for mobile devices using J 2 M E and AspectJ. We present different implementations of a prototype application to compare the AspectJ product line approach with standard object-oriented techniques that are currently used to build families of mobile Java software in industry. The results indicate that AspectJ provides a good solution to the device A P I fragmentation problem by maintaining modularity of features. i i Contents Abstract..... Contents List o f Tables List o f Figures Acknowledgements 1 Introduction..... 1.1 Java for Mobi le Devices 1.2 Implementing a Mobi le Product Line using AspectJ 2 Related Work 2.1 Product Line Practice in the Mobi le Industry 2.2 General Product Line Practices 2.2.1 Mult iple Copies and Version Management...... 2.2.2 Object Oriented Frameworks and Patterns 2.2.3 Code Generation and Template Programming . 2.2.4 Pre-Compilation Utilities 2.3 Aspect-Oriented Product Line Practices 3 MobilePhoto Prototype Application Design 1 3.1 The Base Application 1 3.2 The Optional Features 3.3 Architecture... 4 MobilePhoto Implementation using AspectJ 4.1 De-coupling Optional Features using Aspects 4.2 Binding Features to the Application using Advice 4.3 Managing Multiple Features Using Precedence 4.4 The Bui ld Process 5 MobilePhoto Implementation using Object Oriented Programming 5.1 De-coupling Optional Features Using O O Design patterns 5.2 Binding Features to the Application using a Pre-Processor 5.3 Managing Multiple Features Using Pure Variants™... 6 Evaluation '. •••• ••• 6.1 Quantitative Analysis 6.2 Modularity and Flexibili ty 6.3 Scalability 6.4 Multi-Platform Support 6.5 Complexity o f Implementation 6.6 Tool Support 7 Conclusions 7.1 Contributions 7.2 Future Work Bibliography Appendix A : Acronyms Appendix B : A N T Bui ld Script Source Listing Appendix C: SmsAspect Source Code Listing i i i List of Tables Table 3-1: Basic Features Included in A l l MobilePhoto Product Instances 12 Table 3-2: Optional Features Available for MobilePhoto Product Instances 13 Table 3-3: Sample of J 2 M E Devices Indicating the Supported Software Components... 14 Table 3-4: Data Store Schema for MobilePhoto Image Data 15 Table 3-5: Data Store Schema for MobilePhoto Image MetaData 15 Table 4-1: MobilePhoto Product Instances (AspectJ) 17 Table 5-1: MobilePhoto Product Instances (Object-Oriented) '. 29 Table 5-2: Pure Variants Feature Model for MobilePhoto 35 Table 6-1: MobilePhoto Jar Size Comparison.... 40 Table 6-2: MobilePhoto Heap Memory Comparison 41 Table 6-3: MobilePhoto Source Code Metrics Comparison 42 Table 6-4: Modified Classes for Custom Blackberry AspectJ Runtime 48 iv List of Figures Figure 1-1: Proposed Mobi le Product Line Bui ld Process 4 Figure 2-1: Example Version Control Branching Technique for Mobi le Product Lines ... 7 Figure 4-1: A O P Feature Weaving Applied to Mobi le Product Lines 17 Figure 4-2: MobilePhoto Package Diagram 19 Figure 4-3: Class Diagram for S M S Feature (AOP) 20 Figure 4-4: Design Diagram Showing S M S Feature Interaction with Base Application. 21 Figure 4-5: Partial Source Listing for S M S Aspect of MobilePhoto 22 Figure 4-6: Sequence Diagram to Send S M S (AspectJ) 23 Figure 4-7: Declaring Precedence to Manage Feature Interaction in AspectJ 24 Figure 4-8: MobilePhoto Bui ld Process 26 Figure 4-9: Eclipse V i e w with A N T and Bui ld Configuration Plugins 27 Figure 5-1: O O P Patterns and Preprocessor Applied to Mobi le Product Lines 29 Figure 5-2: Class Diagram for S M S Feature (OOP): 31 Figure 5-3: Partial Source Listing of MainUIMidlet Class (OO Version) 32 Figure 5-4: Partial Source Listings of MainUIMidlet Class (OO Version) '. 33 Figure 5-5: Sequence Diagram to Send S M S (OOP) ; 34 Figure 5-6: Screen Capture of Pure Variants Plugin with MobilePhoto Feature Mode l . . 37 Figure 5-7: Partial Source Listing for Ma in Bui ld Target (OO Version) 38 Figure 5-8: MobilePhoto Bui ld Process Using Pure Variants 39 Acknowledgements I would like to thank my supervisor, Gai l Murphy for keeping me focused, providing amazing guidance and feedback and showing me the ropes in the world of academic research. Thanks to all the great friends and colleagues I've met in Vancouver for making it such an enjoyable experience. Thank-you to my family for providing support and encouragement throughout my life, and particularly in the past couple years. Lastly, thanks to Beverley for learning more about computers than she ever wanted to know, and for being there no matter what. T R E V O R J. Y O U N G The University of British Columbia August 2005 vi 1 Introduction Within the past few years, there has been a substantial increase in the amount and diversity of micro devices available on the consumer market. Devices such as phones, organizers, watches and music players can now run Java software such as games or business applications. M u c h of the current focus has been on creating content for cellular phones and personal digital assistants since there are already millions of users who carry these in their pockets on a daily basis. For instance, in China, there are 300 mil l ion mobile subscribers, and this number is expected to grow to 500 mil l ion within the next two years.1 Mobi le phone operators such as Sprint and Vodafone report that mobile games and other data services now account for roughly 10 percent of their annual -revenue, while mobile-game publishers generated $1.2 bil l ion in global sales in 2004. 2 For a programmer who wants their application to run on more than one device, managing the complexity of many different hardware and software configurations can be more difficult than anticipated 3 ' 4 ' 5. In the mobile phone market alone, there are over 250 device platforms serviced by more than 80 different mobile operators in numerous languages.2 The major hardware vendors in the market like Research in Motion, Palm, Nokia, Motorola, Siemens and Ericsson have anywhere from 20-50 models of devices each. It should not be surprising that the different models and classes of devices all have different programmable capabilities, platforms and requirements. A t the hardware level, these devices have different screen sizes, memory restrictions, varying audio/video features, multiple input devices (such as stylus, keyboard, keypad, thumbwheel, hard buttons), and numerous peripheral extensions such as M P 3 players, digital cameras and wireless connectivity using Bluetooth, C D M A , G P R S or 802.11. The software platform is also not standardized across devices. Many of the phones run on the Symbian operating system 6, while most P D A ' s and organizers run some version of Palm OS, R I M OS, Microsoft PocketPC or even Linux. This diversity of device features and software platforms creates a large number of configurations that need to be supported. A s an example, imagine you are a mobile game developer and have two games that you would like to release to the masses. If you want to deploy your game on ten different devices, and support two different languages7 you may need to create as many as 2x2x10 = 40 different builds. N o w consider this problem from the perspective of a mid-sized mobile game publisher that has thirty game titles and needs to support fifty different devices in five languages. Y o u are now potentially managing 30x5x50 = 7500 build configurations. A s a concrete example of this scenario, international games publisher 1 China 's Min is t ry o f Information Industry (http://www.china.org.cn/english/BAT/127434.htm) 2 M o b i l e Entertainment Analyst Art icle (http://mobenta.com/analvsis/item-2138.html) 3 Challenges and Opportunities in M o b i l e Games (http://www-128.ibm.com/developerworks/library/wi-austingameconf.html?ca=dnt-539) 4 Dealing W i t h a Fragmented Java Landscape for M o b i l e Game Development ( http://www.gamasutra.com/features/20031217/tammenkoski_pfv.htm) 5 Creation vs. Fragmentation (http://www.screamingthumbs.com/2005/04/creation-vs-fragmentation.html) 6 http://www.svmbian.com 7 Multi-language support is often a requirement by game portals and mobile network operators 1 GameLoft recently released seven hundred different versions of the game Splinter Cel l for mobile devices in sixty five different countries.8 One way to address this problem is to develop the software as a product line, which supports the development of a family of systems that share a common set of features and that are developed from a common set of core assets, but which can be configured in different ways. In comparison to existing systems built using a software product line approach, mobile devices typically demonstrate greater variability in both the software and the hardware platforms, each of which place rigid restrictions on the developer in terms of available memory or disk resources and access to functionality o f the operating system. These restrictions mean that some of the common techniques for developing a software product line for desktop applications do not work with mobile systems. Moreover, instead o f building a product line that supports two or three desktop or server platforms, mobile applications need to be portable across dozens or even hundreds of different devices. 1.1 Java for Mobile Devices To help support the mobile developer community who must deliver applications fast, at low cost, and with high quality, Sun Microsystems provides a version of the Java platform, Java 2 Platform Micro Edition ( J 2 M E ) 9 that supports micro devices with different hardware capabilities. J 2 M E is an environment for running applications on mobile devices such as cell phones, personal digital assistants (PDAs) , set top boxes, and embedded devices. It includes Java Virtual Machines ( JVMs) and a subset of the standard Java APIs. The architecture of J 2 M E has been designed to allow developers to choose from a combination of configurations, profiles and optional packages to construct a . complete Java runtime environment that closely fits the requirements of a particular range of devices and a target market. This means that a developer could select the M I D P 2.0 profile (Mobile Information Device Profile), the C L D C 1.1 configuration (Connected, Limited Device Configuration) and the W M A (Wireless Messaging A P I ) 1 0 optional library as a base for their application. However, the application would be limited to devices that support that particular combination of M I D P 2.0, C L D C 1.1 and W M A technology, restricting the functionality that the application can provide and the devices upon which it can run. There are many choices of profiles, configurations, optional and proprietary libraries that fit together in various combinations depending on the operating system and hardware o f the device, but building an application across these different configurations and profiles is difficult. A s a programmer, you must be aware that using components or libraries that are specific to certain devices, profiles or configurations wi l l make your application less portable. Gameloft Simultaneously Launches 700 Versions o f T o m Clancy's Splinter C e l l Chaos Theory in 65 Countries ("http://www.gameloft.com/press release.php?press 1=333) 9 http://iava.sun.com/j2me/overview.html 1 0 Refer to the appendix for a complete list o f acronyms used throughout this document 2 J 2 M E offers a partial solution to building portable applications as there exist four critical problems with trying to manage a software product line for mobile devices using this technology. First there are the physical hardware differences between devices, including screen or canvas sizes, font sizes and types, soft and hard buttons, heap memory, storage space, audio/video capability, and colour depth. Second, there have been many reports of differences in the Java virtual machine implementations between device manufacturers. These differences have resulted in a number of bugs that surface on some platforms but not others, and developers are forced to accept the V M embedded in the device by the vendors. 1 1 A third problem is that many mobile applications (especially for cell phones) can only be deployed through the telecommunications providers that service the device, and these carriers generally enforce certifications or requirements on the application developer. Often before developers can publish their mobile application to general users, they are required to support multiple languages for the carrier, or may be limited by the size of external Java applications that can be installed, or the amount of wireless data it can send. Finally, many of the device vendors release proprietary Java A P I ' s to take advantage of special functions that are only available on their hardware. This is in addition to the standardized optional API ' s from Sun that are similarly only supported by certain hardware or software configurations. For instance, the optional Wireless Messaging A P I ( W M A ) for J 2 M E w i l l only work on devices that support the M I D P 2.0 profile and have wide area wireless connectivity. We refer to this problem as the device A P I fragmentation problem. 1.2 Implementing a Mobile Product Line using AspectJ The thesis of this research is that aspect-oriented programming can alleviate the device A P I fragmentation problem for mobile device applications within the constraints of these kinds of devices, such as limitations on the application footprint size and the memory usage. Using aspect-oriented techniques, the application can be partitioned into base components and optional features; a developer can then selectively include only the components that are supported by a target device. In particular, we investigate the use of AspectJ[l] to support this approach. A high level diagram of this process is depicted in figure 1-1. 1 1 This problem exists in J 2 S E / J 2 E E as wel l , although in J 2 M E you generally cannot install a choice of V M 3 Figure 1-1: Proposed Mobile Product Line Build Process Aspect-oriented programming can help with the expression of the product-line, but approaches are also needed to help with the configuration of the product-line. In this thesis, we also investigate how to keep the product line build process simple and scalable so as to handle many devices and features with minimal maintenance. In particular, we investigate build configuration techniques to ensure that only those components which are supported by the target platform will be included in the final executable of the application. To evaluate the effectiveness of the aspect-oriented approach, we compare the AspectJ implementation with one that uses standard object-oriented programming paradigms and design patterns. To accurately compare the two techniques, we designed and implemented a prototype application in J2ME and tested the execution and build process on a variety of micro devices and emulators. Details of the implementation and build process are provided for each alternative in Chapters four and five, followed by an analysis of the complexity, modularity, resource usage and scalability of each in Chapter six. 4 2 Related Work In this chapter, we discuss current programming practices in the development of mobile applications, research into product line techniques that may be suitable for mobile devices, and existing applications of aspect-oriented programming to solve product line problems. 2.1 Product Line Practice in the Mobile Industry Commercial J 2 M E applications for mobile devices are not very abundant because J 2 M E is a relatively new technology and it has only recently become a standard option deployed with new mobile phones on the market. For example the J 2 M E virtual machine does not even come pre-installed with the Palm OS or Microsoft's Pocket P C . In addition, it has taken time for software development kits (SDK's ) , toolsets and integrated development environments (IDE's) to offer developers support in mobile development. The lack of a standardized platform has led to the industry adopting a number of ad hoc approaches. A n interview with Al l en Lau, C T O of Tira Wireless suggests that a large number of mobile application providers tend to target only the most dominant device platforms, and consider porting to other devices only i f the demand is there. Al len further describes the J 2 M E (game) industry as being divided into application developers and specialized porting companies. In many cases, publishers of original application content develop one or two generic versions of their J 2 M E application for representative 'mass market' devices (such as the Nokia Series 60 and Series 40 platforms) and then arrange for another company to port, optimize and test the application for all the other handsets it must support. This seems to be a desirable option for small mobile developers who do not have the resources or access to all the hardware to port and test it on their own. In fact, there are a number of companies that have built successful business models around porting J 2 M E games and business applications across various devices. 1 4 Unfortunately, there is very little information on the processes these porting companies follow. This indicates a very real problem for programmers or small software companies who want to develop applications for devices in the mobile industry. It is a problem that is l ikely to get worse before it gets better as the number of phones, P D A ' s and other micro devices deployed commercially increases over the next two to three years. Some recent open source projects such as Antenna 1 5 , J 2 M E Pol i sh 1 6 and NetBeans M o b i l i t y 1 7 offer utilities to help alleviate this problem but tend to help with only specific problems such as U l 1 2 The first K V M for Pa lm was released in 1999. Standardized M I D P 1.0 specification was released in 2000, and hardware manufacturers began embedding it in devices after that, (http://iava.sun.com/i2me/') 1 3 Comments from telephone interview with A l l e n Lau , Tira Wireless, M a y 2005 (http://www.tirawireless.com) 1 4 www.small-device.com. www.tirawireless.com. www.octanetech.com. www.mforma.com 1 5 http://antenna.sourceforge.net/ 1 6 http://www.j2mepolish.org/ 1 7 http://www.netbeans.org/kb/articles/mobility.html 5 consistency or preprocessing support and do not yet offer a complete solution to building mobile product lines. 2.2 General Product Line Practices With the advances of wireless technology and reduced costs of micro hardware, the mobile computer industry has only recently become a popular platform for custom application development. A s a result, product line techniques in the mobile space are not well established or implemented. The software development environment for this technology has some significant differences compared to desktop computing which means typical product line approaches are not necessarily effective. Outside the mobile application domain, there are a variety of product line implementation techniques that have been used with different degrees of success. Some are used in isolation; others can be used in combination with different product line approaches or complementary component and framework methodologies. This section presents general product line practices that could be considered for mobile application development. In the cases where these general techniques have been tried with mobile development we comment on their applicability to the device A P I fragmentation problem. 2.2.1 Multiple Copies and Version Management The 'brute force' approach to building product lines is to write the application on a single platform, and then create copies for each additional device you need to support and make platform specific modifications to each copy. This approach is not a generally recommended approach but might be a tempting ad-hoc solution when timing or resources are in short supply. Applying this technique to mobile product families would not be difficult because these applications typically involve less source code than a general-purpose application. Discussions with developers in the J 2 M E space 1 8 indicate this is often the approach currently used to handle differences in device variability. This might suffice for two or three different devices, but when you need to deploy your application on dozens or hundreds of devices, keeping all the different copies in sync would be very hard to manage. Even a simple change to a common feature might require the developer to update every copy of the application. This approach can be made easier with the help of version control utilities. Configuration management software such as C V S (Concurrent Version Control System) 1 9 offers branching, versioning and merging techniques that allow you to create sub-branches off of a stable code base to take different copies of your source code in different directions. One technique of this approach is called a Platform Line or Permanent Variant Branch 2 0 . This method attempts to track platform specific components and sources by creating a separate code base for each device or platform variant. It is better than simply managing 8 Contacts from mobile and wireless companies Tira Wireless, iAnywhere Solutions, Eontec and others 9 https://www.cvshome.org/ 1 0 http://v^w.cmcrossroads.corri/bradapp/acme/branching/branch-creation.html#PlatfonirLine 6 directories and resources at the file system level because most configuration management software provides the ability to automatically merge (push or propagate) baseline code changes to the branch variants. For example, figure 2-1 shows how the main (trunk) code base might contain source code that is compliant with the M I D P 1.0 standard which would run on any J 2 M E enabled device. Separate branches could then be created for different platforms that use optional or proprietary APIs that are only supported by specific devices. Thus, a separate branch could be created for Nokia devices or Motorola devices, and these can be further sub-branched into specific models of the manufacturer. When changes are made to the common code base, it can be merged back into the branches to keep all the product instances in sync. / M I D P 1.0 Q - version - branch LZZI / M o t o r o l a I branch branch / N o k i a / i - S e r i e s branch O C H merge O merge branch / S e r i e s 6 0 Figure 2-1: Example Version Control Branching Technique for Mobile Product Lines However, with this approach you can end up with a very complex tree structure containing one branch for every individual device class. Depending on how you structure your branches, you may also have a lot of duplicate code. For instance, i f both Nokia series 60 and Motorola i-Series phone models support an S M S text messaging feature, you wi l l either have duplicate code in each branch, or have to re-structure your entire tree to keep a single component base for the common S M S code. Once again, this might be an acceptable solution for managing two or three product platforms, but scaling this to dozens of different product instances could be very difficult to manage. Another factor to consider with this approach is that re-structuring your branches after development is not easy because of the static way in which most version control packages handle these features. Y o u must typically know the details of all the platforms you wish to support when you create your branching structure, and you must also know what features or 7 components each of these platforms support. Developers could take this one step further and branch at a finer granularity (e.g., create branches for each component or feature), but this comes with greater maintenance responsibility for the code bases, and necessitates a more complex build system. 2.2.2 Object Oriented Frameworks and Patterns The ability to re-use the same software artifact in many different products is an important factor to reduce development time. Object-oriented frameworks[2] and design patterns[3] are an effective way of building re-usable components and sometimes form the basis of product line development practices. Some of these object-oriented frameworks have component models integrated into them that allow plug-n-play behaviour for software applications with many optional features. For example, the Eclipse Integrated Development Environment ( IDE) 2 1 is used as the base for a family of I B M products such as WebSphere Studio, WebSphere Device Developer, Rational X D E 2 2 along with other variations that provide unique features depending on the target users. The Eclipse software project uses a Java framework that provides a platform for producing different product instances from a set of core assets. This makes it easy to mix and match different plug-ins (with unique features) to form a complete product instance that targets a specific developer domain. A number of software companies have used the base of Eclipse to form their own I D E product families. However, the infrastructure required to enable this easy plug-n-play o f optional features increases the size of the core software. The size constraints of mobile devices would make an approach such as this one difficult to deploy because it increases the final executable size. In addition, some of the basic object oriented features required by these frameworks are not available in the limited J 2 M E libraries. For instance, as of M I D P 2.0 there is no support for things like reflection, JNI (Java Native Interface), or user defined classloading. 2.2.3 Code Generation and Template Programming There is also an increasing interest in applying generative programming techniques to product line practices. [4] These approaches often rely on modeling tools to define abstract components and artifacts for an application, and then generate product specific source code depending on the target platform selected. Template programming is another technique used in this area. Davis et al. recently conducted research investigating a generative-based approach for application tailoring of mobile devices [5]. They focused on defining a model that can generate web-based content or standard J 2 M E source code, rather than on the variability of device platforms or models. They tested two approaches: one using X S L T templates to transform user-defined properties into source code, and another that uses a tool to define the meta-model of an application and requires an implementation of a custom interpreter in C++ to generate code from this model. Davis et www.eclipse.org http://www-306.ibm.eom/.software/awdtools/developer/ 8 al. state that "the interpreter must contain transformation code for every artifact needed in the tailoring process" and "an interpreter must be written for each target device" ([5] p.4). This approach thus pushes the work from maintaining multiple source code bases to maintaining multiple design artifact bases, and continuously tweaking the generation or transformation rules and code to support new product instances. Trying to support a large number of product instances using this technique would likely require substantive effort. 2.2.4 Pre-Compilation Utilities The use of utilities or tools that include build configuration features or pre-processing capabilities is something that is becoming popular among mobile programmers. One of the most common uses of the preprocessor in C is to include code that is conditional on the execution platform. Since Java was designed to be platform independent ("write once, run anywhere"), it is generally thought that a preprocessor should not be needed. However, with the variability in mobile devices and the fragmented A P I problem inherent in the J 2 M E platform, this is not the case. Tools such as J 2 M E Polish, Antenna and NetBeans now provide custom Java preprocessors, which allow a developer to reduce the size of the compiled code by including only platform-specific code for the target device. Bui ld configuration techniques achieve a similar result at a higher-level by excluding entire source files i f they are not supported by the target platform. These utilities may be used in combination with other product line techniques, and can be effective at reducing the final application size of mobile applications. 2.3 Aspect-Oriented Product Line Practices Various approaches to using aspect-oriented technology to develop software product lines have recently started to emerge. Much of this research is focused on using aspects to customize middleware components and servers or desktop applications that have less variability across hardware and software platforms, and allow for a larger application size with more available resources.[6] A study by Murphy et al. explored methods of separating features from application source code using AspectJ [7] which could apply to the design of mobile applications. Loughran, Rashad et al. [8, 9] discuss a hybrid approach using aspect-oriented programming and Frames to support the evolution of software product lines. They provide some simple implementation examples for a generic caching component, but at the time of this writing it has not been tested for mobile applications. Lopez and Batory demonstrate the use of AspectJ to build a product line of graphing algorithms.[10] The application in their case study is built using the standard Java platform which does not suffer from device A P I fragmentation. Part of their findings identify that AspectJ has no built-in support for handling design rules and feature interaction, thus programmers have to manually perform the complex and error prone task to select the artifacts necessary to create a specific product instance. In more recent work, they evaluate a number of modularization technologies (including AspectJ) in terms of how they support the creation of features as modules. Many of their findings regarding basic properties for feature modularity are technology independent and could 9 be applied to the mobile domain[l 1]. Bodkin, Colyer and Hugunin released a practitioner report[12] discussing their experience in industry on a project where they applied aspect-oriented programming to achieve platform independence for an application. Their motivation for using aspect-oriented programming was to target multiple runtime environments with a single source code base for a middleware product line. The implementation was successful at modularizing typical cross-cutting features such as logging, tracing and error handling, but noted concerns with immature tools and difficulty of developers to adopt an ' A O P mindset' when programming. Their report indicates that aspect-oriented techniques can help problems with application portability, though issues in mobile development such as device A P I fragmentation, memory restrictions and footprint optimization were not present in the case study. We are aware of two groups who have used an aspect-oriented feature weaving approach with Java development on mobile platforms. A t the Federal University of Pernambuco, Alves has applied a variation management technique with AspectJ to J 2 M E game development for mobile phones. They use an incremental approach to re-factor existing J 2 M E games to isolate commonality from variability within mobile software[13]. Other papers from the same group investigate the use of AspectJ to enable adaptive J 2 M E applications to behave differently according to changes in its environment. [14], [15]. Anastasopoulos provides a set of specific areas to investigate when evaluating aspect-oriented programming techniques as a product line implementation technology, and provides a case study using J 2 M E and mobile phones.[16] Similar to the work described in this thesis, the Anastasopoulos case study also looks at J 2 M E and AspectJ. In contrast, the Anastasopoulos work is intended as a general discussion on the relevance of aspect-oriented programming in product line development and does not address the specific problems related to J 2 M E and mobile applications, such as device A P I fragmentation. Our research extends some of these preliminary findings by focusing on building product lines for mobile applications that use aspect-oriented techniques starting from scratch (as opposed to re-factoring existing applications). This study encompasses a wider range of micro devices than previous work, that includes various mobile phones, personal digital assistants and pager devices. It compares both the source code and the build process for an aspect-oriented implementation and a straight object-oriented implementation, focusing specifically on the problem of device A P I fragmentation. 10 3 MobilePhoto Prototype Application Design To investigate the J 2 M E device A P I fragmentation problem across devices, we designed a mobile application that supports different feature combinations for different devices, depending upon the capabilities of the device. Our prototype application is a photo album (image viewer) appropriate for cellular phones, personal digital organizers or Blackberry devices although it is not limited to these. The requirements we devised for our photo album application include several different features. Some of these features incorporate APIs that can execute on any J 2 M E enabled device (e.g., anything that supports M I D P 1.0), some can only execute on a single, specific model (e.g., Blackberry 7210), while other features may be supported by a subset of devices (e.g., all mobile phones that support S M S text messaging). The application was designed from the outset as a product family that needs to run on multiple devices with different variations in A P I support. The structure of the application is split into two parts: the base application and the optional features. The base application contains the core functionality that allows a user to select photo images from a list and view them on the device screen. The optional features comprise functionality that might only be supported by certain classes of devices. For example, a phone that supports text messaging could have an optional feature to wirelessly send a photo to another user via S M S . Devices such as the Blackberry that support e-mail could similarly mail a photo to a friend over a supported wireless network. However, not all mobile devices support the optional or proprietary. APIs that offer this functionality, so it would be inefficient (as well as error prone) to include such a feature on a device that cannot support it. This approach to building a product line follows a decomposition approach [16] in which the common features are separated from the variant features so that optional components can be attached to the common functionality on demand. A n alternate approach is generalization (or data controlled variation) in which generic code is created to encompass many different variations. We chose not to use generalization because we felt the decomposition method would allow for better tool support and more potential for automating the build process. 3.1 The Base Application The components of the base application are implemented using the lowest common denominator of J 2 M E to ensure they can run on any J 2 M E compliant device. For our prototype, this translates to an implementation that uses only M I D P 1.0 and C L D C 1.0 API ' s , and avoids all optional or proprietary libraries. Therefore all ofthe base application features listed below wi l l run on any J 2 M E enabled device. Table 3-1 shows the five basic features that are included in the base application for MobilePhoto. 11 Table 3-1: Basic Features Included in Al l MobilePhoto Product Instances Create Photo A l b u m Allows a user to define new photo albums to store related categories of pictures on the device. A l b u m information is persisted using R M S (J2ME Record Management System). Store Photo Handles the conversion and persistence o f photo image files to the mobile device file system using R M S . Add / Delete Photo Al lows a user to permanently delete photos from the device, or add new photos to defined albums. Label Photo Al lows a user to label a photo with text. Labels appear in the display list, and could be used for future search functionality. V iew Photo This displays a selected photo on the device screen. 3.2 The Optional Features The optional feature components of MobilePhoto are de-coupled from the base application so they can be easily added or removed, depending on the device you are targeting. A s a result, the components of the base application are not aware of or dependent on any optional classes. This setup allows the base application to successfully compile when optional features are excluded from the build. Optional features are not standalone components, and require the base application to execute and compile; they only extend the functionality of the base MobilePhoto application. The optional features available are shown in table 3-2. 12 Table 3-2: Optional Features Available for MobilePhoto Product Instances Send Photo via S M S Allows a user to send a photo to another user via Short Messaging Service. Send Photo via Email Al lows a user to send a photo to another user via Email . Link Photo with Address Book Entry Al lows a user to associate an entry in their contact list with a photo in their album. Display Photo of Incoming Caller Intercepts incoming phone calls and displays a photo of the associated caller while ringing. Play melody of Incoming Cal l Intercepts incoming phone calls and plays a custom ring-tone of the associated caller while ringing. A l l of the optional features listed above could only be implemented using proprietary libraries, or optional J 2 M E libraries that w i l l only work on certain mobile devices. Table 3-3 below shows a sample of devices that can support the optional features for MobilePhoto. Note that it lists only six models, from the hundreds of J 2 M E enabled devices currently available. 13 Table 3-3: Sample of J 2 M E Devices Indicating the Supported Software Components H A R D W A R E V E N D O R Nok ia 6600 7210 X X X X X X Palm Tungsten X X X a. « via E m a i l 2 4 Link Photo w/ Contacts 2 Display Photo Incoming Cal le r 2 6 Play Melody Incoming Cal le r 2 6 X X X X X X X 3.3 Architecture Following standard practice[17], MobilePhoto utilizes the Model V iew Controller ( M V C ) design pattern to update the applications views ( U l screens) as the data changes, and to invoke the appropriate actions as the user dictates by pressing buttons or using menu items. The model represents the photo albums and the photos that the albums contain. Photo albums are just a way to categorize a group of photos stored on the device. Photos are MobilePhoto S M S Feature uses the optional W M A A P I from Sun 2 4 MobilePhoto Emai l feature uses the proprietary email messaging A P I from R I M 2 5 MobilePhoto Address B o o k feature uses the optional P I M A P I from Sun 2 6 MobilePhoto Incoming C a l l (Photo and Ringtone) features use the proprietary Telephony A P I from Motorola 14 instances of j a v a x . m i c r o e d i t i o n . l c d u i . Image objects when loaded in the Midlets memory. A l l of this information is persisted to the devices internal storage using J 2 M E ' s record management system (RMS) . R M S is a very crude database implementation that can only store a record Id (assigned automatically by J2ME) and a series of bytes. MobilePhoto creates two record stores for every photo album defined. One store holds the bytes of the images, and a second one holds the metadata of the images. Metadata information is stored as a delimiter separated string of fields and then converted into bytes that are saved in R M S . Tables 3-4 and 3-5 describe the record store 'schema' used by MobilePhoto: Table 3-4: Data Store Schema for MobilePhoto Image Data Record Id Int Automatically assigned by J 2 M E R M S Image Data Byte Array Images are converted into byte arrays. Table 3-5: Data Store Schema for MobilePhoto Image MetaData Record Id Int Automatically assigned by J 2 M E R M S Image Metadata Byte Array The metadata is a string of delimiter separated fields that are converted into a byte array. Specific fields are listed in the next rows. Record Id String Record Id of this entry (stored as string for easier access later). Foreign Record Id String Record Id of the corresponding Image Data record in the data store. Album Name String The name of the photo album this image is associated with. Image Label String A user defined label. Phone Number u String A Phone number for an image to associate with address book entries. (Only used for certain features) Audio File Name1' String Name of an audio file for an image to associate with melodies or ringtones. (Only used for certain features) Phone Number and Aud io F i le fields are only used by certain optional features 15 (Note the only data type RMS stores is byte[]. The italicized fields indicate the contents of the String before it is converted into bytes and persisted to memory.) The view (of the Model V i e w Controller) consists of the actual screens that display the photos, albums and related commands to the user. Since the purpose of this application is to analyze different solutions to device A P I fragmentation, the user interface was kept very simple and offers only one view for the data model. Screens are basic M I D P forms and lists, and a canvas object is used to display the images. It should be noted that when using the standard M I D P L C D U l widgets, the developer has little control over how the U l is displayed on different devices. The virtual machine of the device automatically attempts to display widgets and map menu items to buttons depending on the physical properties available to it (such as screen size and hard buttons). A s a result, items in the U l such as menu commands appear differently on a Nokia phone vs. Palm device vs. Blackberry device. For details on how J 2 M E handles this, refer to Sun's M I D P specification. A controller class is used to receive user actions and call the corresponding events. Events are typically handled by invoking a separate thread to do some work in the background so as to avoid issues with contention for the device display or interruptions from incoming phone calls or external events. http cp. org/en/i sr/detail? id=03 7 16 4 MobilePhoto Implementation using AspectJ For one implementation of MobilePhoto, we used AspectJ. Our intent was to describe the optional features of the application as aspects. Figure 4-1 describes our approach: the base application was written in standard J 2 M E using only M I D P 1.0, with the optional features implemented using optional or proprietary J 2 M E extensions and bound to the base components using aspects. The base application and optional features used in our prototype are concrete implementations of the design and architecture described in chapter 3. A given configuration of the system (figure 4-1) weaves in only those optional features supported by a device. In this way, we are able to build a product line using aspect-oriented programming. Features using optional APIs written independent of Base Base Application (J2ME v.1) Feature using Email APIs Feature using SMS APIs using MP3 APIs Weave only the features supported by the target device Figure 4-1: AOP Feature Weaving Applied to Mobile Product Lines Using the aspect-oriented implementation of MobilePhoto we built a variety of product instances by combining different combinations of optional features. (Table 4-1) 9 . Table 4-1: MobilePhoto Product Instances (AspectJ) Base Application only Base Application + S M S Base Application + S M S + Caller Photo Base Application + S M S + Caller Photo + P I M Base Application + S M S + Caller Photo + P I M + Play Ringtone Base Application + Email 2') The final Jar files for these applications are available for download at http://www.cs.ubc.ca/labs/spl/ 17 The aspect-oriented version of our MobilePhoto application was tested on a number of device emulators from different vendors, in addition to testing on selected (real) hardware devices listed below: • Palm Tungsten C (Hardware device) • Nokia 6600 (Hardware device) • Sun Generic Wireless Toolkit Emulator (v. 2.1) • Sun Generic Wireless Toolkit Emulator (v. 2.2) • Siemens GF62 Emulator • Siemens C X 6 5 Emulator • Siemens SL55 Emulator • R I M Blackberry 7200 Simulator • R I M Blackberry 6700 Simulator • R I M Blackberry 5800 Simulator • Palm OS Emulator (with Sun M I D P 1.0 K V M for Palm) • Palm OS Simulator (with I B M J9 K V M for Palm) • Motorola i730 Emulator • Motorola i830 Emulator • Motorola i860 Emulator • Nokia 3410 Emulator • Nokia 7210 Emulator • Nokia Series 60 Emulator Note that MobilePhoto jars were only tested on emulators or hardware that supported the particular feature-set of a given version. 4.1 De-coupling Optional Features using Aspects To enable the exclusion of optional features we had to ensure there was only one-way communication between the optional components and the base components. A s a result, we had the design rule that optional components can call public methods on any class in the base application, but the reverse is prohibited (base components cannot call methods that exist in optional components). This flow of information is referred to as a Class-directional association link, and results in the classes being more re-usable across product instances. [18] A n optional feature in MobilePhoto is contained in a single Java package, separate from the components of the base application. The components that make up a feature are a set of standard J 2 M E Java files (that rely on optional or proprietary libraries) and one or more AspectJ aspects (.aj files). Figure 4-2 shows the package diagram for MobilePhoto, indicating the packages that make up the base application components, and additional packages that contain the optional features. 18 ubc m Wp .m obi lephot o cere ui -.rr.kiF' rflotailephoto rare Hueads AupI i ca t ion> c rT ' iidp friobiiephoto.core.commj I icat ion> ubc .m id p .m obi lephot o .blackbe rry <Email photo feature> ubc .m id p .m obi lephot o .m otorola <Incoming call feature> ubc.midp.mobilephoto.mp3 <Play ring-tone feature> ubc .m id p .m obi lephot o .pirn < Address book feature> lube .m id p .mobi lephot o .sm s <SMS feature> Figure 4 - 2 : MobilePhoto Package Diagram For example, the feature that allows a user to send photos using S M S messages is contained in the ubc . midp. mobilephoto. sms Java package. It includes the four Java source files, and one AspectJ source file displayed in the lower portion of figure 4 -3 . The BaseMessaging class at the top of the diagram is part of a base application package. 19 BaseMessaging A Net works creen , SmsMessaging SmsReceiverThread • « • aspect » SmsAspect. SrnsS enderThread Figure 4-3: Class Diagram for SMS Feature (AOP) No classes in the base application ( u b c / m i d p / m o b i l e p h o t o / c o r e / * packages) are dependent on classes found in the S M S package. Details on how the optional components are integrated with the base application are discussed in the next section. 4.2 Binding Features to the Application using Advice In this version of MobilePhoto, AspectJ is used to bind the optional features to the base application using static weaving. In particular, we use inter-type declarations, execution pointcuts and after advice. In the context of our prototype application, there are two important areas of program flow where optional features need to integrate with the base application. One is the menu initialization, where additional menu items must be added that allow the user to invoke new features. The other is the controller logic, where the application must decide what action to take based on the buttons that were pressed by the user or events received by the system. The controller is part of the base application, but it must be aware of the new actions available to it that are exposed by classes associated with these optional features. To illustrate how this fits together, consider a version of the MobilePhoto product that contains the optional feature to allow a user to send photos over S M S . There are three points in the design of our base application where the S M S feature must integrate: 1) new 20 menu items must be added for the user to invoke the feature, 2) the application controller must know what action to take when a user invokes this feature and 3) the application must be notified when a new photo is being received from another S M S user. We use three pointcuts in the SmsAspect (figure 4-4) to identify these join points. Base Application ImageList initMenuQ ScreenController o commandActionQ i f / SMS.Messaging Feature @.SMSAspeet:; a f t e r i n i t M e m i 'after,: c o m m n n d A r . t i o n a f te r i m a g e R e c e i v e d SMSSenderThread SMSReceiverThread ;® imageReceived() Figure 4 - 4 : Design Diagram Showing SMS Feature Interaction with Base Application The initMenulterns pointcut captures the spot at which the menu items are created when the application first loads. The SmsAspect uses this pointcut to bind advice that wi l l execute after the base application menu items are initialized and inserts two new menu items for this feature: 'Send a Photo over S M S ' and 'Receive a Photo over S M S ' . The simple, yet effective source code for this is shown in figure 4-5. A full listing of the source code for the SMSAspect is in the Appendix. 21 //Introductions: //Define new menu commands associated with SMS feature Command smsSendCommand = new Command("Send SMS", Command.ITEM, 1); Command smsReceiveCommand - new Command("Receive SMS", Command.ITEM, 1); //Capture event when Ul initializes the menu items p o i n t c u t initMenuItems(List 1) : a r g s ( l ) && e x e c u t i o n ( * ImageList.initMenu(List)) ; //Add SMS Specific menu items to the main Ul a f t e r ( L i s t 1) : initMenuItems(1) { 1.addCommand(smsSendCommand); 1.addCommand(smsReceiveCommand); } Figure 4-5: Partial Source Listing for SMSAspect of MobilePhoto New menu commands for the S M S feature are defined as inter-type declarations (or introductions) in the aspect. The pointcut identifies the method in the base application where the menu items are initialized, and obtains a handle on the L i s t argument that stores the menu commands. The after advice then adds the additional commands that allow a user to send and receive photos over S M S . In a similar manner, the SmsAspect also defines a pointcut to capture the spot where the command handler (controller) receives user input and decides what action to take. There is advice defined in the aspect to handle events that are meant for the S M S feature such as pressing one of the S M S menu items. Finally, there is a third pointcut that captures when the S M S listener thread has received a system event indicating an incoming S M S photo from another user has arrived. 3 0 (The diagram of the pointcuts for the Sms Aspect is pictured in figure 4-4). This method of binding with AspectJ pointcuts and advice is used to integrate all ofthe optional features in the MobilePhoto application. A s an example, the U M L sequence diagram in figure 4-6 indicates the flow of execution when a user invokes the feature to send a photo over S M S . Note that the handleCommand () method in the BaseController does not contain logic to invoke the S M S command. It is only after the handleCommand () method completes that the SmsAspect pointcut is triggered, and the aspect executes advice to send the S M S message. Fu l l source code for the MobilePhoto application is available at http://www.cs.ubc.ca/labs/spl/ 22 User presses*'Send SMS ' menu item PhotoListScreeri BaseController Sm sAsbect SmsSen'derThread : commandAction() •4\ hcmdlcC curl m and 0 : startQ i : after hand leComm a ndActiohQ advice i iSm stepect:executesi'afteri;advice toistartsthe thread IhatsVMlli'senddhe photo s Figure 4-6: Sequence Diagram to Send SMS (AspectJ) 4.3 Managing Multiple Features Using Precedence One of the difficulties in managing a large collection of optional features for an application is that some features may conflict with, depend upon or otherwise interact with other features. Effectively managing the possible combinations and dependencies for a complex product line can require a lot of effort, and is beyond the scope of this thesis. AspectJ provides one simple construct that can provide some control over this problem. The d e c l a r e p r e c e d e n c e statement allows you to specify the order in which advice is applied. This technique is especially useful to help manage multiple features that offer similar functionality. For instance, the MobilePhoto application has one feature that w i l l play a custom ringtone when a user receives an incoming call. Another (separate) feature has the ability to pop-up the photo of a person calling during an incoming call. These two features potentially conflict with one another, or could also be combined together to play a custom ringtone and display the caller's photo. In this scenario, we have used the declare precedence statement to control which action happens first. The line of code in figure 4-7 indicates that the ringtone feature has higher precedence over the feature that displays a user photo: 23 declare precedence : Mp3lncomingCallAspect, MotoIncomingCallAspect; Figure 4-7: Declaring Precedence to Manage Feature Interaction in AspectJ This specifies that for after advice, the ringtone feature executes last. (For before advice, it would execute first). We have not investigated any methods of dynamically preventing an optional feature from executing i f it directly conflicted with another feature built into the application. This would have to be done by manually excluding one of the conflicting features during the build process. Section 5.3 discusses the potential of a third party Eclipse plugin that can help (statically) manage these situations during the build process. Using this approach puts the burden of managing features on the developer, because features must now be aware of when they are dependent on or interact with other feature components. 4.4 The Build Process Building a J 2 M E application is not straightforward even when a product-line is not considered. It requires a few additional steps compared to developing standard desktop Java applications. A t a minimum, you must additionally preverify the byte-code, define application descriptor properties in a J A D (Java Application Descriptor) file and package the application as a J A R (Java Archive) file. After these steps are complete, you may elect to obfuscate the code to reduce the size of the application, and might need to use a utility to convert the byte codes into a platform specific format (e.g., .cod for the Blackberry platform or .pre for Palm platform). Devices may also support different external resource formats, such as mp3 versus .wav for audio playback, or place constraints on memory usage, image sizes, size restrictions for sending wireless data etc. The list o f constraints to manage increases with the number of devices you need to support, which adds to the complexity in managing the build process. To add to the confusion, most of the major device vendors have released proprietary S D K ' s , IDE's or toolkits to help developers write applications for their specific platforms. This group includes the (generic) Sun Wireless Toolki t 3 1 , Blackberry Java Development Envi ronment , Nokia Developer's Suite for J 2 M E 3 3 , Motorola iDen S D K for J 2 M E 3 4 , Siemens Mobi le S D K 3 5 , Palm OS (J2ME) Developer Suite 3 6 , and the Qualcomm B R E W S D K 3 7 to name a few. http : / / i ava. sun, com/products/si wtoolkit/ http://www.blackberrv.com/developers/downloads/ide/index.shtml http://www.forum.nokia.com/tools http://idenphones.motorola.com/iden/developer/developer tools, isp http://www.siemens-mobile.com/developer/ http://www.palmos.com/dev/tools/dev suite.html http://brew.qualcomm.com/brew/en/developer/resources/dev resources.html 24 To alleviate some o f this complexity, we used Apache's A N T and an open source extension to it called Antenna 9 that offers additional support for J 2 M E specific build tasks. Although A N T does not eliminate all of the dependencies on installing third party IDE's , S D K ' s or tools, it does let you separate the build process into a simpler chain of tasks and run a single command line script to run the necessary steps. Because this thesis focuses on the variability of optional and proprietary A P I support across micro devices, the build system has to make it easy for a developer to select which optional features should be compiled into the final application or product instance. That is, the compilation and build process should enable the inclusion of only those features that are supported by a device. This criterion is important because of the restrictions mobile vendors and operators place on the size of applications that can be installed. A s an example, Nokia Series 40 phones place a 64 K B maximum on the size of Midlets compared to some Nok ia Series 60 phones that support up to 4 M B . 4 0 Other manufacturer's have varying application size restrictions, with some older models allowing as little as 32 K B for your entire application. Having control over the included features would make it easier to keep the application size minimal, define product configurations (combinations of features and base code) and eventually allow one to perform bulk builds for a complete line of dozens of different platforms. For example, i f you are running a build for the phone platform then you should be able to easily specify that you want the feature to send photos via S M S . However, i f you were building the same application for a Blackberry or Palm device, you want to ensure this feature is not included, because it is not supported on those platforms and its inclusion would cause the application to be larger than necessary, and to most likely throw exceptions about missing classes when the Midlet loads. The control of feature inclusions for MobilePhoto is done during the build stage by using a configuration file. A list is maintained that includes the names of all source files or packages (directories) to be included in a particular build. This technique also hinges upon the requirement that the base application is not dependent (from a compiler perspective) upon any of the optional features. Thus excluding a feature w i l l not cause the build to fail. A l l classes for a given feature are also isolated in individual packages. This makes it easier to select a single directory when you want to include a feature in the build. This build configuration compile list, along with a properties file that specifies environment variables such as the classpath, library locations, conversion utilities etc. are used as input to the build process. Figure 4-8 shows the components used in the build process for MobilePhoto. http://ant.apache.org/ http://antenna.sourceforge.net/ http://www.forum.nokia.com/main.html 25 Build properties List of sources to include (base + optional features) - clean - compile - preverify - package A N T build script / \ 1 Resources and source files Final executable Figure 4-8: MobilePhoto Build Process Using this procedure keeps the product line builds simple by isolating the variable components to a properties file and a build configuration compile list. Before creating a new product instance, we update the build properties to ensure the classpath settings are correct, and we update the compile list by selecting which features should be included in the build. Wi th the A N T and A J D T plugins for Eclipse, we are able to control the entire build process within the IDE. Figure 4-9 shows the Eclipse workspace for MobilePhoto with the A N T view in the bottom right pane and the compile list view in the top right pane. 26 \ . \ \ 1 i k M l l U l i t [• I | | i50 I 'lAtfuttli fjle Edit Navigate Search project Eun V£mdow • u v • ^ • ' i • _ ,f* Package Explorer \ Hierarchy ^ S : ^ >Mob4lePhoto [BTTRAIN-LAB] ;+! >ubc;mjdp.photoalbum.blackberry' • + :-fi$ >ubc.rrudp.photc»a]bum,core.ii •+;•••% >ubc.rrudp.photoa!bum.motorola + 03 >ubc.midp.photoa!bum.pim i.+j-J^ >ubc.midp.photoa!bum.Siemens i f B >ubc,midp.pnotoalbum.sms ft]NetworkScreen.java 1.3 (ASCII •= l+lSMSRecelverThread.Java 1.4 (i ; SMSSenderThread.Java 1.4 (A:! =- •• jj| S^SMSAspectlaJiUa^CBiriary); i :+'"(£r' >aic-compiled \ >•& >)2se-c!asses < i^i' Xnidp-compiled >prc-compi!ed >rapc-compiled '••43 >build;xml 1.3 (ASCII -kkv) I ; >defaiit.lst 1.1 (Binary) *5d build, xml ^ tl) 0 ' 5 * * ^ " -default. Isi l«* f7j ScreenContrcJIer 1 B-EItc> nntdp B ' 0 ^ > photoalbum sB-QifSj' blackberry cor© S - Q l S ' motorola, £ ! • • • • • .pim ith-Dtp- Siemens &i -0 i£V sms-£ S GTeamSynchr.. 3> Debug ^ J ^ v a ^ C V 5 Reposito, | P'] fllackBerryEtnaH jj/J Cmail5er.de/Thr i TsMSAspect at 0 b!) NetworkScreen. Java 5M5Aspect.aj SMSReceiverThread.java SMSSender Thread. Java Problems Console f,jSc Af* *E3^. * - , i-jfe MobilePhoto Prototype [full-build] aspect j-compfe :••••<*=; aspectj-mit ~ # clean • ••(§) copy-ajruntime-classes copy-image-files .-6u info ••--(&} make-jar ; t*) make-prc C*J midp-compBe (%) rrudp-preverify ••••.(S.3 rape-compile («? run-default-phone-emulator j - run-mcttorola-phone-emulator ;" run-siemens-pr^e-emulator -- t*5 run-wtk2-default-phone-emulator name="full-build", Figure 4-9: Eclipse View with A N T and Build Configuration Plugins 27 5 MobilePhoto Implementation using Object Oriented Programming Aspect-oriented programming is one approach to tackling the device A P I fragmentation problem for mobile devices. But the use of aspect-oriented technology in industry is still gaining momentum, and particularly in the mobile space it is not a commonly utilized technique. Hence, to effectively evaluate the AspectJ approach for developing mobile product lines we compared it with current practices used in industry. This chapter discusses the details of how the MobilePhoto application was written using standard object-oriented (OO) programming practices and design patterns [3]. In this section, we discuss an object-oriented approach to handle the variance in product instances due to features that are implemented using optional or proprietary A P I ' s which are not supported by all platforms. It should be noted that aspect-oriented programming and object-oriented programming are complementary, not competitive technologies. In fact, the AspectJ version of MobilePhoto uses standard object-oriented techniques that are available in Java (J2ME). The intent of our object-oriented implementation is to compare how well known programming techniques handle the device A P I fragmentation problem with mobile devices, as compared to aspect-oriented techniques. Many developers are turning to the use of J 2 M E preprocessors4 1 to handle the different device characteristics in their Java applications. Some common design patterns such as the Chain of Responsibil i ty^] can also help structure mobile product line development. A given configuration of the system (figure 5-1) uses a preprocessor to bind only those features that are supported by a target device. Each feature implements its own controller to handle actions specific to it. 4 1 http://antenna.sourceforge.net/#preprocess. http://www.i2mepolish.org/clocs/custom-preprocessor.html. http://www.netbeans.org/kb/articles/quickstart-mobilitv-40.html. http://eclipseme.org/ 28 Chain of Responsibility Each feature implements a controller to handle feature specific actions c 1 /fder o | • "5 ST ! .2 0 5 ; ifdef a - i III m s £ ! ifdef j | | | | CM - > 1 /fete/ Preprocessor statements are used to bind features to base application Email Messaging Feature SMS Messaging Feature Final Application Digital Photo ( ) Feature J Figure 5-1: O O P Patterns and Preprocessor Applied to Mobile Product Lines This chapter discusses how we incorporated these practices in the product line, and briefly comments on a proprietary Eclipse plugin called Pure Variants that is helpful in managing the dependencies and conflicts of optional features that are used in MobilePhoto. For the object-oriented implementation of MobilePhoto we built the same combination of product instances as the aspect-oriented version. Table 5-1 lists these 4 2. Table 5-1: MobilePhoto Product Instances (Object-Oriented) Base Application only Base Application + S M S Base Application + S M S + Caller Photo Base Application + S M S + Caller Photo + P I M Base Application + S M S + Caller Photo + P I M + Play Ringtone Base Application + Email The object-oriented version of our MobilePhoto application was also tested on the same set of emulators and hardware that the aspect-oriented version was tested on: • Palm Tungsten C (Hardware device) • Nokia 6600 (Hardware device) • Sun Generic Wireless Toolkit Emulator (v. 2.1) • Sun Generic Wireless Toolkit Emulator (v. 2.2) • Siemens CF62 Emulator The final Jar files for these applications are available for download at http://www.cs.ubc.ca/labs/spl/ 29 • Siemens C X 6 5 Emulator • Siemens SL55 Emulator • R I M Blackberry 7200 Simulator • R I M Blackberry 6700 Simulator • R I M Blackberry 5800 Simulator • Palm OS Emulator (with Sun M I D P 1.0 K V M for Palm) • Palm OS Simulator (with I B M J9 K V M for Palm) • Motorola i730 Emulator • Motorola i830 Emulator • Motorola i860 Emulator • Nokia 3410 Emulator • Nokia 7210 Emulator • Nokia Series 60 Emulator Note that MobilePhoto jars were only tested on emulators or hardware that supported .the particular feature-set of a given version. 5.1 De-coupling Optional Features Using OO Design patterns A s with the aspect-oriented design, the key in allowing optional features to be easily added or removed from an application written using object-oriented programming is ensuring that the base application is not dependent on them for compilation or execution. The package structure for the object-oriented implementation of MobilePhoto is the same as the aspect-oriented version (See figure 4-2). Optional features still needed to add functionality that would let the controller determine what action to take when they are invoked. Our object-oriented approach uses inheritance, the chain of responsibility design pattern and a Java preprocessor to accomplish the de-coupling of components. The preprocessor was only used when necessary to ensure the source code would not become cluttered with non-Java (preprocessor) statements and syntax. The object-oriented implementation used an M V C design where each feature implemented its own controller. The object-oriented version of the MobilePhoto implementation includes a C o n t r o l l e r l n t e r f ace interface. This interface is implemented by the B a s e C o n t r o l l e r and all 'feature specific' controllers extend the B a s e C o n t r o l l e r class. Figure 5-2 shows the class diagram for the object-oriented version of the S M S feature. 30 BaseMessaging BaseController HetvgorkScreen SmsMessaging SmsReceiverThread SnisController SmsSender Thread Figure 5-2: Class Diagram for SMS Feature (OOP) In figure 5-2 the B a s e C o n t r o l l e r and BaseMessaging classes are part of base application packages and the other classes form the S M S feature. Following the chain of responsibility pattern, on startup all the controllers (BaseController plus one controller per feature) are instantiated and each controller w i l l maintain a handle to the next controller in the chain. When a menu item or button is pressed, the first controller in the chain (BaseController) calls its handleCommand ( ) method to see i f it can satisfy the request. If it cannot, then control is passed to the next controller in the chain. The command progresses down the chain until one of the controllers is able to satisfy the request and take the appropriate action. Using this approach allows us to limit the use of preprocessor statements to creating new controllers in the main Midlet class and ordering the chain. A snippet of the source code from this section is in figure 5-3. 31 root-Controller = new BaseController ( t h i s , model); prevInChain = rootController; //#ifdef includeSmsFeature nextlnChain = new SmsController ( t h i s, model); prevInChain.setNextController(nextlnChain); prevInChain = nextlnChain; //#endif //#ifdef includeBlackberryEmailFeature nextlnChain = new BlackberryEmailController ( t h i s, model); prevInChain.setNextController(nextlnChain); prevInChain = nextlnChain; //#endif Figure 5-3: Partial Source Listing of MainUIMidlet Class (OO Version) In the current implementation of MobilePhoto there are six optional features, and therefore six sub-classes of the B a s e C o n t r o l l e r implementation that are initialized in the chain. It is important to note that the order of the controllers in the chain is significant. This ordering is particularly crucial where two features offer similar functionality, such as ones that take action when intercepting incoming phone calls. In the example where the feature that plays a custom ringtone is built into the application as well as the feature that displays a photo of an incoming caller, their order in the chain w i l l dictate which feature is invoked during an incoming call. With the object-oriented programming implementation, either the ringtone wi l l play, O R the photo w i l l display, depending on which one is first in the chain. 5.2 Binding Features to the Application using a Pre-Processor A popular (current) object-oriented solution to the device A P I fragmentation problem is to use a Java preprocessor to help manage device variability. Pre-processing functionality has already been integrated into the most popular open source J 2 M E utilities and Java IDE's . The Java preprocessors available are similar to the ones known from other languages like C and C++. A preprocessor is helpful when trying to maintain a single code base for several devices that have unique bugs, A P I support and hardware or software properties. Using a preprocessor allows for conditional compilation and inclusion of entire source files or small sections of code into another. Although preprocessor usage is often considered poor programming practice by object-oriented enthusiasts, it has been widely accepted by mobile device programmers who want to minimize the size of their J 2 M E applications. In the object-oriented version of our MobilePhoto implementation, the developer edits a properties file to indicate which optional features should be included by the preprocessor. For example, to include the feature that allows a user to send photos over S M S , and the 32 feature to display caller photos for incoming calls the following line must exist in the properties file: preprocessor.symbols=includeSmsFeature,includelncomingCallFeature Scattered throughout the source code of the base application are ifdef statements that tell the preprocessor to include relevant lines of code i f the symbol for a particular feature is defined in the properties file. A s mentioned in Chapter four, there are two points in MobilePhoto where optional features are integrated with the base code: extending functionality of the controller, and inserting new menu items to invoke the feature. This means we were able to limit our preprocessor usage to only two classes. We were able to further reduce the amount of preprocessor included code by implementing the Chain of Responsibility design pattern, discussed in the previous section. To illustrate further, the preprocessor statements and corresponding code used by the S M S feature are shown in figure 5-4. [imports] //#ifdef includeSmsFeature import ubc.midp.mobilephoto.sms.SmsController; //#endif [startApp()] I/#ifdef includeSmsFeature nextlnChain = new SmsController ( t h i s, model); pr e v I n C h a i n . s e t N e x t C o n t r o l l e r ( n e x t l n C h a i n ) ; prevInChain =•nextlnChain; //#endif PhotoListScreen (menu item addition): [class variables] 11#ifdef includeSmsFeature s t a t i c f i n a l Command smsSendCommand = new Command("Send SMS", Command.ITEM, 1 ) ; s t a t i c f i n a l Command smsReceiveCommand = new Command("Receive SMS", Command.ITEM, 1); //#endif [initMenuQ] I/#ifdef includeSmsFeature this.addCommand(smsSendCommand) ; this.addCommand(smsReceiveCommand); //#endif Figure 5-4: Partial Source Listings of MainUIMidlet Class (OO Version) Similar sections of the preprocessor tagged lines of code above are needed for each optional feature of the application. The six optional features in MobilePhoto quickly increase the number and complexity of preprocessor statements needed throughout the 33 code. The U M L sequence diagram in figure 5-5 shows the flow of execution when a user invokes the feature to send a photo to another user over S M S . Note that when the B a s e C o n t r o l l e r is unable to handle the action to send an S M S message, it passes control to the next controller in the chain. In this scenario, the SmsController is next in the chain. The type of controllers and the ordering of them wi l l depend on which features were included by the preprocessor and the order they are specified in the source code. User presses 'Send SMS' menu item PhotbListScreen BaseController SmsController: BaseController Sin sSenderThread : command Action© •4\ postCommandQ •41 haridloCorrl m and 0 •^gotNoxtControll eiQ ;: pdstCommandO : starto; 0 : handl eS om ma ndOrdurns f alsesif.curr^ Figure 5-5: Sequence Diagram to Send SMS (OOP) 5.3 Managing Multiple Features Using Pure Variants™ The focus of this research has been on implementation techniques that make it easy to include combinations of optional features that are supported by a specific device platform. However, it does not address the issue of feature modeling or managing the relationships between these optional features. To investigate the potential of enforcing relationship rules for features in our model, we used a third party development tool for the Eclipse IDE called Pure Variants 4 3 . The Pure Variants Eclipse plugin let us add a layer of abstraction on top of our J 2 M E object-oriented implementation. The tool allows a developer to define a feature model for your product line and configure attributes, relations and restrictions between the features. From our MobilePhoto design we arranged the features into groups, specified a type for each http://www.pure-svstems.com/Variant_Manai;ement.49-0.html 34 feature and defined relationships between features when necessary. The MobilePhoto features were grouped into a category of either 'Base Features', 'Address Book Features', 'Incoming Cal l Features' or Photo Transfer Features'. We also defined a new group called 'Bu i ld Environment Features' which does not technically include features in the application but it let us capture the variability of the build requirements such as classpath settings, J 2 M E platform versions and preprocessor usage. The ability to configure these build environment 'features' allowed us to automate the build process more effectively, as we wi l l discuss later. Feature types include: Optional, Mandatory, Or (select at least one from a group) and Alternative (select exactly one from a group). We also defined relationships between features where necessary to indicate dependencies or conflicts. Table 5-2 shows a summary of the groups, types and relations that make up the MobilePhoto feature model. Table 5-2: Pure Variants Feature Model for MobilePhoto Group Feature Type Relationships Base Create Photo Album mandatory Store Photo mandatory A d d Photo mandatory Delete Photo mandatory Label Photo mandatory V i e w Photo mandatory Address Book Link Photo with Address Book optional <Requires> Include P I M lib Photo Transfer S M S Photo Transfer optional <Requires> Include W M A lib <Requires> Target M I D P 2.0 Email Photo Transfer optional <Requires> Include R I M lib <Requires> Convert to R I M .cod Incoming Cal l Display Photo of Incoming Caller alternative <Requires> Link Photo with Address Book <Requires> Include Motorola lib Play Ringtone of Incoming Caller alternative <Requires> Link Photo with Address Book <Requires> Include Motorola lib Bui ld Environment Use Preprocessor optional <Conflicts> Use Aspect Weaver Use Aspect Weaver optional <Conflicts> Use Preprocessor Use Obfuscator optional Convert to Palm .pre optional 35 Convert to R I M .cod optional <Requires> Target M I D P 1.0 Target M I D P 1.0 optional Target M I D P 2.0 optional Include W M A lib • optional <Requires> Target M I D P 2;0 Include R I M lib optional <Requires> Convert to R I M .cod Include Motorola lib optional Include P I M lib optional There are a number of ways you could define your feature model to give you the desired level of control during the build process. If desired, we could have specified that the 'Display Photo of Incoming Caller ' and 'Play Ringtone of Incoming Caller' features were both optional instead of alternative i f we wanted to allow both features to be installed together to display a photo and play the ringtone on an incoming call. We could also create sub-groups under the 'Bu i ld Environment' feature group to include 'Compile Options', 'Optional Libraries' and 'Target Device' . This would allow you to define alternative types within compile options (e.g., Choose exactly one of Preprocessor or Weaver) or. obtain finer control of the target devices by defining sub-groups of M I D P 1.0 and 2.0 to include specific device models (e.g., Nokia 6600 could be part of the sub-group 'Target M I D P 2.0'). Once the feature model is defined, Pure Variants provides a visual editor within Eclipse to let you select checkboxes for the features you want to include in your product instance. There is a checker included that w i l l validate your selections to make sure the relationship and type rules are satisfied so there are no missing requirements or conflicting elements. Figure 5-6 shows the MobilePhoto feature model in the Pure Variants Eclipse window. 36 3 MobilePhoto_Optional_Features.xfm • I MobilePhoto [Root] B • | Base Features [MobilePhoto_Core] • 5 Create New Photo Album [MobilePhoto_Core_NewAlbum] s Edit Photo Label [MobilePhoto_Core_LabelPhoto] •/ 5 View Selected Photo [MobilePhoto_Core_ViewPhoto] v v Delete Selected Photo [MobilePhoto_Core_DeletePhoto] • | Add New Photo [MobilePhoto_Core_AddPhoto] iJ V Reset Image Data [MobilePhoto_Core_ResetData] B •/ | Build Environment 'Features' [MobilePhoto_BuildResources] I+J Q ? Optional Libraries [MobilePhoto_BuildResources_Lib] !_] ? Default Images [MobilePhoto_BuildResources_Images] [J 9 AspectJ Build [MobilePhoto_BuildTask_AspecUCompile] Lj 'j1 Use Pre-processor [MobilePhoto_BuildTask_Preprocess] l j V Obfuscate [MobilePhoto_BuildTask_Obfuscate] RI • ^ Target J2ME Platform [MobilePhoto_BuildResources_TargetPlatform] !+] Cl Properties File [MobilePhoto_BuildResources_Properties] fcj LJ 1* Address Book Features [MobilePhoto_AddressBook]. [J f AssoclateiPhoto with:'Address:Book:Entr,yj[Mob!JeP|ra^  View Photo for Address Book Entry [MobilePhoto_AddressBook_PhotoView] i_J * Associate Ringtone with Address Book Entry [MobilePhoto_AddressBook_RingtoneAssociate] B •/ ? Photo Transfer Features [MobilePhoto_Transfer] 0 f SMS Photo Transfer [MobllePhoto_Transfer_SMS] • f Email Photo Transfer (RIM) [Mobi!ePhoto_Transfer_RIMEmail] • ? HTTP Photo Transfer [MobilePhoto_Transfer_HTTP] El Q f Incoming Call Features [MobilePhotoJncomingCall] i • I Play Ringtone on Incominr Display Photo on Incoming Call (Motorola) [MobilePhoto JncomingCall_DisplayPhotoJ<lotorola] Play Ringtone on IncomiH Feature Models j i^ ] Family Models | '^ Problems | S Console 53 Id: ikgpANUrVxnX09dv4 Unique Name: MobilePhoto_IncomingCalI_DisplayPhoto_Motorola Visible Name: Display Photo on Incoming Call (Motorola) Class: ps:feature Description: This feature is only available to Motorola phones that support the Motorola Telephony API. It will display a picture of the person calling if the feature is turned onj and the user Figure 5-6: Screen Capture of Pure Variants Plugin with MobilePhoto Feature Model In figure 5-5 you can see that when the 'Display Photo on Incoming C a l l ' feature is selected, the tool automatically highlights the 'Associate Photo with Address Book Entry' feature because of the Requires relationship we defined. Using the Pure Variants plugin also enabled further automation of the build process. The plugin includes functionality to generate an X M L document from your feature model and allows you to transform it with an X S L style sheet, based on the features you select from the model. We defined an X S L transformation that automatically generates an A N T build file specific to the features you select for a product instance. The transformation is based on a common build.xml file template and uses the selected features as input to generate a custom build file specific for a target device. The selected features help generate the appropriate classpath settings, include the appropriate source files, and insert additional build tasks that are only necessary for certain platforms, such as converting to .pre files for Palm, or using the R A P C compiler for Blackberry. For example, the main task in the Pure Variants version of our build script template is defined in figure 5-7. 37 < ! - - ===== = == = == = == = = = = == = = = == = = == = = = = = == = = ====== = = = = = = ==== = == = ====== = = - - > <!-- F u l l B u i l d (Default Target) --> < j - - = ==== = = = = = = = = = === = = = = = ======= = = === = = = = = = = = === = = = = === = = = = ==== --> <target name="full-build"> < a n t c a l l target="clean" /> <an t c a l l target="midp-preprocess" condition="pv:hasFeature( 1BuildTask_Preprocess')" /> <a n t c a l l target="midp-compile" /> <a n t c a l l target="copy-image-files" /> <a n t c a l l target="midp-preverify" /> <a n t c a l l target="make-jar" /> <a n t c a l l target="rapc-compile" condition="pv:hasFeature('TargetPlatform_RIM')" /> <a n t c a l l target="make-prc" condition="pv:hasFeature('TargetPlatform_PalmPRC')" /> </target> Figure 5-7: Partial Source Listing for Main Build Target (OO Version) Notice in figure 5-7 that there are three conditional ant calls in the full-build task that w i l l only be generated in the targets build.xml file i f certain attributes or features are selected in the Pure Variants configuration editor. The midp-preprocess task invokes the preprocessor, and is only included i f the developer checked the preprocess attribute from the 'Bui ld Environment' feature group. Similarly, the rape-compile task and make-prc tasks are only generated i f you are building for the R I M or Palm platforms respectively. A n updated diagram of the build process using Pure Variants is shown in figure 5-8. 38 Build properties Feature Selection Feature Model - clean - compile - preverify - package - src list A N T build script / Final executable Resources and source files Figure 5-8: MobilePhoto Build Process Using Pure Variants The Pure Variants plugin was only tested using the object-oriented implementation of MobilePhoto, but could also be integrated with the AspectJ version. The only output is a generated build script, so the main difference would be adding AspectJ compile tasks to the build.xml template. 39 6 Evaluation To assess the advantages and disadvantages of using aspect-oriented programming to address the device A P I fragmentation problem for mobile devices, we compare, qualitatively and quantitatively, the two different techniques used to implement the MobilePhoto prototype. Our evaluation builds on categories introduced by [19] to compare an AspectJ implementation with an object-oriented implementation. Our analysis focuses on the effectiveness of each technique to build a product line, and speculates on how each approach might work with more complex or wide-ranging product lines for mobile devices. Almost all o f the source code used in the AspectJ implementation of MobilePhoto is the same as the code in the object-oriented version. Both followed the same architecture and design and adhered to the requirement of maintaining component independence such that base components can be compiled with or without optional components. The key differences in the two implementations were how to achieve de-coupling of optional feature components, how to bind optional features into the core application, and how to manage feature interaction. The rest of this chapter compares these implementations in terms of modularity, scalability, complexity, tool support, platform support and quantitative analysis of size and resource usage. 6.1 Quantitative Analysis One of the most important factors to consider when choosing an implementation technique for mobile development is the size and performance of your final application. Most J 2 M E enabled devices have little storage space for data, and have limitations on the size of the application that can be installed. These micro devices also have less heap memory available and slower processors which mean you should avoid using technology that hinders your application in these regards. Our evaluation of the AspectJ implementation and the object-oriented implementation of MobilePhoto shows that the application size w i l l always be larger when using AspectJ because you must include the AspectJ runtime classes with your application jar file. Table 6-1 compares the size of the jar files for each implementation when only the base components are used, and when all the components are compiled into the application. Table 6-1: MobilePhoto Jar Size Comparison MobilePhoto AOP (Base) MobilePhoto OOP (Base) MobilePhoto AOP (All)* MobilePhoto OOP (AH)* Final app size [jar] 200 K B jar 165 K B jar 251 K B jar 213 K B jar The aspect-oriented implementation jars listed in table 6-1 were created by including the classes found in the standard AspectJ runtime without modification. The size of this jar (aspectjrt.jar) is 40 K b . We were able to reduce this size slightly by removing all of the 40 AspectJ features that are not supported in J 2 M E , removing all the comments from the source and running it through an obfuscator. The size of our modified (and obfuscated) AspectJ runtime jar was 29 K b 4 4 . Table 6-2 shows measurements of heap memory use 4 5 at specified intervals during the MobilePhoto application lifecycle. It compares equivalent product instances for the aspect-oriented and object-oriented implementations after invoking various commands in the application. Each feature listed was executed in isolation, immediately after application launched to ensure that data for one feature invocation is not confounded by data from another. The maximum heap size for the emulator used was 2 M b (-2000 Kb) , therefore whenever the memory usage reached the 2000 K b upper limit, garbage collection occurred and cleared the memory back to 0. The data indicates that the memory usage of the aspect-oriented implementation is slightly better than the object-oriented implementation, but not significant enough to make a noticeable difference during use. A minor note is that the object-oriented version used more memory when the application launched, as you can see in every version except the base, it garbage collected before the aspect-oriented version did. Table 6-2: MobilePhoto Heap Memory Comparison Launch Select Album View Photo Display Caller Photo List Contacts A O P Base 1935 1953 166 OOP Base 1936 1954 167 A O P Base + SMS 1936 156* 204 OOP Base + SMS 224* 242 291 A O P Base + SMS + Caller Photo 1936 168* 217 244 OOP Base + SMS + Caller Photo 275* 294 343 376 A O P Base + SMS + Caller Photo + P I M 1936 186* 234 264 213 OOP Base + SMS + Caller Photo + Increase P I M 286* 306 354 389 200 indicates garbage collection occurred at 2 Mb, and dropped back to 0 before increasing again We found that the source code metrics for both implementations were similar. The number of classes (or aspects) used and the total lines of code were either identical, or 4 4 We used the open source ' jarg' (Java Archive Grinder) obfuscator (http://iarg.sourceforae.net") 4 5 The Motorola iDen S D K M e m o r y Moni to r was used to record heap data using the i860 device emulator 41 only slightly higher in the object-oriented implementation. There was also little noticeable difference in the time to build each executable using A N T . Table 6-3 below provides details o f MobilePhoto source code metrics. Table 6-3: MobilePhoto Source Code Metrics Comparison MobilePhoto MobilePhoto MobilePhoto MobilePhoto AOP (Base) OOP (Base) AOP (All)46 OOP (All)46 # build script 7+ 6+ 7+ 6+ tasks # Classes (& 16 (no aspects) 16 41 (35 classes + 41 Aspects) 6 aspects) # Lines of 550 565 1481 (227 from 1524 Code Aspect code) Build Time 19 Seconds (to 18 Seconds (to 31 Seconds (to 29 Seconds (to run Ant build run Ant build run Ant build, run Ant build, with ajc) with javac) no conversions) no conversions) The most significant finding of the quantitative analysis is that any J 2 M E and AspectJ implementation w i l l increase your application by approximately 29 K b . This is important when developing for devices with tight restrictions on the size of application. In most other quantitative categories we found the difference between the AspectJ and object-oriented implementations to be insignificant. 6.2 Modularity and Flexibility A likely concern for mobile developers is the maintenance effort involved in managing the source code and build process as a system evolves, given the many different combinations of features that a product instance allows. Better modularity in the application tends to lead to less maintenance. When updating an existing system with new features, it can be difficult to cleanly isolate all the functionality required by a feature into a separate module. Source code statements associated with a feature implementation may be scattered throughout the rest of the components in the base application. In the aspect-oriented implementation, AspectJ helped to extend the base application while keeping the logic and code associated with a particular feature in a separate module. In the AspectJ implementation of MobilePhoto, we were able to modularize each of the optional features. The implementation of each optional feature is contained in a few files (classes and aspects) that are grouped into a single Java package. If, for example, a change or update is required for the feature that handles the sending and Indicates the application with ' a l l ' features was compiled. Note that such a configuration would not run on any current devices since some features conflict. (Ie. N o such device that supports the Blackberry email feature and Siemens features together) 42 receiving of digital photos over S M S , a programmer can focus on classes in the ubc .midp .mobilephoto. sms package. Including or excluding this feature when building a product instance simply requires the developer to select a checkbox in the Eclipse build configuration plugin for the named package that corresponds to the S M S feature. Changing the logic associated with a feature requires updating one or more classes or aspects in the package for the optional feature. Changing the way the feature integrates with the base application components requires updating the source of the aspect. Configuring the build process to include an optional feature in the final product requires updating a build compile list to add the features' package. In general, maintaining the AspectJ implementation for MobilePhoto is a straightforward process. The 'pure' object-oriented implementation of MobilePhoto modularizes the programming logic associated with optional features, but does not prevent the scattering of source code changes needed to integrate the features with the base components. For example, in the object-oriented version the majority of the source code associated with the S M S feature is still contained in the ubc .midp .mobilephoto. sms package. However, to integrate this feature with the base application it was also necessary to modify classes in the base components such as MainUIMidlet and PhotoListScreen with preprocessor statements. Using the preprocessor allowed us to maintain the simplicity of the build process, so that editing a property file would trigger the inclusion or exclusion of the integration code based on preprocessor 'ifdef tags. Incorporating the Chain of Responsibility design pattern improved things further so that instead of having to embed the controller logic for a feature directly in the BaseController class, each feature maintained its own extension of the controller that was only part of the chain i f the feature was included in the build process. Therefore in the object-oriented implementation of MobilePhoto, changing the logic associated with a feature only required updating one or more classes in the feature's package. Changing the way the feature integrates with the base application components was slightly more time consuming because the developer has to update the necessary base components with the source code to integrate optional features that is embedded using preprocessor tags. Finally, configuring the build process for the object-oriented version remained straightforward by updating the build compile list in addition to the properties file to specify which features should be preprocessed. Another item to consider is the granularity each technique can achieve for the developer to change and control the feature interaction and integration at fine grained levels. In the object-oriented version, there are few constraints on where new source code related to a feature can be added to the base application classes, assuming the developer is wil l ing to make substantial modifications at times. A wide range of changes is possible because preprocessor statements can be written anywhere to manipulate the actions associated with a feature. However, with AspectJ the developer is limited by the pointcut language that defines where features can be bound to base components, and what type of advice can apply. This lack of fine granularity is particularly evident using AspectJ with J 2 M E , where certain features of AspectJ are not available (see section 6.4 for details on AspectJ support with J2ME) . One option is to use a preprocessor in combination with AspectJ, 43 however the increased flexibility and finer granularity would be offset by the loss of modularity due to scattered preprocessor statements. A final matter that should be noted is the impact of binding time - the point in the development cycle at which the features of your product instance become fixed, and your variability is decided[20] - on flexibility. The later in the development cycle this binding occurs, the greater the flexibility. Al lowing an end user to select their optional features for a product during the download or installation stage provides more flexibility than requiring a programmer to pre-code the variability at design or during compilation. The time of binding has an impact on scalability as well , because as more (unique) product instances are offered, more effort is required to update or customize each product instance during the build cycle. In both MobilePhoto implementations, the binding time occurs during compilation and linking. Technically, in the object-oriented implementation it occurs just prior to compilation when the preprocessor is run, and in the AspectJ version it occurs just after compilation when weaving takes place at the bytecode level. However, from the developer standpoint this has no effect on effort or flexibility because in both scenarios the developer merely checks a box to specify which optional features are desired, and then runs the build script. Future work might consider whether or not dynamic weaving techniques in aspect-oriented programming [21] could be used to delay binding further and increase flexibility. Wi th the current size constraints of micro devices, dynamic weaving may not be applicable because dynamically including features implies that all o f the potential features one may want to include would have to be deployed to the device initially, making the application larger than necessary. However, dynamic weaving combined with negative variation product line techniques[19] might make sense. Dynamic weaving could make the deployment process more flexible i f a developer were able to build an application containing all o f the optional components available, and then apply empty advice at runtime to replace or remove features that are not supported by the device it is deployed to. 6.3 Scalability The flexibility and ease o f maintaining an application may not be the highest priority when producing a system that changes infrequently and only needs to support a single platform. But when you are targeting numerous mobile devices with hardware and software that is changing at a rapid pace, scalability becomes more of a concern. It is important to consider how well your product line development process can scale in terms of the number of optional features available to products and the number of devices you must support. The number of features you can squeeze into a single application instance w i l l be limited by the amount of memory or disk space the hardware vendor allows for third party applications. But as hardware gets cheaper, the number of features you can include wi l l increase. Especially i f you are targeting higher end devices that offer larger amounts of resources to play with. For the AspectJ implementation, creating most additional features requires adding additional packages (one per feature) that contain the Java 44 implementation logic and the aspect that integrates the functionality into the base application. The object-oriented version requires adding new packages for new features, and updating various classes in the base application to integrate these features using preprocessor statements. When dealing with relatively few features, this is not too difficult to manage. But the wide range of hardware peripherals that micro devices offer can lead to a large array of optional features to plug into your product line. This results in many lines of preprocessor tagged source code scattered throughout the components of the base application. The MobilePhoto application has six optional features, which means multiple sections of code in the base components must contain six embedded preprocessor statements in every area you need to integrate these features. For example, in the MainUIMidlet class, there are preprocessor tagged insertions of code for import statements (one for each feature), and code to create new instances o f sub-controller objects and add them to the chain of handlers. This is multiplied by six, since there are six optional features. A s the number of optional features grows, the source code in the object-oriented version of the base application becomes littered with ifdef statements, making it harder to read and understand how a particular feature interacts with the application, and how it interacts with other features. Being prepared to handle an increasing number of optional features is good practice, but in the mobile space it is probably not as important as being able to handle an increasing number of hardware devices in your product line. The most popular genre of J 2 M E applications currently on the market is mobile gaming. In general, there is not a great deal of variability in the gaming features, but there is a large demand to support an increasing number of devices. In our case of building mobile product lines, scalability refers to whether your development and build process can handle dozens or even hundreds of different device models. Given the flexibility provided by the aspect-oriented approach, scalability in this context relates to the level of automation that can be achieved in the build process. The main parameters to the build process vary by device in terms ofthe libraries needed during compilation (e.g., M I D P 1.0 vs. M I D P 2.0, or including proprietary Blackberry or Nokia libraries), the inclusion or exclusion of source components for optional features, and the addition of build tasks that are specific for a particular device (e.g., converting J A R files to native Palm OS or R I M OS format). The object-oriented implementation and the AspectJ implementation are essentially equal in this regard, since the standard build process is the same for both implementations. The use of A N T X M L files to manage the build scripts helps keep things simple and makes it easy to automate tasks. In the cases we tested, supporting a new device in the build system was trivial and involved adding a new A N T task only i f it was necessary to convert the J 2 M E jar file into a platform specific format (as was the case for both Palm and Blackberry devices) and updating properties such as paths to the IDE or toolkit install directories to the location of the conversion utilities. When new features were added to the application, we needed to update the list o f source files in the compile list and update the classpath settings i f new optional or proprietary libraries were required during compilation. The task of updating the compilation list was made easier in the Eclipse IDE by using the feature of the A J D T 45 plugin 4 7 that scans your source code directory and provides a check-box to indicate which packages should be compiled into the application. The A J D T plugin is intended for AspectJ development, but the build configuration selector generates a file that can be used with standard A N T build tasks and was also used for building the object-oriented implementation of MobilePhoto. B y using A N T and the A J D T Eclipse plugin mentioned, executing a build for different devices was as easy as checking off different combinations of features, and double clicking the ant script. Although we were able to use a single build file for all the product instances, updating the device specific properties each time might become tedious as the number of devices to support grows very large. One option to improve the scalability in this regard is to automatically generate a new build script based on the target platform and features selected. We tested this approach with the Pure Variants plugin (see section 5.3) and it worked well. This frees the developer from having to edit build files or manually invoke additional build tasks that are only required by certain devices. A s the number of devices to support grows, the developer can quickly build product instances by checking a few boxes, generating the target build script and executing a single A N T task. This leads to improved scalability in the development cycle because there is less work managing the build process. Automating the build tasks would require the same effort for the object-oriented and AspectJ implementations, so scalability in this regard was equal. 6.4 Multi-Platform Support One issue we encountered when deploying an AspectJ-based application on mobile platforms is that AspectJ was not designed to work with the core J 2 M E class libraries. To execute Java applications that have aspects woven in them, the AspectJ runtime 4 8 must also be deployed to the device and run within the context of whatever virtual machine is installed on your phone or P D A . The AspectJ runtime used in this research (AspectJ v 1.2.0) is intended to be used with a J2SE virtual machine. A s a result, there are a number of classes in the runtime that depend upon Java libraries that only exist in the standard Java environment, and that are not available in the micro edition version. Y o u can still deploy and utilize the AspectJ runtime on J 2 M E platforms but the limitation impacts J 2 M E and AspectJ development in two areas. The first area of impact is the extent to which the developer can access information about a join point. Specifically, J 2 M E does not include support for reflection, and has very limited threading capabilities. Although we have not rigorously tested what parts of the AspectJ runtime w i l l work or fail with J 2 M E , there are two notable restrictions that we found. The lack of reflection in J 2 M E means that thisJoinPoint cannot be used in advice. The thisJoinPoint construct of AspectJ uses reflection to allow a programmer to capture static and dynamic context information associated with jo in points. For instance, you can obtain access to the target object, the execution object and the method http://eclipse.org/aidt/ http://eclipse.org/aspecti/ 46 arguments using t h i s J o i n P o i n t . For our prototype application, this would have made it easier to access the L i s t objects during menu initialization, or accessing controller objects after the command handler executes. This limitation was not a major setback, and we were able to work around it by implementing wrapper methods for the join points, and adding additional parameters that could be accessed using the args keyword of AspectJ. For example, in standard AspectJ, we can write the following initMenultems pointcut: > p o i n t c u t initMenultems() : e x e c u t i o n(* Ph o t o L i s t S c r e e n . i n i t M e n u ( ) ) ; In our advice, we can update List object that stores the menu items by using: (PhotoListScreen)thisJoinPoint.getTarget().getList().addCommand(n ewCommand) However, in J 2 M E an alternative syntax is needed that exposes explicitly the L i s t to be updated: p o i n t c u t i n i t M e n u l t e m s ( L i s t 1 ) : a r g s ( l ) && e x e c u t i o n ( * P h o t o L i s t S c r e e n . i n i t M e n u ( L i s t ) ) ; In this case, we have to change the PhotoListScreen. initMenu ().method to include the L i s t parameter so that the advice could append new menu items to that object using 1.addCommand(newCommand); The absence of t h i s J o i n P o i n t was the only limitation we experienced with the pointcut language while implementing the AspectJ version of MobilePhoto. However, there is a similar issue related to cf low pointcuts that we were aware of although it did not affect our implementation. J 2 M E has very limited support for threading and does not include many of the utility classes found in the standard j ava. u t i l package. Unfortunately, parts of the AspectJ runtime related to c flow pointcuts rely on many of these thread, stack and utility classes. We read about this limitation from an F A Q entry on the AspectJ website 4 9 . The second major limitation we experienced using AspectJ to implement MobilePhoto was a difference in behaviour for Java enabled R I M devices. For most emulators and hardware that we tested, the AspectJ version of our application executed without any problems as long as we avoided using t h i s J o i n P o i n t constructs. However, Research In Motion's Blackberry platform was an exception. The Blackberry virtual machine has strict dependency checking when a Java application launches on the device. When we first tried running MobilePhoto on the R I M simulators 5 0, the application crashed with a series of exceptions indicating it could not find many of the classes used in the AspectJ runtime. We did not encounter this problem on other devices, as long as the runtime was preverified against some J2SE libraries, and as long as we did not use any features of http://dev.eclipse.org/viewcvs/in^ We tested using Blackberry JDE v 3.7 and v 4.0, and the standalone Simulator v 3.7.0.52 47 AspectJ that relied on unsupported APIs. But for the Blackberry we had to make several modifications to the source code of the AspectJ runtime before it would work. Specifically, we had to remove any references or usage of classes that were not supported by the standard J 2 M E library. These changes did not affect the AspectJ usage in MobilePhoto, and slightly reduced the size of the runtime. Table 6-4 provides a summary of the AspectJ runtime source files that were modified, and notes the non-J2ME references that had to be removed. Table 6-4: Modified Classes for Custom Blackberry AspectJ Runtime Modified AspectJ Runtime Class Non-J2ME references removed org.aspectj .lang.SoftException J a v a . i o . P r i n t W r i t e r org.apsectj.runtime.internal.CFlowCounter System.getProperty(x,x) not supported i n J2ME org.apsectj.runtime.internal.CFlowStack System.getProperty(x,x)* org. apsectj .runtime.internal. Conversions Java.lang.Float, Java.lang.Double, j ava.lang.Number, d o u b l e , f l o a t p r i m i t i v e t y p e s * * org.apsectj .runtime.internal. cflowstack.ThreadCounterlmpl 1 j a v a . u t i l . I t e r a t o r , j a v a . u t i l . L i s t , j a v a . u t i l . A r r a y L i s t org.apsectj.runtime.internal.cflowstack.ThreadStackFactorylmpl java.lang.ThreadLocal ( i n h e r i t e d from t h i s c l a s s ) org.apsectj.runtime.reflect.Factory j ava.lang.ClassLoader org.apsectj.runtime.reflect.ini tializerSignaturelmpl j a v a . l a n g . r e f l e c t . M o d i f i e r org. apsectj .runtime.reflect.Signaturelmpl Java.lang.ClassLoader, J a v a . u t i l . S t r i n g T o k e n i z e r , j ava.lang.ref.SoftReference, Java.lang.Float, java.lang.Double, j ava.lang.Number, java.lang.Void, Class.getClassLoader*, Class.getComponentType* org. apsectj .runtime.reflect.StringMaker J a v a . l a n g . r e f l e c t . M o d i f i e r , Class.getComponentType* * listed method calls are not available for the named class in J2ME ** double and float primitive types are not supported by RIMJ2ME implementation After we replaced the standard AspectJ runtime jar file with our modified jar file the application successfully launched on all Blackberry simulators and the MobilePhoto application worked correctly. Some of these limitations could be fixed by updating the AspectJ runtime source code to use J 2 M E only classes to implement the same functionality. However, re-writing reflective classes and utility classes like iterator, ThreadLocal or A r r a y L i s t would likely increase the size of the jar file and it would be difficult to guarantee the same behaviour as the standard J2SE implementations. 48 There is one other issue to note when compiling AspectJ aspects against the J 2 M E platform. Sun introduced an additional preverification phase in the development and deployment process that is required to run Java applications on mobile devices. Preverification performs certain checks on the Java bytecodes ahead of runtime. If this first verification pass is ok, the preverifier annotates the classfiles (using standard Java bytecode attributes), and then saves the annotated class files or passes them along to the next tool in the compile chain. When the J 2 M E virtual machine ( V M ) on a device attempts to execute a J 2 M E CLDC-based application, it checks the Java class files for these preverification annotations. Proper annotations in the class files guarantee that certain compile-time checks were made, and so the V M can pass through its own verification and security checks much faster and start executing the application more quickly. Sun provides a (command line) utility that w i l l preverify your J 2 M E application code prior to deployment. 5 1 However, when writing a J 2 M E application with AspectJ you must include the runtime classes within your jar file, but the AspectJ runtime classes w i l l fail the preverification step because they utilize classes from the J2SE that are not available within the J 2 M E core classes. Y o u can work around this issue by including the required J2SE classes on the classpath during the preverification step. Even though these classes w i l l not be available at runtime, as long as you are not using them (e.g., thisJoinPoint and cf low) your application should run without any problems. For this reason, we extracted the specific Java classes from the J2SE library that were required by the AspectJ runtime to include in the preverification classpath. This technique worked with all o f the available emulators and hardware tested, with the exception of the Blackberry platform, which was discussed above. 6.5 Complexity of Implementation The complexity of applying the product line implementation technology affects how easy it would be for developers to build an application with the technology. For example, how easy is it for a J 2 M E programmer to implement their own product line using a similar strategy? This analysis of implementation complexity looks at the design and implementation of the application framework and components in the two approaches taken, and the ease with which (optional) variant components can be reused across product instances. Both versions of our prototype application were programmed using Java 2 Micro Edition, but using the AspectJ technique likely requires a little more effort i f a developer is not familiar with aspect-oriented programming concepts. However, the use of AspectJ is somewhat simplified when applied to mobile devices because some of the more complicated functions in AspectJ are not available when deploying to mobile devices (see Section 6.4). Therefore a developer who is not familiar AspectJ only has to learn some basic pointcut syntax, and become familiar with the new AspectJ build tasks available for A N T . B y comparison there is probably less of a learning curve for programmers to use 5 1 The preverify tool is included with the Sun Wireless Toolki t (http://iava.sun.com/products/siwtoolkit/') 49 the preprocessor approach taken in the object-oriented implementation, since there is no new language to use except some basic 'ifdef tags. Both MobilePhoto implementations would be classified as positive variability techniques[19], using a decomposition (or module replacement) model[16]. Positive variability adds functionality to create new product instances, while negative variability removes it. Our decision to use positive variability with module replacement simplifies the development process, but is only applicable when you are designing your application from scratch with variability in mind. When you must re-factor an existing application into a family of mobile products, a negative variation approach might be necessary. The use of AspectJ in a negative variation approach is discussed elsewhere [22], [13]. Another issue of complexity in the AspectJ approach is the ease of testing the correctness of the implementation. Standard object oriented unit and integration testing approaches may not apply to due to the fact that aspects behave differently than common classes, and the side effects may not always be apparent to the developer by reading the source code[23]. Understanding the testing constraints for an aspect-oriented implementation may extend the learning curve for new programmers during the development cycle. However, the area of testing aspects is being explored further, and helpful tools are starting to emerge to facilitate this and make it easier. 5 2 6.6 Tool Support Tool support for developing J 2 M E applications is still in its infancy. Although there is an abundance of S D K ' s , programming tools and development environments available from vendors, most of these tools are aimed at developing Java applications for a specific hardware platform. Almost every hardware manufacturer that supports Java on their device has also released a proprietary development environment to make it easier to build applications specifically for their platform. A few of these vendors plan to release versions of their toolkits that integrate with existing IDE's like Eclipse or Netbeans. But at the moment, there is still a significant amount of installation, setup and configuration required just to get your development workspace to the point where you can program, test and debug applications for multiple devices. Y o u can reduce this list o f tools i f you want to sacrifice the functionality offered in proprietary API ' s and rely on only the generic emulators for testing. But you still need to install some of the utilities from Palm and R I M that convert your Java application into native file formats. A l l of the vendor specific development environments available come bundled with emulators for their device models, optional and proprietary libraries that are available on the devices, and additional tools necessary to test and deploy mobile applications in markets where they are available. Before we could use all o f the required libraries, emulators and utilities necessary to build the relatively small product line for the MobilePhoto prototype we needed to install all of the applications listed below: http://www.aunit.org/ is a unit testing framework for AspectJ that follows the xUni t / JUni t framework. 50 o Eclipse IDE (Could be any Java editor of choice) o AspectJ Development Toolkit (AJDT plugin for Eclipse) o Sun J 2 M E Wireless Toolkit o Apache Ant + optional tasks for J 2 M E and AspectJ o J 2 M E Preprocessor (Antenna) o Blackberry Java Development Environment o Nokia Developer Suite for J 2 M E o Motorola i D E N S D K for J 2 M E o Siemens Mobi l i ty Developer Suite o Sun P R C Conversion Tool for Palm OS o I B M J9 Virtual Machine for Palm OS (+ utilities) Some open source projects might alleviate these problems with compatibility. The E c l i p s e M E 5 3 open source plugin helps connect a variety o f wireless toolkits and emulators to the Eclipse development environment so mobile programmers can focus on the application instead of the development workspace. The latest release o f the Netbeans Java IDE includes a Mobi l i ty Pack 5 that specifically tries to solve the problems with device fragmentation. It includes a preprocessor for J 2 M E , and extends the graphical interface to allow the developer to define configurations that w i l l only display the source code associated with a target configuration. For example, we could define a blackberry configuration for MobilePhoto and configure Netbeans so that only the blackberry preprocessor statements are visible, while the lines of code associated with other devices (or features) are hidden from view. This would certainly help the readability of source code for projects that contain lots of preprocessor statements and many targeted device platforms. Although this benefit is only available as long as you are using the NetBeans IDE to program because the underlying source code still contains all o f the preprocessor tagged code in the files they are used in. I B M has also released a branded version of Eclipse (part of their Eclipse 'product line') called Websphere Device Developer (WSDD) that provides automatic integration for a variety of J 2 M E emulators and utilities available. W S D D requires a purchased software license to use, and at the time of this writing it did not offer any solution to the A P I fragmentation problem. Despite the wide array of development environments available (and necessary), we found that none of them met all o f our needs to facilitate easier mobile product line development. The vendor provided tools were generally lacking in basic Java IDE features that many developers have come to expect, such as advanced search and navigation, re-factoring and customizable views. These vendors IDE's also included no support for aspect-oriented programming. Most of the IDE's (with the exception of Netbeans) did not directly support a preprocessor, which meant that the object-oriented version of MobilePhoto could not have been built using the built-in IDE compiler. When we attempted to use Ec l ipseME with the A J D T plugin for Eclipse to compile the aspect-oriented version of MobilePhoto it resulted in conflicts in the IDE. Specifically, the AspectJ runtime needs to be packaged into your final J 2 M E application, but it fails the http://ec1ipseme.org/ http://www.netbeans.org/kb/articles/mobilitv.html 51 J 2 M E preverification step because it relies on classes that do not exist in the M I D P or -C L D C libraries. We were not able to find a work-around for this with the Ecl ipseME plugin. To get around this using A N T , we had to manually extract the required classes from the J2SE library and override the preverification classpath for the AspectJ runtime files. Overriding this classpath was not always possible to do with the built-in IDE plugin editors. There were also additional classpath conflicts that had to be resolved since the Aspect source files are built using the AspectJ compiler and may need access to standard (J2SE) libraries, while regular J 2 M E source files should only be compiled against the J 2 M E core libraries. None of the third party J 2 M E IDE's currently facilitate (or encourage) component or feature based development, and have no way of managing feature interaction the way that Pure Variants did. There are some generic toolsets available that support feature oriented programming for product line development. The A H E A D Tool Suite ( A T S ) 5 5 is a collection of Java based tools that treats features as the core building blocks of a system. Programs in A T S are unique compositions of algebraic operations that correspond to a feature module. We did not attempt to build J 2 M E and AspectJ programs using A H E A D since it focuses heavily on the algebraic domain and feature management but is lacking in general Java programming and IDE functionality. http://www.cs.utexas.edu/users/schwartz/ATS.html 52 7 Conclusions We evaluated the use of aspect-oriented programming, and in particular AspectJ, to alleviate problems with fragmented A P I support across micro devices when implementing a family of mobile Java applications. Many existing approaches to product line development are not applicable for mobile devices because o f tight restrictions on application resources and because the volume of devices to support is much greater than typical desktop or server platforms. To evaluate our strategy, we compared two different implementation techniques for a mobile prototype application written in J 2 M E . One implementation uses standard object-oriented practices, design patterns and preprocessor utilities that are used by many J 2 M E application developers in industry. A second implementation uses aspect-oriented practices, including pointcuts and advice, and the AspectJ weaver. We compared these implementations with respect to the complexity of the development, modularity, scalability, device support, tool support and quantitative measurements of size and resource usage. We found that aspect-oriented programming, as supported by AspectJ, provides an effective way to bind optional components to your mobile application during the build process. It allows a developer to isolate J 2 M E API ' s that are only supported by specific device types and keep them in a single module instead of being scattered throughout the application classes. However, there is minimal support in AspectJ to manage dependency relationships between different optional features. Bui ld configuration is also required to minimize the application size and exclude unnecessary resources. The biggest drawback is that including the AspectJ runtime with your application increases its size between 30-40 K B , which is significant for many micro device platforms. Most of the other metrics compared such as memory utilization, number of classes, lines of code, duration of builds etc. revealed no significant difference between the object-oriented programming and aspect-oriented programming implementations. Scaling the product line build process to include many optional features and many supported devices is difficult using only object-oriented techniques and a preprocessor. A s the optional features increase, the number of embedded preprocessor statements scattered throughout your code base also increases, making it difficult to manage without some type of tool support. A t the moment, tool support for building J 2 M E product lines in general is still lacking, and tool support for using aspect-oriented programming with J 2 M E is almost non-existent. 53 7.1 Contributions This research makes several contributions: • It demonstrates the feasibility of using AspectJ on a wide variety of simulators and real hardware devices that support J 2 M E (including Symbian based phones from Nokia , Motorola and Siemens, Palm OS devices, and R I M Blackberry devices.) • It documents specific classes and methods in the AspectJ runtime that are not supported on current J 2 M E platforms due to the absence of reflection and minimal threading support in the M I D P and C L D C libraries. • It documents limitations of using AspectJ on certain devices, notably current Blackberry simulators and devices by Research In Motion can only execute a custom modified version of the AspectJ runtime. • It provides a sample application implemented in an aspect-oriented and object-oriented version that may be used for education or research purposes. 7.2 Future Work Aspect-oriented programming has potential to optimize development practices for software product lines, and particularly for mobile devices. The work described in this thesis focused on the use of aspects to vary the functionality available in a particular configuration of a prototype application. It would also be interesting to see i f aspects could alleviate other problems with porting J 2 M E applications, such as variations in device hardware, operating constraints on networking usage or multi-language support, and V M specific bugs. This work has also focused on aspect-oriented programming as provided by AspectJ. It would also be useful to broaden the range of implementation languages (e.g., C/C++, AspectWerkz 5 6 or HyperSpaces 5 7) and device platforms (e.g., Microsoft PocketPC 5 8 or Qualcomm B R E W 5 9 ) to see i f similar advantages are obtained. Another avenue of future work is creating a fully functioning version of the AspectJ runtime that is optimized for J 2 M E . This work might involve eliminating AspectJ's. dependency on the J2SE API ' s , and removing unsupported (or unnecessary) classes from the runtime. Having a J 2 M E optimized version of the AspectJ runtime could limit the increase in size that all mobile applications incur when using AspectJ. http://aspectwerkz.codehaus.org/index.html http://www.research.ibm.com/hvperspace/ http://www.microsoft.coni/windowsmobile/ http://brew.qualcomm.com/brew/en/developer/resources/dev_resources.html Bibliography [I] Gregor Kiczales, E . H . , J im Hugunin, M i k Kersten, Jeffrey Palm, Wi l l i am G . Griswold. An overview of AspectJ. in European Conference on Object-Oriented Programming. 2001. Budapest, Hungary. [2] Don Batory, R . C . , & Yannis Smaragdakisi. Object-Oriented Frameworks and Product-Lines, in First Conference on Software Product Lines. 2000. Denver, Colorado. [3] Erich Gamma, R . H . , Ralph Johnson, John Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. 1995, Reading: Addison Wesley. 395. [4] Krzysztof Czarnecki, U . W . E . Components and Generative Programming, in Foundations of Software Engineering. 1999. Toulouse, France. [5] Victoria Davis, J .G., Joel Jones. Generative Approaches for Application Tailoring of Mobile Devices. in 43rd ACM Southeast Conference. 2005. Kennesaw, G A , U S A : A C M . [6] Frank Hunleth, R . K . C . , Footprint and Feature Management using Aspect-Oriented Programming Techniques, in LCTES'02 - SCOPES'02. 2002. [7] Gai l C . Murphy, A . L . , Robert J.Walker, and Martin P. Robillard. Separating Features in Source Code: An Exploratory Study, in 23rd International Conference on Software Engineering. 2001. Toronto, Canada. [8] Nei l Loughran, A . R . , Weishan Zhang, Stan Jarzabek, Supporting Product Line Evolution with Framed Aspects, in AOSD 2004: Workshop on Aspects, Components and Patterns for Infrastructure Software. 2004: Lancaster, U K . [9] Ne i l Loughran, A . R . , Framed Aspects: Supporting Variability and Configurability for AOP, in International Conference on Software Reuse. 2004: Madrid, Spain. [10] Roberto E . Lopez-Herrejon, D .B . , Using AspectJ to Implement Product-Lines: A Case Study. 2002, The University of Texas: Austin, p. 9. [II] Roberto E . Lopez-Herrejon, D .B . , and Wi l l i am Cook. Evaluating Support for Features in Advanced Modularization Technologies, in ECOOP. 2005. Glasgow, Scotland. [12] Ron Bodkin, A . C , J im Hugunin, Applying AOP for Middleware Platform Independence. 2003, I B M , New Aspects, P A R C . p. 7. [13] Vander Alves, P . M . J., Paulo Borba, An Incremental Aspect-Oriented Product Line Method for J2ME Game Development, in OOPSLA '04: Workshop on Managing Variability Consistently in Design and Code. 2004: Vancouver, Canada. [ 14] A y l a Dantas, P .B. , Developing Adaptive J2ME Applications Using AspectJ. 2003, Informatics Center - Federal University of Penambuco. [15] Arturo Zambrano, S.G., Ignacio Jaureguiberry, Aspect-Based Adaptation for Ubiquitous Software, in Mobile HCI2003. 2003: Udine, Italy. [16] Michalis Anastasopoulos, D . M . , An Evaluation of Aspect-Oriented Programming as a Product Line Implementation Technology, in International Conference on Software Re-Use. 2004: Madrid, Spain. 55 [17] Yuan, M . J . , Enterprise J2ME: Developing Mobile Java Applications. 1st ed. 2004: Prentice Hal l PTR. 480. [18] M i k Kersten, G . C . M . Atlas: A Case Study in Building a Web-Based Learning Environment using Aspect-oriented Programming, in OOPSLA. 1999. Denver, Colorado. [19] Michalis Anastasopoulos, C .G . , Implementing Product Line Variabilities, in Symposium on Software Reusability. 2001: Toronto, Canada. [20] Claudia Fritsch, A . L . , Dr. Thomas Strohm. Evaluating Variability Implementation Mechanisms, in Proceedings of International Workshop on Product Line Engineering. 2002. Seattle, U S A . [21] Andrei Popovici, T .G . , and Gustavo Alonso, Dynamic Weaving for Aspect-Oriented Programming, mAOSD 2002. 2002: Enschede, Netherlands. [22] Vander Alves, P . M . J . , Leonardo Cole, Paulo Borba, and Geber Ramalho, Extracting and Evolving Mobile Games Product Lines, in 9th International Software Product Line Conference (SPLC'05). 2005: Rennes, France. [23] Roger T. Alexander, J . M . B . , Towards the Systematic Testing of Aspect-Oriented Programs. 2004, Colorado State University, Department of Computer Science: Fort Collins, Colorado, p. 11. 56 Appendix A: Acronyms The following list details the acronyms used in this thesis. J 2 M E Java 2 Platform, Micro Edition A P I Application Programming Interface A O P Aspect Oriented Programming A O S D Aspect Oriented Software Development OOP Object Oriented Programming O O Object Oriented P D A Personal Digital Assistant R I M Research In Motion ( J ) V M (Java) Virtual Machine K V M Kilobyte Virtual Machine W M A Wireless Messaging A P I C L D C Connected Limited Device Configuration C D C Connected Device Configuration J2EE Java 2 Enterprise Edition J2SE Java 2 Standard Edition J A D Java Application Descriptor J A R Java Archive M I D P Mobi le Information Device Profile P I M Personal Information Manager R M S Record Management System S M S Short Message Service W O R A Write Once Run Anywhere S D K Software Development K i t IDE Integrated Development Environment C T O Cheif Technology Officer (G)UI (Graphical) User Interface C V S Concurrent Version System M V C Model V i e w Controller C D M A Code Divis ion Multiple Access (Wireless data transmission protocol for mobile telephone networks) G P R S General Packet Radio Service (Wireless data transmission protocol for mobile telephone networks) 802.11 Family of specifications for wireless L A N s developed by the IEEE L C D Liquid Crystal Display O R B Object Request Broker A N T Another Neat Tool (Build Tool) X M L extensible Markup Language X S L ( T ) extensible Stylesheet Language (Transformation) U M L Unified Modeling Language F A Q Frequently Asked Questions 57 Appendix B: ANT Build Script Source Listing <?xml version--" 1. 0" encoding -" iso-8859-1" ?> <project name="MobilePhoto AOP Version" d e f a u l t = " f u l l - b u i l d " basedir="."> <!-- Define a l l relevant properties here. --> <property name="workspace.dir" location="${basedir}"/> <property file="laptopBuild.properties"/> <property name="antenna.jar" location="${antenna.home}\\aritenna-bin-0.9.12.jar"/> <property name="ajc.adapter" value="org.aspectj.tools.ant.taskdefs.AjcllCompilerAdapter"/> <!-- For Blackberry, use the modified AspectJ Runtime Jar f i l e --> <property name="aspectjtools.jar" -l o c a t i o n = " $ { a s p e c t j . l i b . d i r } / a s p e c t j t o o l s . j a r " / > < ! - - D e f i n e core MIDP l i b r a r i e s --> <!-- MIDP 1.0 CLDC 1.0 --> .. <property name="midpapilO.jar" location=" $ {wtk. home} \lib\midpapilO ..jar" / > <property name="cldcapi10.j ar" l o c a t i o n s"${wtk.home}\lib\cldcapi10.jar"/> <!-- MIDP 2.0 CLDC 1.1 --> <property name=".midpapi20. j a r " location="${wtk.home}\lib\midpapi2 0.jar"/> <property name="cldcapill.jar" location="${wtk.home}\lib\cldcapi11.j ar"/> < ! - - D e f i n e T h i r d Party and optional M I D P L i b r a r i e s - - > <!-- The motorola and siemen's zip f i l e s are just archives of the class d i r e c t o r i e s for the respective devices. The contained f i l e s can be found in the i n s t a l l d i r e c t o r y of the respective SDK or T o o l k i t . --> <property name="moto730.zip" location="${motorola.home}/lib/i730/Motorola730.zip"/> <property name="wma.jar" location="${wtk.home}/lib/wma.jar"/> <property name="mmapi.jar" location="${wtk.home}/lib/minapi.jar"/> <property name="jsr7 5.jar" locatioh="${wtk-beta.home}/lib/jsr75.jar"/> <property name="blackberryLib.jar" location="${blackberry.jde.home}/lib / n e t_rim_api.jar"/> <property name="siemensLib.zip" location=" $ {.Siemens . home} /SiemensJ2MElib .zip" /> <!-- Set the classpath to be used --> <property name="build.classpath" value="${midpapi2 0.jar } ;${c ldcap i l l .jar};${wma.jar};${mmapi.jar},-${j sr7 5.jar};${moto73 0.zip} ; $ { a s p e c tjrt.jar};${siemensLib.zip};${ blackberryLib.jar} ; $ { a n t e n n a .jar};"/>-<!-- Builds for Blackberry should only use MIDP 1.0 and CLDC 1.0 --> <!-- <property name="build.classpath" value="${midpapilO.jar};${cldcapi10.jar};${aspectjrt.jar};${black berryLib.jar};"/> --> <!-- D i r e c t o r i e s created or used during the b u i l d process --> 58 < p r o p e r t y n a m e = " r a p e - c o m p i l e d . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / r a p c -c o m p i l e d " / > < p r o p e r t y name= " p r e - c o m p i l e d . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / p r e -compiled" /> < p r o p e r t y n a m e = " m i d p - c o m p i l e d . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / m i d p -c o m p i l e d " / > < p r o p e r t y n a m e = " s r e . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / s r e " / > < p r o p e r t y n a m e = " a s p e c t - s o u r c e . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / u b c / a s p e c t j / p h o t o a l b u m " / > < p r o p e r t y n a m e = " a j c - c o m p i l e d . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / a j c -c o m p i l e d " / > . < p r o p e r t y n a m e = " p r e v e r i f i e d . d i r " l o c a t i o n ^ " $ { 'workspace . . d i r } / p r e v e r i f i e d " / > < p r o p e r t y n a m e = " j a r . d i r " l o c a t i o n s " $ { w o r k s p a c e . d i r } / j a r s " / > < p r o p e r t y n a m e = " p a l m . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / p a l m " / > < p r o p e r t y n a m e = " r i m . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / r i m " / > < p r o p e r t y n a m e = " i m a g e s . d i r " l o c a t i o n = " $ { w o r k s p a c e . d i r } / i m a g e s " / > < ! - - T h i s r e s o u r c e i s r e q u i r e d f o r A n t e n n a b a s e d t a s k s - - > < t a s k d e f r e s o u r c e = " a n t e n n a . p r o p e r t i e s " c l a s s p a t h = " $ { a n t e n n a . j a r } " /> < : - - ============================================================= - - > < ! - - F u l l B u i l d ( D e f a u l t T a r g e t ) - - > < t a r g e t n a m e = " f u l l - b u i l d " > < a n t c a l l t a r g e t = " c l e a n " /> < ! - - m i d p - c o m p i l e i s o n l y n e c e s s a r y f o r B l a c k b e r r y b u i l d s - - > < ! - - < a n t c a l l t a r g e t = " m i d p - c o m p i l e " / > - - > < a n t c a l l t a r g e t = " a s p e c t j - c o m p i l e " . / > < a n t c a l l t a r g e t = " c o p y - a j r u n t i m e - c l a s s e s " / > < a n t c a l l t a r g e t = " c o p y - i m a g e - f i l e s " /> < a n t c a l l t a r g e t = " m i d p - p r e v e r i f y " /> < a n t c a l l t a r g e t = " m a k e - j a r " / > < / t a r g e t > < ! - - B l a c k b e r r y B u i l d P a r t 1 ( N e e d s t o s p l i t i n two b e c a u s e t h e a s p e c t J c o m p i l e e x i t s A N T , e v e n t h o u g h t h e b u i l d i s v a l i d ) - - > - c t a r g e t n a m e = " b b e r r y - l " > < a n t c a l l t a r g e t = " c l e a n " /> < a n t c a l l t a r g e t = " a s p e c t j - c o m p i l e " /> < / t a r g e t > < i - - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - - p -< ! - - B l a c k b e r r y B u i l d P a r t 2 ( s p l i t i n two b e c a u s e t h e a s p e c t J c o m p i l e e x i t s A N T , e v e n t h o u g h t h e b u i l d i s v a l i d ) - - > < i - - ============================================================= - - > < t a r g e t n a m e = " b b e r r y - 2 " > < a n t c a l l t a r g e t = " c o p y - a j r u n t i m e - c l a s s e s " /> < a n t c a l l t a r g e t = " c o p y - i m a g e - f i l e s " / > < a n t c a l l t a r g e t = " m i d p - p r e v e r i f y " ' /> < a n t c a l l t a r g e t = " m a k e - j a r " /> < a n t c a l l t a r g e t = " r a p e - c o m p i l e " / > < / t a r g e t > 59 !-- ============================================== --> ! - - C l e a n a l l t a r g e t s - - > ! — ============================================================= - - > t a r g e t n a m e = " c l e a n " d e s c r i p t i o n = " c l e a n a n d c r e a t e c l a s s e s / j a r d i r , . a j e s y m f i l e s " > < ! - - D e l e t e a l l t h e d i r e c t o r i e s a n d t h e i r c o n t e n t s - - > $ {a j c - c o m p i l e d . d i r }"_/> $ { p r e v e r i f i e d . d i r } " / > $ { m i d p - c o m p i l e d . d i r } " / > $ { r a p e - c o m p i l e d . d i r } " / > $ { p r e - c o m p i l e d . d i r } " / > < d e l e t e q u i e t = " o n " d i r = ' < d e l e t e q u i e t = " o n " d i r = ' < d e l e t e g u i e t = " o n " d i r = ' < d e l e t e q u i e t = " o n " d i r = ' < d e l e t e q u i e t = " o n " d i r = ' < d e l e t e q u i e t = " o n " > < f i l e s e t d i r = " $ { j a r . d i r } " e x c l u d e s = " * * / * . j a d " / > < / d e l e t e > < d e l e t e q u i e t = " o n " > <f i l e s e t d i r = " $ { w o r k s p a c e . d i r } " i n c l u d e s = <•**/*. a j e s y m " / > < / d e l e t e > < ! - - R e c r e a t e t h e d i r e c t o r i e s we j u s t d e l e t e d - - > < m k d i r d i r = " $ { a j c - c o m p i l e d . d i r } " / > < m k d i r d i r = " $ { p r e v e r i f i e d . d i r } "•/> < m k d i r d i r = " $ { m i d p - c o m p i l e d . d i r } " / > < m k d i r dir=" $ { r a p e - c o m p i l e d , d i r } "./> < m k d i r d i r = " $ { p r c - c o m p i l e d . d i r } " / > < m k d i r d i r = " $ { j a r . d i r } " / > / t a r g e t > !-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = === = === = = = = = = = = = --> ! - - C o m p i l e M I D P c l a s s e s u s i n g s t a n d a r d m i d p ( j a v a c ) c o m p i l e r - - > ! - - ============================================================= — > t a r g e t n a m e = " m i d p - c o m p i l e " > < ! - - F o r M o t o r o l a B u i l d , o n l y u p d a t e j a d s o i t i n c l u d e s p r o p e r t y i D E N - M i d l e t - P h o n e : M a i n U I M i d l e t l O - - > < w t k j a d j a d f i l e = " $ { j a r . d i r } / $ { j a d . n a m e } " j a r f i l e = " $ { m i d p -c o m p i l e d . d i r } / $ { j a r . n a m e } " n a m e = " $ { m i d l e t . n a m e } " u p d a t e = " t r u e " v e n d o r = " T r e v o r Y o u n g " v e r s i o n = "1.0.0"> < m i d l e t name= "$ { m i d l e t . name}"" c l a s s = " $ { m a i n . c l a s s } " / > < / w t k j a d > < ! - - C o m p i l e e v e r y t h i n g , b u t d o n ' t p r e v e r i f y ( y e t } . U s e b o o t c l a s s p a t h t o o v e r r i d e M I D P 1.0 / C L D C 1.0 a p i s - - > < w t k b u i l d s r c d i r = " $ { s r c . d i r } " d e s t d i r = " $ { m i d p - c o m p i l e d . d i r } " p r e v e r i f y = " f a l s e " b o o t c l a s s p a t h = " $ { b u i l d . c l a s s p a t h } ; " > < i n c l u d e s f i l e n a m e = " M o b i l e P h o t o C o m p i l e L i s t . 1 s t " / > < / w t k b u i l d > < ! - - P a c k a g e t h e c o m p i l e d c l a s s e s i n t o a J A R a n d J A D f i l e - - > < w t k p a c k a g e j a r f i l e = " $ { m i d p - c o m p i l e d . d i r } / $ { j a r . n a m e } " j a d f i l e = " $ { j a r . d i r } / $ { j a d . n a m e } " o b f u s c a t e = " f a l s e " p r e v e r i f y = " f a l s e " > < f i l e s e t d i r = " $ { w o r k s p a c e . d i r } " • • i n c l u d e s = " $ { m a i n . c l a s s } . c l a s s " / > < / w t k p a c k a g e > / t a r g e t > 60 ! - - Some I n i t i a l i z a t i o n t a s k s r e q u i r e d f o r A s p e c t J C o m p i l e r T a r g e t - - > ! - - = = = == = == = = = = = = = = = = = = == = = = = = = = = = = = == = = - - > t a r g e t n a m e = " a s p e c t j - i n i t " > < ! - - C h e c k t h e r e q u i r e d l i b r a r i e s - - > < a v a i l a b l e f i l e = " $ { a s p e c t j t o o l s . j a r } " p r o p e r t y = " a s p e c t j t o o l s . j a r . a v a i l a b l e " / > < a v a i l a b l e f i l e = " $ { a s p e c t j r t . j a r } " p r o p e r t y = " a s p e c t j r t . j a r . a v a i l a b l e " / > < ! - - S e t s name o f new t a s k t o i a j c , o l d t a s k t o a j c - - > < t a s k d e f r e s o u r c e = " o r g / a s p e c t j / t o o l s / a n t / t a s k d e f s / a s p e c t j T a s k d e f s . p r o p e r t i . e s " > < c l a s s p a t h > < p a t h e l e m e n t p a t h = " $ { a s p e c t j t o o l s . j a r } " / > < / c l a s s p a t h > < / t a s k d e f > < p r o p e r t y n a m e = " t a s k d e f s . i n i t " v a l u e = " t r u e " / > / t a r g e t > ============================================================= - - > ! - - C o m p i l e A s p e c t J S o u r c e s a n d w e a v e w i t h M I D P c o m p i l e d J a r - - > ! - - ============================================================= - - > t a r g e t n a m e = " a s p e c t j - c o m p i l e " d e p e n d s = " a s p e c t j - i n i t " d e s c r i p t i o n = " U s e s A s p e c t J c o m p i l e r t o c o m p i l e a n d w e a v e " > < e c h o m e s s a g e = " C o m p i l i n g w i t h a j c . . . ( D i s a b l e d I m p o r t E r r o r s , W i l l P r o c e e d O n E r r o r ) " /> < i a j c d e s t d i r = " $ { a j c - c o m p i l e d . d i r } " f o r k = " t r u e " p r o c e e d O n E r r o r = " t r u e " n o i m p o r t e r r o r = " t r u e " f o r k c l a s s p a t h = " $ { a s p e c t j t o o l s . j a r } " c l a s s p a t h = " $ { b u i l d . c l a s s p a t h } ; " a r g f i l e s = " $ { w o r k s p a c e . d i r } / M o b i l e P h o t o C o m p i l e L i s t . 1 s t " i n p a t h = " $ { m i d p - c o m p i l e d . d i r } " v e r b o s e = " t r u e " / > / t a r g e t > i - - ============================================================= - - > ! - - U n j a r t h e A s p e c t J R u n t i m e C l a s s e s s o t h e y c a n b e p r e v e r i f i e d - - > ! - - ============================================================= - - > t a r g e t n a m e = " c o p y - a j r u n t i m e - c l a s s e s " > < u n z i p s r c = " $ { a s p e c t j r t . j a r } " d e s t = " $ { a j c - c o m p i l e d . d i r } " / > / t a r g e t > ! - - ============================================================= - - > ! - - C o p y I m a g e F i l e s s o t h e y a r e b u n d l e d w i t h t h e j a r f i l e - - > t a r g e t n a m e = " c o p y - i m a g e - f i l e s " > < m k d i r d i r = " $ { p r e v e r i f i e d . d i r } / i m a g e s " / > < c o p y t o d i r = " $ { p r e v e r i f i e d . d i r } / i m a g e s " > < f i l e s e t d i r = " $ { i m a g e s . d i r } " / > < / c o p y > / t a r g e t > 61 ! - - P r e v e r i f y M I D P c l a s s e s , A s p e c t s a n d t h e A s p e c t J R u n t i m e L i b r a r y - - > t a r g e t n a m e = " m i d p - p r e v e r i f y " > < ! - - N o t e we h a v e t o i n c l u d e some c l a s s e s f r o m J 2 S E i n o r d e r f o r t h e A s p e c t J r u n t i m e c l a s s e s t o p r e v e r i f y . F o r n o w , t h e r e q u i r e d c l a s s e s a r e i n t h e a t e m p d i r e c t o r y - - > < w t k p r e v e r i f y s r c d i r = " $ { a j c - c o m p i l e d . d i r } " d e s t d i r = " $ { p r e v e r i f i e d . d i r } " c l a s s p a t h = " $ { b u i l d . c l a s s p a t h } ,• $ {j 2 s e . p a r t i a l . z i p } ; " /> / t a r g e t > : — = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = — > ! - - G e n e r a t e f i n a l J A R f i l e f o r M I D P d e v i c e s a n d u p d a t e J A D - - > !-- ============================================================= --> t a r g e t n a m e = " m a k e - j a r " > < ! - - P a c k a g e t h e c o m p i l e d c l a s s e s i n t o a J A R a n d J A D f i l e - - > < w t k p a c k a g e j a r f i l e = " $ { j a r . d i r } / $ { j a r . n a m e } " j a d f i l e = " $ { j a r . d i r } / $ { j a d . n a m e } " b a s e d i r = " $ { p r e v e r i f i e d . d i r } " o b f u s c a t e = " f a l s e " p r e v e r i f y = " f a l s e " > < / w t k p a c k a g e > / t a r g e t > j - - ============================================================= --> ! - - C o m p i l e / c o n v e r t J a r f i l e f o r B l a c k B e r r y u s i n g r a p e . e x e - - > ! — ============================================================= — > t a r g e t n a m e = " r a p e - c o m p i l e " > < e x e c e x e c u t a b l e = " & q u o t ; $ { b l a c k b e r r y . j d e . h o m e } / b i n / r a p e . e x e & q u o t ; " > < a r g l i n e = " i m p o r t = & q u o t ; $ { b l a c k b e r r y , j d e . home} / l i b / n e t _ r : i . m _ a p i . j a r ; & q u o t ; c o d e n a m e = $ { m i d l e t . n a m e } - m i d l e t & q u o t ; $ {j a r . d i r } . / $ {j a r . name} & q u o t ; & q u o t ; $ { j a r . d i r } / $ { j a d . n a m e } & q u o t ; " / > < / e x e c > < c o p y t o d i r = " $ { r a p c - c o m p i l e d . d i r } " > < f i l e s e t d i r = " $ { w o r k s p a c e . d i r } " > < i n c l u d e n a m e = " * . d e b u g " / > < i n c l u d e n a m e = " * . c o d " / > < i n c l u d e n a m e = " * . c s o " / > < / f i l e s e t > < / c o p y > < d e l e t e q u i e t = " o n " > < f i l e s e t d i r = " $ { w o r k s p a c e . d i r } " i n c l u d e s = " * . d e b u g " / > < f i l e s e t d i r = " $ { w o r k s p a c e . d i r } " i n c l u d e s = " * . c s o " / > < f i l e s e t d i r = " $ { w o r k s p a c e . d i r } " i n c l u d e s = " * . c o d " / > < / d e l e t e > / t a r g e t > 62 < ! - - = = = = = = = = = = = = = = = = = = = = == = = ==== = = = = = = = = = = = = = - - > <!-- Convert Jar f i l e for Palm OS using Sun MIDP converter --> < I - - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - - > <target name="make-prc"> <exec executable^"${palm.midp.home}/converter.bat"> <arg line="-Xdescriptor:${jar.dir}/${jad.name}"/> </exec> </target> < ! - - ============================================================= - - > <!-- Run the Midlet i n the standard Phone Emulator --> < ! - - ============================================================= - - > <target name="run-default-phone-emulator"> <wtkrun j adfile="j ars/${j ad.name}" device="DefaultColorPhone" wait="true"/> </target> <!-- Run the Midlet i n the Motorola Phone Emulator --> < I - - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - - > <target name="run-motorola-i730-phone-emulator"> <exec executable="&quot;${motorola.home}/bin/emulator&quot;"> o r g line="-Xverbose:monitors -Xdevice:i730 -Xdescriptor:&quot;${jar.dir}/${jad.name}&quot;"/> </exec> </target> <!-- Run the Midlet i n the Motorola Phone Emulator --> <!-- ============================================================= --> <target name="run-motorola-i860-phorie-emulator"> <exec executable="&quot;${motorola.home}/bin/emulator&quot;"> <arg line="-Xverbose:monitors -Xdevice:i860 -Xdescriptor:&quot;${jar.dir}/${jad.name}&quot;"/> </exec> </target> <!-- Run the Midlet i n the Motorola Phone Emulator --> <!— ============================================================= - - > <target name="run-motorola-i605-phone-emulator"> <exec executable="&.quot;${motorola.home}/bin/emulator&quot;"> <arg line="-Xverbose:monitors -Xdevice:i605 -Xdescriptor : &quot; $ {jar. dir} /$ {j ad. name} &quot.; " / > </exec> </target> <!-- Run the Midlet i n the Siemens Phone Emulator --> <!-- ============================================================= --> <target name="run-siemens-phone-emulator"> <exec executable= "&quot;${Siemens.home}/emulators/CX65/bin/emulator&quot;"> <arg line= "Xdescriptor:&quot;${jar.dir}/${jad.name}&quot;"/> </exec> 63 / t a r g e t > ! - - R u n t h e M i d l e t i n t h e WTK 2 .2 B e t a P h o n e E m u l a t o r t a r g e t n a m e = " r u n - b e t a - d e f a u l t - p h o n e - e m u l a t o r " > < e x e c e x e c u t a b l e = " $ { w t k - b e t a . h o m e } / b i n / e m u l a t o r " > < a r g l i n e = " -X d e s c r i p t o r : & q u o t ; $ { j a r . d i r } / $ { j a d . n a m e } & q u o t , - " / > < / e x e c > / t a r g e t > ! - - I n f o T a r g e t : E c h o u s a g e a n d i n f o r m a t i o n a b o u t . t h i s b u i l d s c r i p t -t a r g e t n a m e = " i n f o " > < e c h o > I n s e r t a n y r e l e v a n t h e l p i n f o r m a t i o n h e r e . . . < / e c h o > / t a r g e t > / p r o j e c t > 64 Appendix C: SmsAspect Source Code Listing p u b l i c aspect S m s A s p e c t { Command s m s S e n d C o m m a n d = new C o m m a n d ( " S e n d S M S " , C o m m a n d . I T E M , 1) Command s m s R e c e i v e C o m m a n d = new C o m m a n d ( " R e c e i v e S M S " , C o m m a n d . I T E M , 1) ; Command a c c e p t P h o t o C o m m a n d = new C o m m a n d ( " A c c e p t P h o t o " , C o m m a n d . I T E M , 1); Command r e j e c t P h o t o C o m m a n d = new C o m m a n d ( " R e j e c t P h o t o " , C o m m a n d . I T E M , 1); N e t w o r k S c r e e n n e t w o r k S c r e e n = new N e t w o r k S c r e e n ( " R e c i e v e r D e t a i l s " ) ; S t r i n g s e l e c t e d l m a g e N a m e = " n u l l " ; B a s e C o n t r o l l e r c o n t r o l l e r ; b y t e [ ] i n c o m i n g l m a g e D a t a ; / / D e f i n e p o i n t c u t s p o i n t c u t i n i t M e n u l t e m s ( L i s t 1) : args(1) && e x e c u t i o n ( * P h o t o L i s t S c r e e n . i n i t M e n u ( L i s t ) ) ; p o i n t c u t h a n d l e C o m m a n d A c t i o n ( B a s e C o n t r o l l e r s c , C o m m a n d c , D i s p l a y a b l e d) : a r g s ( s c , c , d) && e x e c u t i o n ( * B a s e C o n t r o l l e r . p o s t C o m m a n d ( B a s e C o n t r o l l e r , C o m m a n d , D i s p l a y a b l e ) ) ; p o i n t c u t i m a g e R e c e i v e d ( b y t e [ ] i m a g e D a t a ) : a r g s ( i m a g e D a t a ) && e x e c u t i o n ( * S m s R e c e i v e r T h r e a d . i m a g e R e c e i v e d ( b y t e [ ] ) ) ; / / D e f i n e a d v i c e a f t e r ( L i s t 1) : i n i t M e n u l t e m s ( 1 ) { 1 . a d d C o m m a n d ( s m s S e n d C o m m a n d ) ; 1 . a d d C o m m a n d ( s m s R e c e i v e C o m m a n d ) ; } a f t e r ( b y t e [ ] i m a g e D a t a ) : i m a g e R e c e i v e d ( i m a g e D a t a ) { i f ( i m a g e D a t a = = n u l l ) S y s t e m . o u t . p r i n t l n ( " i m a g e D a t a w a s N U L L ! " ) ; i f ( c o n t r o l l e r = = n u l l ) S y s t e m . o u t . p r i n t l n ( " c o n t r o l l e r w a s N U L L ! " ) ; . A l e r t a l e r t =•new A l e r t ( " N e w I n c o m i n g P h o t o " ) ; a l e r t . s e t S t r i n g ( " A M o b i l e P h o t o u s e r h a s s e n t y o u a P h o t o . Do y o u w a n t t o a c c e p t i t ? " ) ; a l e r t . a d d C o m m a n d ( a c c e p t P h o t o C o m m a n d ) ; a l e r t . a d d C o m m a n d ( r e j e c t P h o t o C o m m a n d ) ; a l e r t . s e t C o m m a n d L i s t e n e r ( c o n t r o l l e r ) ; c o n t r o l l e r . s e t C u r r e n t S c r e e n ( a l e r t ) ; . i n c o m i n g l m a g e D a t a = i m a g e D a t a ; } a f t e r ( B a s e C o n t r o l l e r s c , Command c , D i s p l a y a b l e d) 65 handleCommandAction(sc, c, d) { / / S e t t h e a s p e c t ' s c o n t r o l l e r v a r i a b l e t o t h e m i d l e t o n e c o n t r o l l e r = sc; Str i n g l a b e l = c.getLabel(); i f (label.equals("Send SMS")) { selectedlmageName = sc.getSelectedlmageName(); networkScreen.setCommandListener(controller); . controller.setCurrentScreen(networkScreen); } e l s e i f (label.equals("Send Now")) { / / G e t t h e d a t a f r o m t h e c u r r e n t l y s e l e c t e d i m a g e ImageAccessor accessor = new ImageAccessor(sc.getModel()); ImageData i i = accessor.getlmagelnfo(selectedlmageName); b y t e[] imageBytes = accessor.loadlmageBytesFromRMS(ii.getParentAlbu mName(), ii.getlmageLabel(), ii.getForeignRecordld()); / / G e t t h e d e s t i n a t i o n i n f o S t r i n g smsPort = "1000"; Str i n g destinationAddress ='"5550001"; Str i n g messageText = "Command goes here"; smsPort = networkScreen.getRecPort(); destinationAddress = networkScreen.getRecPhoneNum(); SmsSenderThread smsS = new SmsSenderThread(smsPort,destinationAddress,messa geText); smsS.setBinaryData(imageBytes); new Thread(smsS).start(); } e l s e i f (label.equals("Receive SMS")) { / / s t a r t r e c e i v e r t h r e a d SmsReceiverThread smsR = new SmsReceiverThread(sc); System.out.println("SMSAspect::Starting SMSReceiver Thread"); new Thread(smsR).start(); }" e l s e i f (label.equals("Cancel Send")) { / / T O D O : I f t h e y w a n t t o c a n c e l ' s e n d i n g the - SMS m e s s a g e , s e n d t h e m b a c k t o m a i n s c r e e n System.out.println("Cancel sending of SMS message"); } e l s e i f (label.equals("Accept Photo")) { Image image = Image.createlmage(incominglmageData, 0, incominglmageData.length); PhotoViewScreen canv = new PhotoViewScreen(image); controller.setCurrentScreen(canv); 66 } e l s e i f ( l a b e l . e q u a l s ( " R e j e c t P h o t o " ) ) { / / T O D O : Go back t o w h a t e v e r s c r e e n t h e y w e r e p r e v i o u s l y o n S y s t e m . o u t . p r i n t l n ( " R e j e c t P h o t o c o m m a n d " ) } 67 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051632/manifest

Comment

Related Items