I am encountering a strange behaviour in the way iOS14 handles a CollectionView. I have noticed that (changing from iOS13.5 to iOS14) the order in which the UICollectionViewCells are displayed is wrong. The pictures below are screenshot from exactly the same code (in xCode12), the only difference is that the correct ones are with a build for iOS13.5 and from a simulator with an iPhone 11 on iOS13.5, while the wrong ones are with a build for iOS14 and from a simulator with an iPhone 11 on iOS14. Everything else (code, settings, etc) is exactly the same:
Picture 1, how the collection should display (correct in iOS13.5):
If the same code is built with iOS14 and run on the same iPhone simulator with iOS14, the result is the following (not the order is wrong: it is reversed):
In the datasource (which is an array with the labels) all is correct and the cellForItemAt delegate works correctly.
There is definitely something being handled differently in iOS14. One last example is another screenshot where the sizes of the boxes are different (depending on the length of the labels):
Correct (building for iOS13.5) is:
While building for iOS14 yields the following:
Again, the code is exactly the same, I am just building the project for different iOS versions. It seems to me there may be a bug somewhere in the way collections have been modified for iOS14. Any help or thought would be welcome.
I have found how to solve this, and I think it points to some changes in how the management of the delegates for UICollectionView in iOS14 may have taken place.
The solution is simple: I have just added
cell.setNeedsDisplay()
in
func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath)
before returning the cell.
No other change to the code. I noticed that in iOS14 draw() for the cell was not called as in iOS13.5. Thus adding the setNeedsDisplay() forced the redraw of the cell, which in iOS13.5 was happening without the new line of code.
I would be interested to know if anybody knows of any change. Thanks
Related
I do have a crash issue in my app where I have implemented custom layout collection view to show book pages in iPhone. When I do re ordering of pages (ex - if I want to pace the last to 1st place in the book) the app some times crashes in my custom layout code (layoutAttributesForItemAtIndexPath). Looking deeper into the code found that API is receiving in indexPath which is out of bounds. The row value is too big which is converting to -1 and since there will be no data at this location in my layout attributes array, the app crashes. This happens on iOS 9.x and not on 10.x.
Does anyone know why I am getting this crash.
PS: Stacktrace attached.
You have to implement layoutAttributesForItemAtIndexPath():
override func layoutAttributesForItem(at indexPath: IndexPath) -> UICollectionViewLayoutAttributes? {
return cache[indexPath.item]
}
I found this solution here and it solved my problem
When the user selects a row in my table, I need to load a bunch of data with CoreData. This takes several seconds (at least when running on the simulator - haven't tested on a device yet, but I imagine it will still be pretty long). I want to display a loading popover screen (I'm developing for iPad) when the user selects a row, then have it disappear once the data is loaded.
When working with UIButtons, I've always done this by triggering both a TouchDown and TouchUp method. I put the code to display the popover on the TouchDown, then do all my actual work (so in this case loading from CoreData) in the TouchUp. Then at the end of TouchUp, I close the popover.
Is there a way to split up touches in a table view the same way as ones on a button?
So while I was typing up the question I came across something in the Apple Docs for willSelectRowAtIndexPath and it looks like that is there to address this very issue. I didn't see any other topics on this on SO, so I figured I'd make use of this "Answer own question - Q&A" feature on here, so maybe people looking for this in the future will find it a little easier.
Huge FYI block:
I should note that willSelectRowAtIndexPath is actually supposed to return an NSIndexPath, unlike didSelectRowAtIndexPath (which returns void). However, I originally had
-(void)tableView:(UITableView *)tableView willSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
//stuff
}
Note the void return type. Xcode (Version 4.5) allowed this without any errors or warnings (and even had it for me in the autocomplete list). When I ran the code this way, I always hit an invisible breakpoint in libobjc.A.dylib'objc_autorelease: (maybe becaues I have the "All Exceptions" breakpoint enabled?). I couldn't get past this breakpoint, I never got any debug information in the debugger output console, and the app never terminated. I happened to look at the Apple Doc again and notice that it was supposed to return an NSIndexPath (specifically, the index path the code should interpret as being the one that was selected), but if I didn't happen to see it there, I never would have known what the problem was.
My app is using a 2nd UIWindow to show a special screen if iOS wants to take a screenshot of the app.
By accident I used [UIWindow makeKeyWindow:] on my main window if I wanted to remove the 2nd window again. This really should be makeKeyAndVisible: instead but I'm wondering why it worked at all.
I mean: most of the time (99%), my 2nd window was removed as expected and my main window became visible.
I'm asking because I'm wondering if I have really found the problem or if there might still be something else?
Or could it be that the method was incorrectly bound in (previous) MonoTouch versions?
Each method maps to the selector of the same name makeKeyAndVisible and makeKeyWindow.
Or could it be that the method was incorrectly bound in (previous) MonoTouch versions?
GIT history shows (me ;-) that both never changed since they were first added (more than two years ago).
Documentation about the former states:
You can also hide and reveal a window using the inherited hidden property of UIView.
Maybe this happens in your code (or even within the iOS code).
I am a relative novice who is teaching himself Objective-C on Xcode to develop some simple iPhone game apps. I have done some reading on this but fear I'm missing something basic and obvious.
I made a simple "Hello, World" and, based on opinions in various forums, I decided to do a Tic Tac Toe. I found a nice video and built a version based on that, which ran fine. However, my own interpretation is already running into trouble.
I'm using Xcode 4.0.2 on Snow Leopard. I chose a View-Based Application template and pulled a large image view onto the layout to hold a PNG called board. I put nine small image views on the large one to hold individual cells for X and O (and created some PNGs for the images). I just attached board.png to the big image view through IB so that works fine.
Next I tried to associate cell 1 with x.png by assigning it to a variable called ximg. This is all set up in the view controller's viewDidLoad method like so -- "ximg = [UIImage imageNamed:#"x.png"];". I then used the code "cell1.image = ximg;" -- also in viewDidLoad. X appeared on the board when I built and ran.
My next step was cell 2. I wanted to use a variable in a custom method this time, so I could change it in the future. I declared a method "- (void)setcell2" (bad camelCase, I know). I put the following method into my view controller implementation file:
-(void)setcell2 {
cell2.image = ximg;
}
I also added the following message to viewDidLoad -- "[self setcell2];"
As you'd guess, I was figuring that when the app loaded, viewDidLoad would send that message to setcell2, which would attach another X in the second box, but this didn't happen.
If someone could give me some idea of what I'm overlooking, I'd be gratified. Example code is appreciated but I can figure that out with time. This is not homework. Thanks for reading!
Most likely you haven't set your cell up properly in Interface Builder. Make sure you have connected the property to the outlet.
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. :)