A little rant about Android SDK, Java, and Eclipse

I don’t often rant nor say the work “sucks” very often. However as any programmer knows, some tools just frustrate you to no end. Java, the Android SDK, and the Eclipse IDE are something I need to use, but are frequently on my “sucky tools” list. I’ve used a lot of programming languages and tools in my day, and these have made the frustrating Sh** king-of-the-mountain where things like Cobol and JCL reside.

Here is an email rant I made recently:

Wasted the whole day trying to get the settings activity working as I initially designed it. I eventually dropped that after wasting a large amount of time “playing” around with the code, so now the unit conversions happen outside of the settings activity. In the settings activity, it is just cut-and-dry select setting and select type of units. There is no unit conversion and re-selection of a setting value in the spinner as I had attempted to do earlier. For example, 10 for the search distance will me km or miles depending on if the user has one or the other selected. Trying to have the settings activity do conversions was a bad idea on my part.

The value from the drop-down gets saved in the settings as it is without conversion (meaning one setting entry is for units and one setting entry is the value in that units instead of a converted value to metric as I initially had it). The other activities call a function from the Settings class that does the unit conversion for US-Units on-the-fly instead. A lot easier to code and it appears to be functioning with the limited amount of testing I’ve done so far.

The Android SDK, Java, and Eclipse have moved very close to Cobol as one of my leas liked programming tool sets ever………….

1. It’s almost impossible to debug. The debug tools suck, the way Java works sucks, and the Android SDK isn’t any better in how it functions.
2. Java sucks with its haphazard hack-ish object orientated approach to coding.
3. Android SDK tries to follow how Java works, making it suck just as bad.
4. Eclipse sucks bad and the SVN plug-in sucks even worse.

Now I’ll work on the help functionality……….

To not sound like a total troll, let me go into a bit more details about my reasoning:
#1. Debugging this stuff is a far far far cry from say, the Visual Studio IDE and the .NET framework. It doesn’t work on some computers, it has an odd threading approach, and when an exception occurs it’s impossible to find what line the error happened on. Thankfully breakpoints work, at least on my computer (my friend’s computer has issues with debug and breakpoints off and on).

#2. Java is like the OOP language from hell. Try updating an instance of an object in a list collection. Laugh at the pointless verbose nature of the language. Callback methods… classes within classes… this and saving this so this can be accessed from that…

#3. The android SDK and system are just as bad. Slight things in the XML configuration files completely crash the system. Haphazard android versioning. The way threading works (this is very necessary on phone, but it’s poorly designed … android.os.Handler … object.post(new Runnable() {}). The total lack of quality documentation, especially from Google themselves. Sorry, the SDK docs are completely useless verbosity without examples (showing a generic list of functions for a class won’t make it any easier to USE). The virtual machine for testing is tragically slow.

#4. Android and Java pale in comparison to the buggy mess that is Eclipse and the SVN plugin. It’s a quirky and confusing mess of an IDE. I’ve used it for years and I still need to use my tiptoes to get around it safely. An IDE with a restart menu button and multiple “clean code” buttons says it all…

That being said, there are some positive aspects to Android itself. It is reasonable solid and functional in version 2.2 (my current phone version). The developer costs are very low. Nice virtual machine, phone hardware based testing, and telnet functionality.

This entry was posted in Thoughts and tagged , , , , , . Bookmark the permalink.