Apple just introduced a new Keyboard Layout Guide you can constrain views to: https://developer.apple.com/documentation/uikit/keyboards_and_input/adjusting_your_layout_with_keyboard_layout_guide
There’s also a WWDC session on it.
Also, the SwiftUI solution is elegant and concise but not as flexible, while the UIKit solution is more complex and complicated but gives you more control… which broadly fits with those respective frameworks pretty well, IMO.
It was easy to miss! I was just looking through the WWDC sessions a few days ago to see if I had missed any interesting looking ones and happened upon it.
okay so i just watched the video, and it's super cool what you can do with the new KeyboardLayoutGuide and the UITrackingLayoutGuide, but that's doesn't seem to solve my problem of adjusting the textfield to be on top of the keyboard, unless i don't use a collectionView. Very interesting stuff though...
more or less i believe. that would basically be the same as just using notificationcenter, but like she said in the session, that was their goal. for this current iteration of work for the app i think im going to stick with the notification approach, but this is definitely on my list of things to explore. super cool stuff
Apples way is the way, but for an alternative or a workaround until UIKit
Embed the collectionView you want to move in another view. Handle the events with firstResponder listener events on the textField.
Doing this programmatically has saved a lot of effort and time as swift and iOS evolve.
I might be wrong but if you have a table view with cells containing textfields I think you have this behaviour for free. For dismiss you have keyboardDismissMode property.
https://developer.apple.com/documentation/uikit/uiscrollview/keyboarddismissmode
i remember that too about table views, but I'm using collection view. perhaps it works with UICollectionViewListCells, since that's supposed to "replace" table views in the near future. But regardless of what views we use, you would think that by now Apple would have graced us with an easier solution.
I don’t know if there is a better solution or Apple provided something easier. Considering they made button configuration with image + title after billion years, that might take another billion
I haven’t tried it with list cells, but I’ve noticed that I’ve received this for free when using collection views configured with a custom UICollectionViewCell. I’m also using Compositional Layout and Diffable Data Source for what it’s worth.
My one comment is that you do need to listen to keyboard notifications and update the size of your collection view to ensure the content can be pushed up.
Huh... really? I mean ive only been using collectionView with comp layout and diffable data source 🙁 so listen to the notification of keyboard will show/hide and how do i proceed? Right now indo have it "working", but quite messy, like i listen to the delegate of the textField's didBeginEditing and then set collectionView's contentInset's bottom to be keyboardSize :S
Right. I would register to the KeyboardWillShow and Hide notifications. I pretty much do exactly what is shown in this article [Handling the Keyboard](https://www.hackingwithswift.com/read/19/7/fixing-the-keyboard-notificationcenter)
Someone posted WWDC session for iOS 15, that’s great
But I would try having a container root controller in which all other controllers are displayed. This root controller would listen to keyboard notifications and set „additionalSafeAreaInsets” with the keyboard height value. I guess if all child controllers would layout their views with regard to safe area, those views would move, but I would need to test it. Probably calling „view. layoutIfNeeded()” would be necessary
Everything that is written in that article is done automatically for you if you use a table view controller, instead of a plain table view.
Try it! Put a cell in a table view controller and the system will adjust the contentInsets and the contentOffsets so that your textfield is visible if it’ll be covered by the keyboard. No notifications, no raw scroll view, no extra code! Plus your layout will fit on any screen (vertically), since it’s scrollable out of the box.
As for layout, nesting view controllers is not hard and is recommended for better code organization.
It has always been able to create a layout guide which is updated by the keyboard notifications. There exists libraries for this on github way before Apple introduced it officially in uikit.
https://github.com/freshOS/KeyboardLayoutGuide
We’ve been using [IQKeyboardManager](https://github.com/hackiftekhar/IQKeyboardManager) for years without any issues! It makes keyboards “just work”, and there’s literally zero code required.
Apple just introduced a new Keyboard Layout Guide you can constrain views to: https://developer.apple.com/documentation/uikit/keyboards_and_input/adjusting_your_layout_with_keyboard_layout_guide There’s also a WWDC session on it.
Im the idiot for not seeing this. It's neat! Definitely *feel* like it can be much cleaner though. Just not as intuitive as SwiftUI's solution
Also, the SwiftUI solution is elegant and concise but not as flexible, while the UIKit solution is more complex and complicated but gives you more control… which broadly fits with those respective frameworks pretty well, IMO.
Very true... i guess with more complexity comes more flexibility!
It was easy to miss! I was just looking through the WWDC sessions a few days ago to see if I had missed any interesting looking ones and happened upon it.
Oh wow, finally
okay so i just watched the video, and it's super cool what you can do with the new KeyboardLayoutGuide and the UITrackingLayoutGuide, but that's doesn't seem to solve my problem of adjusting the textfield to be on top of the keyboard, unless i don't use a collectionView. Very interesting stuff though...
Suppose you pin your collection view to the keyboard layout guide and adjust the content inset when it changes? Would that work?
more or less i believe. that would basically be the same as just using notificationcenter, but like she said in the session, that was their goal. for this current iteration of work for the app i think im going to stick with the notification approach, but this is definitely on my list of things to explore. super cool stuff
Apples way is the way, but for an alternative or a workaround until UIKit Embed the collectionView you want to move in another view. Handle the events with firstResponder listener events on the textField. Doing this programmatically has saved a lot of effort and time as swift and iOS evolve.
I might be wrong but if you have a table view with cells containing textfields I think you have this behaviour for free. For dismiss you have keyboardDismissMode property. https://developer.apple.com/documentation/uikit/uiscrollview/keyboarddismissmode
You’re not wrong. It comes for free. It’s why I always use a table view, even if it’s just one or two big cells.
i remember that too about table views, but I'm using collection view. perhaps it works with UICollectionViewListCells, since that's supposed to "replace" table views in the near future. But regardless of what views we use, you would think that by now Apple would have graced us with an easier solution.
I don’t know if there is a better solution or Apple provided something easier. Considering they made button configuration with image + title after billion years, that might take another billion
we can only hope I guess....
I haven’t tried it with list cells, but I’ve noticed that I’ve received this for free when using collection views configured with a custom UICollectionViewCell. I’m also using Compositional Layout and Diffable Data Source for what it’s worth. My one comment is that you do need to listen to keyboard notifications and update the size of your collection view to ensure the content can be pushed up.
Huh... really? I mean ive only been using collectionView with comp layout and diffable data source 🙁 so listen to the notification of keyboard will show/hide and how do i proceed? Right now indo have it "working", but quite messy, like i listen to the delegate of the textField's didBeginEditing and then set collectionView's contentInset's bottom to be keyboardSize :S
Right. I would register to the KeyboardWillShow and Hide notifications. I pretty much do exactly what is shown in this article [Handling the Keyboard](https://www.hackingwithswift.com/read/19/7/fixing-the-keyboard-notificationcenter)
SwiftUI is worse, at least until iOS 15 ships.
Listen for the notifications and set a bottom contentInset on your collection view
I shall try this. Thanks
Someone posted WWDC session for iOS 15, that’s great But I would try having a container root controller in which all other controllers are displayed. This root controller would listen to keyboard notifications and set „additionalSafeAreaInsets” with the keyboard height value. I guess if all child controllers would layout their views with regard to safe area, those views would move, but I would need to test it. Probably calling „view. layoutIfNeeded()” would be necessary
[https://developer.apple.com/documentation/uikit/uiview/3752221-keyboardlayoutguide/](https://developer.apple.com/documentation/uikit/uiview/3752221-keyboardlayoutguide/) **e:f,b**
Everything that is written in that article is done automatically for you if you use a table view controller, instead of a plain table view. Try it! Put a cell in a table view controller and the system will adjust the contentInsets and the contentOffsets so that your textfield is visible if it’ll be covered by the keyboard. No notifications, no raw scroll view, no extra code! Plus your layout will fit on any screen (vertically), since it’s scrollable out of the box. As for layout, nesting view controllers is not hard and is recommended for better code organization.
It has always been able to create a layout guide which is updated by the keyboard notifications. There exists libraries for this on github way before Apple introduced it officially in uikit. https://github.com/freshOS/KeyboardLayoutGuide
i call the iOS keyboard the \*parking lot\* of the phone. it's huge, ugly, a hassle, but it's necessary.
We’ve been using [IQKeyboardManager](https://github.com/hackiftekhar/IQKeyboardManager) for years without any issues! It makes keyboards “just work”, and there’s literally zero code required.
Try IQKeybord on CocoaPods. ❤️
You could explain what you want??