Tag Archives: development

My delicious.com bookmarks for July 13th through July 22nd

  • The Rise and Fall of the Independent Developer – "My fear is that It’s only a matter of time before developers find the risks and expenses prohibitive and retreat to the safety of a larger organization. We’ll be going back to square one."
  • The Equality and Human Rights Commission’s choice is beyond belief – "But what these cases illustrate is that in certain areas compromise is not possible because the rights of different minorities are mutually exclusive. When one group refuses to fulfil its job description because it disapproves of another group, there is no middle ground, no give and take."

Patents

Dilbert.com

The cartoon ((Sorry it’s too big. I couldn’t find a way to shrink it without stealing a copy.)) for today’s Dilbert Day to Day Desk Calendar seemed appropriate for some things that are happening in the mobile software industry at the moment.

If you’ve not been following events — shame on you — then you can read all about it here. In summary, a number of small developers have been sued by a “patent troll,” that is a company that does not develop or make anything but demands royalties for the use of “intellectual property” it bought.

These events and the cartoon show quite succinctly everything that is wrong with the current patent system.

My delicious.com bookmarks for March 26th through March 31st

  • ‘Useless’ Is A Loaded Word – "In almost any life situation where you need to get something out of another person, being a dick is never the right method to go about it. Using loaded words like ‘useless’ or ‘worthless’ is being a dick. We will listen to your feedback and thank you for it, but unless it is some urgent issue that will affect every user, it’s most likely getting shoved to the bottom of the pile in favor of doing things to make the friendly customers happy."
  • Don’t blame inflation for all the price rises – Summary: food and gadgets are cheaper, entertainment is considerably more expensive.
  • We should stop running away from radiation – "A sea-change is needed in our attitude to radiation, starting with education and public information."

Why you need a crash reporter

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.

However, what has become clear is that not all of the crash reports make it into iTunes Connect. There are two, maybe three, levels of screening going on. First, the user has to sync their phone with iTunes. I do this mainly to update my podcasts but otherwise I’d do it fairly infrequently. Second, the user also needs to allow the crash reports to be uploaded. I suspect most users do but, you never can tell. Third, Apple clearly does… something with the reports when it gets them. There’s clearly some degree of filtering going on but quite what is anyones guess.

The practical upshot of all this is that you’re quite likely to hear about crashes before you see them. I’ve seen reviews in iTunes complain about crashes. I’ve received tweets and support emails. And all before a single report appears in iTunes Connect.

It’s the reviews in iTunes that bug me the most, as I have no way to ask for further information.

Until now.

The most recent version of Yummy, Yummy Browser and www.cut all included crash reporting code. That is, should the app crash, the next time it’s launched it will say as much as offer to upload the report to a web server.

As I type this I see around a hundred crash reports on my web-server and zero in iTunes Connect. Luckily, I’ve seen no bad reviews in iTunes and, surprisingly, I’ve had no support emails or queries on Twitter.

Without the crash reporter I would have had no idea there were these serious bugs — I’d never seen them! I’m always surprised about crashing bugs as I consider myself to be the main user and so likely to come across these problems first.

Using the reports I can easily see that 90% of the crashes were coming from two bugs. Interesting but slightly less importantly, I can also see that jailbroken phones seem to have more problems than others. I see that the vast majority of my users are on 4.x, with 4.2.1, by far, being the most common. (None of the bugs are OS specific so these numbers should be pretty representative.)

The other thing about having the details on a web-server is that I was able to flag them. When a crash with a known fix is submitted, the apps will now tell the user that this is the case.

I never thought I’d say that the lack of support email is a bad thing, yet there was one bug that took me a long time to track down. I could see where exactly in the code it was crashing but I could see no way that it could actually happen. In the end I stumbled across it quite by chance, but being able to talk to a user who was experiencing the problem would, in this case, have been very useful.

No software is perfect. But at least now I can see problems almost as soon as they happen and provide direct and timely feedback. This is such a huge plus that it shouldn’t be underestimated.

My delicious.com bookmarks for March 9th through March 12th