For some reasons we have situations when we have to set properties from a NSDictionary to an UIView.
Everything was OK 'till the iOS 6 was released. Now -[UITableView setValue:value forKey:#"style"] is crashing the app. In iOS 6 it calls setValue:forUndefinedKey: but in iOS 5.1 it doesn't (and everything is OK then). I know that style UITableView's property is read-only but... why? I have my own implementation of setValue:forUndefinedKey: but I don't want to filter somehow such properties (it'll be difficult to).
I know that style UITableView's property is read-only but... why?
Because Apple decided to be so, and they probably have a pretty good reason for it. Don't try setting readonly properties, they will crash your app.
Related
I am working on an iPad application which is converted to ARC. Application is for os >= ios 5.0. So my doubt is that, how do I manage viewOutlets? I use -(void)didReceivememoryWarning to set ViewOutlets to nil. But in ios 5.0 and 5.1 application shows lots of memory leaks. As -(void)viewDidUnload is deprecated in ios 6.0 , I am not using the same in the application. Is the correct way to manage outlets? Please give me a quick reply.
ARC (automatic reference counting) features is available in iOS 5 and ahead (iOS 6 and so on..) version.
When you are using ARC unable in your project, you dont need to `manually release any object` that you have allocated for your stuff.
ARC will automatic handle this one.so it will beneficial for `Memory Management`.
Hope ,You understand what i m trying to say.
for more clarification , please refer below link:
To ARC or not to ARC? What are the pros and cons?
ARC, worth it or not?
Good Luck !!!
There is NO DIFFERENCE in how you code for iOS 5 vs. iOS 6.
If you are having problems, it's because you don't understand what viewDidUnload does and when it's called.
viewDidUnload is called when the view of the controller is unloaded. In iOS 6, views are never unloaded. In iOS 5 and before, views were almost never unloaded either. So in both cases, pretty much viewDidUnload is never called.
If your program is leaking stuff, it's because you are not releasing things. You always need to release instance variables in dealloc. I suspect that this is your problem.
When the controller's view is unloaded (which only happens in iOS 5 and before, but this is irrelevant), viewDidUnload allows you to optionally discard some resources to save memory, as long as they are resources that will be re-created when the view is loaded again. This usually includes properties and instance variables that are outlets (since when the view is loaded, it will load the Xib again and re-connect the outlets to new objects), as well as any variables that are set in viewDidLoad.
If you coded your program correctly, I can go in there and remove viewDidUnload, and it would not have any effect on the correctness of the program. (Since viewDidUnload is almost never called anyway.)
You should almost never have to use didReceiveMemoryWarning either.
I have a problem where I'm getting a bad access code for my app running iOS 6. I'm currently segueing to another navigationBar based view, and getting the bad access code inside the class I'm segueing to (during the segue!). The trace goes back to the first thing I release inside of Dealloc (which is just a standard UILabel).
Is this a possible problem with iOS 6? I thought dealloc was deprecated starting in iOS 6? Does anyone have any ideas? Thanks!
You cannot use release with ARC. You probably don't even need to override dealloc.
My app should support both iPhone resolutions (5 and older) using iOS 5 and iOS 6. When I use autolayouts in IB, on iOS 5 app crashes like this: link
So, I am trying to use NSLayoutConstraint in code, but unsuccessfully yet.
Subquestions:
I am adding constraints in viewDidLoad method, but is it correct?
Does updateViewConstraints invoke by framework? I have never seen that it was invoked.
I tried to use examples from apple's docs, but it was without effect to view.
Anybody knows how to do it?
PS: I know it's possible to make it manually by setting frames, but I would like to use NSLayoutConstraints.
UDP: Yes, I know, that's why i use NSLayoutConstraint in code. I can make condition for determining iOS version. The question is about iOS6.
The AutoLayout feature is only compatible with iOS6 and is not supported in iOS5. Thus the crash
If you intend your app to be compatible with iOS5, you can't use AutoLayout in your XIB files.
You can only use older methods, like the AutoResizingMask for example (which is often sufficient for most cases anyway).
the problem is:
while setting transient undefined attribute in -(void)didSave metod after first save: does not make context dirty in iOS 4.3 (Simulator), but makes it dirty in iOS 5.0 Simulator.
I need the same behaviour in iOS 4.3.
So - what is the cheapest way to make context dirty between 2 (BOOL)save: calls.
Once again - in iOS 5 setting transient attribute in -(void)didSave makes context dirty, but on ios 4.3 not.
and more - I need to make all objects that were changed in didSave method "dirty"
Have you tried subclassing NSManagedObjectContext and returning true for the hasChanges property or similar?
At a great number of requests from people using older iOS hardware, I'm currently refactoring and optimizing my app so it will work on iOS 3. That being said I've got a glitch with my UITabBar that I can replicate on all of the iPhone 3G units I've tested it on.
The glitch appears to have been fixed in iOS 4, but I was wondering if before that time, anyone else had this glitch as well and had figured out a (relatively elegant) workaround for it.
The problem is what you can see below; when a memory warning occurs and all of the views offscreen are released, when I bring a view controller with a tab bar back on screen, all of the UITabBarItems that are supposed to be in it are gone. As far as I can see, they're not being drawn at all; ie tapping the tab bar has no effect. After setting breakpoints and examining the UITabBar and its items in memory, they're all still there (ie not getting released), just that they're not getting redrawn when the UITabBar is re-created in the controller loadView method.
My app works similar to the official Twitter app in that I implemented my own version of UITabBarController so I could control the integration of it with a parent UINavigationController properly. I set it up as closely as possible to the original UITabBarController class though, with all of the child view controllers handling their own respective UITabBarItems and initializing them inside the class' init methods. Once the child view controllers are passed to my TabController object via an accessor method, the tabBarItems are accessed and added to the UITabBar view.
Has anyone seen this behaviour before and know of a way I can fix it? I'm hoping there's a really simple fix for this since it already works in iOS 4, so I don't want to hack it up too badly.
Thanks a lot!
After a bit of research, I think I found a solution to this. It's not the most elegant solution I was after, but it definitely works.
I'm guessing after a memory warning is triggered, something is happening to the UITabBarItem objects that basically renders them corrupt. I tried a lot of things (flushing out the UITabBar, re-creating the controllers array etc), but nothing worked.
I finally discovered that if you completely destroy the UITabBarItems and allocate new ones in their place, then those ones will work. :)
So my final solution to this was to add an extra condition in the viewDidLoad method of my controller that if the detected system was iOS 3, and there was already an array of UITabBarItems, it would go through each one, copy out all of the properties needed, destroy it, allocate a new one and then copy the old properties over to the new one.
I'm still going to keep an eye out for a better solution (I think there's a bit of overhead in this method), but thankfully at this stage, iOS 3 legacy support is becoming less and less of an issue. :)