Tag Archives: Engineering

iOS vs. Android – programmer first impressions

I did my first “Hello World” style Android app yesterday, and while it’s only a first impression I wanted to share my first impressions.

My background is that I’ve been a professional Mac software developer for about 15 years and a hobbiest Mac and Apple developer since I was a wee lad. I used to work at Metrowerks, makers of CodeWarrior, back in the day when CodeWarrior was “the thing” for Mac software development. So I’ve not only used developer tools, I’ve made them. That all said, I don’t have a lot of iOS experience from a developer perspective because I’ve only so much time in a day and just didn’t have time nor a job that required it. But that’s changing and so into the abyss I go. I say this because yes, my initial Android experience is going to be tainted by the world I’m coming from. I’m not saying the new world is bad, just different.


Android uses the Java programming language. I haven’t touched Java in over a decade, and I know the language has evolved. First thing I did was pick up a book on the language. I bought Learn Java for Android Development by Jeff Friesen. The book has NOTHING to do with Android itself, it’s a pure language book. But I choose this book because the book is geared towards Android so it doesn’t waste time talking about matters irrelevant to Android, like AWT. I didn’t give the book a hard-read, nor did I bother with doing much of the exercises because I don’t feel I need it (famous last words?). I’ve used Java in the past, I’ve been programming for quite a while, and the book is geared towards someone who is starting from scratch. So talking about Generics? It’s akin to C++ templates so I just needed to get the details and differences. Container classes? Just give me an overview of what’s there, I don’t need to read 10 pages about all the various methods and what they do (that may come later for reference).

That all said, there’s a lot that’s changed in Java since I last really used it and I think a lot of the changes are good. Being able to “inline” a lot of things, nest classes, anonymous classes… it’s nice to just define your “callback” right there as you go along. It’s nice to have a language that’s more pure OO than C++ (Objective-C is pretty good at being true OO). It’s nice to see the library expanded, and things like Generics added. Yes there’s a lot of syntax I’ll have to get used to, but that’s how it is when you switch from one language you’ve used for years to one you haven’t. I should be alright.

But while the language is fine, the IDE is another story.


Oh…. I don’t like.

You see, every platform does things they way they do it because they believe they have something different and better. Mac OS X is one thing, Windows is another, Linux another… and everyone does their thing differently. Sure most of the core concepts are the same, but little details of interactions and how widgets work and the parts mesh vary. And Java apps seem to like to do things their own way, perhaps with a Windows-bias since many Java developers are Windows-based. Coming from the elegant world of the Mac user experience? Using Eclipse feels bizarre and klunky. I’m sure I’ll get used to it, but it still feels strange and like a step backwards in terms of human-computer interaction and experience.

One thing that really bugs me is I don’t like being forced into a tabbed single-window-only interface. I’m not that into tabbed interfaces, but I have come to appreciate when tabs are good and when they are not — for me. Apple’s really pushed a single-window mode of being on Mac OS X, and for the most part that’s alright. What I find I like is the ability to exist how I want to exist. Sometimes I want two windows because I need to arrange the content as I need to to do my work. Other times I want these “windows” to be grouped together and thus having the content in multiple tabs within the same window makes the most sense. I like options. If Eclipse allows me to escape this tabbed world, I haven’t found it yet.

Tools Install

You want to develop for the Mac? These days it’s pretty much Xcode. You download, you install, and off you go. All the apps you need, compilers, libraries, documentation, everything. It’s simple and rather painless.

To develop for Android? I had Eclipse installed from a prior thing I was working on, but now I had to get another version. So download that. Then I have to download the Android SDK and put that somewhere and tell Eclipse about it. Then I have to actually download and install all the API’s and tools for developing Android apps. Then more configuring. Finally, I can get going. What a pain. I don’t really blame anyone for this because the nature of the beast is so open, requires things from different vendors, and there’s a lot of flexible options. I do think options are good, but I also think there’s something to be said for providing a setup to get new folks started. It’s a high bar of entry, and I can only wonder how a total programming newbie would handle this. If Google could provide a “one click download and install” that gets you going, that’d be awesome. Sure it may provide more than is needed, it may bias towards one product or SDK or something, but get the n00b going, then once they grok the world they can sort things out and streamline later.

