I want to like ebooks, I really do.
I like that the Kindle is smaller than a real paperback but can store dozens, hundreds even, of novels. I like that you can lose the hardware device and just download the books again. I like that I can read the same book on my iPhone as well as my iPad. It doesn’t even bother me that there’s no physical product. I’m not going to re-read most of my books yet they continue to take up the limited space in my London flat.
Most developers of iOS applications have a love-hate relationship with the main interface with Apple.
No, let me re-phrase that.
Most developers of iOS applications hate iTunes Connect, the main impediment to a good relationship with Apple.
To be fair it has improved since it opened in mid-2008. One of those improvements has been the inclusion of crash reports. A crash report, in case you’re not a developer, is something that iOS devices such as iPhones and iPads write out when an application crashes. It includes all kinds of useful information, including some, but not all, of the internal state of the application in question. It’s very, very useful for diagnosing problems.
Seth Godin has had a couple of posts recently about how to treat your best customers. One of the thing that he observes is that the way you define “best” is not necessarily the most obvious. Is a customer that pays full price always better than one that recommends your service to five of their friends?
In defining the best customers, my mind wandered to the opposite extreme, the worst customers. This reminds me of something that happened a few years ago. It’s only fair to note that I heard this “through the grape-vine.” It could be completely true or mostly made up, but where-ever it falls I think it’s an interesting anecdote.
It’s hard to explain to someone who is not already a programmer the kinds of things that you have to do when building an application. The thing you’re trying to explain is often very abstract and the answer frequently would involve lots of code.
That’s why I thought this particular problem might make an interesting discussion. In talking about this very simple problem we can talk about the things that developers deal with every day and, hopefully, the process can be followed by most people who have used an iPhone (or, actually, any computer). You won’t be a programmer at the end but you might have a greater appreciation for what happens behind the scenes.
When I travel I don’t normally take a laptop with me1. Too big; too heavy; too fragile; too expensive; too inconvenient.
But the iPad is different. It’s smaller and lighter. The fact that it’s limited compared with my MacBook wasn’t going to a problem as I only had two main use cases for it: reading and downloading my photos.
It’s nearly four years old now, so I do expect the odd beach ball occasionally. When my MacBook is doing something hard or complex or just opening iTunes, it often shows its “I’m too busy to respond to you right now” indicator. But this time it was different. The beachball appeared and didn’t really go away again. Sure, it occasionally hid but as soon as I instructed the machine to do anything it would return.
Last year Yahoo! announced, with no notice, a significant change that had far reaching consequences for all third party applications including my iPhone program, Yummy. This is the third in a series of posts that discusses how I dealt with it.
We’ve already talked about most of the work, starting with an overview, the announcement, the low level technical challenges and the implementation (technical and UI). All that remains it to launch it, and that’s what we’re going to talk about today.
Last year Yahoo! announced, with no notice, a significant change that had far reaching consequences for all third party applications including my iPhone program, Yummy. This is the third in a series of posts that discusses how I dealt with it.
On Monday I gave an overview of the problem, Tuesday I looked at how those changes were announced and why they were tricky, and yesterday I looked at how I actually implemented those technical details.
Last year Yahoo! announced, with no notice, a significant change that had far reaching consequences for all third party applications including my iPhone program, Yummy. This is the third in a series of posts that discusses how I dealt with it.
On Monday I gave an overview of the problem and yesterday I looked at how those changes were announced and why they were tricky. Today we’ll look at how I actually implemented those technical details — though not at the code level so don’t worry if you’re not a programmer!
Last year Yahoo! announced, with no notice, a significant change that had far reaching consequences for all third party applications including my iPhone program, Yummy. This is the second in a series of posts that discusses how I dealt with it.
Yesterday I spoke at a high level about my iPhone application and some changes that Yahoo! made to their side of the system. Today I’d like to talk in a little more detail about how those changes were announced and why they were tricky.