iCloud looks like it will be an incredible technology for moving app data between devices. This is inherently a good thing, and it will open avenues for many new types of apps. But, there is a fundamental problem. Right now, the only way to access it is through Objective-C APIs embedded into iOS and Mac OS X. Under the hood, they are obviously talking to the network and doing the business of syncing data, but that networking layer is not exposed or documented, and would have to be reverse-engineered in order to understand and use. So the only way for developers to move their data through this system is through a pre-compiled bundle that gets referenced within an application.
This has a few interesting practical repercussions. If you build an application targeting iCloud, you can only ever put it on two platforms - Mac and iOS. You will never be able to port it to Android, WebOS, Windows Phone, or the web (mobile or desktop). If you sync data through iCloud, And, you will never be able to have a server component that can do things with your data all the time.
Here's some examples of what I'm talking about. In my To Do list app, Todolicious, one thing I would love to be able to do is to push badges to your iPhone and Mac showing the number of To Dos you have left. When you tap a To Do to mark it as done, suddenly all your devices would show the correct number on the icon. With the sync server I was building, this was fairly trivial; wait for the user's list to change, and send a signal to push the count everywhere. But if I back Todolicious with iCloud, I have no way of speaking between my server and iCloud (and I'd still need a server of some kind to send the notifications, after all).
Similarly, if I were to build a web app version of Todolicious (which I was planning on), I could not get access to that data within iCloud at all. I'd have to have either to sync to both iCloud and a custom solution (unwieldy, poor UX and network traffic, and otherwise gross), or not load existing data at all (completely negating the benefit of having such a web app).
So there is a serious ecosystem lock-in problem for apps that wish to target iCloud. All of these problems go away when iCloud is made available as a server-to-server API. A big benefit in the promise of cloud computing includes service interoperability, but right now iCloud is merely a data silo. I have filed this as a bug, rdar://9598555, for a server-to-server API (through which you could build code that speaks to iCloud on your server or on other platforms). I dearly hope Apple addresses it.
Such a server-to-server API would drastically decrease the friction of setting up cloud services to complement an iCloud-backed app, and would lead to better apps and more pleased users.
Caboose is an app that loads notifications from the Boxcar service. It provides a reusable class for interacting with the Boxcar service for receiving push notifications. Currently it loads notifications for one account and dumps them to a Growl feed, but a full UI is planned.
For a little less than a year, I've been writing code built atop Twitter, specifically Matt Gemmell's MGTwitterEngine. I've got a few things running on this code, which I've not talked about publicly (other than minor hints on Twitter), but have been well-received by the few people who have seen it. Still, these projects have needed to extend both MGTwitterEngine and related libraries to add functionality or fix bugs. I'll spend this blog post documenting some of those changes across the different projects.
Most of these changes were made to make the engine's behavior a bit more extensible. Here's the GitHub repository.
MGTwitterEngineIDis a typedef for unsigned long long values. Everywhere a user ID or tweet ID is returned, it will return one of these. You will want to check your existing Twitter code to make sure there are no potential Twitpocalypse-related problems, updating old data types to the new
- Subclasses of
MGTwitterEnginecan now override a new method,
-_sendRequest:withRequestType:responseType:, if they want to use custom networking code (such as with an
NSURLRequestqueue class). I use this to implement both Twitter's password authentication and OAuth, and decide at runtime which to use.
- Added a
MGTwitterEngineDelegate, which can be used to update your UI.
- Fixed a few bugs in the YAJL parser which crashed or parsed incorrectly.
Things I still need to do:
In my custom subclass ofUpdate: Thanks to Uli Kusterer, the dependency on
MGTwitterEngine, I use a class I wrote called
TCDownload, which I'll talk about below. There are still a few references to it in my
MGTwitterEngineclass; those should be fairly straightforward to remove.
TCDownloadhas been removed. The changes have been merged from his fork into mine.
- Add full support for Twitter lists. I have some basic Twitter list functionality working in a private subclass, but far from all of it. There are some problems with the YAJL parser that don't appear easily fixable with the stock
MGTwitterEngine(specifically, the API key for the list description is the same as the key for the user's bio, and these are overwriting each other internally). I'm going to look into replacing the manual parsers
- Add full support for new-style retweets. Haven't started this yet.
- Add support for geolocation in incoming and outgoing tweets. Haven't started this yet.
I've forked yajl to support 64-bit tweet IDs, mainly by changing the callback methods and the string parser from
strtoull. Here is the GitHub repository.
This is a repository of scattered classes which serve various purposes. There are two classes which are relevant for our discussion,
TCOAuthDownload. You will need the
TCDownload class if you use the vanilla
MGTwitterEngine fork, although I'll be removing those dependencies. Here is the GitHub repository
TCDownloadis a generic wrapper that encapsulates an HTTP request to the interwebs. It wraps NSURLRequest and NSURLConnection under the hood. It automatically queues request and gets callbacks on a background thread (although you can change either of these). I use it a few places inside my
MGTwitterEnginefork, but removed most of those changes and put them in a subclass.
TCOAuthDownloadis a subclass of
TCDownloadwhich accepts OAuth tokens and sends out requests with the correct headers. It relies on the
OAuthConsumerframework, which I'll talk about below.
This framework deals with OAuth. Twitter has officially announced that basic auth will be dead in June 2010, so getting on the OAuth bandwagon now is a good idea. Here's my fork of the OAuthConsumer framework on GitHub.
- Changed the signature code to use Common Crypto instead of the C libraries' HMAC APIs. This seems to work more consistently on both Mac and iPhone.
- Added a
-parseHTTPKey:value:method which is used to parse extended attributes in OAuth access tokens. Twitter uses this to pass some special metadata, like the username of the logged-in user. Subclasses of
OATokencan extend this to parse those tokens.
This isn't strictly a tool for doing Twitter development, but it can be handy when learning how to implement the OAuth login flow. I posted about it more back in January, and you can find the code and a prebuilt app over at GitHub.
Twitter uses OAuth as its supported form of authentication. This is fine for some apps like clients where users need to authenticate themselves, but it doesn't work well for bots or scripts run by one person. If the bot needs an access token, it can be a real pain to obtain without writing the intermediate code.
This application, OAuthery, serves a simple purpose. You supply it the consumer key and secret for your OAuth application. It creates a request token and the URL for authorizing it. You complete the authorization in a web browser and get a PIN number. You then enter that PIN number back into the application, and it spits out your access key and secret. At this point, the user authentication is complete, and you can add those credentials to your script, and access API resources.
This is largely intended as a developer tool for people developing applications with Twitter's OAuth impelmentation. It also provides code to show exactly how to perform the authentication process with OAuth and Twitter, so that developers who wish to implement such functionality in their own apps can use this as reference.
Inactive, because it's a simple tool that serves a limited purpose.
OpenEmu is a Cocoa framework and application for running multiple emulators as plugins. Many popular open source emulators; such as SNES9x, Nestopia, and VisualBoyAdvance; are fully compatible with this system. As all the emulators are going through the same architecture, it can be tuned to use the latest Quartz and Core Graphics technologies to deliver screaming performance.
Most of my participation has been in fixing bugs and doing some application-side coding. My big task so far is an in-development ROM organizer powered by Core Data, with smart playlists, Quick Look for save states, and ratings.
VillainousStyle is a drawing library for defining a visual style from a chain of individual drawing instructions. Each instruction modifies the drawing context to perform common operations; such operations include shadows, fills, borders, and shapes. It allows for multiple style sheets which can be used to theme an application in multiple visual contexts. VillainousStyle sits on top of CoreGraphics, and does not use WebKit for rendering at all. It is a fork of the VSStyle and VSShape classes, originally from the Three20 project.
VSStyleSheet is an abstract superclass for a set of styles. Subclass it and add methods for each style you wish to add. You will likely want to create a protocol for your styles to implement, to ensure that your stylesheet implements all the necessary styles.
There is a global stylesheet, which can be thought of as the "active" stylesheet. Call
+[VSStyleSheet setGlobalStyleSheet:] to change the active theme, which will fire a
VSStyleSheetChangedNotification. When that gets fired, you'll want to tell your views to update their styles and redraw.
Styles affect drawing and positioning. Most will affect the next VSStyle objects in the chain.
- VSSolidFillStyle - Fills the current shape with a solid color
- VSLinearGradientFillStyle - Fills the current shape with a gradient between two colors
- VSReflectiveFillStyle - Fills the current shape with a glossy-style gradient between two colors
- VSSolidBorderStyle - Draws a border around the current shape with a solid color
- VSBevelBorderStyle - Draws a beveled edge border for a 3D effect around the current shape
- VSFourBorderStyle - Draws a border around the current shape with four colors, one for each edge
- VSShadowStyle - Draws a shadow behind content with a given color, blur, and offset
- VSInnerShadowStyle - Draws a shadow inside the content with a given color, blur, and offset
- VSBoxStyle - Adds a margin or padding to the content area
- VSInsetStyle - Adds edge insets to the content area
- VSTextStyle - Draws text inside the current shape
- VSImageStyle - Draws an image inside the current shape
- VSMaskStyle - Clips the drawing area to an image mask
- VSShapeStyle - Clips the drawing area with a VSShape object
Shapes affect the fills and borders, but do not clip the content styles.
- VSRoundedLeftArrowShape - a rounded rectangle with a left-facing arrow
- VSRoundedRightArrowShape - a rounded rectangle with a right-facing arrow
- iPhone static library
- Cappuccino library
- File-based stylesheets that can be read/written from VSStyleSheet objects
- GUI builder for styles
- More styles!
The templates that ship with Xcode are not the greatest. Some of them are inconsistent and don't enforce good coding standards (e.g. missing a dealloc method). Other templates which would be useful just flat out don't exist (e.g. an NSOperation subclass, or a protocol header file). This project aims to supplement or replace the built-in templates for Xcode to speed up coding and improve the quality of code.
All files will be processed by Xcode. The generated source files must produce consistent, readable, commented code. The code must have these characteristics:
- Each file must have a comment block at the top describing the file.
- Each class must implement its superclass' designated initializer and dealloc.
- Stub methods must be organized by their purpose, class or protocol. -- Each group must be organized by their class hierarchy, with protocol stubs following. -- Each group must be prefaced by a pragma mark naming the class or protocol the methods were implementing. -- Clusters of methods (such as relating to KVO) should be organized along the lines above, with a pragma mark.
- All method implementations should contain a method call to their super implementation if needed.
- All method implementations should contain a commented out stub line that will signify where to insert their code.
- All comments must be in the form of two slashes //, and none using the /* */ form. This will allow developers to comment out large blocks of code as needed.
- Different people want different things in their template. For instance, someone may want to include an implementation of observeValue:... for every class. Would be nice to have a template generator application (yeah yeah, very meta) which would make templates customized to the developer.
URL Shrink is a new OS X tool with a very simple purpose - converting URLs to shorter permalinks on various web services. As the internet has matured, and services like IM, IRC, and Twitter have forced us to write shorter messages, it was clear that a system was needed that was as ubiquitous as Quicksilver.
For now, the main service of URL Shrink is just converting a URL that is on the clipboard, although this will be expanding over time (including things like a system text service, a command line client, a Quicksilver plugin, etc.). To do this, there is a keyboard shortcut (option-shift-space) which will convert the URL in the background to a tiny URL using one of the services provided. If you've selected one as your favorite, it'll choose that one. For example, I'm personally partial to is.gd, so all the URLs that are processed by URL Shrink on my machine go through is.gd.
At a low level, URL Shrink is a system where multiple shrinking engines can be added. It was designed to be extremely easy for developers to write just a little bit of code to integrate with other web services, including private URL services. For information on that, see the project page below.
URL Shrink is licensed under the BSD license. I encourage its adoption within other applications; I'll be adding .framework and .a targets for building this into Mac and iPhone apps respectively. Indeed, the project was born out of the URL shrinking capacity of another app I'm working on.