I have a UICollectionView that needs to be updated, reloaded as I need. I have this implemented in other projects but specifically in this one it does not allow the UI to update, even though I can get the code to execute upon reloadData, reloadSections:, and invalidateLayout.
I can see the delegate and datasource methods for the collection view get called when I do this, however the UI does not update at all.
Any advice for workarounds or possible solutions?
My code is fairly generic so I can not understand why this is happening. I subclassed the UICollectionView, but did not add any subclassed initializers to the subclass since I have gotten away with this in other projects and I do not think it is the issue.
I have seen some force the operations onto the mainQueue, but I don't think this is the issue anyway since UIKit updates only run on the main queue.
EDIT: extra info:
I perform a reloadData or reloadSections, THEN I called invalidateLayout on collectionView.collectionViewLayout
Related
I've got this UICollectionView set up with a fetched results controller, using core data. I use UIImagePickerController to add items to the UICollectionView. Now when I tap one of the photos stored on my device, it will be added to my managed object context and will be inserted into the UICollectionView.
Now when I quickly add multiple items, the app crashes with the following error:
2012-10-07 13:17:46.770 PhotoLibrary[2444:907] *** Assertion failure in -[UICollectionView _endItemAnimations], /SourceCache/UIKit/UIKit-2372/UICollectionView.m:2801
It seems like it can't handle adding an item while the animation of the previous added item hasn't ended yet. Just happens when you add them really quickly, but some of the users will do that.
Is there a good way to just wait and add the item when the other one is finished? Users should be able to add them "real time", so I can't just run all the changes at once.
The error only occurred when adding a few items quickly. But the real problem wasn't really related to the animation. I was creating the managed objects used to store the new items in a block, used in the ALAssetsLibrary's assetForURL:resultBlock: method.
Took a while to figure out that that was the problem, the managed objects were created in a separate thread. Turns out that managed objects doesn't handle that well.
Now moved the creation of the new items outside of the block, now it just works fine.
Without example code, I'm presuming the problem occurs when calling the - (void)reloadData method after inserting data into the UICollectionView. The documentation for this method explicitly calls out the fact you shouldn't call this method in the middle of an animation caused by insertion/deletion since the insertion/deletion will invoke the animation code automatically.
Some other notable methods are - (void)insertItemsAtIndexPath:(NSArray *)indexPaths and - (void)performBatchUpdates:(void (^)(void))updates completion:(void (^)(BOOL finished))completion. I have not used the batch method, but I've used the insert method a number of times and it works well.
I'm working with some code that I need to refactor. A view controller is acting as a container for two other view controllers, and will swap between them, as shown in the code below.
This may not be the best design. Swapping the view controllers in this way might not be required. I understand that. However, as I work with this code I want to further understand what happens with the addChildViewController call. I haven't been able to find the answer in Apple's docs or in related questions, here (probably an indication that the design needs to change).
Specifically - how does the container view controller handle a situation where it is asked to add a child view controller, which it has already added? Does it recognise that it has already added that view controller object?
E.g. if the code below is inside a method - and that method is called twice...
[self addChildViewController:viewControllerB];
[self.view addSubview:viewControllerB.view];
[viewControllerB didMoveToParentViewController:self];
[viewControllerA willMoveToParentViewController:nil];
[viewControllerA.view removeFromSuperview];
[viewControllerA removeFromParentViewController];
Thanks,
Gavin
In general, their guidelines for view controller "containment", when one contains another, should be followed to determine whether you will need to implement containment.
In particular, worrying about adding the same child view controller twice is like worrying about presenting the same view controller twice. If you've really thought things through, you shouldn't need to face that problem. Your hunch is correct.
I agree that Apple's docs should be more up-front about what happens with weird parameters or when called out of sequence, but it may also be a case of not wanting to tie themselves to an error-correcting design that will cause trouble down the road. When you work out a design that doesn't ever call these methods in the wrong way, you solve the problem correctly and make yourself independent of whatever error correction they may or may not have - even more important if you consider that, since it's not documented, that error correction may work differently in the future, breaking your app.
Going even a bit further, you'll notice that Apple's container view controllers can't get in an invalid state (at least not easily with public API). With a UITabViewController, switching from one view controller to another is an atomic operation and the tab view controller at any point in time knows exactly what's going on. The most it ever has to do is remove the active one and show the new one. The only time where it blows everything out of the water is when you tell it "you should blow everything out of the water and start using these view controllers instead".
Coding for anything else, like removing all views or all view controllers no matter what may in some cases seem expedient or robust, but it's quite the opposite since in effect one end of your code doesn't trust the other end of your code to keep its part of the deal. In any situation where that actually helps you, it means that you've let people add view controllers willy-nilly without the control that you should desire, and in that case, that's the problem you should fix.
There's a UIViewController method -(void)viewDidUnload. I tried putting NSLog("unloaded"); in there to see when the view is unloaded, but nothing was printed to the console.
Where do I put my code, so that before a view unloads I can perform an action?
If you read the viewDidUnload documentation, you see that it's related to low memory conditions and may be called to help with that. There is also a viewWillUnload that get's called before the view is released. It's also related to low memory.
If you're only interested in when the view is no longer seen, there are will/did disappear methods.
Are you using storyboard or not?
Have you tried any of this methods
-(void) viewWillUnload{}
or
-(void)viewWillDisappear:(BOOL)animated{}
If you are using storyboards the one that will that usually performs is viewWillDisappear.
I was trying to fix a memory leak in my application and stumbled upon a very interesting thing. Now i'm not sure if there's a bug that i made somewhere or simply misuse of the technology so i'll try to get things clear with your help. Here's what happens:
i create a custom uiviewcontroller that loads its view from nib file
i release the controller
controller's dealloc method gets called where i release a custom view that i've specifically added to the view hierarchy as an outlet (i made a retainable property out of it). It has a dealloc method with a call to nslog.
the main view in the nib file (connected to controller's view outlet) is also a subclass of a uiview which also has a call to nslog in its dealloc
The problem is - even though the uiviewcontroller's dealloc is getting called, neither the main view nor the child (the one with outlet) gets released (their NSLogs don't fire).
Is it normal that this happens? Maybe iOS doesn't release the views right away? Or should i start looking for bugs in the code? If so - what could be the most probable causes?
Thanks for reading
The problem with late night debugging is that you don't consider even the simplest angles. Since i like to know how things work and do everything from scratch, i've created my own system for switching view controllers. The problem was that even though i used to deallocate the view controller when needed, i forgot to remove it from superview, thus having one more retain too many. Now there's a leak somewhere else, but i'm sure i'll solve it myself. Thanks for your comments.
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. :)