Nevertheless, things are going.

First App

A friend sent me this blog posting on writing your first Android app. I figured I’d give it a try before I went through all the Getting Started stuff at the Android Developer website. First, this blog posting was great because it gave better instructions on how to get the tools downloaded, installed, and configured. Thank you for that!

But as I worked through this, it helped me see how spoiled I am in the MacOSX/iOS world, especially with how integrated the developer toolchain is.

Designing the user interface. So, I have to hand-write XML? Holy crap… I thought we were in the 21st century! Oh sure there’s a little tool to work it, but it sounds like no one uses it and it’s very rudimentary. That everyone just prefers to edit the XML by hand. Man, that’s…. unacceptable in this day and age.

Then to hook your GUI into your code, you have to do all this manual labor in code to make it happen. Yes, I’m spoiled by the actions and outlets paradigms in Cocoa, where in my code I can just declare an IBAction or IBOutlet, then in Interface Builder just click and drag to hook everything up. It’s a small thing, but it’s there.

I do like Android Virtual Devices thing, where you can simulate any sort of device. That’s of course necessary, but it seemed to run a little smoother than the iPhone/iPad simulator.

As an aside, I got to learn about a cool prototyping/wireframing tool called balsamiq.  That app is way cool.

From here?

The first impression I’m left with? Android as a technology might be really advanced, but the developer experience is archaic. The toolset just feels really klunky, and I can see how spoiled I am with Apple’s tools.

That said, that’s the toolset and I will work with it. I’m sure I’ll get used to it and come to find things I love and things I hate. I’m still looking forward to delving deeper into the world of Android development. I’ve only begun and I’m sure my impressions will change, but first impressions are important and the impression I’ve been left with is one that desires more. Here’s hoping for the best.

Don’t assume; assert.

For the love of Knuth

If you write code that makes assumptions, assert on those assumptions and assert in a manner that the developer stuck with maintaining your code will see them.

Doing so would save much hair loss, and cut down on the number of times the original author of the code gets damned to hell by the maintainer.

Thank you.


I am an engineer by trade, and Wife points out that I have an engineer mind.

While I spend much of my time working with complex systems, I understand that simplicity is king. Simplicity is actually quite difficult to achieve because it takes work. You start off doing what you need to do, over time things grow and it will become more complex and kinda messy. You must take the time to stop, step back, and reengineer and rearchitect things to regain that simplicity. Typically this will mean you must discard and cast off.

Antoine de Saint-Exupery said:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Tao Te Ching #48:

In the practice of the Tao,
every day something is dropped.
Less and less do you need to force things,
until finally you arrive at non-action.

Simple is not easy, but it is best.

I’ve seen a few things in the past couple days that reinforce this.

I stumbled across this blog posting on “What is good code?

Good code is simple. Even complex good code is comprised of simple building blocks. Good code hides or cuts through the complexity in the problem, to provide a simple solution – the sign of a true coding genius is that he makes hard problems look easy, and solves them in such a way that anyone can understand how it was done (after the fact). Simplicity is not really a goal in its own right, though; it’s just that by means of being simple, code is more readable, discoverable, testable, and maintainable, as well as being more likely to be robust, secure and correct! So if you keep your code simple (as simple as possible, but no simpler), it is more likely to be good code – but that is by no means sufficient in and of itself.

And all of this talk of simplicity isn’t just something for the world of engineering…. I think it applies to all things in life, and I think it’d do well to be applied to government.

Witness the mess there is in classifying sensitive information: (h/t Slashdot)

Protecting and classifying sensitive information such as social security numbers shouldn’t be that hard, but perhaps not surprisingly the US government has taken complicating that task to an art form.

It seems that designating, safeguarding, and disseminating such important information involves over 100 unique markings and at least 130 different labeling or handling routines, reflecting a disjointed, inconsistent, and unpredictable system for protecting, sharing, and disclosing sensitive information, according to the watchdogs at the Government Accountability Office.

Read the full article (it’s short) to see just how messy the problem is. This is not simplicity, this is about the furthest thing from simplicity. How does this make life easier?

