Translator entry

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



A few months ago, this blogger acquired the HTC G1 and plunged into the world of Android development. Having released a couple of applications on the Android Market, Kushik Dutta (that is his name) 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. There are several links of the form [X] in the text, at the very end there is their decoding.

Android vs Windows Mobile

I wanted to refrain from blogging on this topic until I dive enough into 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 corns and be able to defend my opinion. [0]

')

Byte code

Google has 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 runtime as a bytecode in Sun Java or Microsoft Intermediate Language (IL) [1]. I couldn’t understand why Google decided to make its bytecode specification for Java until I read this great post . And the bottom line is that Sun has licensing issues with Java ME and an “open” alliance of mobile devices (Open Handset Alliance) cannot actually have an open platform without the likelihood that any mega-corporation will not bother counting [2]



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

Tongue

Generally speaking, the bytecode generated off-frame is just as important as the color of my socks. I don't think about it regularly. What really matters is the language in which you write. I can understand that Google chose Java to make it easier for targeted developers to migrate to a new platform, but still ... yes, I will finally say it. Java sucks.



Why java sucks? Let's count.

1. Terrible restrictions around package / file / directory / class names
2. Lack of anonymous methods
3. No closure (closure)
4. No lambda expressions
5. No events / delegates
6. Absence of partial classes
7. Funny implementation of transfers
8. Awful implementation of generics
9. The absence of structures and, as a consequence, the impossibility of storing composite objects entirely 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 silly and unintuitive bracketing

How many reasons? 15? Ha ha ha!





I'm not trying to find fault - everything listed above, I use on a regular basis. Nonetheless, I note that I somewhat like anonymous classes, 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 one another - both languages ​​can do everything you need, just in every language you need to do it his Except that C # allows you to develop faster, more efficiently, more elegantly. [3]

Development environment

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





My most favorite sore spot is the inability to simply click on the Expressions view and edit something on the spot. Be sure to click the right mouse button and select Add / Edit there. As a result, a primitive text editor without Intellisense opens, in which you can type an expression, pray that it contains no errors, and click OK. Wrong - repeat all over again.

Earlier, I praised the possibilities of inner classes in Java. No matter how good they are, Eclipse almost negates their convenience: you cannot see the value of the parent class variable in the inner class! This makes debugging true flour: you have to load parent classes into local variables if something went wrong, otherwise it’s just impossible to find and fix even the simplest jambs. True, I'm not sure if this is a problem in Eclipse, Java or Android.



The autocompletion in Eclipse is terrifyingly annoying. It is impossible to supplement everything so violently, regardless of the desires of the developer. In the end, I generally disconnected everything, because what he inserted into me was for the most part useless. But even with the auto-add-on completely disabled, Eclipse continues to set brackets for me ...

Sdk

Despite the fact that I complained a lot about developing for Android, I want to point out that I did not complain about Android itself. In essence, any API that I would think of is standardized and exists.

My litmus test in this sense was porting Klaxon to Android. This helped to highlight the colossal 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 class SensorManager, 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 figured this out on Windows Mobile:

• I started with CeRunAppAtTime . Wrote a big P / Invoke. It works for some time, and then completely ceases. Other people had the same problems. I had to switch to another mechanism.
• Next, I tried CeSetUserNotificationEx . Wrote another hefty P / Invoke.
• In order for this to work, we had to figure out how to properly fill in the structure of a UserNotificationTrigger .
• Then it turned out that if the device is sleeping, then Klaxon does not always work correctly .
• Once again, having scrutinized the documentation, I solved this problem too - it turns out that it was necessary to explicitly send a power command to the device, otherwise it fell asleep again.
• Klaxon worked for some time until the transition to summer time happened. On some phones, notifications work an hour later. No idea why. I gave up.

Now compare with Android:

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

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





Thus, one of the two difficult parts during the development for Windows Mobile on Android turned out to be easy. 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 is tearing the Windows Mobile SDK into pieces (disregarding the features of languages ​​and frameworks).



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

Platforms

Android is quite tightly clamped in terms of security. Applications must register the capabilities that 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 the fault of Android, but the phones are not so “open” are obtained - the operators tied and will tie the phones to themselves, because they subsidize them. For example, the user does not have access to the root account . This makes it impossible to customize / modify the standard applications installed on Android. But if you still got root access, you can really change the standard applications, because they are in source codes.



On the other hand, Windows Mobile does not hide anything. The developer can get low-level access to absolutely anything. For example, if Android had no Sensor API, the developer would have no chance (except installing the binaries manually via ADB). Another example: in Android, there is no support for streaming video through the Media Player, and as far as I know, nothing can be done about it, unless the system’s binaries are patched via OTA update.



Oh yes, the Android Market! I will not say anything, from the title and so everything is clear.

Prim.per .: Yes, the Marketplace is only in the autumn of 2009 will appear ...

Conclusion

At 4 am you will not write some fantastic conclusion. I can only say that I really enjoy 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 fantastic! Finally, I do not need to fight with the phone to get online. So guess which phone is always with me. And think for which of the phones I'm more interested in developing.



I really hope that Microsoft will be able to create a user-friendly 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 snatch a page from the Apple book and say: “we will score backward compatibility, we will score on existing applications, we will simply make a completely new platform that works” . For too long, they resorted to the mantra "backward compatibility", which simply prevents them from moving on. In the meantime, 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 the development for the Android platform. Klaxon has greatly helped underscore the colossal differences between the two platforms.

[1] Yes, I understand that IL is not interpreted on Windows Mobile. it goes through a JIT compilation.

[2] Whatever Microsoft was “evil,” he wasn’t seen on the news trying to defend his patents. Unlike Sun

[3] I want to look at Ruby

[4] Maybe Google will do it in the future.