Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Use AOP to Help Get Mobile Content to Market Faster

Developers fight an uphill battle to make their applications work efficiently on a litany of mobile devices. But those who employ the power of aspects will have a powerful instrument for solving porting problems without repetitious code.




Application Security Testing: An Integral Part of DevOps

obile devices are becoming the most prevalent computing platform ever. With close to 2 billion mobile handsets in use everyday, mobile is not a platform that any developer can ignore. However, when developing mobile applications developers are finding it challenging to take full advantage of the true revenue potential of this rapidly growing market.

The process of mobile content deployment—which includes the development, adaptation, optimization, localization, testing/certification, channel packaging, and channel stocking of content for mobile devices—is very different than in the enterprise and desktop worlds. Mobile phones are personalized devices, which leads to significant variation between devices, with handset manufacturers offering different screen sizes, performance, memory, sound systems, form factors, keypad layouts etc. The result is fragmentation of the runtime environment. This is further complicated by operator specific APIs (e.g. Sprint's Game Lobby), network-related issues (e.g. certain ports are blocked on some mobile networks), and other operator-specific requirements or channel packaging.

With more than 1,000 handset models already on the market and at least 20 new devices being introduced every month, the challenge is becoming increasingly complex. Further complicating the mobile deployment process are the unique content submission requirements of more than 700 mobile operators. All of which make it impossible to deploy the same mobile application on all devices, across all channels.

Fortunately, we do have technologies that can help ease the burden. In getting mobile content from the development stage to the end user, aspect-oriented programming (AOP) provides developers with a way to expedite and reduce the complexity of the entire process. Whether the target platform is MIDP, BREW, Windows Mobile, DoJa (DoCoMo Java), or WIPI (Wireless Internet Platform for Interoperability), AOP can enable you to modularize and reuse code snippets for device-/operator- specific issues or other optimizations without reverting to the lowest common denominator approach. AOP also provides scalability to efficiently add more people to the project to increase the throughput linearly.

AOP Background and Terms
Before examining AOP in the context of mobile content deployment, I'll first review the fundamentals of AOP.

OOP is often not sufficient in modularizing code. While most classes in OOP perform a single, specific function, they often share common requirements with other classes. These requirements are known as cross-cutting concerns.

AOP enables developers to dynamically modify static OO models to meet new requirements; it facilitates modularization of cross-cutting concerns. This cross-cutting code module can be kept in a single location and needn't be scattered across the existing model to the areas where it's needed.

Logging is an excellent example of a cross-cutting concern. Every developer has used debug logs at some point in time, and logging most likely affects every single logged part of the software. As a result, logging code cross-cuts all logged classes, methods, and/or procedures.

Assume that you are developing a MIDP application that occasionally crashes when getting system events in your Canvas class (such as key presses) so you decide to add some logging code in all system event callbacks as follows:

void paint(Graphics g) { logging("entering paint"); // your paint code logging("leaving paint"); } void keyPressed(int keyCode) { logging("entering keyPressed"); // your key processing code logging("leaving keyPressed"); } void keyReleased(int keyCode) { logging("entering keyReleased"); // your key processing code logging("leaving keyReleased"); } void keyRepeated(int keyCode) { logging("entering keyRepeated"); // your key processing code logging("leaving keyRepeated"); } void hideNotify() { logging("entering hideNotify"); // your hideNotify code logging("leaving hideNotify"); } void showNotify() { logging("entering showNotify"); // your showNotify code logging("leaving showNotify"); }

Clearly, this can become a very tedious task. Every time you want to trace more method calls, you'd have to add the same logging code twice. By the time you had finished debugging, your code would be littered with logging methods that have to be removed manually. Performing a logging task (or any kind of cross-cutting task) in this manner decreases the program modularity and tangles the code. This is what OOP was not designed to address.

What you really want is a way to specify "add a logging method call to the beginning and the end of these six methods" in a separate module, which translates into the following pseudo code:

loggingAspect { loggableCalls = paint, keyPressed, keyReleases, keyRepeated, showNotify, hideNotify; insertBefore: loggableCalls { logging("entering " + $methodName); } insertAfter: loggableCalls { logging("leaving " + $methodName); } }

As you can see, the logging code is now totally encapsulated in a reusable module with the core modules untouched. It makes the resulting code much cleaner.

The previous example only involves modifying one source file. If the logging code must span multiple files, using traditional methods will be even less desirable. Without AOP the logging code might need to be added to multiple locations of multiple source files (see Figure 1). Using AOP, the logging code can be modularized and "woven in" to the executable using a weaver (see Figure 2).

Figure 1. Without Aspects: Handling a cross-cutting concern such as logging, without aspects, requires multiple versions of the source.
Clearly, using AOP means the traceability, reuse, and maintenance of the entire source code can be greatly improved. Before moving on, I'd like to introduce three AOP vocabulary words that will come in handy: pointcut, advice, and aspect.

A pointcut is the point (or points) of execution in the application at which cross-cutting concern needs to be applied. In the above example:

loggableCalls = paint, keyPressed;

Pointcuts can be a combination of method execution, instantiation of an object, initialization of a field, catching of an exception, or any other well-defined points along the execution of a program.

Advice is the code that you want to apply to your existing model. In the above example:

insertBefore: loggableCalls { logging("entering " + $methodName); } insertAfter: loggableCalls { logging("leaving " + $methodName); }

The combination of pointcuts and advices form an aspect.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



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