Then I see this flowchart on Department of Defense acquisitions:

The Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System -- MY BRAIN HURTS!

Wow. Even the name (The Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System) is a complex beast.

I truly hope no one considers that to be a simple, streamlined process.

Have you ever noticed, any time the government talks about streamlining or improving their process, they always create some new group to do so? Nothing ever gets shut down or shed or cast off… it’s always grows.

If people are tired at how inefficient government is, at how bloated and slow it is, how complex, how confusing… why aren’t we working to truly simplify things? Why does no one believe in casting off? Why do we call them “law-makers”, as that seems to imply all they can do is make more laws instead of refining or repealing what we already have?

Why don’t we have any politicians that run on a platform of repealing, stripping down, and simplifying? Why is a discussion of “loss of government jobs” considered a bad thing? closing of government agency a bad thing?

Consider how truly simple things are better in life (or at least, consider how those ugly complex things make life difficult). Work towards the ideal.


BWToolkit is a library of code for Cocoa development.

Actually, it’s more than just a library of code. It comes with an Interface Builder (version 3) plugin that simplifies development and use of the framework. BWToolkit is open source under the generous BSD license, and you can obtain it as source code or you can obtain it as a nice “drop and play” package.

I’ve stumbled across BWToolkit a few times in my development work, but it wasn’t until recently that I could begin using it (seems to have a requirement of Mac OS X 10.5 as a minimum…. doesn’t state that explicitly, but you can see it in some of what it does plus examining the source code). In my use of it so far, it’s been really well done and a real joy to development. Having been an engineer of the PowerPlant C++ Mac application framework back in the day, I know what it can be like to write reusable code modules like this, and BWToolkit has a lot of spit and polish.

Some things I like about it:

  • Drop and play. Just download the distribution, install the IB plugin, ensure the framework is added to your project (link to it, copy it into your resulting bundle) and that’s it. So simple.
  • Use is very simple, because there’s no extra work. Just edit merrily away in Interface Builder.
  • It’s got a lot of those widgets that you commonly want to use but there’s nothing standard from the OS for you to use. Oh sure you could make the widgets, but BWToolkit makes things like the BWAnchoredButtonBar, BWAnchoredPopUpButton, BWUnanchoredButtonContainer and so on… it just helps round out those commonly used widgets so all you have to do in IB is just drag and drop and get on with your work.
  • I love the BWSheetController. I wish I had thought of that class! It’s so common to have a xib with a main window (e.g. document) and then you need to display a sheet on the window. To display the sheet, there’s a lot of infrastructure code you have to write every time, and it’s the same code over and over — perfect candidate for a reusable class to factor that out. With BWSheetController it’s even better because it’s just adding an instance of the controller to the xib, hooking up some outlets, and viola… functional sheet with just a few clicks. Wonderful!
  • Most of the classes are based upon Cocoa classes. For instance, BWSplitView is an NSSplitView, the button classes are typically just aggregates of other NSButton’s. It’s good to subclass where it makes sense, instead of fully recreating from scratch.
  • The use of the BSD license pretty much means there’s little reason NOT to use BWToolkit. It makes your life a lot easier, little restriction upon use, it’s free (beer and speech). What’s not to like?

Some things I don’t like:

  • I found a bug (BWSplitView’s show up in initial random locations if the host window’s “visible upon launch” setting is not on). I reported the bug via email but have received no reply from the author (it’s been long enough). Granted, it seems he’d prefer filing it in his bug tracking system, but I don’t have the cycles right now to do that so I wanted to at least email to ensure the bug didn’t slip through the cracks. So, I’m not sure how active the project is right now. *shrug*
  • There’s not much documentation. Granted, there’s enough to get you going, and eventually you can figure things out. But to make a well-rounded distribution, full documentation of the classes/widgets and an accompanying sample application that shows everything off would make for a better final product.
  • Some of where documentation would be very useful would be things like bottom bars…. you can do bottom bars now so, what’s the point of this class? What advantage does it provide? Or is it a holdover from long ago when the OS provided no means whatsoever? In which case, is the bottom bar class smart about the OS version? Again, one could figure it out from reading code, but formal documentation is better.

