Tuesday, September 21, 2010

Windows Mobile to Android

Android droid This is the first in a series of articles aimed at Windows Mobile developers who want to learn how to port existing applications or create new applications for Android platforms. I’m studying it for my personal interests in my free time: I thought that it would have been interesting to share with you all the things and problems I faced (and will face) while learning it, from the point of view of a Windows Mobile developer. So I decided to plan this series, that will develop as brief tutorials with a focus on the essential things you need to know to develop Android applications.

Let’s start with an introduction to the Android platform, to its features and to all the required stuff to begin.

 

 

 

Hardware and Software Requirements


Hardware

For all practical purposes, your choices come down to using a PC (Windows/Linux) or a Mac, with at least 3GB of disk space and 2GB of RAM. Optionally, an Android phone can be useful for testing/debugging purposes (but everything can be done using the software Android emulator only).

 

Software

Android Market

To publish your mobile applications through the Android Market, you have only to register and pay a very little one-time fee, which you can do at http://www.android.com/market/. Differently from Microsoft and Apple application stores, there is no review process and distributing apps through the Market is non-exclusive; you may choose to distribute your applications through other channels as well. In addition, Android Market offers a licensing service that lets you enforce licensing policies for the applications that you publish through Android Market: with the licensing service, your applications can query Android Market at run time to obtain their licensing status for the current user, then allow or disallow further use as appropriate.

 

Key Points

 

Native, .NET and Java

Windows Mobile application can be written in C/C++ or, using .NET Compact Framework, in VB.NET/C#. To write application for Android platform, in addition to learning its frameworks and becoming comfortable with Eclipse, you will have to learn Java. If you are a C# programmer, a part from little syntax differences and constructs, you’re already able to read and write programs in Java proficiently; if you know C/C++ or other languages, learning Java should be easy. For those who don’t know Java:

  • it’s an object-orientated programming language (except the primitive data types, all elements in Java are objects);
  • it’s strongly-typed (types of the elements must be pre-defined and conversion to other objects is relatively restricted);
  • it’s has automatic memory management: Java manages the memory allocation and de-allocation for creating new objects. The program does not have direct access to the memory. The garbage collector deletes automatically object to which no active pointer exists. But this doesn’t mean that the developer shouldn’t be aware of limited resources and memory leaks;
  • it’s platform independent: Java program do in general not access directly system resources but use a Java virtual machine as abstraction;
  • it’s an interpreted and compiled language: Java source code is transferred into byte-code which does not depend on the target platform. This byte-code will be interpreted (and/or compiled using JIT techniques) by the Java Virtual machine (JVM). Specifically, Android platform uses a custom Google implementation of the JVM: the Dalvik VM.

It is also possible (starting from Android 1.5) to develop native C/C++ application through the Android Native Development Kit (NDK).

 

Optimized memory, process management and services

Like Java and .NET, Android uses its own run-time engine and virtual machine (Dalvik VM) to manage application memory. But differently from the others, the Android run-time also manages the process lifetimes: it ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications.

In addition Android supports applications and services designed to run invisibly in the background: background services make it possible to create invisible application components that perform automatic processing without direct user action. Background execution allows your applications to become event-driven and to support regular updates, or prioritizing and filtering incoming calls and messages.

 

Programming Environment

Coding in the Java language within Eclipse is very intuitive; Eclipse provides a rich Java environment (almost equivalent to Visual Studio), including advanced debugging features (in the emulator or directly on a physical device), context-sensitive help, auto-completion (similar to Visual Studio IntelliSense feature), code suggestion hints and more. Once your Java code is compiled cleanly, the Android Developer Tools make sure the application is packaged properly, including the AndroidManifest.xml file.

It's possible to develop Android applications without Eclipse and the Android Developer Tools plug-in, but you would need to know your way around the Android SDK and its command-line tools.

 

Graphical User Interfaces (GUI)

The user interface for an Android app can be created using two techniques:

  • programmatic: using Java code to create the user interface widgets (similarly to the way Windows Mobile application user interfaces are built)
  • declarative: creating XML files that configures the user interface (similarly to WPF/Silverlight XAML files)

The declarative approach is preferred whenever possible. One obvious advantage is the relatively easy to make minor changes to the user interface without modifying the Java code. It consists of an Android UI specific set of XML tags that can be used to parameterize and link together Java based user interface widgets. Each widget in the UI is a View and each set of widgets comprising a user interface is typically a tree of Views.

Eclipse environment helps you to create application user interfaces through a drag-and-drop graphical designer, similar to Visual Studio’s Form Design/XAML view. There are also developer tools which let you inspect/edit GUI at run-time, directly in the emulator or on a physical device, and there is an open-source tool which can help in developing Android app GUI graphically: DroidDraw.

 

