2011 has been witnessing the Mobile Device Management (MDM) approach. The MDM approach allows organizations to take complete advantage of the device given to the employee by the organization. The MDM is more policy oriented i.e. it depends on the policy of the organization in handling its mobile devices. It is about configuring the mobile devices and making sure that the IT policies that have been set up remain intact, as well as monitoring the overall status and health of the device.

It is the Mobile Application Management (MAM) approach that will be witnessed in 2012 with the Bring Your Own Device (BYOD) program heating up the mobile space. The MAM approach is about managing applications on any mobile device. It is about managing the strategy and process around developing/procuring, securing, deploying, accessing configuring, updating and removing business/enterprise applications from mobile devices used by the employees. IT departments have a lot to keep in mind: identify employee-owned devices on the network; selecting recommended platforms for users; provisioning devices for secure access and centralized monitoring (whether company or employee-owned); dealing with lost or stolen devices; easily wiping corporate data from employee devices; coordinating volume purchases from public app stores and publishing in-house apps.

So, if you are into the BYOD program, then MAM is for you!

In-app processing: Ensure that most of the content processing happens within the application or before sending it to the server. Optimize/compress content as much as possible to save bandwidth cost. This will help in reducing the bandwidth cost and the time to communicate with the internet.

Server-side processing: In case the content has to be processed in the server only (without happening in the application), optimize the number of times the application has to communicate with the server. This can be done if multiple data requests can be combined into a single request with multiple sub-requests. If the same can be done for returned data, then the time saving is going to be double.

Data Exchange Methods: For server/app data exchange, JSON and SOAP are suggested technologies. These technologies are effective when it can be formatted in the device and when a live data feed is required. Delimited text can also be used for returning results from a server to an app. Splitting delimited text can be quicker and easier than parsing JSON or SOAP if the data is simple.

Content Caching: Caching content on servers has been standard practice for reducing bandwidth for a long time. Apply caching techniques to app development for better performance and efficiency. This will reduce pinging servers constantly unless a live data feed is required.

Media Optimization: If media is an absolute essential in the application, then encode it to the best possible settings based on the actual content. If your content is static and manageable in size, consider including it within the app rather than via an in-app download or streaming.

Mobile application design and development is a tricky balancing act. High levels of application performance and usability must be achieved while working with many device-related constraints. The following are some of the important application architecture and design considerations:

• Development Methodology:

Use an iterative development methodology that includes rapid iterations of design, prototyping, development and continuous testing

Architecture & UI Design: Design a layered architecture appropriate for mobile devices that improves reuse and maintainability. Depending on the application type, multiple layers may be located on the device itself. Use the concept of layers to maximize separation of concerns, and to improve reuse and maintainability for the mobile application. Mobile devices require a simpler architecture, UI, and other specific design decisions in order to work within the constraints imposed by the device hardware. Keep these constraints in mind and design specifically for the device instead of trying to reuse the architecture or UI from a desktop or Web application.

• Target Devices:

Consider the types of devices that will be supported and its constraints. Design decisions are highly influenced by target device’s screen size, resolution, orientations, memory, CPU performance characteristics, Operating Systems capabilities & limitations etc.

• Memory:

Store data on the device selectively and archive less frequently accessed data on the server. When working with the native part of the app, consider macro elements and static processing. The idea is to minimize the memory use, in terms of space and allocation frequency. Consuming all the memory is one issue, consuming less memory but continuously creating objects and destroying them is also bad.

• Processing:

Manage content intelligently; reduce size and reformat if required (e.g. resize and crop large bitmaps). Design applications such that majority of the processes run from the server. Maximize the use of “Push” strategy for updates that are behind the scenes, delivering data before the user needs it.

• Security:

Ensure that the device – server communication is secured and server accepts request only from authentic source (device). Encryption of the data that is stored and that is sent over the network ensures secure processing. Having data backed up in the server, in case the device is stolen, lost or destroyed is also advised

Designing applications for Tablets involves special considerations, though there are similarities to a phone application design. Some of the best practices in designing apps for Android based tablets are:-

· User Interface Design: Tablet screens have lot more screen space available allowing user interface to show more information, while maintaining the visual appeal and simplicity of the handheld device. The Honeycomb Action Bar for Android based tablet applications is a Multi-Purpose bar which provides features that include navigation, overflow menu options and the major advantage of providing consistency in versions between phone and tablet applications.

· The Manifest file Modifications: The Android Manifest file contains all the essential information of the application for the code to run in the Android System. This manifest file should be updated to explicitly list features the application would support and those supported by the tablet.

· SQLite Databases: SQLite is a lightweight transactional database engine that occupies small amount of disk storage and memory, so its a perfect choice for creating databases on many mobile operating systems.  Android provides full support for SQLite databases. Any database created will be accessible by name to any class in the application, but not outside the app. Data type integrity is not maintained in SQLite i.e. a value of a certain data type can be fed in a column of another data type (put string in an integer and vice versa). Referential integrity is not maintained in SQLite, there is no FOREIGN KEY constraints or JOIN statements. SQLite Full Unicode support is optional and not installed by default.

· Controlled Application Package Size: The end product is delivered in the form of a package file. This file is termed as Android Package File (APK), which when installed in the tablet will initiate the application. The permitted package size in the Android market for the final Android Application Package (APK) file is 50 MB. When applications exceed this permitted limit, issues arise. A preferred solution for this is to provide a minimal set of resources to launch the application and then download the rest of the image graphics specific to the device from an application server. This method allows images to be updated and add new target devices without updating the application, faster initial download and installation on all devices.