Tag Archives: SDK

iPhone SDK release rumor roundup

According to an online report, sources say the forthcoming iPhone SDK — coming out this week — will feel the heavy hand of Cupertino. The software feature some heavy constraints by Apple in distribution and in support for hardware peripherals.

Apple announced the SDK release date last week.

The source of the latest speculation came from an iLounge story by Jeremy Horwitz. He said the event will tout enterprise applications for the iPhone but that the actual SDK won’t be released until WWDC in June.

The most controversial aspect of Apple’s SDK plan is its intention to formally approve or deny all SDK-based software releases for its devices. Our sources confirm that Apple will act as a gatekeeper for applications, deciding which are and are not worthy of release, and publishing only approved applications to the iTunes Store; a process that will less resemble the iTunes Store’s massive directory of podcasts than its sale of a limited variety of iPod Games.

While one source saw this as a positive for major developers, suggesting that Apple will be choked by application submissions and forced to give priority to releases from larger companies, another source disagreed, stating that Apple’s current approval processes for third-party products have resulted in lengthy, needless delays. It is unclear whether Apple will need to approve subsequent bug fixes and feature additions to accepted applications, another issue that could clog the approval system and postpone important improvements.

Analyst Ross Rubin at NPD Group called this news “mixed, but again, no surprise.” In his blog, he said the censorship by Apple may ensure a better user experience, while limiting choice.

We’ll have to see how heavy a hand Apple takes here, but it’s probably a safe bet that applications that impinge on potential Apple revenue streams, including Skype, instant messaging programs, and other music store clients, will be excluded. I wouldn’t expect a Windows Live Messenger client any time soon.

Apple is also reportedly limiting developers from connecting hardware peripherals to the iPhone via its dock. Rubin continued:

The most disappointing is that developers won’t be able to access iPod functions via the dock connector, scuttling or at least complicating accessories such as keyboards. This one is somewhat curious as Apple has certainly done well collecting fees for the iPod dock connector in peripherals for older iPods. So at least Apple has some motivation to open this up at some point.

However, developer John Gruber at Daring Fireball said security could be a component of this reported decision.

If it’s true that the dock connector is off-limits, that’s unfortunate, but also not surprising — clearly a big part of what Apple’s been working on in advance of this SDK are ways to sandbox applications for security and control of resources. (Expect “sandbox” to be an oft-repeated word.)

Applications don’t talk directly to hardware ports in Mac OS X, either. That’s the realm of kernel extensions and other device drivers. Apple could, in theory, be on the cusp of announcing a very liberal application SDK but which still wouldn’t allow for third-party hardware drivers. I wouldn’t be surprised if the SDK severely limits direct access to the file system, let alone direct access to the hardware.

A developer I spoke with said there wasn’t much point in speculating on questions driven by a business model, since those can change very quickly. He added that the reason for the lateness of the SDK is that the entire iPhone/iPod Touch mobile strategy (and product) is half-baked. I have to agree with him.

We will see whether Horwitz’s sources are correct about the timing of the SDK. Perhaps there will be more clarity in the summer about the next generation of the iPhone as well.

At the same time, the limitations on third-party hardware connecting with the dock port could be a platform consideration. Apple has a vision in mind for its mobile platform and that doesn’t seem to be one with a lot of input.

The idea is that if mobile users want to create content, then they should use a platform made for creation: the MacBook Air, for example. And if they want to view or listen to content, then they have great choices for that.

I bought a keyboard for my Palm V back in the days. I used it a bit. And I know many people who entered a lot of data on that platform.

Still, I was messaging recently with a former Palm product manager who now is using an iPod Touch.

It’s the first iPod I’ve ever purchased for myself, and ironically I almost never have earbuds connected (nor do I carry them with me). It’s my pocketable email/contacts/calendar/web device, and I’m getting more productive use out of it than I ever did with a Palm device.

