Tag Archives: ipad

Opinion

Glitches

It started with this image. Or rather the glitch that you can see in the middle of the screen.

It’s one of the screens in a new app that I’ve been developing. There’s lots of hard stuff in there but this is the first problem that has really stumped me. What it appeared to be was this: a text view (UITextView) on a table (UITableView) showed a nasty glitch when you tried to place the curser in the text box.

First thoughts:

  • Transparency
  • Scrollview (UITextView) within a scrollview (UITableView)
  • Image background

So I switched off the transparency. (No effect.) I switched off scrolling while editing. (No effect.) I made the background boring. (No effect.)

I was stumped.

I showed it to some guys at the London iOS Developer Group meeting. They too were stumped. (This was a bit of a relief. It meant that I wasn’t doing anything completely stupid, which is always a risk.)

So I tried writing a question for Stack Overflow. And, as I often do, I stumbled across the solution.

Note that the text view has a small border and rounded corners? Yup, that’s the culprit. Or at least, some of that code is. Here are the two lines that do it:

self.layer.cornerRadius = 5;
self.layer.shadowOpacity = 0.5;

(There were quite a few other lines adjusting the layer too, which is what took the time to narrow down.)

It was nothing to do with the table view or the text view per se. It wasn’t even any of the visible transparency effects.

Of course, in the screen I have no need for a shadow, indeed you can’t even see one, so the solution was easy. Quite why this combination causes such a weird effect have no idea, but I’m glad that I found the solution.

(I raised a bug report with Apple: rdar://11041657.)

Software

www.cut 3.0

I’m very pleased to announce the new version of www.cut, a major release including an almost complete rewrite of all the UI code and a bunch of stuff under the hood. You don’t care about that, but it does bring you iPad support, the ability to lengthen already shortened URLs and the ability to sync your settings between devices using iCloud.

The iCloud bit, as with lots of stuff under the hood, means that it will only work on devices that run iOS5.

On the “business” side, www.cut is no longer free. It is now a “tier one” app, that means 99 cents, 69 pence or your local equivalent.

The reason for this change is two-fold: advertising, despite what you may have heard, is not a massive money-spinner unless you have millions of users. www.cut, you won’t be surprised to hear, has nowhere near that. Secondly, and more importantly in some ways, I just don’t like adverts. I almost always pay for apps in preference to using an ad supported version. I think the app is better without them.

With the change, I have tried to be as fair as I can. All existing users will get the upgrade for free, including those who only have the free version. I thought it better to be generous to early adopters that screw over the people who actually upgraded.

Links

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."
Opinion

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.

Opinion

Why you need a crash reporter

2 Comments

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.