2015-03-23 20:28:42 +00:00
|
|
|
/**
|
|
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This source code is licensed under the BSD-style license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
* of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
*/
|
2015-03-14 08:22:25 +00:00
|
|
|
|
|
|
|
#import "RCTWebView.h"
|
|
|
|
|
|
|
|
#import <UIKit/UIKit.h>
|
|
|
|
|
|
|
|
#import "RCTAutoInsetsProtocol.h"
|
|
|
|
#import "RCTEventDispatcher.h"
|
|
|
|
#import "RCTLog.h"
|
|
|
|
#import "RCTUtils.h"
|
|
|
|
#import "RCTView.h"
|
2015-03-26 09:58:06 +00:00
|
|
|
#import "UIView+React.h"
|
2015-03-14 08:22:25 +00:00
|
|
|
|
2015-07-02 01:06:39 +00:00
|
|
|
NSString *const RCTJSNavigationScheme = @"react-js-navigation";
|
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
@interface RCTWebView () <UIWebViewDelegate, RCTAutoInsetsProtocol>
|
|
|
|
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
@property (nonatomic, copy) RCTDirectEventBlock onLoadingStart;
|
|
|
|
@property (nonatomic, copy) RCTDirectEventBlock onLoadingFinish;
|
|
|
|
@property (nonatomic, copy) RCTDirectEventBlock onLoadingError;
|
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation RCTWebView
|
|
|
|
{
|
|
|
|
UIWebView *_webView;
|
2015-07-08 00:07:52 +00:00
|
|
|
NSString *_injectedJavaScript;
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
- (instancetype)initWithFrame:(CGRect)frame
|
2015-03-14 08:22:25 +00:00
|
|
|
{
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
if ((self = [super initWithFrame:frame])) {
|
2015-04-21 01:01:46 +00:00
|
|
|
super.backgroundColor = [UIColor clearColor];
|
2015-03-14 08:22:25 +00:00
|
|
|
_automaticallyAdjustContentInsets = YES;
|
|
|
|
_contentInset = UIEdgeInsetsZero;
|
|
|
|
_webView = [[UIWebView alloc] initWithFrame:self.bounds];
|
|
|
|
_webView.delegate = self;
|
|
|
|
[self addSubview:_webView];
|
|
|
|
}
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
2015-08-24 10:14:33 +00:00
|
|
|
RCT_NOT_IMPLEMENTED(- (instancetype)initWithCoder:(NSCoder *)aDecoder)
|
2015-06-15 14:53:45 +00:00
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
- (void)goForward
|
|
|
|
{
|
|
|
|
[_webView goForward];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)goBack
|
|
|
|
{
|
|
|
|
[_webView goBack];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)reload
|
|
|
|
{
|
|
|
|
[_webView reload];
|
|
|
|
}
|
|
|
|
|
2015-06-15 14:53:45 +00:00
|
|
|
- (NSURL *)URL
|
|
|
|
{
|
|
|
|
return _webView.request.URL;
|
|
|
|
}
|
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
- (void)setURL:(NSURL *)URL
|
|
|
|
{
|
|
|
|
// Because of the way React works, as pages redirect, we actually end up
|
|
|
|
// passing the redirect urls back here, so we ignore them if trying to load
|
|
|
|
// the same url. We'll expose a call to 'reload' to allow a user to load
|
|
|
|
// the existing page.
|
|
|
|
if ([URL isEqual:_webView.request.URL]) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!URL) {
|
|
|
|
// Clear the webview
|
2015-06-15 14:53:45 +00:00
|
|
|
[_webView loadHTMLString:@"" baseURL:nil];
|
2015-03-14 08:22:25 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
[_webView loadRequest:[NSURLRequest requestWithURL:URL]];
|
|
|
|
}
|
|
|
|
|
2015-03-31 17:05:59 +00:00
|
|
|
- (void)setHTML:(NSString *)HTML
|
|
|
|
{
|
|
|
|
[_webView loadHTMLString:HTML baseURL:nil];
|
|
|
|
}
|
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
- (void)layoutSubviews
|
|
|
|
{
|
|
|
|
[super layoutSubviews];
|
|
|
|
_webView.frame = self.bounds;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)setContentInset:(UIEdgeInsets)contentInset
|
|
|
|
{
|
|
|
|
_contentInset = contentInset;
|
|
|
|
[RCTView autoAdjustInsetsForView:self
|
|
|
|
withScrollView:_webView.scrollView
|
|
|
|
updateOffset:NO];
|
|
|
|
}
|
|
|
|
|
2015-04-21 01:01:46 +00:00
|
|
|
- (void)setBackgroundColor:(UIColor *)backgroundColor
|
|
|
|
{
|
|
|
|
CGFloat alpha = CGColorGetAlpha(backgroundColor.CGColor);
|
|
|
|
self.opaque = _webView.opaque = (alpha == 1.0);
|
|
|
|
_webView.backgroundColor = backgroundColor;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (UIColor *)backgroundColor
|
|
|
|
{
|
|
|
|
return _webView.backgroundColor;
|
|
|
|
}
|
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
- (NSMutableDictionary *)baseEvent
|
|
|
|
{
|
|
|
|
NSMutableDictionary *event = [[NSMutableDictionary alloc] initWithDictionary: @{
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
@"url": _webView.request.URL.absoluteString ?: @"",
|
2015-03-14 08:22:25 +00:00
|
|
|
@"loading" : @(_webView.loading),
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
@"title": [_webView stringByEvaluatingJavaScriptFromString:@"document.title"],
|
2015-08-24 10:14:33 +00:00
|
|
|
@"canGoBack": @(_webView.canGoBack),
|
|
|
|
@"canGoForward" : @(_webView.canGoForward),
|
2015-03-14 08:22:25 +00:00
|
|
|
}];
|
|
|
|
|
|
|
|
return event;
|
|
|
|
}
|
|
|
|
|
2015-09-04 12:50:01 +00:00
|
|
|
- (void)refreshContentInset
|
|
|
|
{
|
|
|
|
[RCTView autoAdjustInsetsForView:self
|
|
|
|
withScrollView:_webView.scrollView
|
|
|
|
updateOffset:YES];
|
|
|
|
}
|
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
#pragma mark - UIWebViewDelegate methods
|
|
|
|
|
2015-06-15 14:53:45 +00:00
|
|
|
- (BOOL)webView:(__unused UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request
|
2015-03-14 08:22:25 +00:00
|
|
|
navigationType:(UIWebViewNavigationType)navigationType
|
|
|
|
{
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
if (_onLoadingStart) {
|
|
|
|
// We have this check to filter out iframe requests and whatnot
|
|
|
|
BOOL isTopFrame = [request.URL isEqual:request.mainDocumentURL];
|
|
|
|
if (isTopFrame) {
|
|
|
|
NSMutableDictionary *event = [self baseEvent];
|
|
|
|
[event addEntriesFromDictionary: @{
|
|
|
|
@"url": (request.URL).absoluteString,
|
|
|
|
@"navigationType": @(navigationType)
|
|
|
|
}];
|
|
|
|
_onLoadingStart(event);
|
|
|
|
}
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
2015-07-02 01:06:39 +00:00
|
|
|
// JS Navigation handler
|
|
|
|
return ![request.URL.scheme isEqualToString:RCTJSNavigationScheme];
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
2015-06-15 14:53:45 +00:00
|
|
|
- (void)webView:(__unused UIWebView *)webView didFailLoadWithError:(NSError *)error
|
2015-03-14 08:22:25 +00:00
|
|
|
{
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
if (_onLoadingError) {
|
2015-03-14 08:22:25 +00:00
|
|
|
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
if ([error.domain isEqualToString:NSURLErrorDomain] && error.code == NSURLErrorCancelled) {
|
|
|
|
// NSURLErrorCancelled is reported when a page has a redirect OR if you load
|
|
|
|
// a new URL in the WebView before the previous one came back. We can just
|
|
|
|
// ignore these since they aren't real errors.
|
|
|
|
// http://stackoverflow.com/questions/1024748/how-do-i-fix-nsurlerrordomain-error-999-in-iphone-3-0-os
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
NSMutableDictionary *event = [self baseEvent];
|
|
|
|
[event addEntriesFromDictionary: @{
|
|
|
|
@"domain": error.domain,
|
|
|
|
@"code": @(error.code),
|
|
|
|
@"description": error.localizedDescription,
|
|
|
|
}];
|
|
|
|
_onLoadingError(event);
|
|
|
|
}
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)webViewDidFinishLoad:(UIWebView *)webView
|
|
|
|
{
|
2015-07-08 00:07:52 +00:00
|
|
|
if (_injectedJavaScript != nil) {
|
|
|
|
[webView stringByEvaluatingJavaScriptFromString:_injectedJavaScript];
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// we only need the final 'finishLoad' call so only fire the event when we're actually done loading.
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
if (_onLoadingFinish && !webView.loading && ![webView.request.URL.absoluteString isEqualToString:@"about:blank"]) {
|
|
|
|
_onLoadingFinish([self baseEvent]);
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
@end
|