Ouch. Another switcher, I guess.

First look: latest Google Android SDK a big improvement

Late last year, we tested a prerelease of the software development kit for Google’s Linux-based Android mobile phone operating system. Although we saw a lot of potential in the platform, there were a number of serious flaws in both the software and the underlying development process. Both have seen noteworthy improvement since our original tests.

The developers announced the availability of m5-rc14 this week, a new Android prerelease that addresses many issues and brings a significant user interface overhaul to the operating system. I put the new version of the SDK and Eclipse plug-in to the test on my Ubuntu desktop computer to see how it compares to the version that we tested in December.

As we noted in our previous review, one of the significant strengths of Android in the area of third-party development is the ease of installing the SDK. That advantage has been retained, but I ran into a minor snag with dependencies for the Android Eclipse plug-in. Ubuntu 7.10 users who wish to use the Android plug-in might need to download the latest version of Eclipse in order to do so. If you have a standard version of Eclipse, the installation process for Android and the plug-in is relatively straightforward and can be done in a matter of minutes.

Twittering away on Android

My first test after installing the new SDK was attempting to compile and run the experimental Twitter client that I developed for my previous article. This initially failed because of alterations to the Android XML manifest file format, but it was very easy to make the requisite changes. You can refer to the Android manifest documentation page to see how the current manifest file should look.

In the source code for the program itself, the only element of the Android API used by my Twitter client that no longer works is the now-defunct EmboldenedSpan object. I simply changed it to a StyleSpan object with a Typeface.BOLD paramater. All things considered, it wasn’t all that painful to get my simple application working with the new version of the SDK, but developers with more complex projects might have a different experience. Google’s documentation includes an overview of the API changes between the m3 and m5 releases. In general, the documentation seems to be a bit better all across the board.

Squashing bugs and polishing the UI

In our previous article about Android, we voiced sharp criticism of Google for failing to provide a public bug tracking system, an omission that greatly impeded the process of providing feedback. Google finally resolved that problem last month when it announced that it would be using the issue tracker at the Android code.google.com page. This is a very positive sign that Google is taking the needs of the Android third-party developer community more seriously.

The user interface of the Android platform also got a big boost with this release. The home screen menu system is a bit more finger-friendly now and still retains solid usability with navigation buttons. We noted in our previous article that Android has a highly hardware-neutral design that reflects Google’s intention to make it support a variety of different kinds of handsets. The user interface changes generally seem consistent with that approach. One oddity is a slide-down panel that displays notifications. It can be dragged from the top of the screen, but I couldn’t find a way to activate it with a button. Overall, the new home screen menu feels more functional and less cramped than its predecessor, but is a bit less stylish.

One very noticeable change in the Android user interface is the addition of transition animations. The animations show up in many places throughout the system, generally when windows, dialogs, and menus appear. They are very subtle and add some additional elegance without becoming a distraction.

I tested several of the applications that come with the SDK, including the mapping program, the contact book, and the web browser. I also tested the experimental Google Talk chat integration feature. I was able to connect to Google Talk and receive messages, which are displayed as items on the notification panel. The performance and usability of the bundled applications is pretty decent.

The interface feels more complete now, but there are still some holes. For instance, the home screen menu offers an option for changing the background wallpaper, but selecting it only displays a dialog stating that the feature isn’t available yet. There is obviously still work to be done before the interface is ready for use on a phone, but it is definitely improving at a reasonable pace.

It seems like the initial prerelease was primarily to let developers see what the platform would offer, and this release is more about addressing the needs that emerged in the process. Google is clearly giving due consideration to criticisms of Android and resolving problems identified by third-party developers. There are still technical issues to resolve, but Google has now demonstrated enough responsiveness to developer demands to justify giving the company the benefit of the doubt. This second look at the platform and the development ecosystem has boosted my confidence in the endeavor and given me reason to be optimistic about Android’s prospects.

[via arstechnica]