Friday, June 25, 2010

I was curious about how the iPad plans that were announced by Bell, Rogers and Telus compared, where the break points were, and so forth. So I threw together a Google Spreadsheet to do some quick math on the plans. Assuming I read the plan rules correctly, I think the lessons are as follows:

Bell and Rogers have eerily similar plans, like one copied the other, or both took a suggestion from Apple.

The $15 plan offered by Bell and Rogers saves $5 over the $20 plan from Telus until you use more than 250MB.

From 800MB to 5GB, Bell and Rogers $35 plan seems to be the way to go, because you'll be paying more than $35 by the time you pay Telus for your overage.

After 5GB, it seems like Telus' plan, which maxes out at $50, would be cheaper than paying Rogers or Bell for another $35/5GB, assuming Telus doesn't cut you off.

None of the plans spell out the edge cases:

Telus does have fine print saying "Subject to a monthly data limit of 5GB", but they're not very clear what happens if you hit that limit.

Neither Rogers nor Bell explains what happens when you reach your cutoff. If you run out of data on the $15 plan, can you upgrade to the $35 plan for $20, keeping the original timeframe? Can you buy a new 30-day window of $15?

Based on my iPhone data usage, if I were to acquire and use an iPad regularly, I think I could probably live within 250MB, although if I went over occasionally, it might be simpler to have Telus' plan. I suspect I wouldn't go over 800MB.

Wednesday, June 16, 2010

One of my most common feature requests is for Instapaper to periodically download articles in the background. A lot of people forget to launch the app to let it download content before going underground or boarding a plane.

I’ve already received multiple emails from people who are excited for iOS 4’s multitasking because they can’t wait for this to finally stop being an issue, because they think Instapaper will be able to download articles periodically in the background.

It’s painful to respond, crushing their hopes, to tell them that the iOS multitasking system doesn’t allow me to do that.

The solution he proposes:

The application gives the system an NSURLRequest and an ideal refresh interval, such as every 30 minutes, every few hours, or every day.

iOS executes that request, whenever it deems that it should, and saves the response to a local file.

Next time the application launches, iOS hands it an NSData of the most recent response.

It's an improvement, although it doesn't go far enough for me. There's a couple of enhancements I'd love to see.

Idle Processing

If the user isn't actively using the phone when the data is retrieved, it would be great if the application were given a chance to process that information, and possibly notify the user (even if this requires user opt-in).

For instance, if you've got a stock application and it periodically retrieves the prices of the equities within your portfolio, it would be nice if it could be set to notify you when prices cross certain thresholds, or change dramatically, rather than having to launch the application before it's given a chance to process the data.

Server Push

The polling model will do, but since the iPhone already supports push notifications, it seems like supporting push notifications whose target is an application rather than the user would also be handy. Instead of having your stock application download regular price updates, the server-side element could watch stock prices, looking for price changes of enough difference to matter, then push those prices to your application.

No Guarantees

As with the rest of Marco's solution, I think it's reasonable to give iOS some decision-making authority with respect to when and how these things are processed. I don't expect the phone to run out making regular requests to the server or sending lots of push notifications and firing up applications when the battery's already low.

The Future of iPhone Multitasking

I suspect Apple has already considered approaches like what Marco has proposed and the enhancements I'm suggesting here. I also suspect that they've decided explicitly not to take these approaches for the time being.

I can live with that. They're expanding on multitasking for iOS4, and applications will take some time to catch up. Once developers, consumers and Apple have had the chance to take iOS 4 multitasking in hand, there will be a chance to expand upon that further, and I think the proposal offered by Marco and the enhancements I'm suggesting here are good examples of the directions they can take while still taking a cautious approach to multi-tasking in iOS.