Massively has a good look at an iPhone app that's a must-have for players of the space-based multiplayer EVE Online -- Capsuleer 2.0 isn't an actual client, but like the desktop app EVEMon, it allows you to monitor and track your EVE pilots from outside the game. It's also got skill queues built in (unlike other MMOs, EVE allows you to have your pilots level even while you're away from the game, so most of the strategy in leveling actually comes in choosing the next skill to work towards), a skill library, more pilot details, and even a mini-RSS feeder, incorporating a few popular blogs from around the EVE blogosphere.

The two developers of the app tell Massively that their biggest issues in developing the app were mostly by way of the limits CCP (the company behind EVE Online) places on what third-party apps can do with their info.. Most of the things they can't do are built into the game itself, and so it makes sense that a certain amount of functionality can't leave the game client (or else people might never log into the game). The app is currently free in the App Store right now, and the devs aim to keep it that way, but just recently added ads to the mix from the game's official magazine to cover server costs and bandwidth.

Finally, they say they're excited about the possibilities with iPhone 3.0 -- notifications are mentioned, and of course it would be cool to get a popup reminder every time a pilot is about to hit a skill. They're also working on a way to provide stats about the ingame Faction Warfare. Sounds cool -- EVE Tracker is still another possibility if you want to follow your EVE progress on the iPhone, but it looks like Capsuleer adds even more innovation to the mix.

When I shared an AppleScript last week which created randomized signatures using TextExpander, I promised to revisit it when the iheartquotes.com API started working again. It's working right now, but it seems to go up and down; check this link before you try the script and make sure you get a quote, not an error message.

As before, when used with a TextExpander snippet set to the AppleScript type, this script will provide a random quote, this time pulling it from the Internet rather than our own list. The script is essentially the same, so I'm only going to explain the part which changed; visit the previous article for a rundown on the rest:

