 |
 |
||
|
Currently writing about iPhone Development, GWT, Ajax, Leopard, and Java.
iPhone Software Development: No Anger Here
Monday, March 10, 2008
I'd like to follow up on my initial impressions of the iPhone SDK. Overall, I think Apple did a great job with the SDK, and released a powerful, comprehensive environment for developers. I brought up a few minor criticisms in my post, but concluded with:
Now, back to happily writing code with the iPhone SDK...
"Setting aside these concerns, I'm very impressed by the iPhone SDK. It builds on the strong foundation of OS X, while integrating with the multi-touch and mobile capabilities of the iPhone. You can tell a great deal of work went into preserving the Mac experience on a device lacking in memory & computing horsepower."The Internet being the Internet, I shouldn't have been surprised to see my post quoted in an article by Alexander Wolfe of InformationWeek entitled "iPhone SDK Developers Angry at Apple's Tight Control." A few points of clarification:
- I'm not angry at Apple or the SDK. Thrilled, actually. I can't wait to release native applications for the iPhone and iPod touch.
- Access to calendar appointments & media would be nice, and I hope it's added in a future version. (As Fraser Speirs notes, this is the beta SDK.) After perusing the technical docs, I thought it was a noticable omission and worth pointing out. It probably wasn't worth the "glaring" adjective, but I surely wasn't suggesting Apple keeps all the good stuff to itself.
- Access to the phone & SMS functionality would be great, but is problematic from a security/carrier standpoint. I made that point in my post, and Wolfe included it. I was actually impressed to hear Steve Jobs say that a 3rd party VOIP app would be allowed over WiFi.
Now, back to happily writing code with the iPhone SDK...
Visiting Aspen: A Trip Through the iPhone SDK
Saturday, March 08, 2008
The real iPhone SDK has arrived. While I enjoyed developing iPhone web apps (and have another one in the works), software developers like myself were waiting for something beefier, and Apple delivered a heifer. The previous web-only "human interface guidelines" weighed in at a measy 54 pages. The new guidelines are double that size, and serve as an addendum to the 200 page iPhone OS Programming Guide. I've been plowing through the docs and tools to learn about the new SDK and v1.2 of the iPhone software, codenamed Aspen. It's been a fun trip.
The Good
Apple delivered an architecture familiar to any OS X developer: Objective-C, Cocoa, and lots of Core* frameworks. Built on top of a Mach kernel, the iPhone OS contains all the basics like threading, networking, and file-system access. The gaming industry will be happy with support for OpenGL ES (embedded systems), 3D audio, and access to the accelerometer. For business software developers, the exciting technologies are SQLite (a lightweight, embedded database that is taking over the world) and XML parsing via libXML2 and libxslt.
But in my mind, the real All-Stars of the SDK are:
- Full access to multi-touch events via the Cocoa touch framework
- Location-based services (triangulation and bonjour)
- System-wide access to address book contacts and photo albums
The Bad
The biggest letdown is that Apple didn't expand this mobile platform far enough. While the shared address book contacts and photo albums are great, there are a few glaring things that developers can't access:
- appointments from the Calendar app
- music or videos from the iPod app
- phone or SMS functionality
For an entirely different reason, there's no way to compete with Apple's iPhone Mail app. Applications can register custom URLs to launch their application. For example, my Flickr viewing app could register "flickr". If a user clicked on the URL "flickr:user123" from another app, my Flickr app would launch and display photos from user123. According to the iPhone OS Programming Guide, URL conflicts between 3rd party apps are undefined: so if two apps register "flickr", there's no guarantee who wins. However, if a 3rd party application tries to register a URL identical to one defined by Apple (like "mail" or "tel"), the Apple-provided application always wins. Here's hoping the rumors are right about Apple improving the Mail app, since there's no getting rid of it.
* Technically you could design a new iPod app with all the media enclosed in its sandbox, but without iTunes integration you'd be DOA.
The Controversial
The iPhone SDK's first big, public firestorm arose over AppStore and Apple's cut. Native iPhone applications can only be distributed by Apple, and they take 30% of the revenue for their efforts. I'm reserving judgment on this one: when John Siracusa and John Carmack take opposing sides of an issue, I'll wait on the sidelines to see how it plays out.
However, my immediate concern with AppStore is not with the 30% cut, but with the iPhone Developer Program. In order to deploy and test an application on an iPhone, you have to become a member of the iPhone Developer Program and pay $99. Like the thousands of developers hammering the ADC site on Thursday, I signed up for the program and gladly offered to pay. But alas, I just got a message thanking me for my application and promising to get back to me in the future. The fine print says the program "will initially be available to a limited number of developers in the U.S. and will expand to other countries in the coming months." Until my membership gets approved, I can only test my iPhone applications via the software emulator, not on my actual iPhone. I'm sure they're deluged with applications and I don't mind waiting in line with everyone else, but I hope it gets processed in weeks, not months. Please Apple, take my money! (They're usually so good at that...)
As we get closer to the official SDK launch in June, it will be interesting to see how long it takes from developer submission to AppStore appearance. What will the screening and approval process be like? When Microsoft started the XBox Arcade service, they were deluged with ideas and submissions from independent developers. It took them months to work through the backlog, with the bigger companies usually getting preferred treatment. I anticipate a similar deluge from indy iPhone developers, and I hope Apple has the resources to handle it when June rolls around. If not, expect another round of controversy
The Apple Polish
Setting aside these concerns, I'm very impressed by the iPhone SDK. It builds on the strong foundation of OS X, while integrating with the multi-touch and mobile capabilities of the iPhone. You can tell a great deal of work went into preserving the Mac experience on a device lacking in memory & computing horsepower.
My favorite nugget is that developers can include an application launch image in their distribution. Quoting from the programming guide, this image "should closely resemble the application’s initial user interface; the system displays the launch image before an application is ready to display its user interface, giving the impression of a quick launch." Even when it's computationally impossible, Apple found a way to make apps feel snappy.
GWT Leopard Fixed
Wednesday, November 07, 2007
Google Web Toolkit now works on Mac OS 10.5. Google's team posted a link to the unofficial test build of GWT 1.4.61 in the issue tracker (comment #46):
http://code.google.com/p/google-web-toolkit/issues/detail?id=1792#c46
According to the post, this is not an official release and is still under testing, so report any problems to GWT Issue 1792. I've tested the patch on Leopard with the Hello World, Kitchen Sink, and my GWTFlow applications. Everything works great. I had no problems launching GWT applications via shell scripts or debugging them from Eclipse. Other users report similar successes with IntelliJ JetBrains and Cypal Studio.
If you're interested in the gory details of the GWT/Leopard incompatibilities, view the history in the issue notes. The first two problems stemmed from changes in Apple's AWT subsystem initialization and Webkit's Carbon interop. The third problem was a ClassLoader bug in Leopard's 1.5 JVM when starting Java with -XstartOnFirstThread.
Many thanks to Google's Kelly Norton* and members of the GWT community for tracking this issue down.
*If you want to thank Kelly in person and hear some in-depth talks on GWT and Ajax, register for the upcoming Google Web Toolkit Conference (Dec 3-6, 2007 in San Francisco). Take $100 off registration with discount code GW-ADAM.
http://code.google.com/p/google-web-toolkit/issues/detail?id=1792#c46
According to the post, this is not an official release and is still under testing, so report any problems to GWT Issue 1792. I've tested the patch on Leopard with the Hello World, Kitchen Sink, and my GWTFlow applications. Everything works great. I had no problems launching GWT applications via shell scripts or debugging them from Eclipse. Other users report similar successes with IntelliJ JetBrains and Cypal Studio.If you're interested in the gory details of the GWT/Leopard incompatibilities, view the history in the issue notes. The first two problems stemmed from changes in Apple's AWT subsystem initialization and Webkit's Carbon interop. The third problem was a ClassLoader bug in Leopard's 1.5 JVM when starting Java with -XstartOnFirstThread.
Many thanks to Google's Kelly Norton* and members of the GWT community for tracking this issue down.
*If you want to thank Kelly in person and hear some in-depth talks on GWT and Ajax, register for the upcoming Google Web Toolkit Conference (Dec 3-6, 2007 in San Francisco). Take $100 off registration with discount code GW-ADAM.
Leopard vs Vista: Duke University Sees More Interest in Mac OS 10.5 Upgrades
Monday, November 05, 2007
Today's Duke University Chronicle reports a problem with Mac OS 10.5 and the campus ePrint system. It's a pretty standard story: ePrint is incompatible with the new Mac operating system, and the Duke IT department has developed a workaround until the vendor can patch their software.Interestingly, Duke faced the same ePrint incompatibility when Microsoft released Vista. This creates a controlled environment for gauging interest in Vista vs Leopard: if students are upgrading to a new OS, they'll ask for help getting ePrint to work. According to Duke OIT manager Kevin Davis, Leopard is winning:
"We're actually seeing more concerns about Leopard than we did from Vista, which I suspect is because there is much more active interest around Leopard than we saw with Vista's release."Like other schools, Duke is seeing an increase in students choosing Macs. It's encouraging to see the enthusiasm from the student body in upgrading to Leopard. But if I was back in school and had to worry about term papers and tests, I'd probably wait until Winter Break to upgrade...
DTrace: Why Java 6 on Leopard Matters
Saturday, November 03, 2007
In all the hullabaloo and developer discontent about Mac OS 10.5 shipping with Java 1.5, one question has been frequently overlooked: why do we need Java 6? Why is Java 1.6 so much better than Java 1.5?
The standard answer is performance. And it's true, Java 6 smokes Java 5, especially in GUI applications. But I spend most of my time in the server world, so the Java 6 performance improvements don't impact my life that much. There are some other nice-to-haves like XML binding, better exception logging, and improved web service support - but nothing on the scale of the Java 1.4->1.5 changes.
So why does Java 6 on Leopard Matter?
DTrace!
DTrace is a kernel debugging framework created by Sun. Apple built DTrace support into Leopard and created a Garageband-like GUI around it: Instruments, aka Xray. Apple is pretty proud of DTrace (5 of Leopard's 300 new features are DTrace related), and rightfully so. The developer community is also excited about it - in his seminal Mac OS 10.5 review, John Siracusa called it "indistinguishable from magic" and said DTrace "can't help but lead to better, faster, more stable applications."
For an in depth description of DTrace, I highly recommend you read Siracusa's review, Sun's page, or the developers' blogs. If you're short on time, here's the poor man's guide to DTrace:
How developers monitored & debugged applications before DTrace:
How developers monitor & debug applications after DTrace:
DTrace and Java 6
So what does DTrace have to do with Java? DTrace allows developers to get a top-to-bottom view of application activity and see what happens across the entire stack. You can look "beneath the JVM" and understand how your application interacts with the kernel. Very cool stuff.
Unfortunately, DTrace probes are only available in Java 6 - it can't be hooked up to Java 5, which ships with Leopard. So there's this incredibly useful tool that developers are dying to use for debugging Java applications. It's sitting there in the terminal, taunting techies. But everytime they type "dtrace -l", 21,527 probes scroll by without a hotspot in sight.
Performance & parity are all great reasons to want Java 6 on Leopard, but I'm looking forward to DTrace support.
The standard answer is performance. And it's true, Java 6 smokes Java 5, especially in GUI applications. But I spend most of my time in the server world, so the Java 6 performance improvements don't impact my life that much. There are some other nice-to-haves like XML binding, better exception logging, and improved web service support - but nothing on the scale of the Java 1.4->1.5 changes.
So why does Java 6 on Leopard Matter?
DTrace!
DTrace is a kernel debugging framework created by Sun. Apple built DTrace support into Leopard and created a Garageband-like GUI around it: Instruments, aka Xray. Apple is pretty proud of DTrace (5 of Leopard's 300 new features are DTrace related), and rightfully so. The developer community is also excited about it - in his seminal Mac OS 10.5 review, John Siracusa called it "indistinguishable from magic" and said DTrace "can't help but lead to better, faster, more stable applications."
For an in depth description of DTrace, I highly recommend you read Siracusa's review, Sun's page, or the developers' blogs. If you're short on time, here's the poor man's guide to DTrace:
How developers monitored & debugged applications before DTrace:
How developers monitor & debug applications after DTrace:
DTrace and Java 6
So what does DTrace have to do with Java? DTrace allows developers to get a top-to-bottom view of application activity and see what happens across the entire stack. You can look "beneath the JVM" and understand how your application interacts with the kernel. Very cool stuff.
Unfortunately, DTrace probes are only available in Java 6 - it can't be hooked up to Java 5, which ships with Leopard. So there's this incredibly useful tool that developers are dying to use for debugging Java applications. It's sitting there in the terminal, taunting techies. But everytime they type "dtrace -l", 21,527 probes scroll by without a hotspot in sight.
Performance & parity are all great reasons to want Java 6 on Leopard, but I'm looking forward to DTrace support.
Java 6 on Leopard: Developer Discontent
Tuesday, October 30, 2007
In my Leopard First Impressions post, I mentioned that Mac OS X 10.5 ships with Java 5, not Java 6. Sun released Java 6 almost a year ago, so this is generating quite a bit of angst in the Java developer community. Is Apple abandoning Java? Is it time to install Ubuntu? Should Duke sell his iPods?
In short, no. The same thing happened in 2003: Apple shipped OS X Panther with the old version of Java (1.3). A few weeks later, however, Apple released the latest Java (1.4.1) via a software update. I'd expect the same thing to happen in this case. Eric Burke created a nice timeline showing the history of Mac OS X releases, and he agrees: it's not time to panic, Java 1.6 is coming.
From a stroll through the Java developer blogs and mailing lists, there are roughly three areas of contention:
1. Java versions on Mac are always late
2. Steve Jobs said nobody uses Java anymore
3. Apple is too secretive towards developers
All are legitimate and longstanding critiques, but none have stopped me from developing Java on a Mac these past few years (and enjoying it!). Yes, Apple takes some time to release the latest & greatest versions - but coming from the world of application servers & corporate software, I'm used to being a version or two behind. Developing on Windows or Linux would let me use Java 6 right now, but I'm not willing to put up with the trade-offs.
From a consumer standpoint, I still love the fact that a modern version of Java is shipped with every copy of OS X and integrated with the software update system. It might be a version or two behind, but it's still light years ahead of the Windows world - I shudder to think what JRE is on grandma's Acer.
The Steve Jobs comment was in the context of supporting Java applets on the iPhone. Applets have been losing to Flash and Ajax for years. Server-side Java development, however, is alive and thriving - and I'm pretty sure they're aware of that in Cupertino.
The last issue, secrecy, is par for course with Apple. I haven't been following the release of information too closely this time. In general, though, most communication is reserved for ADC members and covered under a strict NDA. Apple & Microsoft take different approaches with developers: Apple gives away XCode and charges for information, while Microsoft gives away information and charges for Visual Studio. (But really, who's keynote would you rather watch?)
Leopard is a great developer's environment right now. When Java 6 is released, it will get even better.
In short, no. The same thing happened in 2003: Apple shipped OS X Panther with the old version of Java (1.3). A few weeks later, however, Apple released the latest Java (1.4.1) via a software update. I'd expect the same thing to happen in this case. Eric Burke created a nice timeline showing the history of Mac OS X releases, and he agrees: it's not time to panic, Java 1.6 is coming.
From a stroll through the Java developer blogs and mailing lists, there are roughly three areas of contention:
1. Java versions on Mac are always late
2. Steve Jobs said nobody uses Java anymore
3. Apple is too secretive towards developers
All are legitimate and longstanding critiques, but none have stopped me from developing Java on a Mac these past few years (and enjoying it!). Yes, Apple takes some time to release the latest & greatest versions - but coming from the world of application servers & corporate software, I'm used to being a version or two behind. Developing on Windows or Linux would let me use Java 6 right now, but I'm not willing to put up with the trade-offs.
From a consumer standpoint, I still love the fact that a modern version of Java is shipped with every copy of OS X and integrated with the software update system. It might be a version or two behind, but it's still light years ahead of the Windows world - I shudder to think what JRE is on grandma's Acer.
The Steve Jobs comment was in the context of supporting Java applets on the iPhone. Applets have been losing to Flash and Ajax for years. Server-side Java development, however, is alive and thriving - and I'm pretty sure they're aware of that in Cupertino.
The last issue, secrecy, is par for course with Apple. I haven't been following the release of information too closely this time. In general, though, most communication is reserved for ADC members and covered under a strict NDA. Apple & Microsoft take different approaches with developers: Apple gives away XCode and charges for information, while Microsoft gives away information and charges for Visual Studio. (But really, who's keynote would you rather watch?)
Leopard is a great developer's environment right now. When Java 6 is released, it will get even better.
Leopard: First Impressions, Java, GWT
Saturday, October 27, 2007
I had the official Leopard release up & running on my laptop by 8:00pm EST. Short of an early FedEx delivery or mugging Walt Mossberg, I don' t think I could have done it much faster. Install was a breeze - click a few buttons, grab some dinner, and come back to a star-covered desktop.
Leopard First Impressions
Three features immediately help my productivity: Quick Look, Spaces, and Tabbed Terminal. I spent half an hour zipping through old files using Quick Look, finding documents and spreadsheets I'd completely forgotten about. Spaces & Tabbed Terminal are a developer's best friend (although I kept tripping the Spaces hot keys when RDCing to a Windows box). I'm still working on my optimal desktop configuration, with 2x2 currently in the lead.
Network sharing is great, except for a slight lag when populating the Shared list. This causes Places to appear in one spot then jump down 40 pixels. This happens in open & save dialogs, resulting in some whack-a-mole mouse action. (Anyone know how to move Places above Shared?)
Other personal highlights: faster Safari, faster Spotlight (hallelujah), unified UI. The animated iChat backgrounds will make for a nice demo to non-Mac friends. The transparent top bar is ridiculous and the tiny blue lights in the dock are hard to see, but I'll gladly put up with them to get all the other improvements.
Java on Leopard
Most of my third party tools worked like a charm: Eclipse, Smultron, Fugu, RDC. I had no problems upgrading XCode/Interface Builder. Unlike previous releases, the developer tool install does not include the Java Developer Documentation - you now have to download it separately. Log in to the ADC Member Site (free memberships work), click Downloads, then select Java for Mac OS X 10.5 Documentation. As reported earlier, Leopard ships with Java 5 (build 1.5.0_13-b05-237); hopefully they'll release Java 6 soon as a software update.
Google Web Toolkit on Leopard
Unfortunately, GWT on Leopard has some issues. If you start hosted mode, it either exits immediately or brings up the window then quickly crashes with this stack trace:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at apple.awt.CGraphicsEnvironment.displayChanged(CGraphicsEnvironment.java:65)
at apple.awt.CToolkit$4.run(CToolkit.java:1259)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)...
Update 11/6/07: GWT now works on Leopard! View my latest post for more information and links to a test build.
Shrook
(Updated 10/28/07: Shrook is now compatible with Leopard!)
