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


831-ubc_2005-0718.pdf [ 6.5MB ]
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

Full Text

Using AspectJ to Build a Software Product Line for Mobile Devices  by Trevor J. Y o u n g B.Math, University o f Waterloo, 1999  A THESIS SUBMITTED IN P A R T I A L F U L F I L L M E N T OF T H E REQUIREMENTS FOR THE 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 STUDIES (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 o f programmable micro devices on the market, each having different properties in terms o f 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 o f time and effort to program an application in a way that allows it to run on all o f these devices without modification. However, the variability o f hardware in these mobile phones, P D A ' s or music players has led the vendors to provide additional levels o f 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. W e call this the device A P I fragmentation problem. One potential way to ease the development o f a common application for a variety o f devices is using Aspect-Oriented Programming ( A O P ) 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 o f 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. W e present different implementations o f a prototype application to compare the AspectJ product line approach with standard objectoriented techniques that are currently used to build families o f 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 o f features.  ii  Contents Abstract..... Contents List o f Tables List o f Figures Acknowledgements 1 Introduction..... 1.1 Java for M o b i l e Devices 1.2 Implementing a M o b i l e Product Line using AspectJ 2 Related W o r k 2.1 Product Line Practice i n the M o b i l e Industry 2.2 General Product Line Practices 2.2.1 Multiple 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 3.1 The Base Application 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 A d v i c e 4.3 Managing Multiple Features Using Precedence 4.4 The B u i l d 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 Flexibility 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 W o r k Bibliography Appendix A : Acronyms Appendix B : A N T B u i l d Script Source Listing Appendix C : SmsAspect Source Code Listing  iii  1 1  List of Tables Table Table Table Table Table Table Table Table Table Table Table Table  3-1: 3-2: 3-3: 3-4: 3-5: 4-1: 5-1: 5-2: 6-1: 6-2: 6-3: 6-4:  Basic Features Included in A l l MobilePhoto Product Instances Optional Features Available for MobilePhoto Product Instances Sample o f J 2 M E Devices Indicating the Supported Software Components... Data Store Schema for MobilePhoto Image Data Data Store Schema for MobilePhoto Image MetaData MobilePhoto Product Instances (AspectJ) MobilePhoto Product Instances (Object-Oriented) '. Pure Variants Feature Model for MobilePhoto MobilePhoto Jar Size Comparison.... MobilePhoto Heap M e m o r y Comparison MobilePhoto Source Code Metrics Comparison Modified Classes for Custom Blackberry AspectJ Runtime  iv  12 13 14 15 15 17 29 35 40 41 42 48  List of Figures Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure  1-1: 2-1: 4-1: 4-2: 4-3: 4-4: 4-5: 4-6: 4-7: 4-8: 4-9: 5-1: 5-2: 5-3: 5-4: 5-5: 5-6: 5-7: 5-8:  Proposed M o b i l e Product Line B u i l d Process 4 Example Version Control Branching Technique for M o b i l e Product Lines ... 7 A O P Feature Weaving Applied to M o b i l e Product Lines 17 MobilePhoto Package Diagram 19 Class Diagram for S M S Feature ( A O P ) 20 Design Diagram Showing S M S Feature Interaction with Base Application. 21 Partial Source Listing for S M S Aspect o f MobilePhoto 22 Sequence Diagram to Send S M S (AspectJ) 23 Declaring Precedence to Manage Feature Interaction i n AspectJ 24 MobilePhoto B u i l d Process 26 Eclipse V i e w with A N T and B u i l d Configuration Plugins 27 O O P Patterns and Preprocessor Applied to M o b i l e Product Lines 29 Class Diagram for S M S Feature (OOP): 31 Partial Source Listing of MainUIMidlet Class ( O O Version) 32 Partial Source Listings of M a i n U I M i d l e t Class (OO Version) '. 33 Sequence Diagram to Send S M S (OOP) ; 34 Screen Capture o f Pure Variants Plugin with MobilePhoto Feature M o d e l . . 37 Partial Source Listing for M a i n B u i l d Target ( O O Version) 38 MobilePhoto B u i l d Process Using Pure Variants 39  Acknowledgements I would like to thank m y supervisor, Gail Murphy for keeping me focused, providing amazing guidance and feedback and showing me the ropes i n the world o f academic research. Thanks to all the great friends and colleagues I've met i n Vancouver for making it such an enjoyable experience. Thank-you to m y family for providing support and encouragement throughout m y life, and particularly i n 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 i n the amount and diversity o f 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 o f the current focus has been on creating content for cellular phones and personal digital assistants since there are already millions o f users who carry these in their pockets on a daily basis. For instance, in China, there are 300 million mobile subscribers, and this number is expected to grow to 500 m i l l i o n within the next two years. M o b i l e phone operators such as Sprint and Vodafone report that mobile games and other data services now account for roughly 10 percent o f their annual revenue, while mobile-game publishers generated $1.2 billion in global sales in 2004. For a programmer who wants their application to run on more than one device, managing the complexity o f many different hardware and software configurations can be more difficult than anticipated ' ' . In the mobile phone market alone, there are over 250 device platforms serviced by more than 80 different mobile operators in numerous languages. The major hardware vendors i n the market like Research in Motion, Palm, Nokia, Motorola, Siemens and Ericsson have anywhere from 20-50 models o f devices each. It should not be surprising that the different models and classes o f devices all have different programmable capabilities, platforms and requirements. 1  2  3 4 5  2  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. M a n y o f the phones run on the Symbian operating system , while most P D A ' s and organizers run some version o f Palm OS, R I M O S , Microsoft PocketPC or even Linux. This diversity o f device features and software platforms creates a large number o f 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 languages you may need to create as many as 2x2x10 = 40 different builds. N o w consider this problem from the perspective o f 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 o f this scenario, international games publisher 6  7  C h i n a ' s M i n i s t r y o f Information Industry (http://www.china.org.cn/english/BAT/127434.htm) M o b i l e Entertainment A n a l y s t Article (http://mobenta.com/analvsis/item-2138.html) Challenges and Opportunities i n M o b i l e Games (http://www-128.ibm.com/developerworks/library/wiaustingameconf.html?ca=dnt-539) 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) Creation vs. Fragmentation (http://www.screamingthumbs.com/2005/04/creation-vs-fragmentation.html) http://www.svmbian.com Multi-language support is often a requirement by game portals and mobile network operators 1  2  3  4  5  6  7  1  GameLoft recently released seven hundred different versions o f the game Splinter Cell for mobile devices i n sixty five different countries. 8  One way to address this problem is to develop the software as a product line, which supports the development o f a family o f systems that share a common set o f features and that are developed from a common set o f 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 o f which place rigid restrictions on the developer in terms o f available memory or disk resources and access to functionality o f the operating system. These restrictions mean that some o f 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 o f 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 o f the Java platform, Java 2 Platform M i c r o Edition ( J 2 M E ) 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 ( P D A s ) , set top boxes, and embedded devices. It includes Java Virtual Machines ( J V M s ) and a subset o f the standard Java APIs. The architecture o f J 2 M E has been designed to allow developers to choose from a combination o f configurations, profiles and optional packages to construct a . complete Java runtime environment that closely fits the requirements o f 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 ) optional library as a base for their application. However, the application would be limited to devices that support that particular combination o f 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 o f profiles, configurations, optional and proprietary libraries that fit together i n 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 w i l l make your application less portable. 9  1 0  Gameloft Simultaneously Launches 700 Versions o f T o m Clancy's Splinter C e l l Chaos Theory i n 65 Countries ("http://www.gameloft.com/press release.php?press 1=333) http://iava.sun.com/j2me/overview.html Refer to the appendix for a complete list o f acronyms used throughout this document  9  1 0  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 o f differences in the Java virtual machine implementations between device manufacturers. These differences have resulted i n a number o f 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. 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 o f external Java applications that can be installed, or the amount o f wireless data it can send. Finally, many o f the device vendors release proprietary Java A P I ' s to take advantage o f special functions that are only available on their hardware. This is in addition to the standardized optional A P I ' 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. W e refer to this problem as the device A P I fragmentation problem. 11  1.2 Implementing a Mobile Product Line using AspectJ The thesis o f this research is that aspect-oriented programming can alleviate the device A P I fragmentation problem for mobile device applications within the constraints o f these kinds o f 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 o f this process is depicted in figure 1-1.  11  This problem exists i n J 2 S E / J 2 E E as well, although i n J 2 M E y o u generally cannot install a choice o f 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 o f mobile applications, research into product line techniques that may be suitable for mobile devices, and existing applications o f 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 ( S D K ' s ) , toolsets and integrated development environments (IDE's) to offer developers support i n mobile development. The lack o f a standardized platform has led to the industry adopting a number o f ad hoc approaches. A n interview with A l l e n Lau, C T O o f Tira Wireless suggests that a large number o f 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. A l l e n further describes the J 2 M E (game) industry as being divided into application developers and specialized porting companies. In many cases, publishers o f original application content develop one or two generic versions o f their J 2 M E application for representative 'mass market' devices (such as the N o k i a 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 o f companies that have built successful business models around porting J 2 M E games and business applications across various devices. 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 i n the mobile industry. It is a problem that is likely to get worse before it gets better as the number o f 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 , J 2 M E P o l i s h and NetBeans M o b i l i t y offer utilities to help alleviate this problem but tend to help with only specific problems such as U l 14  15  16  17  The first K V M for P a l m was released i n 1999. Standardized M I D P 1.0 specification was released i n 2000, and hardware manufacturers began embedding it i n devices after that, (http://iava.sun.com/i2me/') Comments from telephone interview with A l l e n L a u , T i r a Wireless, M a y 2005 (http://www.tirawireless.com) www.small-device.com. www.tirawireless.com. www.octanetech.com. w w w . m f o r m a . c o m http://antenna.sourceforge.net/ http://www.j2mepolish.org/ http://www.netbeans.org/kb/articles/mobility.html 1 2  1 3  1 4  1 5  1 6  1 7  5  consistency or preprocessing support and do not yet offer a complete solution to building mobile product lines.  2.2 General Product Line Practices W i t h the advances o f wireless technology and reduced costs o f 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 o f product line implementation techniques that have been used with different degrees o f 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 i n short supply. A p p l y i n g 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 i n the J 2 M E space 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 o f 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 o f the application. 18  This approach can be made easier with the help o f version control utilities. Configuration management software such as C V S (Concurrent Version Control System) offers branching, versioning and merging techniques that allow you to create sub-branches off of a stable code base to take different copies o f your source code in different directions. One technique o f this approach is called a Platform Line or Permanent Variant B r a n c h . 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 19  20  8  9  10  Contacts from mobile and wireless companies T i r a Wireless, i A n y w h e r e Solutions, Eontec and others https://www.cvshome.org/ 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 N o k i a devices or Motorola devices, and these can be further sub-branched into specific models o f 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 i n sync.  /i-Series  branch  O  /Motorola  I  CH merge  branch / M I D P 1.0  branch  merge  O  /Nokia  branch  Q  - version  LZZI  - branch  /Series 60  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 o f duplicate code. For instance, i f both N o k i a series 60 and Motorola i-Series phone models support an S M S text messaging feature, you w i l l either have duplicate code i n 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 o f 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 o f the static way i n which most version control packages handle these features. Y o u must typically know the details o f all the platforms you wish to support when you create your branching structure, and you must also know what features or  7  components each o f 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 o f building re-usable components and sometimes form the basis o f product line development practices. Some o f 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 ( I D E ) is used as the base for a family o f I B M products such as WebSphere Studio, WebSphere Device Developer, Rational X D E 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 o f core assets. This makes it easy to m i x and match different plug-ins (with unique features) to form a complete product instance that targets a specific developer domain. A number o f software companies have used the base o f 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 o f the core software. The size constraints o f mobile devices would make an approach such as this one difficult to deploy because it increases the final executable size. In addition, some o f the basic object oriented features required by these frameworks are not available i n the limited J 2 M E libraries. For instance, as o f M I D P 2.0 there is no support for things like reflection, JNI (Java Native Interface), or user defined classloading. 21  2 2  2.2.3 Code Generation and Template Programming There is also an increasing interest i n 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 i n this area. Davis et al. recently conducted research investigating a generative-based approach for application tailoring o f 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 o f 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 o f an application and requires an implementation o f a custom interpreter i n 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 o f product instances using this technique would likely require substantive effort.  2.2.4 Pre-Compilation Utilities The use o f utilities or tools that include build configuration features or pre-processing capabilities is something that is becoming popular among mobile programmers. One o f the most common uses o f the preprocessor i n 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 o f the compiled code by including only platform-specific code for the target device. B u i l d 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 i n combination with other product line techniques, and can be effective at reducing the final application size o f 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. M u c h o f 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 o f separating features from application source code using AspectJ [7] which could apply to the design o f mobile applications. Loughran, Rashad et al. [8, 9] discuss a hybrid approach using aspect-oriented programming and Frames to support the evolution o f software product lines. They provide some simple implementation examples for a generic caching component, but at the time o f this writing it has not been tested for mobile applications. Lopez and Batory demonstrate the use o f 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 o f 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 o f modularization technologies (including AspectJ) in terms o f how they support the creation o f features as modules. M a n y o f 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 aspectoriented 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. W e are aware o f two groups who have used an aspect-oriented feature weaving approach with Java development on mobile platforms. A t the Federal University o f 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 o f AspectJ to enable adaptive J 2 M E applications to behave differently according to changes in its environment. [14], [15]. Anastasopoulos provides a set o f specific areas to investigate when evaluating aspectoriented 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 o f aspectoriented 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 o f 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 o f 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 o f 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 o f 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 o f 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 o f 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 o f 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 o f 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. A P I s 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) i n which generic code is created to encompass many different variations. W e 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 o f the base application are implemented using the lowest common denominator o f 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 A P I ' s , and avoids all optional or proprietary libraries. Therefore all ofthe base application features listed below w i 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 A l l MobilePhoto Product Instances  Create Photo A l b u m  Store Photo  A d d / Delete Photo  Label Photo  V i e w Photo  A l l o w s a user to define new photo albums to store related categories o f pictures on the device. A l b u m information is persisted using R M S ( J 2 M E Record Management System). Handles the conversion and persistence o f photo image files to the mobile device file system using R M S . A l l o w s a user to permanently delete photos from the device, or add new photos to defined albums. A l l o w s a user to label a photo with text. Labels appear i n the display list, and could be used for future search functionality. This displays a selected photo on the device screen.  3.2 The Optional Features The optional feature components o f 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 o f the base application are not aware o f 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 o f the base MobilePhoto application. The optional features available are shown i n table 3-2.  12  Table 3-2: Optional Features Available for MobilePhoto Product Instances  Send Photo via S M S  Send Photo via Email L i n k Photo with Address Book Entry  Display Photo o f Incoming Caller  Play melody o f Incoming C a l l  A l l o w s a user to send a photo to another user v i a Short Messaging Service. A l l o w s a user to send a photo to another user via Email. A l l o w s a user to associate an entry in their contact list with a photo i n their album. Intercepts incoming phone calls and displays a photo o f the associated caller while ringing. Intercepts incoming phone calls and plays a custom ring-tone o f the associated caller while ringing.  A l l o f 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 o f devices that can support the optional features for MobilePhoto. Note that it lists only six models, from the hundreds o f J 2 M E enabled devices currently available.  13  Table 3-3: Sample of J 2 M E Devices Indicating the Supported Software Components  HARDWARE VENDOR Palm Tungsten  Nokia 6600 7210  X  X  X  X  X  X  X  X  X  X  X  X  via E m a i l L i n k Photo w/ Contacts Display Photo Incoming Caller  2 4  X  X  2  a. «  X  26  Play M e l o d y Incoming Caller  X  26  3.3 Architecture Following standard practice[17], MobilePhoto utilizes the M o d e l V i e w 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 o f photos stored on the device. Photos are MobilePhoto MobilePhoto MobilePhoto MobilePhoto Motorola 2 4  2 5  2 6  S M S Feature uses the optional W M A A P I from Sun E m a i l feature uses the proprietary email messaging A P I from R I M Address B o o k feature uses the optional P I M A P I from S u n Incoming C a l l (Photo and Ringtone) features use the proprietary Telephony A P I from  14  instances o f j a v a x . m i c r o e d i t i o n . l c d u i . I m a g e objects when loaded in the Midlets memory. A l l o f this information is persisted to the devices internal storage using J 2 M E ' s record management system ( R M S ) . R M S is a very crude database implementation that can only store a record Id (assigned automatically by J 2 M E ) and a series o f bytes. MobilePhoto creates two record stores for every photo album defined. One store holds the bytes o f the images, and a second one holds the metadata o f the images. Metadata information is stored as a delimiter separated string o f fields and then converted into bytes that are saved i n 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  Image Data  Byte Array  Automatically assigned by J2ME R M S Images are converted into byte arrays.  Table 3-5: Data Store Schema for MobilePhoto Image MetaData  Record Id  Int  Image Metadata  Byte Array  Record Id  String  Foreign Record Id  String  Album Name  String  Image Label Phone Number  Audio File  Automatically assigned by J2ME R M S The metadata is a string o f delimiter separated fields that are converted into a byte array. Specific fields are listed in the next rows. Record Id o f this entry (stored as string for easier access later). Record Id o f the corresponding Image Data record in the data store. The name o f the photo album this image is associated with. A user defined label. A Phone number for an image to associate with address book entries. (Only used for certain features) Name o f an audio file for an image to associate with melodies or ringtones. (Only used for certain features)  String String  u  Name ' 1  String  Phone N u m b e r and A u d i o F i l e 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 M o d e l V i e w Controller) consists o f the actual screens that display the photos, albums and related commands to the user. Since the purpose o f 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 o f 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 N o k i a 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 o f MobilePhoto, we used AspectJ. Our intent was to describe the optional features o f 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 o f the design and architecture described in chapter 3. A given configuration o f 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 aspectoriented programming. Features using optional APIs written independent of Base Feature using Email APIs  Base Application (J2ME v.1)  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 o f MobilePhoto we built a variety o f product instances by combining different combinations o f optional features. (Table 4-1) . 9  Table 4-1: MobilePhoto Product Instances (AspectJ)  Base Base Base Base Base Base  Application Application Application Application Application Application  only + SMS + S M S + Caller Photo + S M S + Caller Photo + P I M + S M S + Caller Photo + P I M + Play Ringtone + 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 o f our MobilePhoto application was tested on a number o f device emulators from different vendors, in addition to testing on selected (real) hardware devices listed below: • • • • • • • • • • • • • • • • • •  Palm Tungsten C (Hardware device) N o k i a 6600 (Hardware device) Sun Generic Wireless Toolkit Emulator Sun Generic Wireless Toolkit Emulator 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 O S Emulator (with Sun M I D P 1.0 Palm O S Simulator (with I B M J9 K V M Motorola i730 Emulator Motorola i830 Emulator Motorola i860 Emulator N o k i a 3410 Emulator N o k i a 7210 Emulator N o k i a Series 60 Emulator  (v. 2.1) (v. 2.2)  K V M for Palm) for Palm)  Note that MobilePhoto jars were only tested on emulators or hardware that supported the particular feature-set o f a given version.  4.1 De-coupling Optional Features using Aspects To enable the exclusion o f 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 o f information is referred to as a Classdirectional 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 o f the base application. The components that make up a feature are a set o f 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 AupIication>  c rT'iidp  friobiiephoto.core.commj  Iication>  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. m o b i l e p h o t o . sms Java package. It includes the four Java source files, and one AspectJ source file displayed in the lower portion o f figure 4 - 3 . The BaseMessaging class at the top o f the diagram is part o f a base application package.  19  BaseMessaging  A Net works creen ,  SmsMessaging  SmsReceiverThread  • « • aspect » SmsAspect.  SrnsS enderThread  Figure 4-3: Class Diagram for S M S Feature (AOP)  N o 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 i n 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 o f 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 o f our prototype application, there are two important areas o f 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 o f the base application, but it must be aware o f 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 o f 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 o f 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. W e use three pointcuts i n the SmsAspect (figure 4-4) to identify these join points.  SMS.Messaging Feature  @.SMSAspeet:;  Base Application  after initMemi  ImageList 'after,:  initMenuQ  commnndAr.tion after imageReceived  ScreenController o commandActionQ  SMSSenderThread i f  /  SMSReceiverThread ® imageReceived()  ;  Figure 4 - 4 : Design Diagram Showing S M S Feature Interaction with Base Application  The i n i t M e n u l t e r n s 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 w i 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 o f the source code for the SMSAspect is in the Appendix.  21  //Introductions: //Define  new  Command  menu  commands  smsSendCommand  associated  = new  with  SMS  Command("Send  feature  SMS",  Command.ITEM,  1); Command  smsReceiveCommand  Command.ITEM, //Capture  event  -  new  Command("Receive  1); when  Ul  initializes  the  menu  p o i n t c u t i n i t M e n u I t e m s ( L i s t 1) : a r g s ( l ) ImageList.initMenu(List)) ; //Add  SMS  after(List  Specific  SMS",  menu  items  to  the  items  && e x e c u t i o n ( *  main  Ul  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) i n 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 o f 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. (The diagram o f the pointcuts for the Sms Aspect is pictured in figure 4-4). 30  This method o f 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 o f execution when a user invokes the feature to send a photo over S M S . Note that the handleCommand () method i n the B a s e C o n t r o l l e r 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.  F u l l source code for the M o b i l e P h o t o application is available at http://www.cs.ubc.ca/labs/spl/  22  User presses*'Send S M S ' 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 S M S (AspectJ)  4.3 Managing Multiple Features Using Precedence One o f the difficulties i n managing a large collection o f 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 o f effort, and is beyond the scope o f 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 i n 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 o f 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 o f 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). W e have not investigated any methods o f 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 b y manually excluding one o f the conflicting features during the build process. Section 5.3 discusses the potential o f a third party Eclipse plugin that can help (statically) manage these situations during the build process. Using this approach puts the burden o f managing features on the developer, because features must now be aware o f 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 o f 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 o f devices you need to support, which adds to the complexity in managing the build process. To add to the confusion, most o f the major device vendors have released proprietary S D K ' s , I D E ' s or toolkits to help developers write applications for their specific platforms. This group includes the (generic) Sun Wireless T o o l k i t , Blackberry Java Development E n v i r o n m e n t , N o k i a Developer's Suite for J 2 M E , Motorola iDen S D K for J 2 M E , Siemens M o b i l e S D K , Palm OS (J2ME) Developer Suite , and the Qualcomm B R E W S D K to name a few. 31  3 3  3 5  3 4  36  3 7  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 that offers additional support for J 2 M E specific build tasks. Although A N T does not eliminate all o f the dependencies on installing third party I D E ' s , S D K ' s or tools, it does let you separate the build process into a simpler chain o f tasks and run a single command line script to run the necessary steps. 9  Because this thesis focuses on the variability o f 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 o f only those features that are supported b y a device. This criterion is important because o f the restrictions mobile vendors and operators place on the size o f applications that can be installed. A s an example, N o k i a Series 40 phones place a 64 K B maximum on the size o f Midlets compared to some N o k i a Series 60 phones that support up to 4 M B . 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 o f features and base code) and eventually allow one to perform bulk builds for a complete line o f dozens o f 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 v i a 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. 4 0  The control o f feature inclusions for MobilePhoto is done during the build stage by using a configuration file. A list is maintained that includes the names o f 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 o f 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  - clean - compile - preverify - package  Build properties  Final executable A N T build script  /  \ 1  List of sources to include (base + optional features)  Resources and source files  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 i n the build. W i t h the A N T and A J D T plugins for Eclipse, we are able to control the entire build process within the I D E . 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  fjle  \.\\ 1  ikMllU  Edit  Navigate  lit  ,f* Package Explorer >Mob4lePhoto  ;+!  project  • u  _ : ^  [• I | | i 5 0 I'lAtfuttli  Search  \  Eun V£mdow  •^• 'i •  v  Hierarchy  ^  ^  S  + -fi$ >ubc.rrudp.photc»a]bum,core.ii :  + 03 >ubc.midp.photoa!bum.pim fB •= ;  blackberry  S-QlS'  motorola,  "  £ 1  | P']  S TeamSynchr.. G  fllackBerryEtnaH  .pim  ith-Dtp-  Siemens  & i - 0 i £ V sms-  1.3 (ASCII  NetworkScreen. Java  l+lSMSRecelverThread.Java 1.4 (i  0 b!) 5M5Aspect.aj  SMSSenderThread.Java 1.4 (A:! =- •• jj| S^SMSAspectlaJiUa^CBiriary);  *^  f7j ScreenContrcJIer  photoalbum  sB-QifSj'  £!•••••  i  >ubc,midp.pnotoalbum.sms  ft]NetworkScreen.java  «*  cor©  •+;•••% >ubc.rrudp.photoa!bum.motorola i.+j-J^ >ubc.midp.photoa!bum.Siemens  l  nntdp  B'0^>  >ubc;mjdp.photoalbum.blackberry' •  5*  -default. Isi  B-EItc>  [BTTRAIN-LAB]  0 '  tl)  *5d build, xml  SMSReceiverThread.java  i  :+'"(£r' >aic-compiled  \  > • & >)2se-c!asses  <  SMSSender Thread. Java  i^i' Xnidp-compiled >prc-compi!ed  Problems Console f,jSc A f * * E 3 ^ . * - ,  >rapc-compiled  '••43 >build;xml ;  1.3 (ASCII -kkv)  I  i-jfe MobilePhoto Prototype [full-build] aspect j-compfe  >defaiit.lst 1.1 (Binary)  :••••<*=; 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  3> Debug  ^  jj/J Cmail5er.de/Thr  J  ^ v a ^ C V 5 Reposito, i T s M S A s p e c t at  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 o f aspect-oriented technology i n 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 o f 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 o f MobilePhoto uses standard object-oriented techniques that are available in Java (J2ME). The intent o f 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. M a n y developers are turning to the use o f J 2 M E preprocessors to handle the different device characteristics in their Java applications. Some common design patterns such as the Chain o f Responsibility^] can also help structure mobile product line development. A given configuration o f 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. 41  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/  4 1  28  Chain of Responsibility  Each feature implements a controller to handle feature specific actions Email Messaging Feature  Final Application  1 /fder c o "5 ST ! ; ifdef .2 a-i  SMS Messaging Feature  | •  0 5  III  !  ifdef  j|||| 1 /fete/  m  s £ CM ->  (  )  Digital Photo Feature  Preprocessor statements are used to bind features to base application  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 o f optional features that are used in MobilePhoto. For the object-oriented implementation o f MobilePhoto we built the same combination o f product instances as the aspect-oriented version. Table 5-1 lists these . 42  Table 5-1: MobilePhoto Product Instances (Object-Oriented)  Base Base Base Base Base Base  Application Application Application Application Application Application  only + SMS + S M S + Caller Photo + S M S + Caller Photo + P I M + S M S + Caller Photo + P I M + Play Ringtone + Email  The object-oriented version o f our MobilePhoto application was also tested on the same set o f emulators and hardware that the aspect-oriented version was tested on: • • •  Palm Tungsten C (Hardware device) N o k i a 6600 (Hardware device) Sun Generic Wireless Toolkit Emulator (v. 2.1)  • •  Sun Generic Wireless Toolkit Emulator (v. 2.2) Siemens C F 6 2 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 N o k i a 3410 Emulator N o k i a 7210 Emulator N o k i a Series 60 Emulator  Note that MobilePhoto jars were only tested on emulators or hardware that supported .the particular feature-set o f 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 o f 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 o f responsibility design pattern and a Java preprocessor to accomplish the de-coupling o f 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 o f 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 o f the S M S feature.  30  BaseMessaging  HetvgorkScreen  SmsMessaging  BaseController  SmsReceiverThread  SnisController  SmsSender Thread  Figure 5-2: Class Diagram for S M S 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 o f base application packages and the other classes form the S M S feature. Following the chain of responsibility pattern, on startup all the controllers ( B a s e C o n t r o l l e r 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 ( B a s e C o n t r o l l e r ) 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 o f the controllers is able to satisfy the request and take the appropriate action. Using this approach allows us to limit the use o f preprocessor statements to creating new controllers in the main Midlet class and ordering the chain. A snippet o f the source code from this section is in figure 5-3.  31  r o o t - C o n t r o l l e r = new B a s e C o n t r o l l e r ( t h i s , prevInChain = r o o t C o n t r o l l e r ;  model);  //#ifdef includeSmsFeature n e x t l n C h a i n = new S m s C o n t r o l l e r ( t h i s , model); prevInChain.setNextController(nextlnChain); prevInChain = n e x t l n C h a i n ; //#endif //#ifdef includeBlackberryEmailFeature n e x t l n C h a i n = new B l a c k b e r r y E m a i l C o n t r o l l e r ( t h i s , prevInChain.setNextController(nextlnChain); prevInChain = n e x t l n C h a i n ; //#endif  model);  Figure 5-3: Partial Source Listing of MainUIMidlet Class ( O O Version)  In the current implementation o f MobilePhoto there are six optional features, and therefore six sub-classes o f 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 o f the controllers i n 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 o f an incoming caller, their order in the chain w i l l dictate which feature is invoked during an incoming call. W i t h the object-oriented programming implementation, either the ringtone w i 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 I D E ' 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. U s i n g a preprocessor allows for conditional compilation and inclusion o f entire source files or small sections o f 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 o f their J 2 M E applications. In the object-oriented version o f 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 o f the base application are ifdef statements that tell the preprocessor to include relevant lines o f code i f the symbol for a particular feature is defined in the properties file. A s mentioned i n Chapter four, there are two points i n MobilePhoto where optional features are integrated with the base code: extending functionality o f 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. W e were able to further reduce the amount of preprocessor included code by implementing the Chain o f Responsibility design pattern, discussed in the previous section. T o 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 n e x t l n C h a i n = new S m s C o n t r o l l e r ( t h i s , model); prevInChain.setNextController(nextlnChain); prevInChain =•nextlnChain; //#endif PhotoListScreen (menu item addition): [class variables] 11#ifdef i n c l u d e S m s F e a t u r e 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 ( O O Version)  Similar sections o f the preprocessor tagged lines o f code above are needed for each optional feature o f the application. The six optional features i n MobilePhoto quickly increase the number and complexity of preprocessor statements needed throughout the  33  code. The U M L sequence diagram i n figure 5-5 shows the flow o f 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 i n the chain. In this scenario, the S m s C o n t r o l l e r is next in the chain. The type o f controllers and the ordering o f them w i l l depend on which features were included b y the preprocessor and the order they are specified i n the source code.  User presses 'Send SMS' menu item  PhotbListScreen  SmsController: BaseController  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 S M S (OOP)  5.3 Managing Multiple Features Using Pure Variants™ The focus o f this research has been on implementation techniques that make it easy to include combinations o f optional features that are supported b y a specific device platform. However, it does not address the issue o f feature modeling or managing the relationships between these optional features. To investigate the potential o f enforcing relationship rules for features i n our model, we used a third party development tool for the Eclipse I D E called Pure Variants . The Pure Variants Eclipse plugin let us add a layer o f abstraction on top o f our J 2 M E objectoriented 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 43  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 o f either 'Base Features', 'Address Book Features', 'Incoming C a l l Features' or Photo Transfer Features'. W e also defined a new group called ' B u i l d Environment Features' which does not technically include features in the application but it let us capture the variability o f 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 w i 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). W e also defined relationships between features where necessary to indicate dependencies or conflicts. Table 5-2 shows a summary o f the groups, types and relations that make up the MobilePhoto feature model. Table 5-2: Pure Variants Feature Model for MobilePhoto  Relationships  Feature Create Photo A l b u m Store Photo A d d Photo Delete Photo Label Photo V i e w Photo  Type mandatory mandatory mandatory mandatory mandatory mandatory  Address Book  L i n k Photo with Address Book  optional  <Requires> Include P I M lib  Photo Transfer  S M S Photo Transfer  optional  Email Photo Transfer  optional  <Requires> <Requires> <Requires> <Requires> .cod  Display Photo o f Incoming Caller  alternative  Play Ringtone o f Incoming Caller  alternative  Use Preprocessor  optional  Use Aspect Weaver Use Obfuscator Convert to Palm .pre  optional optional optional  Group Base  Incoming Call  Build Environment  35  Include W M A lib Target M I D P 2.0 Include R I M lib Convert to R I M  <Requires> Link Photo with Address Book <Requires> Include Motorola lib <Requires> Link Photo with Address Book <Requires> Include Motorola lib <Conflicts> Use Aspect Weaver <Conflicts> Use Preprocessor  Convert to R I M .cod Target M I D P 1.0 Target M I D P 2.0 Include W M A lib • Include R I M lib  optional optional optional optional optional  Include Motorola lib Include P I M lib  optional optional  <Requires> Target M I D P 1.0  <Requires> Target M I D P 2;0 <Requires> Convert to R I M .cod  There are a number o f ways you could define your feature m o d e l to give you the desired level o f control during the build process. If desired, we could have specified that the 'Display Photo o f Incoming Caller' and 'Play Ringtone o f Incoming Caller' features were both optional instead o f 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. W e could also create sub-groups under the ' B u i l d 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 o f Preprocessor or Weaver) or. obtain finer control o f the target devices by defining sub-groups o f M I D P 1.0 and 2.0 to include specific device models (e.g., N o k i a 6600 could be part o f the subgroup '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 i n 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 B  MobilePhoto [Root] • | 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  •/ | I+J  Build Environment 'Features' [MobilePhoto_BuildResources] Q ? Optional Libraries [MobilePhoto_BuildResources_Lib] !_] ? Default Images [MobilePhoto_BuildResources_Images] [J 9 AspectJ Build [MobilePhoto_BuildTask_AspecUCompile] L j 'j Use Pre-processor [MobilePhoto_BuildTask_Preprocess] l j V Obfuscate [MobilePhoto_BuildTask_Obfuscate] 1  RI !+] fcj  • ^ Target J2ME Platform [MobilePhoto_BuildResources_TargetPlatform] Cl Properties File [MobilePhoto_BuildResources_Properties]  LJ 1* Address Book Features [MobilePhoto_AddressBook]. [J f AssoclateiPhoto with:'Address:BookEntr,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]  El  Q f  • ? HTTP Photo Transfer [MobilePhoto_Transfer_HTTP] Incoming Call Features [MobilePhotoJncomingCall] Display Photo on Incoming Call (Motorola) [MobilePhoto JncomingCall_DisplayPhotoJ<lotorola]  i • I  Play Ringtone on IncominrId: ikgpANUrVxnX09dv4 Play Ringtone on IncomiH Unique Name: MobilePhoto_IncomingCalI_DisplayPhoto_Motorola Visible Name: Display Photo on Incoming Call (Motorola) Class: ps:feature Feature Models j i^] Family Models | '^Problems | S Console 53  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 o f the Requires relationship we defined. Using the Pure Variants plugin also enabled further automation o f 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. W e 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 i n the Pure Variants version o f our build script template is defined in figure 5-7.  37  < !- -  ===== = == = == = == = = = = == = = = == = = == = = = = = == = = ====== = = = = = = ==== = == = ====== = =  <!-- F u l l B u i l d  ( D e f a u l t Target)  -->  -->  < j - - = ==== = = = = = = = = = === = = = = = ======= = = === = = = = = = = = === = = = = === = = = = ====  -->  <target 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 " /> < a n t c a l l target="midp-preprocess" c o n d i t i o n = " p v : h a s F e a t u r e ( B u i l d T a s k _ P r e p r o c e s s ' ) " /> < a n t c a l l target="midp-compile" /> < 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 target="make-jar" /> <antcall target="rapc-compile" c o n d i t i o n = " p v : h a s F e a t u r e ( ' T a r g e t P l a t f o r m _ R I M ' ) " /> < a n t c a l l target="make-prc" condition="pv:hasFeature('TargetPlatform_PalmPRC')" /> </target> 1  Figure 5-7: Partial Source Listing for M a i n 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 ' B u i l d 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 o f the build process using Pure Variants is shown in figure 5-8.  38  Build properties  Feature Selection  - clean - compile - preverify - package - src list  Feature Model  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 o f 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 o f 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 o f MobilePhoto is the same as the code in the object-oriented version. Both followed the same architecture and design and adhered to the requirement o f 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 o f optional feature components, how to bind optional features into the core application, and how to manage feature interaction. The rest o f this chapter compares these implementations in terms o f modularity, scalability, complexity, tool support, platform support and quantitative analysis o f size and resource usage.  6.1 Quantitative Analysis One o f the most important factors to consider when choosing an implementation technique for mobile development is the size and performance o f 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 o f the AspectJ implementation and the object-oriented implementation o f 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 o f 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  Final app size [jar]  MobilePhoto AOP (Base)  MobilePhoto OOP (Base)  MobilePhoto AOP (All)*  MobilePhoto OOP (AH)*  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 o f this jar (aspectjrt.jar) is 40 K b . W e were able to reduce this size slightly by removing all o f 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 o f our modified (and obfuscated) AspectJ runtime jar was 29 K b . 4 4  Table 6-2 shows measurements o f heap memory use 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. 45  The maximum heap size for the emulator used was 2 M b (-2000 K b ) , 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 o f the aspectoriented 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  List Contacts  A O P Base O O P Base  1935 1936  A O P Base + S M S O O P Base + S M S  1936 224*  156* 242  204 291  A O P Base + SMS + Caller Photo O O P Base + SMS + Caller Photo  1936  168*  217  244  275*  294  343  376  1936  186*  234  264  213  286*  306  354  389  200  A O P Base + SMS + Caller Photo + P I M O O P Base + SMS + Caller Photo + Increase P I M indicates  View Photo 166 167  Display Caller Photo  Select Album 1953 1954  garbage collection occurred at 2 Mb, and dropped back to 0 before increasing  again  W e found that the source code metrics for both implementations were similar. The number o f classes (or aspects) used and the total lines o f code were either identical, or 4 4  4 5  W e used the open source 'jarg' (Java A r c h i v e Grinder) obfuscator (http://iarg.sourceforae.net") The M o t o r o l a i D e n S D K M e m o r y M o n i t o r was used to record heap data using the i860 device emulator  41  only slightly higher i n the object-oriented implementation. There was also little noticeable difference i n 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  # build script tasks # Classes (& Aspects) # Lines of Code Build Time  MobilePhoto AOP (Base)  MobilePhoto OOP (Base)  MobilePhoto AOP (All)  MobilePhoto OOP (All)  7+  6+  7+  6+  16 (no aspects)  16  41  550  565  19 Seconds (to run A n t build with ajc)  18 Seconds (to run Ant build with javac)  41 (35 classes + 6 aspects) 1481 (227 from Aspect code) 31 Seconds (to run A n t build, no conversions)  46  46  1524 29 Seconds (to run A n t build, no conversions)  The most significant finding o f the quantitative analysis is that any J 2 M E and AspectJ implementation w i l l increase your application b y approximately 29 K b . This is important when developing for devices with tight restrictions on the size o f application. In most other quantitative categories we found the difference between the AspectJ and objectoriented 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 o f 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 b y a feature into a separate module. Source code statements associated with a feature implementation may be scattered throughout the rest o f the components i n 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 i n a separate module. In the AspectJ implementation o f MobilePhoto, we were able to modularize each of the optional features. The implementation o f each optional feature is contained i n 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 o f digital photos over S M S , a programmer can focus on classes i n the ubc .midp .mobilephoto. sms package. Including or excluding this feature when building a product instance simply requires the developer to select a checkbox i n 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 o f 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 o f MobilePhoto modularizes the programming logic associated with optional features, but does not prevent the scattering o f source code changes needed to integrate the features with the base components. For example, in the object-oriented version the majority o f 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 i n the base components such as MainUIMidlet and P h o t o L i s t S c r e e n with preprocessor statements. Using the preprocessor allowed us to maintain the simplicity o f the build process, so that editing a property file would trigger the inclusion or exclusion o f the integration code based on preprocessor 'ifdef tags. Incorporating the Chain o f Responsibility design pattern improved things further so that instead o f having to embed the controller logic for a feature directly in the B a s e C o n t r o l l e r class, each feature maintained its own extension o f the controller that was only part o f the chain i f the feature was included i n the build process. Therefore in the object-oriented implementation o f 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 willing to make substantial modifications at times. A wide range o f 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 o f advice can apply. This lack o f fine granularity is particularly evident using AspectJ with J 2 M E , where certain features o f AspectJ are not available (see section 6.4 for details on AspectJ support with J 2 M E ) . 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 o f modularity due to scattered preprocessor statements. A final matter that should be noted is the impact o f binding time - the point in the development cycle at which the features o f 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. A l l o w i n g 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 o f 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 i n 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. W i t h 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 o f a concern. It is important to consider how well your product line development process can scale in terms of the number o f optional features available to products and the number o f devices you must support. The number o f features you can squeeze into a single application instance w i l l be limited by the amount o f memory or disk space the hardware vendor allows for third party applications. But as hardware gets cheaper, the number o f features you can include w i l l increase. Especially i f you are targeting higher end devices that offer larger amounts o f 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 o f hardware peripherals that micro devices offer can lead to a large array o f optional features to plug into your product line. This results in many lines o f preprocessor tagged source code scattered throughout the components o f the base application. The MobilePhoto application has six optional features, which means multiple sections o f code i n the base components must contain six embedded preprocessor statements i n every area you need to integrate these features. For example, in the M a i n U I M i d l e t class, there are preprocessor tagged insertions o f 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 o f handlers. This is multiplied by six, since there are six optional features. A s the number o f optional features grows, the source code in the object-oriented version o f 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 o f optional features is good practice, but in the mobile space it is probably not as important as being able to handle an increasing number o f hardware devices i n your product line. The most popular genre o f J 2 M E applications currently on the market is mobile gaming. In general, there is not a great deal of variability i n the gaming features, but there is a large demand to support an increasing number o f devices. In our case o f building mobile product lines, scalability refers to whether your development and build process can handle dozens or even hundreds o f different device models. Given the flexibility provided by the aspect-oriented approach, scalability in this context relates to the level o f 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 N o k i a libraries), the inclusion or exclusion o f source components for optional features, and the addition o f build tasks that are specific for a particular device (e.g., converting J A R files to native Palm OS or R I M O S 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 o f 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 I D E or toolkit install directories to the location o f the conversion utilities. When new features were added to the application, we needed to update the list o f source files i n the compile list and update the classpath settings i f new optional or proprietary libraries were required during compilation. The task o f updating the compilation list was made easier in the Eclipse I D E by using the feature o f the A J D T  45  p l u g i n 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 o f 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. 47  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 o f devices to support grows very large. One option to improve the scalability i n this regard is to automatically generate a new build script based on the target platform and features selected. W e 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 o f 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 i n the development cycle because there is less work managing the build process. Automating the build tasks would require the same effort for the objectoriented 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 must also be deployed to the device and run within the context o f whatever virtual machine is installed on your phone or P D A . The AspectJ runtime used i n 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 i n 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. 48  The first area o f 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 o f 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 o f reflection i n J 2 M E means that t h i s J o i n P o i n t cannot be used in advice. The t h i s J o i n P o i n t construct o f AspectJ uses reflection to allow a programmer to capture static and dynamic context information associated with j o i n 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 a r g s keyword o f AspectJ. For example, i n standard AspectJ, we can write the following i n i t M e n u l t e m s pointcut: >  pointcut initMenultems()  : execution(* PhotoListScreen.initMenu());  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 ) PhotoListScreen.initMenu(List)) ;  && e x e c u t i o n ( *  In this case, we have to change the P h o t o L i s t S c r e e n . i n i t M e n u ().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 o f 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 o f MobilePhoto. However, there is a similar issue related to c f low pointcuts that we were aware o f although it did not affect our implementation. J 2 M E has very limited support for threading and does not include many o f the utility classes found i n the standard j ava. u t i l package. Unfortunately, parts o f the AspectJ runtime related to c f l o w pointcuts rely on many o f these thread, stack and utility classes. W e read about this limitation from an F A Q entry on the AspectJ website . 49  The second major limitation we experienced using AspectJ to implement MobilePhoto was a difference i n behaviour for Java enabled R I M devices. For most emulators and hardware that we tested, the AspectJ version o f 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 , the application crashed with a series o f exceptions indicating it could not find many o f the classes used in the AspectJ runtime. W e 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 o f 50  http://dev.eclipse.org/viewcvs/in^ We tested using Blackberry J D E v 3.7 and v 4.0, and the standalone Simulator v  47  AspectJ that relied on unsupported APIs. But for the Blackberry we had to make several modifications to the source code o f the AspectJ runtime before it would work. Specifically, we had to remove any references or usage o f 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 o f the runtime. Table 6-4 provides a summary o f the AspectJ runtime source files that were modified, and notes the n o n - J 2 M E 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 org.apsectj.runtime.internal.CFlowCounter  Java.io.PrintWriter System.getProperty(x,x) not  org.apsectj.runtime.internal.CFlowStack org. apsectj .runtime.internal. Conversions  System.getProperty(x,x)* Java.lang.Float, Java.lang.Double, j ava.lang.Number,  s u p p o r t e d i n J2ME  double,  f l o a t  p r i m i t i v e  types * *  org.apsectj .runtime.internal. cflowstack.ThreadCounterlmpl 1 org.apsectj.runtime.internal.cflowstack.ThreadStackFactorylmpl  java.util.Iterator, j ava.util.List, java.util.ArrayList java.lang.ThreadLocal ( i n h e r i t e d  org.apsectj.runtime.reflect.Factory org.apsectj.runtime.reflect.ini tializerSignaturelmpl org. apsectj .runtime.reflect.Signaturelmpl  org. apsectj .runtime.reflect.StringMaker  from  t h i s  * listed method calls are not available for the named class in J2ME ** double andfloatprimitive 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 o f 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 i t e r a t o r , ThreadLocal or A r r a y L i s t would likely increase the size o f the jar file and it would be difficult to guarantee the same behaviour as the standard J 2 S E implementations.  48  c l a s s )  j ava.lang.ClassLoader j ava.lang.reflect.Modifier Java.lang.ClassLoader, Java.util.StringTokenizer, j ava.lang.ref.SoftReference, Java.lang.Float, java.lang.Double, j ava.lang.Number, java.lang.Void, Class.getClassLoader*, Class.getComponentType* Java.lang.reflect.Modifier, Class.getComponentType*  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 o f 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 i n the compile chain. When the J 2 M E virtual machine ( V M ) on a device attempts to execute a J 2 M E C L D C - b a s e d 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. 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., t h i s J o i n P o i n t and c f 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 i n the preverification classpath. This technique worked with all o f the available emulators and hardware tested, with the exception o f the Blackberry platform, which was discussed above. 51  6.5 Complexity of Implementation The complexity o f 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 o f implementation complexity looks at the design and implementation o f the application framework and components i n the two approaches taken, and the ease with which (optional) variant components can be reused across product instances. Both versions o f our prototype application were programmed using Java 2 M i c r o 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 o f AspectJ is somewhat simplified when applied to mobile devices because some o f the more complicated functions i n 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 o f a learning curve for programmers to use  5 1  The preverify tool is included with the Sun Wireless T o o l k i 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 o f mobile products, a negative variation approach might be necessary. The use o f AspectJ in a negative variation approach is discussed elsewhere [22], [13]. Another issue o f complexity i n the AspectJ approach is the ease o f 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 o f testing aspects is being explored further, and helpful tools are starting to emerge to facilitate this and make it easier. 52  6.6 Tool Support Tool support for developing J 2 M E applications is still in its infancy. Although there is an abundance o f S D K ' s , programming tools and development environments available from vendors, most o f 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 o f these vendors plan to release versions o f their toolkits that integrate with existing I D E ' s like Eclipse or Netbeans. But at the moment, there is still a significant amount o f 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 i n proprietary A P I ' s and rely on only the generic emulators for testing. But you still need to install some o f the utilities from Palm and R I M that convert your Java application into native file formats. A l l o f 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 o f the applications listed below:  http://www.aunit.org/ is a unit testing framework for AspectJ that follows the x U n i t / J U n i t framework.  50  o o o o o o o o o o o  Eclipse I D E (Could be any Java editor o f choice) AspectJ Development Toolkit ( A J D T plugin for Eclipse) Sun J 2 M E Wireless Toolkit Apache A n t + optional tasks for J 2 M E and AspectJ J 2 M E Preprocessor (Antenna) Blackberry Java Development Environment N o k i a Developer Suite for J 2 M E Motorola i D E N S D K for J 2 M E Siemens M o b i l i t y Developer Suite Sun P R C Conversion T o o l for Palm OS 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 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 o f the development workspace. The latest release o f the Netbeans Java I D E includes a M o b i l i t y Pack 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 o f code associated with other devices (or features) are hidden from view. This would certainly help the readability o f source code for projects that contain lots o f 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 o f Eclipse (part o f their Eclipse 'product line') called Websphere Device Developer ( W S D D ) that provides automatic integration for a variety o f J 2 M E emulators and utilities available. W S D D requires a purchased software license to use, and at the time o f this writing it did not offer any solution to the A P I fragmentation problem. 53  5  Despite the wide array o f development environments available (and necessary), we found that none o f them met all o f our needs to facilitate easier mobile product line development. The vendor provided tools were generally lacking i n basic Java I D E features that many developers have come to expect, such as advanced search and navigation, re-factoring and customizable views. These vendors I D E ' s also included no support for aspect-oriented programming. Most o f the I D E ' s (with the exception o f Netbeans) did not directly support a preprocessor, which meant that the object-oriented version o f MobilePhoto could not have been built using the built-in I D E compiler. When we attempted to use E c l i p s e M E with the A J D T plugin for Eclipse to compile the aspectoriented version o f 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 i n the M I D P or C L D C libraries. W e were not able to find a work-around for this with the E c l i p s e M E 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 I D E 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 o f the third party J 2 M E I D E ' s currently facilitate (or encourage) component or feature based development, and have no way o f 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 ) is a collection o f Java based tools that treats features as the core building blocks o f a system. Programs in A T S are unique compositions o f algebraic operations that correspond to a feature module. W e 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 i n general Java programming and I D E functionality. 5 5  http://www.cs.utexas.edu/users/schwartz/ATS.html  52  7 Conclusions W e evaluated the use o f aspect-oriented programming, and in particular AspectJ, to alleviate problems with fragmented A P I support across micro devices when implementing a family o f 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 o f 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 objectoriented practices, design patterns and preprocessor utilities that are used by many J 2 M E application developers i n industry. A second implementation uses aspect-oriented practices, including pointcuts and advice, and the AspectJ weaver. W e compared these implementations with respect to the complexity o f the development, modularity, scalability, device support, tool support and quantitative measurements o f size and resource usage. W e found that aspect-oriented programming, as supported b y 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 A P I ' s that are only supported by specific device types and keep them i n a single module instead o f being scattered throughout the application classes. However, there is minimal support in AspectJ to manage dependency relationships between different optional features. B u i l d 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 3040 K B , which is significant for many micro device platforms. Most o f the other metrics compared such as memory utilization, number o f classes, lines o f code, duration o f 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 objectoriented techniques and a preprocessor. A s the optional features increase, the number o f embedded preprocessor statements scattered throughout your code base also increases, making it difficult to manage without some type o f 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 o f using AspectJ on a wide variety o f 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 i n the AspectJ runtime that are not supported on current J 2 M E platforms due to the absence o f reflection and minimal threading support i n the M I D P and C L D C libraries. It documents limitations o f using AspectJ on certain devices, notably current Blackberry simulators and devices by Research In M o t i o n can only execute a custom modified version o f the AspectJ runtime. It provides a sample application implemented in an aspect-oriented and objectoriented 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 o f aspects to vary the functionality available i n a particular configuration o f 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 o f implementation languages (e.g., C/C++, A s p e c t W e r k z or HyperSpaces ) and device platforms (e.g., Microsoft P o c k e t P C or Qualcomm B R E W ) to see i f similar advantages are obtained. 56  58  57  5 9  Another avenue o f future work is creating a fully functioning version o f the AspectJ runtime that is optimized for J 2 M E . This work might involve eliminating AspectJ's. dependency on the J2SE A P I ' s , and removing unsupported (or unnecessary) classes from the runtime. Having a J 2 M E optimized version o f 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 i m Hugunin, M i k Kersten, Jeffrey Palm, W i l l i a m G . Griswold. An overview of AspectJ. in European Conference on Programming.  [2]  D o n Batory, R . C . , & Yannis Smaragdakisi. Object-Oriented Product-Lines,  Object-Oriented  2001. Budapest, Hungary. Frameworks  and  i n 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]  K r z y s z t o f 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. i n 43rd ACM Southeast Conference. 2005. Kennesaw, G A , USA: A C M . [6]  Frank Hunleth, R . K . C . , Footprint and Feature Management using Aspect-  [7]  G a i l C . Murphy, A . L . , Robert J.Walker, and Martin P. Robillard. Separating  Oriented Programming  Techniques, i n LCTES'02  - SCOPES'02.  2002.  Features in Source Code: An Exploratory Study, i n 23rd International  Conference  on Software Engineering. 2001. Toronto, Canada. [8]  N e i 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]  N e i l Loughran, A . R . , Framed Aspects: Supporting Variability and for AOP, i n International  [10]  Configurability  Conference on Software Reuse. 2004: Madrid, Spain.  Roberto E . Lopez-Herrejon, D . B . , Using AspectJ to Implement Product-Lines:  A  Case Study. 2002, The University o f Texas: Austin, p. 9. [II]  Roberto E . Lopez-Herrejon, D . B . , and W i l l i a m Cook. Evaluating Support for Features in Advanced Modularization  Technologies, i n ECOOP.  2005. Glasgow,  Scotland. [12]  R o n B o d k i n , A . C , J i m Hugunin, Applying AOP for Middleware  Platform  Independence. 2003, I B M , N e w Aspects, P A R C . p. 7. [13]  Vander A l v e s , P . M . J., Paulo Borba, An Incremental Aspect-Oriented Line Method for J2ME Game Development, i n OOPSLA  Product  '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,  [15]  Arturo Zambrano, S . G . , Ignacio Jaureguiberry, Aspect-Based Adaptation  [16]  M i c h a l i s Anastasopoulos, D . M . , An Evaluation of Aspect-Oriented  Informatics Center - Federal University o f Penambuco. Ubiquitous Software, i n Mobile HCI2003.  2003: Udine, Italy.  as a Product Line Implementation Technology, i n International Software Re-Use. 2004: Madrid, Spain.  55  for  Programming  Conference on  [17]  Y u a n , M . J . , Enterprise J2ME: Developing Mobile Java Applications.  1st ed.  2004: Prentice H a l l P T R . 480. [18]  M i k Kersten, G . C . M . Atlas: A Case Study in Building a Web-Based Learning Environment using Aspect-oriented Programming, i n 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 . , D r . Thomas Strohm. Evaluating Variability Implementation Mechanisms, i n Proceedings  [21]  Engineering. 2002. Seattle, U S A . Andrei Popovici, T . G . , and Gustavo Alonso, Dynamic Weaving for AspectOriented Programming,  [22]  of International Workshop on Product Line  mAOSD 2002. 2002: Enschede, Netherlands.  Vander Alves, P . M . J . , Leonardo Cole, Paulo Borba, and Geber Ramalho, Extracting and Evolving Mobile Games Product Lines, i n 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 o f Computer Science: Fort Collins, Colorado, p. 11.  56  Appendix A: Acronyms The following list details the acronyms used in this thesis. J2ME API AOP AOSD OOP OO PDA RIM (J)VM KVM WMA CLDC CDC J2EE J2SE JAD JAR MIDP PIM RMS SMS WORA SDK IDE CTO (G)UI CVS MVC CDMA GPRS 802.11 LCD ORB ANT XML XSL(T) UML FAQ  Java 2 Platform, M i c r o Edition Application Programming Interface Aspect Oriented Programming Aspect Oriented Software Development Object Oriented Programming Object Oriented Personal Digital Assistant Research In M o t i o n (Java) Virtual Machine Kilobyte Virtual Machine Wireless Messaging A P I Connected Limited Device Configuration Connected Device Configuration Java 2 Enterprise Edition Java 2 Standard Edition Java Application Descriptor Java Archive M o b i l e Information Device Profile Personal Information Manager Record Management System Short Message Service Write Once R u n Anywhere Software Development K i t Integrated Development Environment Cheif Technology Officer (Graphical) User Interface Concurrent Version System M o d e l V i e w Controller Code D i v i s i o n Multiple Access (Wireless data transmission protocol for mobile telephone networks) General Packet Radio Service (Wireless data transmission protocol for mobile telephone networks) Family o f specifications for wireless L A N s developed by the I E E E L i q u i d Crystal Display Object Request Broker Another Neat Tool (Build Tool) extensible Markup Language extensible Stylesheet Language (Transformation) Unified M o d e l i n g Language Frequently Asked Questions  57  Appendix B: ANT Build Script Source Listing <?xml version--" 1. 0" encoding -" iso-8859-1" ?> <project name="MobilePhoto AOP V e r s i o n " d e f a u l t = " f u l l - b u i l d " basedir="."> <!-- D e f i n e a l l r e l e v a n t p r o p e r t i e s here. --> <property name="workspace.dir" l o c a t i o n = " $ { b a s e d i r } " / > <property f i l e = " l a p t o p B u i l d . p r o p e r t i e s " / > <property name="antenna.jar" location="${antenna.home}\\aritenna-bin0.9.12.jar"/> <property name="ajc.adapter" value="org.aspectj.tools.ant.taskdefs.AjcllCompilerAdapter"/> <!-- F o r B l a c k b e r r y , use t h e m o d i f i e d A s p e c t J Runtime J a r f i l e --> <property n a m e = " a s p e c t j t o o l s . j a r " location="${aspectj.lib.dir}/aspectjtools.jar"/> D e f i n e c o r e MIDP l i b r a r i e s --> <!-- MIDP 1.0 CLDC 1.0 --> .. <property name="midpapilO.jar" l o c a t i o n = " $ {wtk. home} \ l i b \ m i d p a p i l O ..jar" / > <property name="cldcapi10.j a r " locations"${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 n a m e = " c l d c a p i l l . j a r " l o c a t i o n = " $ { w t k . h o m e } \ l i b \ c l d c a p i 1 1 . j ar"/> <!--  D e f i n e T h i r d P a r t y and o p t i o n a l M I D P L i b r a r i e s --> <!-- The m o t o r o l a and siemen's z i p f i l e s a r e j u s t a r c h i v e s of the c l a s s d i r e c t o r i e s f o r t h e r e s p e c t i v e d e v i c e s . The c o n t a i n e d f i l e s can be found i n the i n s t a l l d i r e c t o r y of the r e s p e c t i v e SDK o r 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 . j a r " l o c a t i o h = " $ { w t k - b e t a . h o m e } / l i b / j s r 7 5 . j a r " / > <property n a m e = " b l a c k b e r r y L i b . j a r " location="${blackberry.jde.home}/lib/net_rim_api.jar"/> <property name="siemensLib.zip" l o c a t i o n = " $ {.Siemens . home} /SiemensJ2MElib . z i p " /> <!--  <!-- Set t h e c l a s s p a t h t o be used --> <property name="build.classpath" value="${midpapi2 0.jar};${cldcapill.jar};${wma.jar};${mmapi.jar},${j sr7 5.jar};${moto73 0 . z i p } ; $ { a s p e c t j r t . j a r } ; $ { s i e m e n s L i b . z i p } ; $ { blackberryLib.jar};${antenna.jar};"/><!-<!--  B u i l d s f o r B l a c k b e r r y s h o u l d o n l y use MIDP 1.0 and CLDC 1.0 --> <property name="build.classpath" value="${midpapilO.jar};${cldcapi10.jar};${aspectjrt.jar};${black b e r r y L i b . j a r } ; " / > -->  <!--  D i r e c t o r i e s c r e a t e d o r used d u r i n g the b u i l d p r o c e s s -->  58  <property  name="rape-compiled.dir"  location="${workspace.dir}/rapc-  compiled"/> <property  name="pre-compiled.dir"  location="${workspace.dir}/pre-  compiled" /> <property  name="midp-compiled.dir"  location="${workspace.dir}/midp-  compiled"/> <property  name="sre.dir"  <property  location="${workspace.dir}/sre"/>  name="aspect-source.dir"  location="${workspace.dir}/ubc/aspectj/photoalbum"/> <property  name="ajc-compiled.dir"  location="${workspace.dir}/aj  c-  compiled"/>. <property  name="preverified.dir"  l o c a t i o n ^ " $ {'workspace.. d i r } / p r e v e r i f i e d " / > <property  name="jar.dir"  <property  name="palm.dir"  <property  name="rim.dir"  <property  name="images.dir"  <!--  This  <taskdef  resource  is  locations"${workspace.dir}/jars"/> location="${workspace.dir}/palm"/> location="${workspace.dir}/rim"/> location="${workspace.dir}/images"/>  required  f o r Antenna  resource="antenna.properties"  based  tasks  -->  classpath="${antenna.jar}"  />  <:--  ============================================================= - - >  <!--  Full  <target  Build  (Default  Target)  -->  name="full-build">  <antcall <!--  target="clean"  midp-compile  <!--<antcall <antcall  is  />  only  necessary  target="midp-compile"  for Blackberry  builds-->  />-->  target="aspectj-compile"./>  <antcall  target="copy-ajruntime-classes"  <antcall  target="copy-image-files"  <antcall  target="midp-preverify"  <antcall  target="make-jar"  />  /> />  />  </target>  <!--  Blackberry  Build  Part  compile  exits  ANT, even  -ctarget  name="bberry-l">  1  (Needs  though  to  split  the build  <antcall  target="clean"  <antcall  target="aspectj-compile"  is  i n two b e c a u s e  the  valid)  aspectJ -->  /> />  </target>  < 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 ANT, even though t h e b u i l d i s v a l i d ) --> <i-============================================================= - - > <target  name="bberry-2">  <antcall  target="copy-ajruntime-classes"  <antcall  target="copy-image-files"  <antcall  t a r g e t = " m i d p - p r e v e r i f y " ' />  <antcall  target="make-jar"  <antcall  target="rape-compile"  />  </target>  59  />  />  />  !--  ==============================================  !--  Clean  ! —  =============================================================  target  name="clean"  .ajesym <!--  -->  a l l targets  -->  description="clean  and create  -->  classes/jar d i r ,  files">  Delete  a l l the directories  and their  contents  <delete  quiet="on"  d i r = ' $ { a j c - c o m p i l e d . d i r }"_/>  <delete  quiet="on"  dir=' ${preverified.dir}"/>  <delete  guiet="on"  <delete  quiet="on"  <delete  quiet="on"  dir=' ${midp-compiled.dir}"/> dir=' ${rape-compiled.dir}"/> dir=' ${pre-compiled.dir}"/>  <delete  -->  quiet="on">  <fileset  dir="${jar.dir}"  excludes="**/*.jad"/>  </delete> <delete  quiet="on">  <f i l e s e t  dir=" ${workspace. dir}"  i n c l u d e s = <•**/*. a j e s y m " / >  </delete> <!--  Recreate  <mkdir <mkdir  the directories  we j u s t  deleted  -->  dir="${ajc-compiled.dir}"/> d i r = " $ { p r e v e r i f i e d . d i r } "•/>  <mkdir  dir="${midp-compiled.dir}"/>  <mkdir  d i r = " $ { r a p e - c o m p i l e d , d i r } "./>  <mkdir  dir="${prc-compiled.dir}"/>  <mkdir  dir="${jar.dir}"/>  /target>  !-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = === = === = = = = = = = = = --> !--  Compile  ! - -  =============================================================  target  MIDP  classes  using  s t a n d a r d midp  (javac)  compiler  --> —>  name="midp-compile">  <!--  For Motorola  Build,  iDEN-Midlet-Phone: <wtkjad  only  update  MainUIMidletlO  j a d so  jadfile="${jar.dir}/${jad.name}"  compiled .dir}/${jar.name}" update="true" <midlet  i t  includes  property  --> jarfile="${midp-  name="${midlet.name}"  v e n d o r = " T r e v o r Young"  n a m e = "$ { m i d l e t . name}""  version="1.0.0">  class="${main.class}"/>  </wtkjad> <!--  Compile  everything,  bootclasspath <wtkbuild  to  but don't  override  srcdir="${src.dir}"  preverify="false"  preverify  MIDP  1.0/CLDC  (yet}. 1.0  Use apis-->  destdir="${midp-compiled.dir}"  bootclasspath="${build.classpath};"  >  <includesfile name="MobilePhotoCompileList.1st"/> </wtkbuild> <!--  Package  <wtkpackage  the compiled  classes  into  jadfile="${jar.dir}/${jad.name}" preverify="false" <fileset  a JARand JAD f i l e  jarfile="${midp-compiled.dir}/${jar.name}" >  d i r = " $ { w o r k s p a c e . d i r } " ••  includes="${main.class}.class"/> </wtkpackage> /target>  60  obfuscate="false"  -->  ! - - 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 ! - - = = = == = == = = = = = = = = = = = = == = = = = = = = = = = = == = = target  Compiler  Target--> -->  name="aspectj-init">  <!--  Check  <available  the required  libraries  -->  file="${aspectjtools.jar}"  property="aspectj tools.jar.available"/> <available  file="${aspectjrt.jar}"  property="aspectj r t . j ar.available"/> <!--  Sets  name  of  new t a s k  to  iajc,  o l d task  to  ajc  -->  <taskdef resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.pr operti.es" > <classpath> <pathelement  path="${aspectjtools.jar}"/>  </classpath> </taskdef> <property  name="taskdefs.init"  value="true"/>  /target>  !-!--  =============================================================  -->  C o m p i l e A s p e c t J S o u r c e s a n d weave w i t h MIDP c o m p i l e d J a r =============================================================  --> -->  target  name="aspectj-compile"  AspectJ <echo  compiler  to  depends="aspectj-init"  compile  message="Compiling with  Proceed <iajc  On E r r o r ) "  description="Uses  a n d weave"> a j c . . . ( D i s a b l e d Import  Errors,  Will  />  destdir="${ajc-compiled.dir}"  fork="true"  proceedOnError="true" noimporterror="true" 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 ar}" classpath="${build.classpath};" argfiles="${workspace.dir}/MobilePhotoCompileList.1st" inpath="${midp-compiled.dir}"  verbose="true"  />  /target> i - -  ============================================================= - - >  !-!--  Unjar t h e A s p e c t J Runtime C l a s s e s so they c a n be p r e v e r i f i e d =============================================================  target  --> -->  name="copy-ajruntime-classes">  <unzip  src="${aspectjrt.jar}"  dest="${ajc-compiled.dir}"/>  /target>  !--  =============================================================  -->  !--  Copy  -->  target  Image  Files  so  they  are bundled  with  name="copy-image-files">  <mkdir <copy  dir="${preverified.dir}/images"/> todir="${preverified.dir}/images"> <fileset  dir="${images.dir}"/>  </copy> /target>  61  the j a r f i l e  !--  Preverify  target  MIDP  classes,  Aspects  and the AspectJ  Runtime  Library-->  name="midp-preverify">  <!--  Note  we h a v e  to  the  AspectJ  runtime  required  include  classes  <wtkpreverify  some  classes  classes to  are i n the a  from  preverify. temp  J2SE  i n order  F o r now,  directory  for  the  -->  srcdir="${ajc-compiled.dir}"  destdir="${preverified.dir}" classpath=" ${build. classpath}  ,• $ { j 2 s e . p a r t i a l . z i p } ; " / >  /target>  : —  ======= ===== === ====== =============  !--  Generate  final  JARf i l e  f o r MIDP  — >  devices  and update  JAD-->  !-- ============================================================= --> target  name="make-jar">  <!--  Package  <wtkpackage  the  compiled classes  into  a JARand JADf i l e  -->  jarfile="${jar.dir}/${jar.name}"  jadfile="${jar.dir}/${jad.name}" basedir="${preverified.dir}" preverify="false"  obfuscate="false"  >  </wtkpackage> /target>  j--  =============================================================  -->  !--  Compile/convert J a r f i l e  -->  ! —  =============================================================  target  for BlackBerry  using  rape.exe  —>  name="rape-compile">  <exec executable="&quot;${blackberry.j de.home}/bin/rape.exe&quot;"  > <arg 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 ar;&quot;  codename=${midlet.name}  -midlet  & q u o t ; $ {j a r . d i r } . / $ {j a r . name} & q u o t ; &quot;${jar.dir}/${jad.name}&quot;"/> </exec> <copy  todir="${rapc-compiled.dir}"> <fileset  dir="${workspace.dir}">  <include  name="*.debug"/>  <include  name="*.cod"/>  <include  name="*.cso"/>  </fileset> </copy> <delete  quiet="on">  <fileset  dir="${workspace.dir}"  <fileset  dir="${workspace.dir}"  includes="*.cso"/>  <fileset  dir="${workspace.dir}"  includes="*.cod"/>  </delete> /target>  62  includes="*.debug"/>  < !--  = = = = = = = = = = = = = = = = = = = = == = = ==== = = = = = = = = = = = = =  <!--  Convert J a r f i l e  < I - -  = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =  f o r Palm OS u s i n g Sun MIDP c o n v e r t e r  -->  --> - - >  <target name="make-prc"> <exec executable^"${palm.midp.home}/converter.bat"> <arg l i n e = " - X d e s c r i p t o r : $ { j a r . d i r } / $ { j a d . n a m e } " / > </exec> </target> <!--  =============================================================  <!--  Run t h e M i d l e t  i n t h e s t a n d a r d Phone Emulator  -->  -->  <!--  =============================================================  -->  <target name="run-default-phone-emulator"> <wtkrun j a d f i l e = " j a r s / $ { j ad.name}" d e v i c e = " D e f a u l t C o l o r P h o n e " wait="true"/> </target>  <!--  Run t h e M i d l e t  < I - -  = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =  i n t h e M o t o r o l a Phone Emulator  --> - - >  <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 t h e M i d l e t i n t h e M o t o r o l a Phone Emulator --> <!-- ============================================================= --> <target name="run-motorola-i860-phorie-emulator"> <exec executable="&quot;${motorola.home}/bin/emulator&quot;"> <arg l i n e = " - X v e r b o s e : m o n i t o r s - X d e v i c e : i 8 6 0 Xdescriptor:&quot;${jar.dir}/${jad.name}&quot;"/> </exec> </target>  <!--  Run t h e M i d l e t  <!—  =============================================================  i n t h e M o t o r o l a Phone Emulator  --> -->  <target name="run-motorola-i605-phone-emulator"> <exec executable="&.quot;${motorola.home}/bin/emulator&quot;"> <arg l i n e = " - X v e r b o s e : m o n i t o r s - X d e v i c e : i 6 0 5 X d e s c r i p t o r : &quot; $ { j a r . d i r } /$ {j ad. name} &quot.; " / > </exec> </target>  <!-- Run t h e M i d l e t i n t h e Siemens Phone Emulator --> <!-- ============================================================= --> <target name="run-siemens-phone-emulator"> <exec executable= "&quot;${Siemens.home}/emulators/CX65/bin/emulator&quot;"> <arg l i n e = "Xdescriptor:&quot;${jar.dir}/${jad.name}&quot;"/> </exec>  63  /target>  !--  Run the  target  Midlet  in  the  WTK 2 . 2  Beta  Phone  Emulator  name="run-beta-default-phone-emulator">  <exec  executable="${wtk-beta.home}/bin/emulator"> <arg  line=  "-  X d e s c r i p t o r :&quot; $ { j a r . d i r } /${jad.name}&quot,- "/ > </exec> /target> !--  Info  target  Target:  Echo  name="info"  usage  and information a b o u t . t h i s  >  <echo> Insert  any relevant  help  information  </echo> /target> /project>  64  here...  build  script-  Appendix C: SmsAspect Source Code Listing p u b l i c aspect  SmsAspect  { = new C o m m a n d ( " S e n d  Command  smsSendCommand  Command  smsReceiveCommand  Command.ITEM, Command  Command.ITEM,  = new C o m m a n d ( " A c c e p t  Photo",  = new C o m m a n d ( " R e j e c t  Photo",  1);  rejectPhotoCommand  Command.ITEM, NetworkScreen  1)  1) ;  acceptPhotoCommand  Command  SMS", Command.ITEM,  = new C o m m a n d ( " R e c e i v e S M S " ,  1); = new  networkScreen  NetworkScreen("Reciever  Details"); String  selectedlmageName  BaseController byte[]  =  "null";  controller;  incominglmageData;  //Define  pointcut  pointcuts initMenultems(List  1) : a r g s ( 1 )  && e x e c u t i o n ( *  PhotoListScreen.initMenu(List)) ;  pointcut  handleCommandAction(BaseController  Displayable  d)  : args(sc,  c,  d)  &&  sc,  Command  c,  execution(*  BaseController.postCommand(BaseController,  Command,  Displayable));  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 ) && execution(* 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 [ ] ) ) ;  //Define  advice  after(List  :  1)  initMenultems(1)  1.addCommand(smsSendCommand)  { ;  1.addCommand(smsReceiveCommand); }  after(byte[] if  imageData)  :  imageReceived(imageData)  (imageData==null) System.out.println("imageData  if  was  NULL!");  (controller==null) System.out.println("controller  Alert  alert  =•new A l e r t ( " N e w  alert.setString("A Do  y o u want  Incoming  MobilePhoto to accept  was  user  NULL!");.  Photo");  has sent  it?");  alert.addCommand(acceptPhotoCommand); alert.addCommand(rejectPhotoCommand); alert.setCommandListener(controller); controller.setCurrentScreen(alert); .  {  incominglmageData  =  imageData;  } after(BaseController  sc,  Command  65  c,  Displayable  d)  you a  Photo.  handleCommandAction(sc, c, d) //Set  the  aspect's  controller  { variable  to  the  midlet  one  c o n t r o l l e r = sc; String label = c.getLabel(); if  ( l a b e l . e q u a l s ( " S e n d SMS")) { selectedlmageName = sc.getSelectedlmageName(); networkScreen.setCommandListener(controller); . controller.setCurrentScreen(networkScreen); } e l s e i f ( l a b e l . e q u a l s ( " S e n d Now")) { //Get  the  data  from  the  currently  selected  image  ImageAccessor a c c e s s o r = new ImageAccessor(sc.getModel()); ImageData i i = accessor.getlmagelnfo(selectedlmageName); b y t e [ ] imageBytes = accessor.loadlmageBytesFromRMS(ii.getParentAlbu mName(), i i . g e t l m a g e L a b e l ( ) , ii.getForeignRecordld()); //Get  the  destination  info  S t r i n g smsPort = "1000"; S t r i n g d e s t i n a t i o n A d d r e s s ='"5550001"; S t r i n g messageText = "Command goes here"; smsPort = networkScreen.getRecPort(); d e s t i n a t i o n A d d r e s s = networkScreen.getRecPhoneNum(); SmsSenderThread smsS = new SmsSenderThread(smsPort,destinationAddress,messa geText); smsS.setBinaryData(imageBytes); new T h r e a d ( s m s S ) . s t a r t ( ) ; } else i f  ( l a b e l . e q u a l s ( " R e c e i v e SMS")) {  //start  receiver  thread  SmsReceiverThread smsR = new SmsReceiverThread(sc); System.out.println("SMSAspect::Starting SMSReceiver Thread"); new T h r e a d ( s m s R ) . s t a r t ( ) ; }" e l s e i f  ( l a b e l . e q u a l s ( " C a n c e l Send")) {  / /TODO:  If  they  message,  want send  to  cancel  them  back  System.out.println("Cancel } else i f  'sending to  main  t h e - SMS screen  sending of SMS message");  ( l a b e l . e q u a l s ( " A c c e p t Photo")) {  Image image = Image.createlmage(incominglmageData, 0, incominglmageData.length); PhotoViewScreen canv = new PhotoViewScreen(image); controller.setCurrentScreen(canv);  66  } else i f  (label.equals("Reject  //TODO:  Go back  were  to  Photo"))  whatever  previously  67  they  on  System.out.println("Reject  }  screen  {  Photo  command")  


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



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"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items