Fresh from our series “Another Day Another Radar” here’s one that stumped my associate Rene.
Since I’m getting a knack in filing these I did the “quick file” for him, as rdar://11738458 and on OpenRadar. As always I am doing this publicly because other people out there might have experienced the same issue which can be quite nerve-wrecking. Also this problem was observed on an OS X version that is public and widely used.
There’s a gotcha/bug if you’re using -[UIColor CGColor] to get a CGColorRef for use with CoreGraphics. I think several people have already documented this on their blogs, but I was having the same issue in my DTCalendarView when running it on device. The same code worked before enabling ARC, but with ARC enabled it there is a difference whether its running on device or simulator.
On Simulator all is fine. On device however you get a EXC_BAD_ACCESS because the ARC release the UIColor way before the end of the current scope. There are several possible workarounds but it is still unintuitive that previously working code ceases working with ARC.
We were told to also file bug reports for unexpected behaviors or something that is counter intuitive, so here you go… Radar #11717864 and OpenRadar. Here’s the sample project.
Update: Yes, I know that you could call this “works as designed”. But the point here is that it is non-obvious and causes previously working code to break. Even the gurus at the Big Nerd Ranch stumbled over this one and filed is filed. In the least I would expect an LLVM compiler warning for this to be added.
I’m on fire!
Never before have I filed so many Radars in a single day. This one aims to remove the need for components like my DTPinLockController which I used in iWoman.
This is a Feature Request for getting passcode locks on a per app and per folder basis. So that you can hand your unlocked device to your kids for playing Games but still apps being secure that they have no business in starting. This would passcode-enable all apps that don’t have custom solutions and also make all those custom-passcode-viewcontrollers unnecessary.
If there where an API for inquiring about passcode status then we could keep the user logged in just like the Find my Friends app is doing it. This requires entering the password only if you don’t have a passcode lock set.
I filed this as Radar #11716971 and also posted it to OpenRadars. Please dupe it if you think that this is a useful feature for our favorite platform.
The third kind of Radars I plan to file more are for new features. While the Apple bug reporter is mostly made for reporting and tracking bugs this is also the only way to formally file a feature request. This one relates to WWDC videos and iTunes U.
I am suggesting here to organize the WWDC videos similar to the Stanford CS193P course where you have all the videos and materials aggregated together and can keep track of your progress (“gotta watch ’em all”) independently of whether you have downloaded a video or not.
This was filed as Radar #11716509 and also posted on OpenRadar.
The second type of Radar I vowed to be filing more of following WWDC 2012 are so called “Enhancement Requests”. I have yet to see any of my previously filed requests be implemented in iOS, but it never hurts. One Apple representative once told me that “we’ll implement it if enough people want it”.
I recently demonstrated in a tutorial how to add block-support to UIActionSheet. Now here’s the formal feature request suggesting to Apple to implement this in the official SDK.
The following is filed as Radar #11695432 and also added to OpenRadar.
One of the takeaways from WWDC should always be a renewed promise to yourself and Apple engineers: “File better Radars”. With some time at my hands jettting back over the Atlantic Ocean, I prepared a demo project and the text for my latest filing.
This was quite a head-scratcher for me today. So I documented it as a Radar (rdar://11541277) because it just feels wrong to me. If there are reasons for this behavior I was unable to find them documented.
Please let me know via Twitter or in the comments if you have a good reason for this or know of any documentation related to this.
There’s a bug – it seems – in Xcode 4.3.2 that was causing an issue with my DTBannerManager component. I’m documenting the workaround here and how to recognize that you are experiencing the bug.
I finally got around to report an annoying bug in CoreText that has been bugging us in DTCoreText until I wrote a method to correct line origins as a workaround. rdar://10810114
The annoying thing about this bug is that it adds visual noise to otherwise pristinely rendered text. Especially on larger font sizes you see that additional space appears before each CTLine that ends with a paragraph break (\n).
UPDATE: This is a duplicate of rdar://9931615.
I’ve decided that I’ll share my bug reports on my blog from now on as well. Usually you’ll have to make a small demo project to demonstrate the bug to Apple’s engineers and then they are the only ones to see my work. What a waste.
I still believe that Apple’s Bug Reporting system should be open for everybody, but since Apple is still run like a small startup they feel that it helps them conserve more resources to have it closed. That’s why there is Open Radar which somebody put on Google App Engine.
So, here’s my full bug report plus the demo project and screen shot. See if you can reproduce it and find a workaround.
16-Aug-2010 06:40 PM Oliver Drobnik KG:
Summary:
If you load a navigation controller from MainWindow.xib, but add the first view controller in appDidFinishLaunching, then there is a problem on rotation. A gray empty status bar appears underneath the regular status bar which cannot be eliminated.
Steps to Reproduce:
Expected Results:
No extra gray status bar.
Actual Results:
A sticky gray status bar appears underneath the disappearing regular status bar.
I’m attaching a project to demonstrate the behavior. Plus a screenshot.
The behavior is inconsistent with creating a navigation controller in code. There no extra status bar appears.
I filed this bug report on Open Radar as well. Here’s the Project file I’m referencing: StatusBarBug.zip
To see the bug for yourself launch the demo project in iPad Simulator. Tap the screen to show the black status bar. Then rotate the simulator once. Tap the screen again to hide the status bar. Behind it this gray bar appears.
This is how the screen looks like with the extraneous status bar showing.
Iif you set the navigation controller’s root view controller already in the NIB (as it’s usually the case) then this behavior does not occur. So for this demo I moved the view controller outside of the navigation controller.
If you don’t instantiate the navigation controller via a NIB file, but instead put the following code into the applicationDidFinishLaunching, then you will not see this extra bar.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // could also initWithRootViewController, same effect navController = [[UINavigationController alloc] init]; navController.wantsFullScreenLayout = YES; navController.navigationBar.hidden = YES; [navController pushViewController:viewController animated:NO]; [window addSubview:navController.view]; [window makeKeyAndVisible]; return YES; } |
This leads me to the conclusion that something funny is happening when getting your navigation controller from a xib (without root view controller set) versus instantiating it in code. Which prompted me to file this bug. If you find that it is actually something that I am doing wrong here, please let me know.
License:
