C# vs Java Part 2: Desktop and Mobile Platforms
In this post we'll be looking at both the desktop and mobile platforms for C# and Java.
The Desktop (Thick Client Applications)
The desktop platform, or thick client, is not as important of a platform as it was several years ago, and it seems to be getting less and less important everyday. Although, like a pendulum, development seems to swing back and forth between thin and think client experiences. It seems as though the current trend is thick client functionality in a thin client package. (The browser as the OS). For this post I will assume the development of a true thick client application, which is one that runs natively on the client computer and is installed or executed from the client computer. (Although, as I am making this statement I am realizing even that line is becoming blurred with Adobe Air and Silverlight.)
There isn't much choice here. Really, it comes to two options. Swing or SWT. I'll confess my ignorance here. The only thing I really know about Swing is that a long time ago I wrote an application that bounced an image around the screen using a second thread. I tried to do a bit of research here, but I am not coming up with a large amount of information. Probably because not many people are actually doing thick client development in Java anymore. I asked one of the best Java developers I know, (Sreenivasa Majji), and he was able to give me some information.
Apparently, Swing has gotten much faster and easier to use since last time I used it. From my understanding, Swing is pretty comparable to the previous generation of .NET thick client frameworks, Windows Forms. SWT also seems to have comparable functionality, including data binding. The real advantage that Java has here though, is the multi-platform capabilities. A Java desktop application can be run on any operating system that supports Java. (Which is pretty much any operating system.) Deployment has always been an issue in thick client applications, and Java Web Start tends to solve that problem by allowing a client to visit a web page to launch the application.
I have heard complaints that not much progress is being made on Swing or SWT, which seems like it is true. I know finding information about the technologies is not very easy.
The current generation of C# thick client applications use WPF. WPF is basically a wrapper around the DirectX libraries which uses XAML, (an XML based scaled vector graphics UI convention), to create the user interface. WPF development is different from Windows Forms development in many ways. WPF development separates the UI from the logic behind the UI very clearly. XAML is used to define the layout and elements that exist. The UI can almost be completely independently developed by a designer. Everything in the UI is completely customizable, any control can be drawn from a vector representation replacing the default version of that control. Animations and 3D graphics are easily achieved since WPF is built upon DirectX instead of the Win32 libraries. The UI is also scalable since everything is represented in vector graphics.
Desktop development with C# using WPF is very nice. I haven't done a large amount of WPF development myself, but what I have done has been pretty easy and straightforward. The power to use any SVG image or animation can make for some pretty nice UIs. It can also make for some pretty inconsistent UIs though. One major advantage that I see for WPF is that it uses XAML, which is the same technology that Silverlight uses. I know that Silverlight and WPF are not 100% compatible at this point, but they do share many commonalities. I have heard of a few frameworks that try to abstract their difference, but I don't know of one that does that really well yet. I am sure one will be developed, or Microsoft will provide a solution in the near future to make it possible to build an application that can easily be run as a WPF or Silverlight application.
In this case, I think it depends where your install base is. If you are targeting a Windows user base, I think it would be pretty difficult to come up with a reason to use Java over C# for desktop development. If you are targeting a multi-os install base, C# could be used to do Windows Forms application development using Mono, but Mono doesn't support WPF. Java is the most logical choice for doing a multi-platform install if you have to use a thick client. I especially would not want to try and troubleshoot a bug that is different in Mono vs the .NET CLR. I tend to see most traditional desktop applications being replaced with Rich Internet Application (RIA) technologies like Adobe Air, Silverlight and JavaFX. One other side note here; Java and C# are able to call into unmanaged libraries (or native code), using P/invoke for C# and JNI for Java. If you need to do that, C# P/invoke is by far easier than JNI, especially with the dynamic keyword being added to C# 4.0.
Welcome to the next battleground. This platform is under heavy turmoil right now. Microsoft is being killed here by Apple and Google, both producing by far better user experiences. Unlike the other platforms, the choice of language and technology here is more driven by adoption than by convenience. What I mean by that is that there is almost no point deciding what technology to use based on language or features, it is more based on what kind of device you want to target, and who is winning the mobile device war. Now, this is not entirely true, since there are ways to develop in C# on the iPhone ,as well as, Android platforms.
When talking about Java mobile development there are two branches, Java ME, and Android development. You can disagree with me if you want, but as far as I am concerned Java ME on mobile devices is pretty much dead or dying. The idea, however, is great. Multi-platform development on the widest landscape, mobile phones. But, the user experience was pretty much horrible. I have had several mobile phones running different OS versions and each one that had Java on it had some applications that weren't really that great and didn't integrate into the phone well. Apple blocked Java out of the iPhone anyway, which is a huge market sector.
So, let's talk about Android. Android is awesome. I love the idea, the technology is great, it is constantly improving and the architecture is wonderful. Good job Google, you have made an easy to develop for platform that Java developers will be able to quickly adapt to and use to write rich mobile applications. Android development is basically writing Java code, which gets converted to a specialized JVM that sits on top of a Linux kernel and some graphics APIs. Applications use a provider model, which allows mashups of different applications as one application's requests can be fulfilled by part of another application. The development environment takes minutes to set up if you use Eclipse. The UI is nicely separated from the code through the use of layouts and resources. My only real complaint at this point is that you currently have to look up resources by an ID then cast the resource to the appropriate type. The build is already using code generation to create a R.java file which holds the references to all the resources. I cannot understand why Google didn't make that code generation generate strongly typed methods for each resource. Perhaps I am a fanboy of Android, but I have to say, I like it and I think it is the future King in the mobile market.
Do you know how easy it is to create a Windows Mobile application in C#? It is so easy that if I gave you Visual Studio and 5 minutes, you could probably figure out how to make “Hello World” appear on the Windows Mobile emulator. Really, it is that easy. It's a shame that the current version of Windows Mobile is so lacking. Now, don't get me wrong. Windows Mobile is powerful. It is amazing what you can do with Windows Mobile so easily, since you have the power of almost the entire .NET framework at your fingertips. It is a well designed OS, it runs applications really well, it transfers the Windows look and feel we are all so familiar with to a mobile device very well. But, that is exactly what the problem is. It is not really an OS designed for a mobile phone. At least not the way people really want to use their mobile phone.
So, let's talk about the development environment for Windows Mobile using C#. It is almost exactly like developing Windows Forms applications. It's incredibly easy, and for the most part, you don't even realize you are developing for a mobile phone. The emulator is built right into Visual Studio, you just hit run and it launches the emulator and your application. The .NET compact framework has fewer features than the full .NET framework, but most of it is there. One difficulty though is trying to get into the core services of the phone. It is not very easy. For example, trying to replace the dialer application is not really possible.
Silverlight mobile may save the day for C# development on mobile devices, if Microsoft can manage to bring it to iPhone and Android, but for now it's unknown. Also, the next generation of Windows Mobile devices using Windows Mobile 7 may change the game for Microsoft, but with it's Q4 2010 release date, I fear that it will be dead on arrival.
Mobile development is kind of like the wild west right now. It's a huge risk to settle into a technology platform. I place my bets on Java and Android, because it seems to me like the best combination of a good operating system and good development environment. I didn't really mention this, but iPhone development using objective C is ridiculously complicated and makes me want to smash my head into the wall. Having done both Windows Mobile and Android development, I would say Windows Mobile development is slightly easier, but they are pretty comparable. The reason I would choose Java and Android despite this is because Android is a better platform, a growing market, and has a delivery mechanism to easily sell your applications.
Comparing C# and Java development platforms is very difficult due to the overwhelming amount of information out there about each platform and language, but I have tried to take a fair and honest approach. It is pretty clear that each language and corresponding technology have advantages and disadvantages for each platform. I can't pick a clear winner from the platform perspective, like I could with the languages. In the next part I will talk about the non-platform specific frameworks that Java and C# have to work with.