“It is very difficult to write simple code” - Sang Kim
OK, I finally fell to looking at the rumors. But its only because I am waiting for my main work computer to finish an overdue system upgrade. (Yes, that’s my story and I’m sticking to it.) Its not so much that I like rumors, but I find predictions fascinating.
The speculation on payment services is particularly interesting. I speculated on an Apple Bank in 2010 in this blog. I don’t recall now when I first talked about it, but I seem to recall saying to someone who thought the iTunes store was just a passing thing.
Well, we will all find out tomorrow.
I just found out that the 3rd edition of Peopleware: Productive Projects and Teams was published a few months ago.
It is one of my favorite industry books and I recommend it highly for anyone working in teams or managing teams.
I’ve gotten a quick look and I’m happy that the formatting of the Kindle book is much better this time. The 2nd edition had a lot of problems with tables and indented quote sections and other formatting.
UITableView cell contains UILabel set with mask to pin the left and right and allow change to width
If the frame of the cell shrinks past the origin of the UILabel, then the right side of the label will be beyond the right side of the cell frame when it was previously contained entirely inside the frame.
This can be detected with Assertions in the ‘setFrame’ method or you can override the incoming frame to prevent the cell’s frame from shrinking so small that the expansion will be incorrect.
I encountered this puzzle recently: How does a 60-second, repeating, NSTimer drift way out of sync with the iPhone’s system clock? The timer was created with a fireDate that was on the even minute with the clock. It fires at 11:02:00 AM and 11:03:00 AM, etc. But users report the timer firing at 1:23:30 PM for example.
(And we are not talking about timers not firing because the run loop mode changed temporarily.)
It turns out that the clue is the word “iPhone”. The NSTimer does not drift from the system clock, the system clock drifts from the NSTimer. The iPhone can have its clock adjusted during the day by the cellular service, especially if the phone goes out of service and comes back. (Changing locations to a different time zone probably triggers it too.)
You can make it happen by just setting the device clock manually. When you pic a new time, it jumps to the hour and minute chosen, but with zero seconds. The iOS honors the repeat rate from the last firing and adjusts the fireDate accordingly.
So if you need to stay tuned to the clock, you’ll need to update the fireDate on the NSTimer when you receive the significant time update notification.
Thanks to Erv Walter for a great blog tip that has my MacBook waking much faster: “Fixing” Slow Wake for MacBook Pro W/ Retina Display
Now my MacBook is wakes very fast when I open the lid. It took 5 or 10 seconds with the factory settings.
I was working on a “framework” for an iOS app. When I added image resources, they did not work.
After Googling about for the answer, it seems that Apple added a setting for the MacOS framework template to combine related image files (like image.png and email@example.com) into one multi-image TIFF file. Since we based our product on that template, we had that setting. All the images were being put into files the iOS did not support.
If you have this problem, search your project for COMBINE_HIDPI_IMAGES. Be sure that it is set NO in all targets.
“The only thing you can safely assume is that it is unsafe to assume anything.” – Walt Sellers
I recently wrote this while discussing things with a colleague. Eric Rodriguez-Diaz long ago taught me to challenge my assumptions. I now believe that bad assumptions are a large part of most of the bugs in code.
One of the best QA people I have ever worked with caught something that really impressed me. She was working on reports of crashes while touching cells in a UITableView which was the result of a search. When the user would touch one of the cells, the app would sometimes crash. She noticed that the crashes only happened IF autocorrect was showing when the user touched the cell AND the auto-corrected search string would produce no results. (I really wonder if I would have noticed such a detail.)
As it turned out, once the auto-correct is showing, any touch that is not the keyboard or the auto-correct’s popup (for dismissal) then the touch is considered an “accept” of the suggestion.
The part of this that caused the crash was the combination and simultaneous nature of the events. The auto-correct is accepted first. This causes a change in the search results which are the data source for the table. But the touch is also processed for the UITableView. It results in a didSelect call for the index path originally touched. This can result in an attempt to access something that no longer exists.
The quick and easy solution is to disable auto-correct on the search bar. That prevents the whole mess.
But, it also shows that if the data source is not prepared for the possible attempt to use bad numbers, it could result in a crash. And are we really sure that some other subtle combinations of things won’t also result in bad numbers?
A final thought: If you correct your code to handle the invalid indexPath after the change of search, assume there is a result that winds up with the same indexPath. It probably will not be the same result that was there before. Now the user will think there is a bug and file a bug report.
Are you trying to make auto-correct give a suggestion, but it won’t appear?
Make sure to use the on-screen keyboard to do the typing.
It turns out that iOS knows if you are typing on the on-screen keyboard or a physical keyboard. If you are using a physical keyboard, it won’t present suggestions.
This held true for both the simulator and the device. When I tested using the simulator, the keyboard on the computer would not cause suggestions. When I tested using a bluetooth keyboard with an iOS device, it would not cause suggestions either.