Android, graphics and games

Even though Java is the primary development language for Android, Google has realized the need for combined Java/C development in order to make Android succeed as a gaming platform: so they released the Native Development Kit (NDK) starting from Android 1.5. Google is realizing the need to support C development to catch up with the overwhelming number of native games written for other mobile platforms, like the iPhone. PC/console games have been around for decades (mostly written in C/C++), and by using a “simple” ARM C compiler, you could potentially bring thousands of existing games to the Android Platform. In addition, Android provides graphics libraries for 2D canvas drawing and 3D graphics with OpenGL, to help you make the most of the high-end hardware which current mobile phone are equipped with. Android also offers comprehensive libraries for handling still images, video and audio files, including JPG, PNG, MPEG4, H.264, MP3, AAC file formats.

 

Easy access to hardware

On Windows Mobile, hardware can be accessed via native C/C++ applications or with lots of P/Invokes to call native functions from .NET Compact Framework. Android, instead, includes API libraries to simplify development involving the device hardware: these ensure that you don’t need to create specific implementations of your software for different devices, so you can create Android applications that work as expected on any device that supports the Android software stack. The Android SDK includes APIs for location-based hardware (such as GPS and Google’s GSM cell-based location technology), the camera, audio, network connections, Wi-Fi, Bluetooth, accelerometers, the touch screen and power management.

 

Customization: all applications are created equal!

How many times, as Windows Mobile developer, you desired to change the look and feel of the Home Screen, create an alternative message or contacts manager, or deeply interact with contacts, calls, messages, logs? How long did it take to achieve a satisfactory result? With Android, forget all the pain. The system has been designed in such a way that it doesn’t differentiate between native applications and those developed by third parties. This gives consumers unlimited power to change the look and feel of their devices by letting them completely replace every native application with a third-party alternative that has access to the same underlying hardware and data.

 

Intra/Inter-application communication and SQLite Databases

There is almost no equivalence in Windows Mobile (even if it is possible, but it can be hard to achieve the same results). Android includes three techniques for transmitting information from your applications to be used somewhere else: intents, notifications and content providers.

  • Intents provide a mechanism for exchanging intra/inter-applications messages. Using intents you can broadcast a desired action (such as dialing the phone, sending an SMS or editing a contact) in order that other applications in the system may handle it.
  • Notifications are the standard means by which users can be alerted: using the API you can trigger vibration, audio alerts, control status bar notification icons and flash the device’s LED.
  • Finally, you can use Content Providers to give managed access to your application’s private databases. For example, the data stores of Android’s native applications, such as the contact manager, the calls log or the SMS database, are exposed as Content Providers so you can create your own applications that read or modify this data.

For each application, then, Android provides an integrated, lightweight, relational database: SQLite. As Windows Mobile user, probably you are used to SQL CE databases. They’re powerful, but nothing compared to SQLite in terms of performance and resource occupation. Your applications can take advantage of this managed relational database engine to store data securely and efficiently. By default each application database is sandboxed, meaning that its content is available only to the application that created it, but through content providers they can be easily shared to others.

 

What’s next?

I’m actually working, in my free time, on two personal projects for Windows Mobile. I started to plan and analyze things in order to port one of the two applications on the Android Platform: my idea is to use this application as the object of the the next articles. Here there are some of the topics:

  • A look to Eclipse IDE
  • How to create/debug/run an Android project
  • Building the user interface
  • Accessing and controlling device hardware
  • Localization
  • Packaging and deploying

If you are interested in something particular or if you have some questions/comments, let me know!

Saturday, September 11, 2010

Embedded Sparks 2010 Summer update

Also for this contest edition I had not enough free time during the summer to develop the second round device. I just started to build and test some software module prototypes, in order to validate the designed architecture and verify that the Spark Kit performances were enough to support my idea. Sadly and unfortunately, the hardware seemed not enough powerful to handle both DVB-T TV decoding (via an external Avermedia USB DVB-T receiver) and rich WPF graphics, so I decided to stop the development.

Here there are some photos I took while assembling the device:

 

Now the contest has entered its final round and the three finalists have been announced earlier this week. Good luck to everyone!

New Microsoft certifications achieved

In March, I announced that I would have studied all-long this spring to get some other Microsoft certifications. In late April I had the opportunity to take the beta exam .NET Framework 4, Windows Applications development. In the last week of June I was announced that I passed the exam! In addition, the same week, I passed another exam, Microsoft Windows Embedded Standard 7 for Developers. Now, together with Windows CE 6.0 and Windows Mobile 6.5 certifications, I’m a “complete” Microsoft Certified Technology Specialist in embedded field.