All in all, a nice little toolkit.

Still can’t GetLabel()

So we’re at a point in our development cycle where we can finally upgrade our toolset. Installed Xcode 3.2.3, using the LLVM-GCC4.2 compiler, the 10.6 SDK, and setting 10.5 as our minimum OS.

Of course now I compile code and lots of OS function deprecation warnings come up. Time to clean up the source code.

If you need to obtain a Finder label, the old-school way was to use GetLabel(). Even today we still have to use GetLabel(), despite the fact they have deprecated it since 10.5. And while they deprecated it in 10.5, they didn’t provide a replacement API until 10.6. Unfortunately this replacement API isn’t 100% workable.

1. It’s an Objective-C API, in AppKit. Specifically: -[NSWorkspace fileLabels] (and -fileLabelColors).

The old API was a pure C API so you could easily use it anywhere, and we use it in a pure C++ library. Fine. I can create a .mm file with an extern “C” function to provide my own C wrapper and mimic GetLabel()‘s API. But it’s just extra work.

2. It’s only available as of Mac OS X 10.6.

It’s not a huge problem, but it’s irritating they deprecate the old way and didn’t provide a new way until the next OS revision.

3. -fileLabels crashes.

Isn’t that wonderful? They provide a new API and the new API doesn’t work.

And it’s not like it’s any sort of difficult API to work with either. It’s just a simple call.

But how can you get it to crash? Simple. Call [[NSWorkspace sharedWorkspace] fileLabels] 3 times. The first time will be OK. The second time might generate the crash but could also just generate console messages. The third time, you should crash or certainly generate bad messages in the console. If you didn’t crash the third time, certainly on the fourth you should. But typically 3 calls and boom.

-fileLabelColors doesn’t have this problem.

Investigating it, it seems there’s something being double-released/freed/deleted inside of -fileLabels. You can turn on garbage collection and it won’t crash, but lots of ugly console messages are generated.

What also bugs me? How did this API ship with such a bug?  Didn’t they test it? Didn’t they unit test it? Did they only test it under garbage collection? Did they write the API only for the Finder and figure if the Finder wasn’t crashing that was a good enough test to say a public API for the OS would work?  I mean, I can understand complex bugs, I can understand how code paths can be what they are and how bugs can ship (been a professional software engineer for over 15 years). But something like this? I can’t see how this managed to get out the door.


rdar://problem/8301881 Seems it was also reported as rdar://problem/8084710.

So… there’s no GetLabel() replacement for me until they fix it, 10.7 if I’m lucky. Yes I’ve considered other workarounds, no they won’t work in my particular context, or with a lot of work I could get it working but it’s not mission critical and I have bigger issues to deal with.

Updated: Apple DTS wrote back saying this is a known issue being tracked under its original number: rdar://problem/7287108, which as you can see is at least the third report of the problem. So we can only hope Apple’s going to fix it, but I bet we won’t see it until 10.7 at the earliest.

Named pipes and unwanted hangs

The past few days I’ve been dealing with a wonderful little problem.

They’re called “named pipes“.

The main product I work on in my day job was doing some filesystem scans and would hang for some unknown reason. After much investigation we noticed the file it was hanging on was a named pipe file way down in the bowels of the system (a temporary file created by the com.apple.notify process). What was happening was well… it’s a pipe. Something in my app was opening that pipe and thus the app “hung” because it was now wanting to read from the pipe. Thing is, my app doesn’t care about pipes at all, it’s just working with files. As well, we weren’t explicitly opening the file; we would call some other OS routine and somehow somewhere in that OS function’s implementation it called open() and thus we hung.

And so, what a bear this is.

In the end we decided to check for and avoid pipe and socket files at all costs. Any means by which a file can “get into” the app, we put up a wall at the perimeter so no such files can even get in. We figure we keep them out at the wall, then we don’t have to spend lots of CPU cycles internally to constantly deal with them (tho critical code should still perform checks). Plus, since one big part of the problem is we can’t control what others do and if they might open() the file, we have to nip it in the bud as soon we become aware of the file and minimize how much “work” is done on the file in case some other function might open() the file and we risk hanging.