set _date to do shell script ¬
 "date +'Sent on %A, %b %d at %l:%M %p'|tr -s ' '"

 set _quote to ""

 try

 set _quote to do shell script "curl -s \\
 'http://www.iheartquotes.com/api/v1/random?source=macintosh&max_lines=4'"

 set {astid, AppleScript's text item delimiters} ¬
 to {AppleScript's text item delimiters, return}
 set _quote to paragraphs 1 through -3 of _quote as string
 set AppleScript's text item delimiters to astid

 end try

 set _out to "
 -Brett

 " & _date & "
 ________________________________
 Brett Terpstra | myemailaddress@mywebsite.com
 The Unofficial Apple Weblog | http://www.tuaw.com

 " & _quote

 return _out

The curl call

Here's the part which makes this more interesting than it was before:

set _quote to do shell script "curl -s \\
 'http://www.iheartquotes.com/api/v1/random?source=macintosh&max_lines=4'"

First off, that really should be all one line, but is split here for formatting purposes. You can remove the double backslash (\\) and merge the lines together if you like. What this does is use AppleScript's ability to run shell scripts (Unix commands) to make a curl call to retrieve a response from the iheartquotes API. Note the "try" statement surrounding that section; it will just return our regular signature without the quote if anything goes wrong. If it gets a response, it stores it in a variable (_quote) and then trims off the last line, like this:

set {astid, AppleScript's text item delimiters} ¬
 to {AppleScript's text item delimiters, return}
 set _quote to paragraphs 1 through -3 of _quote as string
 set AppleScript's text item delimiters to astid

The first two lines (actually one line) are shorthand for setting "AppleScript's text item delimiters" -- the character that AppleScript uses to separate text items in a block of text -- to the return character and store the current text item delimiter in a variable so we can restore it with the last line. Using the paragraphs command, which automatically uses the return key to separate paragraphs, we turn the quote into a list of paragraphs, starting with the first and ending with the third from last. This is because the last two "paragraphs" are always an empty line and a permalink (even if you use the API's parameters to turn off the permalink). The last part of that line, "as string", is where the text item delimiters come into play, putting the list items back together with a return after each one, reconstructing the original formatting.

Note: You could do the same thing by adding |sed -n '$!p' to the end of the do shell script line, right before the last double quote. I suppose you might as well, as long as you're dipping out to the shell anyway ...

From there it's the same as before, just building a final output string from the pieces we've created. This method provides a much wider variety of randomized signatures than constructing your own list by making use of a small section of the wide array of data on the interwebs. The use of curl in an AppleScript can open a lot of possibilities, such as posting to Twitter in various ways. or shortening urls on the fly. Have fun.

TimeXchange is a relatively new addition to the pile of available online time-tracking applications. Its current incarnation on the web is pretty standard, covering bases like multiple time entry, report and invoice creation, and Quickbooks integration. The developers have been fielding a lot of feature requests ... more than they have the capacity to handle. Their solution: an API, announced today, which will allow third-party developers to create applications, mashups and integrations with other tools.

A version of TimeXchange is already available for the iPhone, in both a $2.99US version and a free Lite version (iTunes links). The mobile applications make use of a private API, and demonstrate only a tiny bit of what could be accomplished with the new API. The "hooks" in the API are to be exposed as needed to developers, and custom hooks can be created to meet developers' needs. Beyond task management and mobile time/expense tracking, the API provides the opportunity for industry-specific applications, language localization, multiple currencies, and corporate branding. With no license restrictions, developers can customize an application with TimeXchange as its engine and keep 100% of the profits made on distribution.

The idea of opening an API to third-party development is not a novel one. Harvest (my current time-tracking app) and some others already provide access to an API. Tickspot, which also provides an API, has just released an iPhone app (iTunes link) as well. It's an excellent trend, and things such as desktop widgets, Basecamp integration and mashups allowing time tracking through Twitter and IM have become possible. By providing custom-built API's to developers, TimeXchange hopes to be able to meet any need which might come up.

TimeXchange provides an aggressive pricing scheme and a unique model. For a one-time fee of $19.95US, you get a lifetime membership. There are monthly and yearly payment plans, but a one-time fee is a pretty sweet deal. The major difference in models is that TimeXchange uses a peer-to-peer mentality, rather than a company setup. Every user has an account, and users can invite other users to join a project. It might not be a great model for larger companies, but for a freelancer, contractor or small company, this can be an ideal situation, given that the members of the team change frequently from project to project. Today's API news will hopefully spark some creative development on the Mac, iPhone and web to take advantage of the engine. Interested developers can visit the affiliate page for more information. To check out the service itself, just visit TimeXchange.net.

On last Sunday's talkcast, we all speculated on the situation behind Google's voice app using undocumented API calls on the iPhone. Either Google just went and did it themselves, or they got special permission from Apple to dive into places that most developers aren't really supposed to go. And it turns out that the former is true: Google says to CNET that, yeah, they used undocumented APIs. What are you going to do about it?

They're not using private frameworks at all, and apparently Apple isn't even part of the situation -- Google's engineers just jumped on some extra, undocumented features in the API. The danger here for most devs, apparently, is that if Apple changes something in the undocumented stuff, it'll break the app. But Google seems unconcerned -- they have the resources, apparently, to change things if needed.

As for Apple themselves, my guess is they'll do what they've been doing: stay hands-off until a smaller developer breaks something really important. If anyone is going to get special permission to bend the rules, it'll be Google, and given that Apple's API agreements are something they can choose to enforce (or not) as they see fit, Google likely has nothing to worry about.

Evernote, a versatile (and oft-mentioned) note-taking application for Mac and iPhone (as well as Windows and other mobile platforms), has recently opened up a Service API. This comes as an intriguing extension to the basic AppleScript support found in the 1.1.5 release, and opens up the possibility of creating homegrown interfaces ranging from simple calendar/todo managers to "thick" clients which can manipulate the entire collection of Evernote data.

The AppleScript library itself is quite useful, albeit slightly limiting. You can retrieve lists of notes based on searches, create new notebooks and notes from a variety of sources, and obtain properties for the various elements of Evernote. The most interesting feature of the AppleScript library is the import/export automation capability. You can export (in well-formed XML) entire notebooks, or notes from a list (such as one generated by a search). These can be transported automatically by whatever means work best for your purposes, and then imported on the other end. This, to me, is primarily interesting because it allows for "local" synchronization of large libraries without using up online quotas. It's also ideal for automatic backup of your notes, among other potential applications: a recent MacOSXHints tip shows a means of adding notes to Evernote via Quicksilver, complete with notebook, title and tagging syntax. Open the Evernote dictionary in Script Editor for the full set of definitions.

The AppleScript library lacks the ability to add tags to existing notes, move notes or delete notes and notebooks. These functions can, however, be found in the Service API. I'm waiting on an API key today, but I'm looking forward to exploring the possibilities for both desktop and web applications. Libraries for the API are available in Java, Perl, PHP, Python and Ruby -- along with sample code and documentation -- at the API overview page.

The last thing I'll mention is the query syntax, which can be of as much use in the Evernote search bar as it is in an AppleScript or API call. I hadn't fully realized the extent of the search grammar until I read the API documentation. For Evernote users who haven't explored this, it's a very effective way to build searches quickly without a lot of token-clicking. You can start with the basic tag syntax: tag:"tuaw", which will find every note tagged with "tuaw." Prefix it with a minus sign (-tag:"tuaw") to ignore any result with the "tuaw" tag. Combine multiple search parameters for boolean searches; the default search is "all", requiring the results to match every parameter in the string (AND), but you can prefix the query with any: to make it an OR search. Other possible parameters include created: and updated: (which respond to some natural language dates as well as a compact profile of ISO 8601), intitle: (search only in the titles of notes), as well as terms for narrowing to a specific notebook or querying just about any attribute of a note (latitude, longitude, altitude, author, source, etc.). See section C of the API docs for a full description of the search grammar.

It's great to see such a useful application continuing to expand itself and allow for third-party interaction. If you're interested in developing around Evernote, or just playing with the possibilities, stop by the developer page and take a look around.

Don't get me wrong, I love my iPod touch. As a matter of fact, I'm writing this post with it on the beach as my girlfriend goes surfing. But with Apple's new product announcement on Tuesday, it makes me wonder what changes could be in store for our favorite supercharged music player.

I think the single greatest thing Apple could do for the iPod touch is take a page from the Amazon Kindle and offer free "Whispernet" service for every iPod touch sold. (Or, say, roll it in with a Mobile Me subscription.) Amazon bought access to a chunk of Sprint's EVDO network, which means every Kindle has network access wherever it goes.

Apple could make such a deal with AT&T -- and its various partners worldwide -- to provide the necessary bandwidth. Who knows -- perhaps they have already. Allow tethering with software like NetShare, and you've got Internet access for your Mac, too. Instant-on, and always there. Brilliant.

Another simple addition would be GPS functionality, bringing the iPod touch in line with its newer sibling. Suddenly, the need for both a GPS and an iPod in your car is obviated, and it opens up interesting opportunities with the car manufacturers who already offer iPod integration in their vehicles.

Third, and this could apply to new iPhones too, would be to allow access to the dock connector for Apps. This opens up all kinds of options for iPhone and iPod touch owners to use voice recorders and cameras, as well as potentially control a wide range of equipment from industrial automation tools to backyard telescopes.

Who knows what Apple has up their sleeve? Certainly not me. But with this wish list fulfilled, you can be sure a new iPod touch is in my immediate future.

CrunchGear notes that a version of the iPhone Push Notification Service API has been released to "a handful" of developers, and, according to them, will "surely" be released to everyone when iPhone OS 2.1 is released.

If you remember our WWDC keynote coverage (around 11:05 a.m.), the Push Notification Service maintains a connection with third party servers to alert you via an icon badge, custom sounds, or text alerts.

An app that uses this feature isn't really running in the background, but instead sort of registering itself with a metaphorical "hotel operator" that lives in your phone. Once there's something new to tell you, the hotel operator notifies you.

Hopefully this has little effect on battery life, but without actual, real-world use, it's hard to say.

TUAW reader Vinod tipped us off to GDocsUploader, a small application for drag-and-drop uploading of Office documents to Google Docs. It's a wrapper around a Python implementation of the Google Documents List Data API. The API, which is limited primarily to uploading and searching, has been around for a while now, but we haven't seen too many Mac applications make use of it.

This app is simple, open source and duly small. A notable drawback of GDocsUploader is its use of AppleScript keychain scripting, which is notoriously slow and not altogether reliable (might I suggest something more usable?). It also gets a little sketchy with reporting transfer results, but that could possibly be an issue on the Google side. Overall, once you get through the first round of Keychain-doesn't-like-AppleScript (or was it vice-versa?) problems, it's a great little drop-point for getting Google its docs. Grab it at Google Code.

Thanks, Vinod!

Reports are surfacing on the web that, while everything Apple showed on stage at WWDC 2006 was exciting and purty 'n all, the more exciting attractions are what wasn't shown on stage. AeroExperience, a Vista developer resource site (of all places), claims to have an exclusive list of many of the underlying changes, newly introduced APIs and other developer goodies that might simply not have been prime fodder for the news and PR spotlight session of the keynote.

It's a pretty lengthy list, so here are some of the highlights for you cliffnote readers out there:

• Leopard will feature resolution-independent user interface and there are several functions to get the current scaling factor and apply it to pixel measurements (we've mentioned how cool this is before, and so has Mr. Gruber).
• Address Book adds support for sharing accounts, allowing an application to restrict content according to user (.Mac already does this, so I'm wondering if they mean some kind of framework or protocol is in place to open this up to something like WebDAV or simple FTP).
• Automator includes a new user interface and allows things such as action recording, workflow variables and embedding workflows in other applications.
• Time Machine has an API that allows developers to exclude unimportant files from a backup set which improves backup performance and reduces space needed for a backup (I was curious about how Time Machine would handle 'useless junk' types of files myself).
• Carbon, the set of APIs built upon Classic MacOS and used by most 3rd party high-profile Mac OS X applications, now allows Cocoa views to be embedded into the application. This could provide applications like Photoshop and Microsoft Office access to advanced functions previously only available to Cocoa applications.
• Text engine improvements include a systemwide grammar checking facility, smart quote support, automatic link detection and support for copying and pasting multiple selections.
• Mail stationery is open to developers, allowing any web designer to create fantastic-looking Mail templates, with defined areas for custom user content (bring on the stationary plugin packs!).
• A new framework is included for publishing and subscribing to RSS and Atom feeds, including complete RSS parsing and generation. Local feeds can be shared over Bonjour zero-configuration sharing and discovery (I suspected something like this; sounds like Safari and Mail.app might share the same RSS database, as can other apps, so users don't have to waste time exporting/importing between RSS apps).

Check out the full list at AeroExperience for more of the potentially rocking Leopard features that Steve and company didn't show on stage.

Ever wondered what happens when you can't view a QuickTime movie, and Apple's QT player prompts you to "download the missing component?" Essentially a QuickTime component is QT's version of a plug-in. Similar to how Flash plug-in allows you to view Flash content, or Windows Media Player used to do play WMV's in your browsers on the Mac. Apple long-ago started using an API of sorts for 3rd party developers who wished to extend the functionality of QuickTime. Extend it? Isn't it pretty fully-featured, what with the support for QTVR (yeah, what happened to their authoring tool anyway?), and 3DMF (haha, that's an unfunny joke there)? Even with all the toys packed inside, QT needs room for growth. Send in the clowns of multimedia: your 3rd party component developers.

For example: I live a stone's throw from where venerable Web 1.0 company iPIX used to exist. iPIX, for those who remember, pioneered a way to record and play back immersive video just like QTVR. Initially their tech was only available via RealPlayer, which, at the time, had the most open architecture. Eventually they made a QuickTime version, as did about a dozen others. Recently I tried to play a training video, and I needed the TechSmith codec. I had to download the component, and everything was viewable. Perhaps the best known and widely used component is the MPEG-2 codec, which is needed for DVD authoring.

Components can be codecs, but they don't have to be. The categories of QT components can be found here, although it's a bit technical. The hard part, honestly, is figuring out which components to install. But since there are only 11 on Apple's QT components page, I suggest installing them all and enjoy yourself. And shame on you lazy devs out there who have yet to implement a Mac version! In some cases, the open source community has taken up the gauntlet. Witness XiphQT, an effort to bring Ogg support to QuickTime. A lot of the furor over components has been laid to rest, however, as we see more specialization. For instance, video via Flash is now a popular method of putting videos on the web. This obviates the need for 3 different format buttons (remember those, along with hi and lo bandwidth versions?). Also, specialized content is being embedded in everything from Adobe's PDF format to specialized readers anyway, making the discussion less relevant every day. One special note of caution: the Apple page lists PowerPC components. Unfortunately, you have to check each component on their home site to find Universal Binary editions. The PPC versions will NOT work on an Intel Mac.

Check out this announcement over at the Skype forums: "Skype API for Mac has currently Cocoa, Carbon and AppleScript interfaces. Cocoa and Carbon interfaces are implemented in Skype.framework. The recommended way to use the Skype framework is to include it in your application as an embedded framework. Copy it into your application bundle and link it to your application."

This is a pretty cool tool for developers looking to work Skype functionality into their programs. Hopefully, more good apps like DittyBot will emerge. Nice.

[via digg]