Tue 25 Jan 2005
Application software development on the Mac? Let me count the ways
Category : Technology/softwareDevelopmentPathsOSX.txt
Last week, I was too busy, but not that busy that I'd miss this discussion at silicon.com. "CIO Jury: Apple irrelant to businesses."
Key CIOs? Top IT users? Sure don't look like it. Read the readers' comments. The tide is turning.
One CIO said, "Proprietary hardware and software, overpriced, few applications." Microsoft is proprietary but that doesn't seem to stop them buying Microsoft. "Few applications"? If they only knew.
I've been wrapping my head, these last few weeks, around all the different ways we can build custom applications on the Mac. So I'm going to do a summary, as much for myself, as for anyone who's reading these pages.
Firstly, where Windows has Visual Basic, the Mac has Real Basic. Or AppleScript Studio. Or FileMaker Pro. These are good for custom applications that don't need to be "professionally" done, but that need to be put together in a hurry, and can be "thrown away" without too much bother once they've done the job or served some need. They don't need a deep investment in technical knowledge, and they're often cobbled together by the more knowledgeable (and committed) among the end users, themselves.
Now, when more "serious" programming is required, we can turn to Java - on both platforms. Java is great for building server-based applications that can run on any hardware platform on earth.
On the Mac, there's a twist. You can build native Mac OS X Cocoa applications using Java. And re-use a lot of your code at the data model end of the MVC (Model-View-Controller) continuum.
Java-Cocoa is eminently do-able. We've mapped out a large enough part of the Java-Cocoa API to be able to help people who want to port code they've already written in Java to the Mac so that it gets a Cocoa front-end.
With Java, too, you can get access to any SQL database engine that you want. From Oracle to MySQL to PostgresSQL. Oh, the choices. Thy name is legion.
There is one problem with Java, though. Java applications are easily de-compiled. Unless you first try to "obfuscate" your code, it's really quite possible to recover the source from the compiled byte-code, thus turning away people who'd rather keep their source code hidden. But obfuscation is really so much extra bother. Java is great for server-end stuff, or for in-house system development (as contrasted with shrink-wrapped applications), or for open-source projects. That is still a lot of areas, as far as productive work goes.
Now, shrink-wrap software developers might want to do their software development using Objective-C. (I know, the term shrink-wrap itself is so 20th Century). No doubt that keeps the selling opportunities within the smaller world of Mac users, but there are compensations in the sense that developing Cocoa applications using Objective-C is fun, and you can do quite involved and seemingly difficult things using relatively little code, and you're, on the whole, super-productive, allowing you to build better quality products with a lot less people.
I used to think there was a deficiency in the area of database access when I switched from Java to Objective-C - that meant losing the ability to use the JDBC database-connectivity mechanism and its bountiful harvest.
That was why we've been trying a few approaches over the last few weeks.
One was to use Objective-C and keep all the database access using Java. But that got too messy.
The solution turned out to be quite simple, actually - at least conceptually. A lot of the relational databases we want to use have C API's - MySQL, SQLite, Oracle. Now, following the example of the MySQL Cocoa Project at sourceforge, we now know that it is possible to build a Cocoa framework that is callable by the rest of the Objective-C code, but hides the actual implementation of the database access. In effect, it does what the JDBC layer does for Java applications.
That turned out to be quite exciting. We could use the Open Source sMySQL framework. Or we could build our own, now that we understand the concept.
What we want to do is to build something that will mirror the JDBC calls so that it'll make it easy to port our Luca Accounting System code from Java to Objective-C.
What's more. SQLite is expected to be included in the next revision of our favourite OS. It's currently quite limited in features compared to MySQL but it's usable, and has a pretty liberal usage policy (none of that copyleft viral stuff that comes with GNU licenses). We've tried modifying the Cocoa framework to work with SQLite. The idea works. My friend, Hai Hwee, has also built a little prototype of Luca that works with an embedded SQLite database. That idea also works.
All these is so that we can avoid having to install a database for the users before they can use our applications.
If we're careful with the design, we can take the inspiration from JDBC and build the Cocoa frameworks so that we can access different SQL databases, just by swopping in and out the relevant Cocoa frameworks, without needing to re-write much of the calling Objective-C code. That will be super-powerful.
Zooming out from the trees and surveying the forest, I believe in the phenomena whereby, when the time is right, many people around the world suddenly see the same possiblities, almost simultaneously. I can't remember what this phenomena is called. But the Internet surely makes this even likelier to happen.
Whatever it is, I expect to see an explosion of useful database-linked software coming out for the Mac. The ingredients are in place. And when it arrives, those top, top CIO's aren't going to know what hit them. And, perhaps, where their jobs had gone.
Posted at 2:55AM UTC | permalink