Tool chains

To any person who works to create anything, their tools are the most important items available to them, be they a woodsman, a mason, a photographer, or even a software developer. The latter profession, often defending their own tool set with what can only be described as a religious fervor the likes of which might be construed by the casual observer as bordering on maniacal ravings. Often enough when one digs about such heated discussions one cannot help but feel that one side or the other might harbor some deep seated apprehension.

"perhaps my adversary in this fight is correct?..... Na can't be the superiority of my own {insert environ x here} is irrefutable... Besides he's a ding dong anyway"

Well I have often enough felt that way with my own development choices. Of late however I have found myself yearning to really know if the other guy was in fact a ding dong. I have found myself wanting to really know what the other sides tools are really like. Having no real spare time for anything, the only way that would happen is if the company I work for branched out a bit from their standard platforms and embraced something different.

As is always the case in these matters, changing course is not easy. One needs to make a rock solid, water tight business argument for the case and maybe said argument would not fall on deaf ears. Such was the case a few months ago when I approached the powers that be and made the case for doing some real development for the apple platform, specifically the iPad/iPhone. The case of course being that finally a compelling form factor was available for a touch device we could bring some of our applications onto. We do a lot of crud style applications with scads of human input forms. Often enough the clients we do this stuff for send the users into the field with bulky laptops equipped with air cards and believe that the problem is solved. In reality though a laptop creates a number of barriers between the person taking the information and the source of the information. Not to mention that sending a person out into the world with a laptop in many cases is painting a bullseye on their backs. Many of our clients have to venture into places in our society where that is a real concern. So the iPad makes for a compelling firm factor to reduce these problems. The company felt like I do and we sprung fir a development platform and some other equipment to employ.

Now I will freely admit that I have had exposure to other development environments in the past, so I was not surprised to find life on the apple side of the river different from our primary development environment of Microsofts visual studio environments. I've used eclipse on various platforms (Windows and Linux) as well as a few eclipse variants, have written code in java, c, basic, c#, visual basic, fortran, COBOL, modula 2, forth, assembler... The list goes on. Most of these efforts had what could only be described as minimal environmental support, you have some form of command line compiler, and an editor of some form where you create your code. You hand the code file to the compiler and cross your fingers. If all goes well you get an executable that you can run on your target platform. I am not really calling these tools into question because don't consider them real environments.

I have worked with visual studio now for years, vs 2003 through the current vs 2010. That is an environment. Now on the apple side of things we have Xcode. It's the tool of choice for the apple crowd targeting iPhones and IPads. Apple has had some time with this product and it's now up to version 3 I believe. It consists of the editor, integrated with the file manager style of application like solution explore in visual studio, the debugger supporting all manner of the things a decent debugger should support as well as a user interface builder to facilitate creation of the human interfaces necessary in a typical business application. So I did not find Xcode to be all that unfamiliar. You will note that I am not even talking about the language, or the os on the target platforms, or even the style of human interfaces supported on these devices. These are different devices so there will be language and style differences I fully expect that. What I did not expect was the relative lack of any form of automated help for such things as simple event connection in code to ui elements on the human interfaces being built.

Case in point....
To create a simple form with a button on it. You might thing that placing a button on your interface, naming it something intelligent would expose it to your code. Well I found that was not the case. To expose it to your code you have to create something called an outlet. This in effect creates the code entity that represents your button. Then you have to physically connect that button to the outlet by dragging a line from the list of outlets to the designer representation of your human interface. Finally you can then switch over to your code window and you have the code representation of your button. Wash, rinse, and repeat, for every element on your human interface. I have not even detailed the complexity of the actually building the outlets themselves or any of those details. I am just dismayed that the tool provided is so weak in this simple area. I guess I have been spoiled by what in comparison a very advanced tool in visual studio. Working in Xcode feels like employing stone knives and bear skins.

So yes the apple fanboys who scoff at visual studio as a tool don't know what a real development environment can be like and yes they are ding dongs.....



- Posted using BlogPress from my iPad