A few months ago I published an iPad app to the AppStore called Ghostwriter Notes. It’s an app where you use your iPad like a regular notepad and write with your finger or a stylus. It’s been doing really well but recently it got plagued by a mysterious page disappearance problem. For any app, regardless of platform, data loss is the worse and most embarrassing defect there is. What do you tell the user once you lost their data? Ouch! I spent weeks trying to reproduce the problem to no avail. Until you can reproduce a problem, you can’t fix it. At best, you can take a shot at it, but since you couldn’t reproduce in the first place, how will you validate that it’s fixed.
A couple of days ago, a user found the use case that makes it happen and was nice enough to email me the steps:
I have been able to successfully duplicate this issue with relative ease, the issue exists in the Paging Functionality, I just created a NEW Notebook, and simply wrote the Page # on each page, and made 20 pages..so each page had 1 on page 1, 2 written on page 2, 3 written on page 3, etc..
Then when I got to page 20, I quickly pressed the BACK BUTTON about 10 times, and skips over pages 19 to 11 and then displays page 10, and I lost the content on all pages that were skipped, pages 19-11..
So it would seem the issue is that if you press Page Back or Page Forward many times in a row, without letting the page LOAD, it will DELETE ALL CONTENT on the page…
I am a QA Analyst professionally, so I do take pride in finding and documenting issues. Hope this is fixed in the next release.
So I tried it and voila! the bug showed its ugly face. The problem was actually simple. When the user changes page, the content of the page is put into a bitmap and the bitmap is stored in the database. Ironically this was done so that no data is lost. After all, if I save right before leaving the page, the database will always be current. Not so! If you hit the button to change page fast enough, the UI thread does not render the page, but the code to save the page content is still called and saves empty content into the DB. The fix? If the page hasn’t rendered yet, don’t bother saving.
I don’t know Kyle personally but I must say his diagnostic was right on. Impressive, given the fact that he had no access to the code nor any other design doc. Nice!
Now, all that’s left to do is to finish testing, package it up, submit to iTunesConnect and sit around for a couple of weeks while Apple reviews the app while hoping that other users won’t be flipping pages too quickly.
For the past 7 weeks, I have been working on an iOS book with Rob Warner (Grailbox). The schedule is very aggressive. It incited Rob to write an excellent article about How to Write a Chapter a Week and the pain involved. But frankly, I expected a lot worse so I’m pleasantly surprised. But let’s back up a bit…
First it’s worth mentioning that Rob is a passionate developer who has a passion for literature (and by literature, I don’t mean technical books). Back a few years ago, he wrote The Definitive Guide to SWT and JFace with Apress and earned high marks in the SWT community so he’s not a newbie.
A couple of months ago he invited me to have lunch. The last time he had invited me for lunch was to tell me about a company merger I needed to help with so I already knew lunches with Rob were not to be taken lightly so I was fully prepared to somehow end up with extra work. I am pretty resilient when it comes to managing a heavy workload. I was ready for it. I thought.
When he asked me if I was interested in helping him write a new book for Apress about iPhone/iPad development I was taken by surprise. I can write a lot and very fast. In code. In English, not so much. I was thinking that the last document I had worked on was an architecture blueprint for a large transaction processing system. It’s less than 100 pages and it’s taken countless hours to write. And now he wants to write a 300+ pages book? It just sounded like an insurmountable task to me but I said okay anyway and I don’t regret it.
The book is not yet finished. We’re working on Chapter 7 out of 9. We’ve consistently hit the mark and delivered a chapter per week. We make a pretty good and complementary pair.
This is an interesting experience where we plowed through our fears about writing a book. Every now and then, one of us has a block and the page stays blank for a while. We both have families and they take priority over the book so there are bad weeks, trips to the urgent care clinic, lost pets, father-in-law in car wrecks, broken septics, kid school meetings and leaking water pumps. So we rely on each other to pick up and carry the load forward. This is a very nice example of a working partnership.
Now things are starting to materialize. We even have a cover and if you are wondering, it’s a dragon fruit. I’m going to have to find one and taste it…
After a few months of internal debates, me and myself have finally agreed on what constitutes a useful blog so I have decided to move ahead and get the blog back online. Clean, official and all. Since I am constantly doing something, and it is most often related to coding in some fashion, I have concluded that I should use this blog as a journal (I did not say secret diary, don’t get your hopes up!) to document the different aspects and challenges associated with being software engineer. It will often take the form of code snippets but I’m also trying to improve my writing skills so I’ll try to make an effort to put words around the code…