New iPhone Developer Agreement Bans the Use of Adobe’s Flash-to-iPhone Compiler

Damn.

I am this close, and I really mean this close to having a working cross compiler system that can parse Java class files and convert them to Objective C. The goal is to allow me to write a computational module in Java, then recompile it into Objective C. (I have a working iPhone App that takes advantage of this, and I think it’s mostly bug free–it’s just a matter of finding time to package the system up and upload it for folks.)

My goal was never to write a Java layer to the iPhone API or build a framework to replace the API. All I wanted was to write a symbolic math module in Java and use that module on the iPhone.

But between the CoverFlow Design Patent which may require me to take down the FlowCover source kit, and the changes which require all iPhone code to be written in Objective C, C++ and C, I’m not sure if I’m a happy camper.

Does anyone know if I’ll be allowed to use my J2oc library to recompile non-UI libraries to run on the iphone?

Yes, I do mobile development. But right now I’m working for ATTi in Glendale as a software architect–and I’m assembling a team.

What this means for head hunters:

(1) Unless you’re offering six figures and the first digit is a ‘2’ or greater–please don’t bother. It’s not that I’m making that much money at ATTi, it’s that this is probably the amount it will take to convince me to go somewhere else–especially given the fact that I’m a bike ride from work. (Never underestimate the value of a very short commute to a job you love!)

(2) Don’t expect me to send you any references. We’re hiring, and I’d be stupid to forward to you the good resumes, since we need as many good resumes as we can.

(3) Even if you have the temerity to contact me, trying to entice me to jump ship with the promise of a 20% pay cut, and expect me to start forwarding your resumes (that is, expecting me to do your job for you), at least don’t do it using some sort of automated mailer which–when I politely tell you to go away–then forwards me a form letter asking for my resume for processing purposes.

If you’re going to get 10% or 20% of my salary as a bonus for placing me at another company, then do the work necessary to actually earn that bonus. There is nothing in the world more annoying than a lazy and sloppy head hunter…

With the announcement of Apple’s iPad, a reoccurring theme with both of its supporters and its detractors is the fact that the iPad uses the iPhone OS, which is a task-centric (and non-windowing) operating system. For example:

I need to talk to you about computers. …

After defining the “old world” computing experience as “In the Old World, computers are general purpose, do-it-all machines” and the “new world” as “In the New World, computers are task-centric. We are reading email, browsing the web, playing a game, but not all at once.” we find:

Apple is calling the iPad a “third category” between phones and laptops. I am increasingly convinced that this is just to make it palatable to you while everything shifts to New World ideology over the next 10-20 years.

Those who are complaining about the iPad have primarily complained about the lask of multitasking:

What We Didn’t Get: Multitasking, Notifications, …
Understanding Multi-tasking on the iPad: What is it really?
iPad for Business? Not Without Multitasking

Each of these (and I picked the more polite ones) point out the iPad’s lack of multitasking–which the second article correctly notes is two things: the ability to run two applications at once, and the ability to see two applications at once.

It is entirely conceivable that we could have the second type of multitasking without the first: imagine an operating system where a process is only marked as active (and swapped in from storage) when it’s window has the focus.

In both cases, it really boils down to the WIMP (Windows, Icon, Menu, Pointer) interface: the former supporters are looking for the “next new hotness” beyond the WIMP interface, which relieves them of the task of managing multiple windows on their desktop. The latter doesn’t like the fact that a single window at a time prevents us from (for example) browsing the web while writing in a text editor–which forecloses on the possibility of writing notes in an outliner based on research material in a web browser. My common workflow as a developer is to have multiple windows open: one on a documentation site for an API, another on the code I’m writing, and several others on classes I may be using while writing my code.

But I don’t think either camp is correct.

It is clear that the small size of the iPhone makes the screen impossible to use with the second mode of multitasking, where multiple windows coexist from multiple applications at the same time. The iPhone’s design decision was to have only one application running at a time–but each application is required to save it’s complete state as it shuts down as fast as possible, which (when done right) preserves the illusion of multitasking.

A desktop computer, on the other hand, has much greater resources–including screen real estate. It would make absolutely no sense to have one task at a time running in full screen mode on my 30″ display–and there have been plenty of people who have tried to build prototype window managers for Linux which have a “one window visible at a time” model which have utterly failed. If a one-task at a time model was superior to a windowing model for desktop computers, we would have had that model long ago, given people have been experimenting with it since the 1980’s.

The iPad is clearly between the two in size and resources. It could (with its 1024×768 display) easily display a windowing interface. But the decision to do away with a WIMP interface probably has less to do with the death of windowing interfaces (as folks like John Gruber apparently believe), and more to do with product positioning: the iPad is a peripheral device, auxiliary to your main computer, which requires your computer to function. As such, it makes sense to position the iPad as a one-task-at-a-time device like the iPhone (despite the large display) and instead encourage developers to use the large display to provide a more rich one-application-at-a-time experience.

But just because the iPad is a peripheral device doesn’t mean your desktop computer is next with a one-application-at-a-time experience.

It’s clear from Apple’s design sensibilities that a main computer (your laptop, your desktop) is a main device capable of doing several things at once. And a peripheral computing device (the iPhone, iPod Touch, iPad, and iPod) is a one-task-at-a-time device which requires your main computer, but which can be carried along separately after having been docked with your main computer. (I count the iPod here because I believe it started the trend within Apple of considering peripheral devices that do only one thing at a time.)

And it makes complete sense to me that Apple would do this.

