search

YuAo / WUEmoticonsKeyboard

Customizable emotion icons keyboard for iOS.
MIT License
339 stars 74 forks source link

Keyboard Height #13

Closed mohpor closed 9 years ago

mohpor commented 9 years ago

Hi, This is one of the coolest frameworks I've came across on Github and I thank you for sharing it with us.

The bounds of the input view is determined by WUEmoticonsKeyboardDefaultSize in your code, a static, predefined CGSize. In my experience, it leads to various bugs and view hiccups and we should avoid it. Meanwhile, InputView is contained (a subview) of UIInputSetHostView and we can easily read the actual size of the keyboard from.

To conclude: In WUEmoticonsKeyboard.m at -(void)setup

if (CGRectIsEmpty(self.bounds)) {
        self.bounds = (CGRect){CGPointZero,WUEmoticonsKeyboardDefaultSize};
  }

should be replaced with:

if (CGRectIsEmpty(self.bounds)) {
      self.bounds=(CGRect){CGPointZero,self.superview.bounds.size};
}
YuAo commented 9 years ago

Hi, mophor

Thanks for the suggestion.

It is true that the initial size of the keyboard view is determined by WUEmoticonsKeyboardDefaultSize. And this decision is based on the following facts:

  1. By providing a reasonable default size (which is currently 320x216) for the keyboard view may eliminate the work of setting up the keyboard frame for the framework user.
  2. When assigning a view to the inputView property of a UITextView or UITextField, the assigned view is automatically resized to fit the screen width (or the input area width). So a keyboard view having a default width of 320 is not a problem. The keyboard view with the default size works on iPad and works even if the device is in landscape mode.
  3. There're no negative effects of having a default size on setup - a framework user can choose to assign a different frame/size/bounds to the keyboard view after alloc/init.

After considering your suggestion, I find this suggestion places a few flaws:

  1. Your suggestion relies on an undocumented behavior.

    InputView is contained (a subview) of UIInputSetHostView and we can easily read the actual size of the keyboard from.

    The UIInputSetHostView and its relationship with the keyboard view is not documented. Apple may change the keyboard's internal implementation in a future release of iOS.

  2. When the -[WUEmoticonsKeyboard setup] method is executing, the WUEmoticonsKeyboard is in the middle of its initialization process. It is not added to any view/window yet, so the superview of the WUEmoticonsKeyboard is nil and self.superview.bounds.size is empty.

After reconsidering my current implementation, I do find an issue(inconsistency).

When a framework user creates a WUEmoticonsKeyboard using the designated initializer initWithFrame: and passes CGRectZero, he/she will get a WUEmoticonsKeyboard with the default size(WUEmoticonsKeyboardDefaultSize). This is inconsistent with the expectation of getting a keyboard view with an empty size.

I fixed this in the latest commit 3fc8a0d3c33dcfd421266d3c41e896b8af4a7d8b