Swizzle it just a little bit #197
Swizzle it just a little bit #197
Conversation
Thanks for the PR! I'm wondering if just replacing the inputAccessoryView method on the existing UIWebBrowserView class is less intrusive that replacing the class entirely? Looking at something like https://github.com/cjpearson/cordova-plugin-keyboard/blob/master/src/ios/CDVKeyboard.m#L118-L146, I feel like it's less code and fails pretty gracefully. Also it's potentially less of a red flag to Apple if at runtime the class itself doesn't change, although from what I can tell they are just searching for string matches. In the interest of transparency it might make sense to pull this out into its own plugin. So if you do want to hide the bar, you are explicitly opting in to potential future rejection, considering there is no way to do this with public APIs at the moment. Any thoughts? |
I thought about just replacing the method, but wasn't sure how to do it. Now that I see the example, it looks pretty straightforward! Personally, I don't think it will be less of a red flag - I think the rejections are based on string matching, but I like that it is simpler. I see where you are coming from in wanting to shield users from possible rejection. Feel free to close this if you want to go with cjpearson's simpler approach and/or want to pull this out into a separate plugin. |
Yeah the reason I thought there might be more than just string matching was I'll admit to probably overthinking this. If apps were to start getting If you don't mind updating the PR to only swizzle the method I'll merge it On Tue, May 3, 2016 at 12:06 PM Tony Homer notifications@github.com wrote:
|
The one thing I don't like about this approach is the inclusion of the obfuscated class name strings. |
* master: Update keyboard.js chore(): update to 2.1.0 added mock for browser platform # Conflicts: # www/ios/keyboard.js
@jacquesdev Thanks for the comment! I merged the recent changes from master into my PR branch to resolve the conflict. |
@tony-- looks great! Could you remove the @jacquesdev for future reference you can install any plugin from github at any time: |
@tlancina - right you are, sorry about that! I removed it; also removed the commented out references to |
@tony-- thank you for your contribution and patience! |
@tlancina glad to have an opportunity to help out a bit! |
Thanks to both of you much appreciated :) |
Fixes #179
This approach amounts to a simplified version of hackishlyHidesInputAccessoryView, but removes all instances of the string UIWebBrowserView (as I believe this string is what was causing the App Store rejections).
This version retains classname checking but only checks for the "UIWeb" prefix in order to avoid referencing the string UIWebBrowserView.
The classname check is needed to avoid swizzling every view in webView.scrollView.subviews (originally I thought I would be able to limit this via respondsToSelector: @selector(inputAccessoryView), but then I realized that every UIView responds to @selector(inputAccessoryView)).
According to this SO post, this classname check will not cause problems with app store.
However, if it is still a concern, the classname check could be removed but this might have a performance impact on some apps that have a lot of subviews (e.g., apps with a lot of images).