If your screen is not big enough to display multiple windows at a time, then why put the infrastructure in place to support multiple windows? (I’m looking at you, Windows Mobile.) If your device is not big enough to display windows, then why put the infrastructure to have multiple windows?

And with the exception of two category of applications (those which play music in the background, like Pandora, or those which periodically poll services like an mail application or IM application), why even support multiple applications at once? Do we really need (as we have in Android) the ability of your game staying resident in memory when you’ve swapped tasks to read your e-mail? (After all, the fact that an application stays resident in memory on Android means your process memory space is limited to 16 megabytes of RAM–as opposed to the 100+ megabytes you get on the iPhone.)

A peripheral computing device which does not support multitasking can also be made with less RAM, less CPU power–since it only needs to do one thing at a time. Because it is peripheral and only supports one thing at a time, applications can be built which take full control of the display without worrying about other applications. And the UI can be streamlined and use a completely different model than the WIMP environment.

If you were expecting the power of a tablet computer (a’la a Lenovo ThinkPad running Windows 7) because you see a tablet computer as a main desktop computer that uses a pen or your finger, and not as a peripheral device–then buy a tablet computer. Lenovo makes very nice laptop computers.

But I’m glad Apple decided to make the iPad a peripheral device: I think it was the right decision to release a new type of device rather than releasing a small notebook computer without a keyboard.

Because that’s what a tablet computer (a’la Lenovo) is: a laptop computer either without a keyboard or with a keyboard that can be tucked away.

I spent the day playing with SmartGWT, and came to the conclusion that I’m not particularly a fan.

Don’t get me wrong: the widgets that it produce are sexy as hell. And if the development work you’re doing fits into SmartGWT’s client/server model and you are willing to use SmartGWT’s server-side libraries to handle network communications, it’s probably the best way to go.

But ours doesn’t. And when our model of obtaining data from the SmartGWT server doesn’t fit in their model, it’s an uphill fight–much harder, for example, than me just building our own custom widget set. (I have the advantage over most that building custom widgets in GWT at this point is pretty straight forward for me, so your ‘cost/benefit’ ratio may vary.)

The fundamental problem I have with SmartGWT is that it is just a thin Java wrapper over the SmartClient system all written in JavaScript. While SmartClient is probably a great piece of software for JavaScript, wrapped for GWT it’s a royal pain in the ass to use. Rather than giving you a rich library of various controls (and perhaps a class hierarchy of grids, each which provides some specialized function or override from the basic component), it provides a very small number of highly customizable set of controls.

And there is where I have problems. If I want a dialog, I don’t open a DialogWindow. I open the Window and set three or four different settings to make the Window look like a dialog. If I want a dynamically updating table that takes its information from a remote server data source, I don’t create an instance of a dynamic table and provide the right interface; instead, I create a Grid and set about a half dozen settings which turn the Grid into a dynamic grid.

Now of course this complaint is stylistic: SmartGWT’s sample app makes it pretty clear how to create a dialog or a dynamic grid–and after a day I had a fairly complete screen with a tree navigation widget, a table, and a modal search window with a dynamically updating table.

But it’s beyond just being stylistic: because the DataSource for SmartGWT is not an interface implemented by a half-dozen different implementations, but a singular object which is configured (through some JavaScript mechanism I don’t grok because the whole point of this exercise is to insulate myself from JavaScript) to be a JSON or an XML/RPC or a whatever interface, creating a new DataSource to feed a dynamic table is not just a matter of creating an instance of the interface and filling in the blanks.

In fact, without diving into the underlying JavaScript, it seems impossible to create a new interface to speak the particular flavor of JSON we’re using. (And while SmartGWT does provide a mechanism to speak JSON, it also defines the specific JSON requests and responses, which doesn’t work for us.)

It is this inflexibility, created because they’ve simply wrapped an existing JavaScript framework with a thin layer of GWT Java stuff, which makes SmartGWT a pain in the ass for me to use–and it’s why I don’t like SmartGWT.

I’ve built web sites using PHP and JSP, with ColdFusion, and now with GWT.

One of the biggest problems I’ve run into with PHP and JSP and ColdFusion is that when you obtain information from a user, you commonly wind up flowing your logic through multiple pages. For example, with a shopping cart and checkout page, you wind up flowing a checkout page via a form (and a JSP or PHP landing page which processes the results) to a second page with a form, which flows (via another JSP or PHP page) to yet another page with a form, and so forth. The business logic winds up being separated across multiple HTML pages. We excuse this dividing up a whole bunch of pages across multiple JSP or PHP landing pages (which process the result of the previous page) by trying to invent all sorts of “MVC” like logic that attempts to justify the fact that we have to serve up four separate screens to do essentially one operation. But we’re still dividing up one operation across four separate screens.

What I like about GWT (and AJAX in general, I suppose–though I’m a Java guy, not a Javascript guy) is that I can now put all of this logic on one page. If I need to make an intermediate transaction to the server to validate some element of the form–so be it; it’s not that big a deal to do quick AJAX request and response.

Some people may claim that this is still not as easy as having an application with everything on one box–after all, if you do have to make an intermediate round-trip, you wind up writing something like “doMyRequestWithResponse(new ResponseInterface() {…});”, with the response coming back some time later. But I find that sort of event-driven programming far easier than the sort of “event-driven” type programming that seems to be offered by earlier frameworks.

Sure, it’s a style thing. But I’m far faster throwing together a bunch of widgets in GWT (and debugging them on the fly in Eclipse–cool!) than I am trying to lay out a bunch of HTML for a flow of forms.

In other words, client-server is far easier than server-driven against a dumb (HTML-driven) display engine.