Wednesday, June 30, 2010

Windows Embedded Compact 7 (aka CE7)

It’s not a fresh news, but I just would like to share with you that at the beginning of June Microsoft officially announced the next version of Windows Embedded CE, now named Windows Embedded Compact 7, and made it available for a public technology preview. If interested, more information are available on Microsoft Windows Embedded CE website. A device equipped with Compact 7 has already been shown at Computex 2010, you can see it in this video:

I’m starting these days to play around with the new development platform, so stay tuned for articles and updates.

Tuesday, June 29, 2010

EWF in Windows Embedded Standard 7

While developing a custom shell for a project, I encountered a strange behavior while enabling/disabling EWF protection. For development purposes, I created a Windows Embedded Standard 7 thin client image using IBW, including EWF feature with all default settings. Everything worked fine until I tried to start playing with the disk protection. According to MSDN documentation, EWF can be controlled via EWF Manager tool (EWFMGR) from a console window (with Administrator rights) or programmatically by using EWF APIs.

In the custom shell that I was developing, I needed to control EWF state according to a number of internal procedures: in some cases the protection had to be enabled and in others it had to be disabled. I had no problems when enabling the protection (both via console and programmatically), while the strange thing happened in disabling the protection.

I was expecting that the protection could be disabled in the same way it can be enabled, just by invoking the ewfmgr –disable command from a console window or by using the EwfMgrDisable API function, followed by a device reboot. But that didn’t work. After the device restart, the EWF protection was still enabled. At first I thought I didn’t configure properly the EWF protection when installing the image via IBW, so I created an answer file with ICE, configured the EWF feature with default parameters and then deployed the image again. No way, again: the protection, once enabled, couldn’t be disabled anymore. How to solve the problem?

After many retries and a lot of frustration, I found the solution looking inside the EWF API samples (I couldn’t find any reference about that in MSDN documentation): a comment to the EwfMgrDisable function clearly stated that when EWF is configured in RAM REG mode (as it is when using default settings in Widows Embedded Standard 7), it is necessary to perform a commit operation after calling the disable function. Instead, if EWF is configured in RAM mode, just the disable operation will suffice. Additionally, the same result can be obtained using  ewfmgr –commitanddisable [–live] command (with –live option, no reboot is required) or, through API, with EwfMgrCommitAndDisableLive function.

I hope this little addendum to MSDN documentation can save you time and troubles while using EWF in Windows Embedded Standard 7.

Friday, June 25, 2010

Windows Embedded Standard 7 CTP/RC and RTM answer files compatibility issue

This morning, while building a Windows Embedded Standard 7 image for a project, my colleague and I encountered an unexpected sneaky problem. In the office we have various development machines equipped with different versions of Windows Embedded Studio 7 (which we’ve installed as soon as Microsoft released it for testing during the last months – CTP, RC and RTM). We started to migrate all machines to RTM version, so now we have a number of projects made with CTP and RC (when the product was still named Windows Embedded Standard 2011) and others with RTM. We had never tried to use an answer file from a pre-release version with the final RTM, until today. And unfortunately there are no good news: it took us some hours to figure out a strange problem about DISM during image deployment (IBW log files just reported an error installing an INF file, no other info).

It was strange because we created two similar answer files (they just differed on EWF and FBWF protection), one with ICE RTM and the other with ICE CTP, which we deployed on the same target device without problems. Then we had to edit both answer files and we used ICE RTM: with the file created with ICE CTP, the tool alerted us of a problem with the Distribution Share folder (that was obvious, because the product changed its name and installation folder from \Program Files\Windows Embedded Standard 2011 to \Program Files\Windows Embedded Standard 7), but after using the correct DS, no more validation errors occurred. So we thought that everything was fine and ready for a new deployment. But that was not true! While deploying the CTP-RTM updated answer file, the problem with DISM occurred; while using the RTM-only answer file, everything worked fine. We tried to figure out the problem by modifying the edited settings, thinking that we used some bad values, but nothing changed. At the end, we re-created from scratch the CTP answer file using ICE RTM, and magically everything worked.

Thus, it seems that some compatibility issues exist between Windows Embedded Standard 7 CTP/RC and RTM answer files. To avoid any problems with your pre-release answer files (maybe you received a pre-release promotional evaluation kit), we suggest you to re-create your projects using the RTM version.

Wednesday, June 23, 2010

Embedded Spark Contest news

Finally Embedded Sparks 2010 Summer Challenge first round winners have been announced yesterday night: I was very happy to discover that my eMMEC idea is one of them again! Stay tuned for updates on prototype development progress during next weeks (this time, I hope I will have enough free-time this period in order to come up to the end of Round 2).