To check is pretty simple. Code something like this (NB: I tried using the “code” tags and less-than/greater-than signs for the #include, but WordPress’ editor seems to get confused… so I just used the “pre” tag, which isn’t quite giving me the results I want either… oh well.).

#include "sys/stat.h"

const char*    inPath)
    bool is = true; // assume failure, because if we fail on such 
                    // a simple operation something really has to be wrong
    if (inPath != NULL)
        struct stat statInfo;
        int retval = lstat(inPath, &statInfo); // use lstat() instead of stat() because 
                                                   // we want to minimize resolutions or other "work"
        if (retval == 0)
            if (!S_ISFIFO(statInfo.st_mode) && !S_ISSOCK(stat.st_mode))
                is = false;
    return is;

How you actually cope with it or if you consider them problems or not is up to you and your code and your situation. The key of the above is to get the file’s mode then check the FIFO and SOCK flags. If set, reject the file.

For most people, this isn’t going to be an issue or a problem. I mean, we went around for quite some time and never dealt with the issue. And in daily use, most people aren’t going to see pipe or socket files.

But it’s worth noting and thinking about. Nothing wrong with being a little defensive.

Self-document code is anything but

If you know me, or maybe you can just tell from my blog, I can be verbose.

It’s how I am. I tend to prefer more information to less. I think you get further in life by knowing more, not less.

But I also know this wears on a lot of people. They just want the bottom line and don’t care why or how you got there. IMHO that’s a pity because then they never truly understand and can never arrive at educated conclusions on their own. OK fine, a baby is made, that’s the bottom line. If you want to stop there and never know more, that’s your business. But in my book, knowing how to make that baby is interesting, and then going through the motions of making that baby even more interesting. :-)  Like I said, it’s good to have knowledge and information.

I write software for a living. There’s great debate about documenting code, be it formalized documentation apart from the code or writing comments in the code itself. I’ve never jived with folks that say code should be self-documenting and that’s all the documentation you need. Sure, you should write readable and maintainable code. Naming your variable “numberOfObjects” is far better than just naming the variable “i”. But you must have comments. Why? Precisely.

Self-documenting code can tell you what and how, but it cannot tell you why. For that, you must use external documentation.

You must go through the effort of writing comments to explain bits of code. Depending on the code, you may also want to write larger external documents (e.g. in a word-processor) that explain the greater architecture and how all the parts of the code fit together and how to use it all. This is something that cannot be conveyed by reading the code itself, and I just don’t understand those that think this sort of documentation is a waste of time and somehow if you do it makes you “not a real programmer”.

Well buddy, real programmers know the moment after the code is written it must start being maintained. If you can’t remember what you had for breakfast a week ago, can you expect to remember why you wrote this code when you come back to it in 6 months?

Case in point. Just yesterday I was working on a bug in our software where the application would hang. All signs and symptoms were odd but somehow made sense to each other. When our QA guy told me one key point (“looking at the permissions flags, there’s a ‘p’… what’s that?”) it all came back to me. The file was a named pipe and I dealt with this very problem in the past. I went looking in code for where I previously dealt with it. I found it. The comment was dated over 5 years ago.

5 years ago.

When I fixed the problem — 5 years ago — I added copious comments to the source code to explain the problem in great detail; 50 lines of comments. I know many would say that was ridiculous! That it’s just his (annoying) verbosity! Well, thank goodness for it because without it there would have been no way I would have remembered that 5-year-old problem in such great detail and know exactly how to fix it (again) today.

Here’s an article by Jef Raskin discussing the same thing. Jef Raskin would know.

So yeah… people tell me I’m verbose. I really don’t care. I am who I am and I know when to be curt and I know when to ramble on. There are times when comments aren’t needed (don’t tell me what or how), but you do need to explain why and not be afraid to go into detail because the code you may have to maintain may be your own. Do yourself a favor and explain yourself. And if someday that code gets to be maintained by someone else, do them a favor and explain yourself.

I’ve never known anyone to say there’s such a thing has having too little ammo. I feel the same way about code comments and information. :-)