-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keyboard does not pull the card up #26
Comments
It is out of the scope of this project. But it is highly customizable. So you can add it easily. |
It may be - but the example feels broken. One may simply give up on using the library because of no out of the box support (like other bottom sheet libraries, such as BulletinBoard). |
Anything is highly customizable - that's the nature of writing code :) But if you're going to offer a component that's highly usable, then it's okay to bring into scope basic things that users would expect. |
Do you really think it is? You are confusing customizing the core library and customizing usage of it.
The challenging and most expected part of the library so far is the scrolling behaviour. As there may be different use case about what you have asked it is left to your responsibility. Just observe the keyboard with 2 lines of code and move the sheet or stretch to the full height or almost full height with 1 line of code. |
Just my two cents :) No offense intended. I mean to say that the bottom sheet can be generalized into a number of general use cases, one of which is what your first example displays - an input field for perhaps a pop over login screen or something similar. The bottom sheet library is controlling the scrolling / gestures but part of it should also be automatic handling of cases where the keyboard covers it. View controllers and table view controllers for instance have support built in for the very reason, even though it could be argued that the developers could write two lines of additional code. At Times it’s not just two lines of code - there may be several other things like bottom view constraints or internal constraints that are required to be added or removed etc for this to work across landscape and portrait transitions. Irrespective, I strongly believe this library could do with an optional flag that allows it to handle keyboard showing / hiding without additional support from developers trying to consume it. Even if it’s something you don’t wish to do, I think the example looks terrible the way it currently is - broken. Perhaps the example code could do with a bit of polish then? |
Yeah it suits to the example best in my opinion. I will consider adding it. Thanks for you suggestion. |
To be able to programmatically dismiss the keyboard in the application when dragging a sheet down, how do you detect that? You get a I may very well overlook something obvious - or perhaps there is a better way to accomplish the overall use case of making the keyboard show/hide like in e.g. the Apple Maps app. |
In the first "Apple Maps" example, if you tap on the search field, the card should pull up automatically to allow text input. This seems broken / half-baked.
The text was updated successfully, but these errors were encountered: