Mono for Android Components(Part 3)

Development Tools

No matter what type of project you are building, development tools are an integral part of creating

an application. Long gone are the days of a bunch of files, a character-based editor, command-line

output for debugging, and a make file as the only way to build an application.

Developers who work in the .NET Framework are familiar with Visual Studio. Visual Studio is

Microsoft’s development tool. It includes support for solutions, projects, a visual design surface,

databases, and numerous other features.

Similarly, Mono has its own development tool; MonoDevelop is a free IDE used for developing

with Mono and is an early branch of the SharpDevelop IDE. Originally, MonoDevelop ran only on

Linux, but with version 2.2, MonoDevelop began running on the Mac and Windows. MonoDevelop

lets you create and manage numerous projects as well as debug and deploy to the simulator and

devices for testing.

Thankfully, the Mono team has produced Mono for Android, which will work across Visual Studio

and MonoDevelop, as well as a plug-in for operating systems other than Windows. This facilitates writing

code with Mono for Android across Visual Studio, MonoDevelop on the Mac, and MonoDevelop

on Windows. Developers are free to use whichever of these development IDEs they prefer. At this point

in time, I have personally found that Windows and the Mac each have their own advantages, including:

 Debugging on Windows is where most developers starting with Mono for Android will probably

start.

 Debugging on the Mac seems to work very well in the Android emulator.

MOBILE DEVELOPMENT

Developers need to keep a few key ideas in mind when building applications on Android with Mono

for Android:

 The Android simulator is good for initial testing; however, it is not necessarily accurate for

all testing. Just because something works in the simulator doesn’t mean it will run on all

Android devices in the same way. Final testing should be completed on different versions of

Android devices.

As of the Android SDK available for the writing of this book, testing on a device

is typically more accurate for advanced features. For basic development, the

emulator is easier to work with. Thanks to snapshots, it’s typically quicker to

work with as well.

 .NET executables are fairly small because they can use a shared copy of the framework.

Mono for Android can have applications deployed two different ways. The most common

way is to have the application and Mono for Android bound together. A second way

is for the applications to share the Mono framework. This makes application executables

small, but it also means that a copy of the Mono framework for Mono for Android must be

installed on the device.

At the time of this writing, it is suggested that the application be bound with the

Mono for Android runtime. This is currently what is done when a “Release”

the build of the application is done.

‰ It is important to be a good citizen on a device. Developers will need to continually think

about how to implement features that are good citizens.

Getting Around Support Issues

Although Mono for Android is a commercially licensed product, it is still under continual development,

so it might not support a specific c namespace or assembly. You have two options in this

situation:

1. Wait for the implementation of that assembly from the Mono for Android product.

2. Pull the necessary code or reference the necessary assembly in your project. This is fairly

common if the application needs to use code within the System.Web.* namespaces. For

example, imagine an application that needs to call an REST-based web service and needs to

encode data before it is sent. System.Web.HttpUtility.HtmlEncode() should be called.

Unfortunately, the System.Web namespace is not part of Mono for Android by default.

You must add this namespace by referencing the System.Web assembly in

your application.

Design Issues

In addition to the technical issues of building an application for Android, here are some design

issues developers should be aware of:

Don’t design an application for a desktop environment and think that it can be scaled down

to Android or any mobile device. Android does not have the display, hardware, or storage of a

desktop computer. Android and mobile device applications are good for simple, limited-purpose

functions, but they should not be expected to do everything that a desktop application does.

‰ The Android simulator is a fine tool, but don’t limit your testing to it. A simulator is just

that. A keyboard and mouse are associated with the Android simulator since it is primarily

running on the desktop. Also, understand that the simulator is ultimately using the CPUs of

the development system. While the CPU of a device is fine for the device, it really isn’t comparable

in terms of performance with a desktop. The desktop has a high click speed, more

memory, and typically has higher speed and higher quality Internet bandwidth. To really test

a complicated design, you must test the application from Android on a mobile device while

running on a mobile network.

When testing on a device, though WiFi is a mobile network, the WiFi in your office he or

home is typical of a higher quality than a mobile provider’s network. Typically, WiFi

will have lower latency and higher bandwidth than a 3G (or worse) connection. Applications

must be tested in a mobile scenario. Get a coworker to drive you around to test

an application.

ANDROID

There’s no doubt that Android devices took off in the first half of 2010. Although the Android phone

was not the first graphical phone, it was the first product that provided its software free to phone device

manufacturers made it easy to use and provided an easy-to-use marketplace to purchase applications.

History of Android

In July 2005 Google purchased a small company called Android, Inc., which was involved in mobile

software. With this purchase, Google began heading in the direction of mobile devices. Rumors

regarding Google’s entry into mobile devices began to ramp up in December 2006. In the fall of

2007, the Open Handset Alliance (OHA) was formed, with the goal of creating a set of standards

for mobile devices. The alliance has at its core a mobile device architecture based on the Linux

Kernel version 2.6 (and later), along with an SDK that can be used to build native Android applications.

In the fall of 2008, the first Android phone shipped.

The initial shipment of Android was not well received in the marketplace. It was criticized significantly

by the media and by the first users of the platform. However, Android had several big advantages over competing platforms that were not evident at the time. Android is an open platform. As such, manufacturers are competing against other mobile device manufacturers as well as against other members of the Open Handset Alliance. This means the pace of innovation at the hardware level is significant,and the Android platform shows it compared to other platforms. Android devices are not limited to one manufacturer or one telecommunications carrier either.As such, telecommunications carriers must compete with each other.

 These two factors and others have led to a significant amount of

innovation and advancement in the Android and mobile device marketplaces.

After some initial teething pains, the Android SDK has grown up. (You can find a discussion of the

tools available in the Android SDK — and pertinent to Mono for Android developers — later in this

chapter.) After numerous beta releases in 2007 and 2008, the 1.0 release of the SDK occurred in

September 2008. Since that time, many additional SDK versions have shipped.

In the fall of 2009, OHA introduced the Android 2.0 (Eclair) operating system. This was a

watershed event for Android. Along with the shipment of Android 2.0, Motorola released the Droid

phone, and Verizon began significantly marketing the product. From that point, Android has quickly

grown in the marketplace.

In 2010, OHA shipped Android 2.1. In addition, HTC, Motorola, and others produced a family of

high-end devices. The shipment of these items further accelerated Android’s growth and mindshare.

At the same time, a number of manufacturers introduced tablet devices based on Android.

In early 2011, devices based on Android 3.0 (a.k.a. Honeycomb) shipped. This version of Android

is optimized for the tablet environment. Unfortunately, this version of Android has not been well

received in the marketplace.

In late 2011, Google announced and shipped Android 4.0 (a.k.a. Ice Cream Sandwich). Ice Cream

Sandwich is the version of Android that unifieses the programming APIs for Android phones and tablets.

Growth has been a hallmark of the Android platform. Since its first availability in 2008, Android

shipments have grown significantly. Gartner Group is predicting that Android will see tremendous

growth at least through 2015. Considering that Android had so few devices in the marketplace in

2008, this growth is mind-boggling.

Reference: