Software giants, like Google, are disrupting the otherwise safe and established players in the mobile application development business. Newcomers like Android have led to significant structural changes in the future of mobile application development by imposing their rules. This changed environment not only brings additional opportunities but also adds certain constraints. Developers today, need to assess their options and find out how they can benefit from this changed environment.
While mobile computing has caught the attention of application developers, there has been very little work done to examine the programming ease of these technologies. Here we will take a look at two of the most widely available mobile development environments – Android and Windows Mobile and explore and assess these options from a developer’s perspective.
Android was released by Google in 2007, as an open source platform for mobile software development for smartphones. The Android platform was released as part of the Open Handset Alliance. The primary aim of this alliance was to set up open standards for smartphones. Android is basically a Linux-based, open source operating system for mobiles. As a mobile operating system, it allows developers to create managed codes in Java, by using Java libraries developed by Google. Not only does Android provide a mobile operating system including a development environment, it also offers a custom virtual machine known as the Dalvik Virtual Machine for running applications as well as acts as the middleware in between the operating system and the code. When it comes to application development, Android facilitates the usage of 2D as well as 3D graphic libraries, advanced network capabilities such as 3G, Edge and WLAN and a customized SQL engine for continual storage.
READ MORE :
- Fashion Yesterday and Today
- Support Your Sport and Add Detail to Your Get Up
- 5-Step Guideline for Boosting Your Mobile Marketing
- Mobile Application Development
- Mobile Marketing Techniques and Strategies for Business
Developed by Microsoft, the Window Mobile is an operating system for mobile devices. Based on the Microsoft Windows CE 5.0, Windows Mobile is used as an operating system on many smartphones, PDAs, and touch screen devices. Windows Mobile facilitates the creation of custom written applications in managed as well as native codes. The Application Programming Interface (API) in Windows Mobile is extensible and has rich features along with a programmable layer. Besides that Windows Mobile also takes advantage of the capabilities provided by Microsoft.Net environment.
We will compare these platforms and closely examine their strengths and weaknesses. The platforms will be compared on the basis of implementation and performance aspects as well as developer support. We have chosen these criteria for the comparison as they represent the most important aspects when it comes to mobile software developers.
We will use persistent storage as the basis for comparing the implementation aspect. The technology used for persistent storage in mobile technology varies between various mobile development environments. Both Windows Mobile and Android have the ability to use an on-device database which facilitates easier manipulation as well as extraction of data. Also, as far as local file storage is concerned both environments support memory cards for additional storage space. However, the difference lies in the way the storage space is exploited. While Android cannot install applications on memory cards, Windows Mobile allows it. Both Android and Windows Mobile platforms have a relational database. Also, in both the platforms the libraries have quite a few useful persistence features. Once the libraries have been initialized, access to the database is available via an object-oriented interface which can be easily accessed by developers.
Performance figures are important for both users as well as developers. The performance comparison of the two platforms will be carried out based on the file size. The basic purpose of measuring file size is to get a better idea of the configuration as well as the runtime dependencies that are included in packaged applications.
Android applications come packaged in app (Android Package) files. The .APK file generally has a group of.DEX (Android program files) files, which operate like a single application file for use within the Android platform. The .APK file is basically the compressed version of the contents in the ‘Androidmanifest.xml’ file.
Windows Mobile applications make use of cab-files for application packaging and deployment. The first step while making a distributable file, involves packaging the application in a CAB (Cabinet) file. This CAB file can be deployed to other devices where it can be expanded and installed. A CAB file is basically an executable archive which contains the application, resources, dependencies like DLLs and other resource files.
A comparative study ofenvironments was conducted by Tom Morten Gronli, Jarle Hansen, and Gheorghita Ghinea, of Brunel University, London. In this comparative study, a demo example application was created for both the Windows Mobile and Android development platforms to better illustrate the deployment file size for each application. The demo example application was a simple program which printed a line of text on the screen. The result from the code example was as follows:
- The deployment size of the demo application in the Windows Mobile environment was 2.8 KB.
- The deployment size of the demo application in the Android environment was 9.3 KB.
The file sizes as denoted were without any obfuscator or shrinker software. This is the type of file that an end user would either download or get shipped and then installed on his/her device. As can be seen from above, the demo application in Windows Mobile had a file size of 2.8 KB while Android was approximately three times the size at 9.3 KB. This serves as an indication of the total amount of configuration files and runtime dependencies which must be bundled along with each of the client applications. When it comes to the number of lines of code, Windows Mobile required only 11 lines whereas Android needed 28.
Developer Support Comparison
Developer support is a highly important aspect when it comes to gaining speed as well as quality during the development process. While both mobile development platforms do have similarities, there are some unique differences in developer support. The differences become clearer when we take the integrated developer environment (IDE) and the tooling into consideration.
The only choice for development in Windows Mobile is Visual Studio, which is again developed by Microsoft. With Visual Studio, Windows Mobile needs Microsoft backing before it can implement and ship new features in the IDE. The community can only make suggestions but doesn’t have any direct influence. However, there is a positive side as consistency is assured. Also, the quality approval process implemented by Microsoft while shipping new products will assure quality.
On the other hand, there are several tooling options for Android, with quite a few IDEs. Android has open source communities who contribute to IDE development by providing as well as assuring the quality of plugin functionalities for software. However, the multiple IDE environments can be quite a challenge for maintaining consistency and quality assurance. Consistency becomes a challenge as extension features may be available for only some of the competing IDEs. Quality assurance becomes a major challenge as development carried out by the community is not governed by a common standard for quality required prior to making the new integrated development environment feature available. Quality assurance of the delivered code is essential for delivering fully functional products. These two factors can potentially make code and application portability between environments impossible.
One of the differences between the Android and the Windows Mobileas far as and quality assurance is concerned becomes more apparent in the testing environment. Let us take a closer look at this during unit testing of both development platforms.
Unit testing is basically a quality assurance and validation tool for testing small parts of a computer or mobile applications. The aim is to have each section isolated and tested separately. This will help to isolate and assure the quality of the different units of the application.
Unit testing for Android is considerably straightforward as the API uses the JUnit test framework. The JUnit framework enforces hierarchical organization of the various test units which is a major advantage. Besides that, the JUnit pattern ensures independence of the test units as well as minimizes interference. This is done by first creating and then destroying the recently created test environment, before and after each test method is run. Android even takes JUnit a step further by allowing on device testing of the code. Here the test libraries are incorporated as part of the Android’s standard libraries.
However, there’s one challenge with Android’s on device testing as compared to Windows Mobile is the results’ readability. Android’s on device tests don’t have a user interface which can display the test’s results. In order to view results of the test, a handler which deals with callbacks from Android’s test runner has to be implemented.
Windows Mobile, on the other hand, exhibits a high degree of readability and visibility, while the Android platform is a bit hard to use when it comes to efficiency. The difficulty with Android is the lack of feedback, which is issued automatically through visual tools in the integrated development environment in Windows Mobile.
Windows Mobile implements a version of the xUnit framework. The code for test classes is kept in a separate project, though it still stays inside one solution in the IDE. Like Android, Windows Mobile’s xUnit testing also allows on-device testing. The biggest difference here, as mentioned earlier, is its test feedback. Windows Mobile has a more comprehensive user interface which offers feedback based on each test run. This makes it easier for developers to better understand which test succeeded and why a particular test failed.