Lately, I’ve been receiving, more and more, pleas from developers looking for ways to get around their legal departments when it comes to using open source technology for their company’s app. “The suits don’t get it.”, “My lawyer is paranoid.”, “Our legal team doesn’t want the risk!”, “Do you sell IP protection?” Um no.

Quite frankly, my heart goes out to these poor developers that have to swallow their pride and ask their peers these lame questions. How do you tell a lawyer that he doesn’t know what he’s talking about?

(more…)

Last week was the latest installment of the Ajax Experience in San Francisco. More low-key than last year’s conference, I left the main corridor only to give two talks, one on Dojo and one on Comet. I met a lot of people I had been wanting to meet for a while, and caught up with most of the usual suspects. Interest in Dojo 0.9 was strong, and there were a lot of good questions about Comet, as well as a great discussion at the end of the Comet talk with Greg Wilkins and Joe Walker in the crowd and participating.

If there was one point to take away from the conference, it was that everyone there has now bought into Ajax. Last year’s most frequently asked question, “What about accessibility?”, has now been answered in great detail by Dojo and Dijit. I believe this year’s theme was all about performance. Everyone has had another year to work with web apps, expectations are higher, and everyone wants to do more for less. This isn’t a great shock or surprise, but the comments from people attending the Dojo 0.9 talk tell me that the improvements we have made can’t come fast enough.

One of the more exciting projects coming out of the Dojo Toolkit is DojoX Graphics–a cross-browser API for creating vector graphics. Over the next few months, I’ll be writing a series of tutorials showing you how you can use DojoX Graphics to accomplish a number of tasks–starting with showing you how to soften a polyline like this:

…to this……using cubic bezier curve segments.

(more…)

Many people are perplexed by the absence of instant messaging on the iPhone. Apple has done great things for SMS with their ichat styled interface. Unfortunately they stopped short of providing a seamless IM experience. Hopefully Apple will add these features in a future software update.

The iPhoneDevCamp in San Francisco last weekend saw several groups working to fill the IM gap by building iPhone compatible IM web applications. I spent part of my time there revising the existing cometd chat app to work well on the the iPhone. Comet’s long-running http connections are ideally suited for chat apps as it provides very low latency. We had already tested cometd on the iPhone, so I was encouraged about the ease of porting the existing chat demo.

(more…)

SitePen and Dojo are proud to announce a new beta release of Dojo Offline. This release has a huge amount of exciting new functionality, including a full port to Google Gears, a port from Dojo 0.4 to 0.9, and more.

(more…)

I was never a fan of the way Dojo 0.4.x handled debugging. Sans an available console, the debugger would dump text all over the page. Dojo 0.9 no longer uses dojo.debug in favor of Firebug’s world class debugger. Because Dojo 0.4.x wrapped, extended, and essentially hid Firebug’s console, some 0.9 adopters may be even wonder what console.log is. When porting to 0.9 and doing the obligatory fishing: where did that function go, what do they call it, and is it still there?… inevitably, the first function you look for is dojo.debug, and you come across the console object in firebug.js. Dojo.firebug is a port of Firebug Lite. What this means is that if you are viewing your app on a browser without Firebug, not only will you not get runtime errors, but you’ll get a debugger… actually a console! No more messy text all over my page. Just another reason why Dojo rocks.

(more…)

Well, the plan was to go through every type of input object, button, and image in Safari on my shiny new iPhone and make notes about what functions were available, how event handling works, and any other fun little goodies that came along. I started out with the good old text input box, and after an hour or two of executing functions in all sorts of different orders and being seriously freaked out a couple of times, I’m worried about the pretty severe limitations of one of the most basic widgets of the web browser:

• When the input does not have “virtual keyboard” focus, calling its focus function calls its onfocus function, but does not give the input “virtual keyboard” focus
• When the input does not have “virtual keyboard” focus, but you’ve called its focus function, calling its blur function will call its onblur function. When the input does have “virtual keyboard” focus, calling its blur function does absolutely nothing (which breaks some scripts that prevent input by blurring on focus).
• When the input does not have “virtual keyboard” focus, calling its select function does nothing, until you scroll or zoom in on the page, at which point it calls both its onfocus and onblur functions. When the input does have “virtual keyboard” focus, calling its select function does absolutely nothing.
• Calling its click function calls its onclick function as expected.
• Selecting an input box fires: onfocus, onmouseover, onmousedown, onmouseup, onclick, and sometimes onmousemove
• Selecting the next item on the page fires: onblur, and (conditionally) onchange, but still no key events.
• Clicking the “Done” button in the “virtual keyboard” fires: onblur, and (conditionally) onchange, but still no key events.
• The only key that registers any key events is the return key.

Apple’s iPhone web application development tips are yet the latest example of blurring the lines between the power of the web and the desktop. The example that drives this point home the most is Google Maps:

Google maps links open a built-in Google client rather than making a connection through the public website.

On the desktop, we’re seeing Dojo Offline and Google Gears, as well as more proprietary offerings such as Adobe’s AIR and Microsoft’s Silverlight. One interesting thing coming from Apple that has not received much mention is WebKit and Cocoa bindings, including JavaScript bindings. Soon we’ll be able to use open web standards to create native Mac apps!

The proliferation of JavaScript, HTML, and CSS is rapidly spreading to every area of software development, because open web standards are powerful and relatively easy to comprehend.

Safari on the iPhone does not currently have support for SVG. Safari 3 beta on Mac and Windows is currently the best browser on the planet for SVG performance, so this is a somewhat disappointing omission. We are hopeful that by the end of the year, the iPhone will receive the Safari 3 upgrade, and along with that native support for SVG. For now, we’ll have to wait on dynamic charting and drawing tools due to no SVG and the lack of mousemove event handlers.

It’s been widely reported that Drag-n-drop on the JavaScript layer is going to be a significant challenge. The canonical fun with magnets demo for Cometd relies on Drag-n-Drop for moving magnets around, so that part of the demo is currently a no-op. That said, the rest of the app seems to work pretty well, with the built in version of Safari not skipping a beat in receiving events and moving items on the screen in response to those events. The speed performance is obviously much better with the wifi connection, but we are still having success over the EDGE network as well. Bottom line: Cometd appears to work out of the box on the iPhone!

P.S.: Does anyone know how to take a screenshot with the iPhone itself rather than using a digital camera?

Update: There’s now screenshot utility for the iPhone.