search

OfTheWolf / UBottomSheet

iPhone Maps App bottom sheet - A Protocol Oriented Approach
MIT License
662 stars 68 forks source link

Keyboard does not pull the card up #26

Open guidedways opened 4 years ago

guidedways commented 4 years ago

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.

OfTheWolf commented 4 years ago

It is out of the scope of this project. But it is highly customizable. So you can add it easily.

guidedways commented 4 years ago

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).

guidedways commented 4 years ago

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.

OfTheWolf commented 4 years ago

Anything is highly customizable

Do you really think it is? You are confusing customizing the core library and customizing usage of it.

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.

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.

guidedways commented 4 years ago

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?

OfTheWolf commented 4 years ago

Yeah it suits to the example best in my opinion. I will consider adding it. Thanks for you suggestion.

gammelby commented 3 years ago

To be able to programmatically dismiss the keyboard in the application when dragging a sheet down, how do you detect that?

You get a didChange notification through UBottomSheetCoordinatorDelegate, but I can't find anything useful in the sheet or coordinator instance to actually access the current position.

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.