Translator's entry

Being engaged in development for the Windows Mobile platform over the past two years, I could not help but hear about new platforms such as Apple IPhone, Google Android, Palm Pre. Some time ago I came across a blog of the Windows Mobile developer, which maintained its blog in a rather mocking style, parodying “30 days of Windows Mobile”, his posts from that series were called “30 Days of Bitching about .NET CF”, which translates like “30 days of gossip behind the back of .NET CF”. In these posts, he described the pitfalls that he encountered during development.

A few months ago, this blogger acquired HTC G1 and plunged into the world of Android development. Having released a couple of applications on the Android Market, Kushik Dutta (which is exactly what his name is) decided to write a comparative analysis of the development experience for Windows Mobile vs Android.

The original is here . The article was written in November 2008, today some information is somewhat outdated, but it did not become worse from this. In the text there are several references of the form [X], at the very end there is a transcript.

Android vs Windows Mobile

I wanted to refrain from blogging on this topic until I dive deep enough into the development for Andriod. And although I am by no means the guru of the Android platform, I believe that I can calmly make some fairly general statements, step on someone's blisters and be able to defend my opinion. [0]

Bytecode

Google made some interesting architectural and strategic decisions regarding Android. The most notable are Java as a development language and Dalvik as a virtual machine. In short, Dalvik is a bytecode that is interpreted at run time as bytecode in Sun Java or Microsoft Intermediate Language (IL) [1]. I couldn’t understand why Google decided to make its own bytecode specification for Java until I read this great post . But the bottom line is that Sun has troubles with Java ME licensing and the “Open” Alliance of mobile devices (Open Handset Alliance) cannot actually have an open platform without the likelihood that any mega-corporation will not try to weld for them account. [2]

But the question remains open - why invent a new bytecode when IL is not protected by such licensing (is it an ECMA approved standard )? Maybe Google looked and decided that IL was not suitable for a mobile platform, or maybe they did not want to sleep in the same bed with Microsoft. I believe the latter is most likely.

Tongue

Generally speaking, the bytecode generated behind the scenes is just as important as the color of my socks. I don't think about it regularly. But what really matters is the language you write in. I can understand that Google chose Java to make it easier for target developers to migrate to the new platform, but still ... yes, I’ll finally say it. Java sucks.

Why does Java suck? Let's count.

1. Horrible restrictions around package / file / directory / class names
2. Lack of anonymous methods
3. Lack circuits (closure)
4. The lack of lambda expressions
5. No events / delegates
6. Lack of partial classes
7. Funny implementation of listings
8. Awful implementation of generics
9. The lack of structures and, as a consequence, the inability to store composite objects as a whole on the stack. This significantly affects performance where it matters.
10. Strings are immutable, but not interned (see intern )
11. No access to unsafe code
12. No get / set methods for properties
13. No operator overload
14. No extension methods
15. Finally a dumb and unintuitive parenthesis

How many reasons? fifteen? Ha ha ha


I am not trying to find fault - everything that is listed above, I use on a regular basis. However, I note that I like anonymous classes to some extent, but they are almost useless without events / delegates. I understand that all that I have listed is, by and large, syntactic sugar, and neither Java nor C # is more powerful than each other - both languages ​​can do everything you need, just in every language you need to do it to your own. Except that C # allows you to lead development faster, more efficiently, more elegantly. [3]

Development environment

Eclipse is a huge fragrant piece ... eh. Yes, very rich, flexible, but whoever conducts usability testing of this garbage should work on testing the compressive strength of the rope around his neck.


My favorite sore spot is the inability to just click on the Expressions view and edit anything in place. Be sure to right-click and select Add / Edit there. As a result, a primitive text editor without Intellisense opens, in which you can print the expression, pray that it is error free and click OK. Wrong - repeat all over again.
Earlier, I praised the capabilities of inner classes in Java. No matter how good they are, Eclipse almost negates their convenience: you cannot see the value of a parent class variable in an inner class! This makes debugging a real torment: you have to load the parent classes into local variables if something goes wrong, otherwise it is simply impossible to find and fix even the simplest jambs. True, I'm not sure if this is a problem in Eclipse, Java or Android.

Eclipse's auto-add-on is horrificly annoying. You can’t supplement everything so violently, regardless of the wishes of the developer. As a result, I turned off everything altogether, because what he inserted into me was for the most part useless. But even with auto-completion turned off completely, Eclipse continues to put brackets for me ...

SDK

Despite the fact that I complained a lot about the development for Android, I want to note that I did not complain about Android itself. In fact, any API that I could think of is standardized and exists.
My litmus test in this sense was porting Klaxon to Android. It helped a lot to emphasize the enormous differences between the two platforms.

For me personally, the most noticeable difference was the API for accessing hardware sensors. Android SDK 1.0 offers a simple SensorManager class, which I figured out in 5 minutes. Microsoft had 6 versions of Windows Mobile without any Sensor API.

Secondly, launching scheduled applications on Android is infinitely easier than on Windows Mobile. Compare how I dealt with this on Windows Mobile:

• I started with CeRunAppAtTime . Wrote a great P / Invoke. It works for a while, and then completely stops. Do other people had the same problem. I had to switch to a different mechanism.
• Next I tried CeSetUserNotificationEx . Wrote another hefty P / Invoke.
• In order for this to work, I had to figure out how to properly populate the UserNotificationTrigger structure .
• Then it turned out that if the device is sleeping, then Klaxon does not always work correctly .
• Shoveling the documentation again, I solved this problem as well - it turns out that I had to explicitly send the device a power-on command, otherwise it would fall asleep again.
• Klaxon worked for some more time, until the switch to daylight saving time occurred. On some phones, notifications are triggered an hour later. No idea why. I gave up.

Now compare with Android:

• Refer to AlarmManager
• Configure the triggering of an event (intent) at a specific time
• Handle the event

Everything just works, no problem. I must say that events are convenient to use, they are surprisingly flexible and equally powerful.


Thus, one of the two difficult parts during development for Windows Mobile on Android turned out to be as easy as shelling pears. Finally - the user interface.

Windows Forms vs. Android XML Layout. Windows Forms works with absolute dimensions and positioning. Android works with relative sizes and positioning. "Static" controls against animated controls. In fact, there is nothing to compare, so I will not try.


Simply put, the Android SDK breaks into pieces the Windows Mobile SDK (without considering the features of languages ​​and frameworks).

Windows Mobile has much better documentation (MSDN), but this is the fate of any young SDK.

Platforms

Android is quite tightly clamped in terms of security. Applications must register the capabilities they need, and the user must confirm them. But despite the fact that this is a very, very positive thing, it has its drawbacks. For example, it is impossible to write an application that takes screenshots of something other than itself, because this is considered unsafe [4]

And although this is not Android’s fault, the phones are not so “open” ones - the operators tied and will bind the phones to themselves, because they subsidize them. For example, the user does not have access to the root account . This does not allow you to configure / modify standard applications installed on Android. But if you still get root access, you can reallychange standard applications, as they are in the source.

Windows Mobile, on the other hand, hides nothing. A developer can get low-level access to absolutely anything. For example, if Android did not have a Sensor API, the developer would have no chance (other than installing binaries manually through ADB). Another example: in Android there is no support for streaming video through Media Player, and as far as I know, nothing can be done with it, unless you patch the system binaries through OTA update.

Oh yes, the Android Market! I will not say anything, from the name and so everything is clear.
Note: Yes, the Marketplace will only appear in the fall of 2009 ...

Conclusion

At 4 in the morning you will not write some kind of fantastic conclusion. I can only say that I really like developing for Windows Mobile. The language and development tools are great. However, the platform and applications are not very convenient to use. On the other hand, although I'm not so satisfied with the development for Android, the platform, applications and usability are just fantastic! Finally, I don’t have to fight with the phone to go online. So guess which phone is always with me. And think about which of the phones I'm more interested in developing.

I really hope that Microsoft will be able to create a user-friendlya platform that will make me a happy user and developer. I don’t believe that I’m saying this, but I’ll still say that they need to tear out the page from the Apple book and say: “we will forget for backward compatibility, we will forget for existing applications, we’ll just make a completely new platform that works” . For too long they resorted to the mantra "backward compatibility", which simply prevents them from moving on. Meanwhile, they are all moving away and moving away from the market, part of which they are so afraid of losing.

Footnotes

[0] I developed two applications for the Android Market: Telnet and Klaxon, so I suppose I have an idea about developing for the Android platform. Klaxon helped a lot to emphasize the colossal differences between the two platforms.
[1] Yes, I understand that IL is not interpreted on Windows Mobile. it goes through JIT compilation.
[2] Whatever the “evil” of Microsoft, it was not seen in the news in an attempt to defend its patents. Unlike Sun
[3] I want to look at Ruby
[4] Maybe Google will do it in the future