On the Apple Push Notification Service for iPhone OS/SDK 3.0, there’s an interesting comment thread over on Mobile Orchard. Ryan Daigle writes:
This has the potential to become a very expensive and heavy-weight hack to masquerade as a local cron system on the iPhone.
As Adrian Hosey reasons in that same thread, it really is a lot of fail-prone nonsense. There should be some kind of local device API for scheduling with launchd or whatever the OS uses.
Due to a series of unfortunate events I am in this spot where we lost some code, including some custom PL/SQL written for chart series and data calculations. Most of these queries had been pasted into Campfire at some point so I’m digging through transcripts looking for code to reuse.
Campfire is a web-based chat and collaboration tool; we use it all the time here at Zetetic, so much so that I’ve even taken to using a really great third-party client called Propane for it. In any event, it often happens that I need to search through our transcripts to find a particular conversation or look up bits of code that might not be anywhere else. And it’s always a nuisance to identify what you’re searching for when you search on a string of text and then proceed to click through each matching transcript.
So an idea occurred to me: Save Points! It’s very, very common in many of the interfaces we use (at least in the tech world) to have some kind of toggle in the gutter of a view allowing us to mark an item for later review. GMail and Google Reader both use a star for this:
In Apple’s XCode IDE (and many other IDE’s), we often click in the gutter next to a line of code to set a breakpoint:
What I think Campfire needs is a turn on this type of interface, a feature I can’t help but think of as a Save Point. I want to be able to click in the gutter next to a line of conversation in a Campfire chat so that I can later pull up all my save points instead of searching. In fact, I’d also like to be able to click on the save point and give it a name.
The reason I think it would help me in my current scenario is that presumably when I pasted something like “woot! this is the final version of such and such query and it totally works fast!”, I’d paste the query and then I’d just click a quick save point in case I wanted to return to that point in the conversation at some later date. Here’s hoping the 37Signals folks will consider implementing such a feature.
Right now we’re putting the finishing touches on our first iPhone app to get it into the App Store, or hopefully at least through the approval process. Who knows, really. But we’re hustling, we’ve put a lot of work into these products and we’d like to at least get them out there soon.
In the spirit of staying on top of things, I downloaded and installed the iPhone SDK 3.0 betas (1 and 2) on my development machine. I just wanted to be able to take a look at things so that I could get a head-start on the next generation of our apps. But so far, errors and extreme weirdness have been keeping me from my work on our current apps for the current platform. You’d think when you switch the build environment for platform 2.2.1, the entire XCode environment would adapt, but that’s not what happens. The helpers seem to be generating nib files for the new SDK, I can no longer create grouped-style table views, there are random crashes, nuisance deprecation warnings for the new SDK I’m not using.
Obviously, beta software is beta software, so caveat emptor, but I can’t find any good information on backing out the 3.0 beta installations and resetting my environment. In addition, I’m told that Apple isn’t accepting apps in the store built using this new version of XCode, even if they are built for the current platform, which is in and of itself really lame if true. Still trying to confirm that. So I’d advise anyone doing development right now to hold off on installing the beta SDK environments on their primary development machine. Install it on a spare machine, I reckon. What a nuisance!
Update: Apple does warn you about this on the SDK download page. Among others:
From BW, a fan:
I loved STRIP [on] the palm and have tried all of the password management apps for the iPhone and they all SUCK. Even if I don’t make the Beta, can’t wait for the release, and will definitely buy it.
This sort of thing has been happening a lot, so it’s got us pretty excited. The next release of the STRIP for iPhone beta is a round the corner, so send your UDID to support@zetetic.net if you’d like to help test and check it out. We just got approved by the Department of Commerce to distribute what they call Mass Market Encryption, so now we can finally submit it to the App Store. More on that madness later.
Last night the folks at Twitter released a significant update to their API. Among the changes was a massive change to the way the Twitter API responds to time-sensitive queries. In short, the since parameter and If-Modified-Since
header are no longer supported.
For those unfamiliar with the API, these features allowed searches for Public Tweets or Direct Messages that occurred after a specific point in time. It was intended to both reduce load on Twitter’s service and allow API clients to selectively retrieve tweets that they haven’t seen yet based on a time stamp.
The fact that the API changed is not shocking. The Twitter team had a solid reason behind it, as it seems date based queries weren’t handled efficiently enough for widespread use. There is even an alternate API search, based on message id, that can provide a similar function. Therefore these changes could really stand to benefit the developer community as a whole by providing increased capacity and performance for the API.
First, and most importantly, the API was modified in a way that it would simply begin to ignore since parameters as if they weren’t even there. This means that clients querying the API with the expectation of retrieving a limited subset of tweets they hadn’t seen yet would, all of a sudden, start seeing a completely unfiltered feed of tweets, including ones from the past.
Consider the hundreds of applications like our own apps Tempo and PingMe, which process Twitter direct messages they haven’t yet seen to perform operations on a user’s data. Applications polling the Twitter API using the since parameter would be flooded by old, duplicate messages that they had already processed, possibly causing rampant duplication and perhaps data corruption.
edit: Let me draw an analogy: imagine that one day before release MySQL (or pick your favorite DB) decided to deprecate and ignore the the greater than > operator on queries. No errors – it would just pretend that query clause didn’t exist and return all rows for queries that used a >. How would that affect your application?
It is just poor form for a public API to change in such a way that the results of API operations become unpredictable like this. The API release notes claim this approach was used to ensure that existing applications didn’t break, but in fact would almost guarantee catastrophic failure of applications dependent on the function.
Don’t get me wrong, it’s absolutely Twitter’s prerogative to change the API, and they can do so whenever they want. But with tens of millions of users and thousands of application and sites using the Twitter API, they should be more responsible about these kinds of changes.
If the API drops support for certain operations, just return an error message. Sure, it will be annoying to get error until the application is fixed, but at least you don’t risk corrupting thousands of down-stream integrations with improper data.
To make the situation worse, Twitter gave their developer community 1 day notice about the breaking change. Imagine if you didn’t get that email, or consider a case where an API release occurred without notification.
edit: When you expose a public API it becomes a contract with your developer community. If you make a breaking change to the API you have a fundamental responsibility to effectively communicate the change and ensure that it doesn’t create massive and unpredictable results for clients.
As Twitter grows and becomes more popular in the mainstream it needs to establish a process for notification on API changes and stick with it. Give the developer community enough time to properly code and test changes to their applications before a release. If it’s not convenient to do on the main API, perhaps they could consider some sort of business service that would provide premium access and a stabler environment for groups and teams like ours that really depend on it.