2015-03-23 20:28:42 +00:00
|
|
|
/**
|
|
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
|
|
|
*
|
2018-02-17 02:24:55 +00:00
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
2015-03-23 20:28:42 +00:00
|
|
|
*/
|
2015-02-20 04:10:52 +00:00
|
|
|
|
|
|
|
#import "RCTScrollView.h"
|
|
|
|
|
|
|
|
#import <UIKit/UIKit.h>
|
|
|
|
|
|
|
|
#import "RCTConvert.h"
|
|
|
|
#import "RCTEventDispatcher.h"
|
|
|
|
#import "RCTLog.h"
|
|
|
|
#import "RCTUIManager.h"
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
#import "RCTUIManagerObserverCoordinator.h"
|
|
|
|
#import "RCTUIManagerUtils.h"
|
2015-02-20 04:10:52 +00:00
|
|
|
#import "RCTUtils.h"
|
2015-08-13 14:41:42 +00:00
|
|
|
#import "UIView+Private.h"
|
2015-03-26 09:58:06 +00:00
|
|
|
#import "UIView+React.h"
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2016-11-23 15:47:52 +00:00
|
|
|
#if !TARGET_OS_TV
|
|
|
|
#import "RCTRefreshControl.h"
|
|
|
|
#endif
|
|
|
|
|
2015-05-28 03:15:33 +00:00
|
|
|
@interface RCTScrollEvent : NSObject <RCTEvent>
|
|
|
|
|
2016-04-28 14:43:24 +00:00
|
|
|
- (instancetype)initWithEventName:(NSString *)eventName
|
|
|
|
reactTag:(NSNumber *)reactTag
|
2017-07-15 03:54:46 +00:00
|
|
|
scrollViewContentOffset:(CGPoint)scrollViewContentOffset
|
|
|
|
scrollViewContentInset:(UIEdgeInsets)scrollViewContentInset
|
|
|
|
scrollViewContentSize:(CGSize)scrollViewContentSize
|
|
|
|
scrollViewFrame:(CGRect)scrollViewFrame
|
|
|
|
scrollViewZoomScale:(CGFloat)scrollViewZoomScale
|
2016-04-28 14:43:24 +00:00
|
|
|
userData:(NSDictionary *)userData
|
|
|
|
coalescingKey:(uint16_t)coalescingKey NS_DESIGNATED_INITIALIZER;
|
2015-05-28 03:15:33 +00:00
|
|
|
|
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation RCTScrollEvent
|
|
|
|
{
|
2017-07-15 03:54:46 +00:00
|
|
|
CGPoint _scrollViewContentOffset;
|
|
|
|
UIEdgeInsets _scrollViewContentInset;
|
|
|
|
CGSize _scrollViewContentSize;
|
|
|
|
CGRect _scrollViewFrame;
|
|
|
|
CGFloat _scrollViewZoomScale;
|
2015-05-28 03:15:33 +00:00
|
|
|
NSDictionary *_userData;
|
2016-04-01 13:53:07 +00:00
|
|
|
uint16_t _coalescingKey;
|
2015-05-28 03:15:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@synthesize viewTag = _viewTag;
|
2016-04-28 14:43:24 +00:00
|
|
|
@synthesize eventName = _eventName;
|
2015-05-28 03:15:33 +00:00
|
|
|
|
2016-04-28 14:43:24 +00:00
|
|
|
- (instancetype)initWithEventName:(NSString *)eventName
|
|
|
|
reactTag:(NSNumber *)reactTag
|
2017-07-15 03:54:46 +00:00
|
|
|
scrollViewContentOffset:(CGPoint)scrollViewContentOffset
|
|
|
|
scrollViewContentInset:(UIEdgeInsets)scrollViewContentInset
|
|
|
|
scrollViewContentSize:(CGSize)scrollViewContentSize
|
|
|
|
scrollViewFrame:(CGRect)scrollViewFrame
|
|
|
|
scrollViewZoomScale:(CGFloat)scrollViewZoomScale
|
2016-04-28 14:43:24 +00:00
|
|
|
userData:(NSDictionary *)userData
|
|
|
|
coalescingKey:(uint16_t)coalescingKey
|
2015-05-28 03:15:33 +00:00
|
|
|
{
|
2015-06-15 14:53:45 +00:00
|
|
|
RCTAssertParam(reactTag);
|
|
|
|
|
|
|
|
if ((self = [super init])) {
|
2016-04-28 14:43:24 +00:00
|
|
|
_eventName = [eventName copy];
|
2015-05-28 03:15:33 +00:00
|
|
|
_viewTag = reactTag;
|
2017-07-15 03:54:46 +00:00
|
|
|
_scrollViewContentOffset = scrollViewContentOffset;
|
|
|
|
_scrollViewContentInset = scrollViewContentInset;
|
|
|
|
_scrollViewContentSize = scrollViewContentSize;
|
|
|
|
_scrollViewFrame = scrollViewFrame;
|
|
|
|
_scrollViewZoomScale = scrollViewZoomScale;
|
2015-05-28 03:15:33 +00:00
|
|
|
_userData = userData;
|
2016-04-01 13:53:07 +00:00
|
|
|
_coalescingKey = coalescingKey;
|
2015-05-28 03:15:33 +00:00
|
|
|
}
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
2015-08-24 10:14:33 +00:00
|
|
|
RCT_NOT_IMPLEMENTED(- (instancetype)init)
|
2015-06-15 14:53:45 +00:00
|
|
|
|
2016-04-01 13:53:04 +00:00
|
|
|
- (uint16_t)coalescingKey
|
|
|
|
{
|
2016-04-01 13:53:07 +00:00
|
|
|
return _coalescingKey;
|
2016-04-01 13:53:04 +00:00
|
|
|
}
|
|
|
|
|
2015-05-28 03:15:33 +00:00
|
|
|
- (NSDictionary *)body
|
|
|
|
{
|
|
|
|
NSDictionary *body = @{
|
|
|
|
@"contentOffset": @{
|
2017-07-15 03:54:46 +00:00
|
|
|
@"x": @(_scrollViewContentOffset.x),
|
|
|
|
@"y": @(_scrollViewContentOffset.y)
|
2015-05-28 03:15:33 +00:00
|
|
|
},
|
|
|
|
@"contentInset": @{
|
2017-07-15 03:54:46 +00:00
|
|
|
@"top": @(_scrollViewContentInset.top),
|
|
|
|
@"left": @(_scrollViewContentInset.left),
|
|
|
|
@"bottom": @(_scrollViewContentInset.bottom),
|
|
|
|
@"right": @(_scrollViewContentInset.right)
|
2015-05-28 03:15:33 +00:00
|
|
|
},
|
|
|
|
@"contentSize": @{
|
2017-07-15 03:54:46 +00:00
|
|
|
@"width": @(_scrollViewContentSize.width),
|
|
|
|
@"height": @(_scrollViewContentSize.height)
|
2015-05-28 03:15:33 +00:00
|
|
|
},
|
|
|
|
@"layoutMeasurement": @{
|
2017-07-15 03:54:46 +00:00
|
|
|
@"width": @(_scrollViewFrame.size.width),
|
|
|
|
@"height": @(_scrollViewFrame.size.height)
|
2015-05-28 03:15:33 +00:00
|
|
|
},
|
2017-07-15 03:54:46 +00:00
|
|
|
@"zoomScale": @(_scrollViewZoomScale ?: 1),
|
2015-05-28 03:15:33 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
if (_userData) {
|
|
|
|
NSMutableDictionary *mutableBody = [body mutableCopy];
|
|
|
|
[mutableBody addEntriesFromDictionary:_userData];
|
|
|
|
body = mutableBody;
|
|
|
|
}
|
|
|
|
|
|
|
|
return body;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (BOOL)canCoalesce
|
|
|
|
{
|
|
|
|
return YES;
|
|
|
|
}
|
|
|
|
|
2015-07-07 00:29:30 +00:00
|
|
|
- (RCTScrollEvent *)coalesceWithEvent:(RCTScrollEvent *)newEvent
|
2015-05-28 03:15:33 +00:00
|
|
|
{
|
2015-11-03 22:45:46 +00:00
|
|
|
NSArray<NSDictionary *> *updatedChildFrames = [_userData[@"updatedChildFrames"] arrayByAddingObjectsFromArray:newEvent->_userData[@"updatedChildFrames"]];
|
2015-07-07 00:29:30 +00:00
|
|
|
if (updatedChildFrames) {
|
|
|
|
NSMutableDictionary *userData = [newEvent->_userData mutableCopy];
|
|
|
|
userData[@"updatedChildFrames"] = updatedChildFrames;
|
|
|
|
newEvent->_userData = userData;
|
|
|
|
}
|
2015-08-11 13:37:12 +00:00
|
|
|
|
2015-05-28 03:15:33 +00:00
|
|
|
return newEvent;
|
|
|
|
}
|
|
|
|
|
|
|
|
+ (NSString *)moduleDotMethod
|
|
|
|
{
|
|
|
|
return @"RCTEventEmitter.receiveEvent";
|
|
|
|
}
|
|
|
|
|
2016-02-03 13:22:14 +00:00
|
|
|
- (NSArray *)arguments
|
|
|
|
{
|
|
|
|
return @[self.viewTag, RCTNormalizeInputEventName(self.eventName), [self body]];
|
|
|
|
}
|
|
|
|
|
2015-05-28 03:15:33 +00:00
|
|
|
@end
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
/**
|
|
|
|
* Include a custom scroll view subclass because we want to limit certain
|
|
|
|
* default UIKit behaviors such as textFields automatically scrolling
|
2017-03-05 22:01:05 +00:00
|
|
|
* scroll views that contain them.
|
2015-02-20 04:10:52 +00:00
|
|
|
*/
|
|
|
|
@interface RCTCustomScrollView : UIScrollView<UIGestureRecognizerDelegate>
|
|
|
|
|
2015-05-06 17:46:45 +00:00
|
|
|
@property (nonatomic, assign) BOOL centerContent;
|
2016-09-27 13:19:45 +00:00
|
|
|
#if !TARGET_OS_TV
|
2018-07-23 20:17:33 +00:00
|
|
|
@property (nonatomic, strong) UIView<RCTCustomRefreshContolProtocol> *customRefreshControl;
|
2017-08-07 06:44:37 +00:00
|
|
|
@property (nonatomic, assign) BOOL pinchGestureEnabled;
|
2016-09-27 13:19:45 +00:00
|
|
|
#endif
|
2015-02-20 04:10:52 +00:00
|
|
|
|
|
|
|
@end
|
|
|
|
|
|
|
|
|
|
|
|
@implementation RCTCustomScrollView
|
|
|
|
|
|
|
|
- (instancetype)initWithFrame:(CGRect)frame
|
|
|
|
{
|
2015-03-01 23:33:55 +00:00
|
|
|
if ((self = [super initWithFrame:frame])) {
|
2015-02-20 04:10:52 +00:00
|
|
|
[self.panGestureRecognizer addTarget:self action:@selector(handleCustomPan:)];
|
2017-02-02 17:51:19 +00:00
|
|
|
|
2017-02-03 23:13:36 +00:00
|
|
|
if ([self respondsToSelector:@selector(setSemanticContentAttribute:)]) {
|
|
|
|
// We intentionaly force `UIScrollView`s `semanticContentAttribute` to `LTR` here
|
|
|
|
// because this attribute affects a position of vertical scrollbar; we don't want this
|
|
|
|
// scrollbar flip because we also flip it with whole `UIScrollView` flip.
|
|
|
|
self.semanticContentAttribute = UISemanticContentAttributeForceLeftToRight;
|
|
|
|
}
|
2017-08-07 06:44:37 +00:00
|
|
|
|
|
|
|
#if !TARGET_OS_TV
|
|
|
|
_pinchGestureEnabled = YES;
|
|
|
|
#endif
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (UIView *)contentView
|
|
|
|
{
|
|
|
|
return ((RCTScrollView *)self.superview).contentView;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @return Whether or not the scroll view interaction should be blocked because
|
|
|
|
* JS was found to be the responder.
|
|
|
|
*/
|
|
|
|
- (BOOL)_shouldDisableScrollInteraction
|
|
|
|
{
|
|
|
|
// Since this may be called on every pan, we need to make sure to only climb
|
|
|
|
// the hierarchy on rare occasions.
|
|
|
|
UIView *JSResponder = [RCTUIManager JSResponder];
|
|
|
|
if (JSResponder && JSResponder != self.superview) {
|
|
|
|
BOOL superviewHasResponder = [self isDescendantOfView:JSResponder];
|
|
|
|
return superviewHasResponder;
|
|
|
|
}
|
|
|
|
return NO;
|
|
|
|
}
|
|
|
|
|
2015-06-15 14:53:45 +00:00
|
|
|
- (void)handleCustomPan:(__unused UIPanGestureRecognizer *)sender
|
2015-02-20 04:10:52 +00:00
|
|
|
{
|
2015-12-03 14:07:23 +00:00
|
|
|
if ([self _shouldDisableScrollInteraction] && ![[RCTUIManager JSResponder] isKindOfClass:[RCTScrollView class]]) {
|
2015-02-20 04:10:52 +00:00
|
|
|
self.panGestureRecognizer.enabled = NO;
|
|
|
|
self.panGestureRecognizer.enabled = YES;
|
|
|
|
// TODO: If mid bounce, animate the scroll view to a non-bounced position
|
|
|
|
// while disabling (but only if `stopScrollInteractionIfJSHasResponder` was
|
2017-02-02 17:51:19 +00:00
|
|
|
// called *during* a `pan`). Currently, it will just snap into place which
|
2015-02-20 04:10:52 +00:00
|
|
|
// is not so bad either.
|
|
|
|
// Another approach:
|
|
|
|
// self.scrollEnabled = NO;
|
|
|
|
// self.scrollEnabled = YES;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-18 21:33:49 +00:00
|
|
|
- (void)scrollRectToVisible:(CGRect)rect animated:(BOOL)animated
|
2015-02-20 04:10:52 +00:00
|
|
|
{
|
2017-07-18 21:33:49 +00:00
|
|
|
// Limiting scroll area to an area where we actually have content.
|
|
|
|
CGSize contentSize = self.contentSize;
|
|
|
|
UIEdgeInsets contentInset = self.contentInset;
|
|
|
|
CGSize fullSize = CGSizeMake(
|
|
|
|
contentSize.width + contentInset.left + contentInset.right,
|
|
|
|
contentSize.height + contentInset.top + contentInset.bottom);
|
|
|
|
|
|
|
|
rect = CGRectIntersection((CGRect){CGPointZero, fullSize}, rect);
|
|
|
|
if (CGRectIsNull(rect)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
[super scrollRectToVisible:rect animated:animated];
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returning `YES` cancels touches for the "inner" `view` and causes a scroll.
|
|
|
|
* Returning `NO` causes touches to be directed to that inner view and prevents
|
|
|
|
* the scroll view from scrolling.
|
|
|
|
*
|
|
|
|
* `YES` -> Allows scrolling.
|
|
|
|
* `NO` -> Doesn't allow scrolling.
|
|
|
|
*
|
|
|
|
* By default this returns NO for all views that are UIControls and YES for
|
|
|
|
* everything else. What that does is allows scroll views to scroll even when a
|
|
|
|
* touch started inside of a `UIControl` (`UIButton` etc). For React scroll
|
|
|
|
* views, we want the default to be the same behavior as `UIControl`s so we
|
|
|
|
* return `YES` by default. But there's one case where we want to block the
|
|
|
|
* scrolling no matter what: When JS believes it has its own responder lock on
|
|
|
|
* a view that is *above* the scroll view in the hierarchy. So we abuse this
|
|
|
|
* `touchesShouldCancelInContentView` API in order to stop the scroll view from
|
|
|
|
* scrolling in this case.
|
|
|
|
*
|
|
|
|
* We are not aware of *any* other solution to the problem because alternative
|
|
|
|
* approaches require that we disable the scrollview *before* touches begin or
|
|
|
|
* move. This approach (`touchesShouldCancelInContentView`) works even if the
|
|
|
|
* JS responder is set after touches start/move because
|
|
|
|
* `touchesShouldCancelInContentView` is called as soon as the scroll view has
|
|
|
|
* been touched and dragged *just* far enough to decide to begin the "drag"
|
|
|
|
* movement of the scroll interaction. Returning `NO`, will cause the drag
|
|
|
|
* operation to fail.
|
|
|
|
*
|
|
|
|
* `touchesShouldCancelInContentView` will stop the *initialization* of a
|
|
|
|
* scroll pan gesture and most of the time this is sufficient. On rare
|
|
|
|
* occasion, the scroll gesture would have already initialized right before JS
|
|
|
|
* notifies native of the JS responder being set. In order to recover from that
|
|
|
|
* timing issue we have a fallback that kills any ongoing pan gesture that
|
|
|
|
* occurs when native is notified of a JS responder.
|
|
|
|
*
|
|
|
|
* Note: Explicitly returning `YES`, instead of relying on the default fixes
|
|
|
|
* (at least) one bug where if you have a UIControl inside a UIScrollView and
|
|
|
|
* tap on the UIControl and then start dragging (to scroll), it won't scroll.
|
2018-01-10 20:07:33 +00:00
|
|
|
* Chat with @andras for more details.
|
2015-02-20 04:10:52 +00:00
|
|
|
*
|
|
|
|
* In order to have this called, you must have delaysContentTouches set to NO
|
|
|
|
* (which is the not the `UIKit` default).
|
|
|
|
*/
|
2015-06-15 14:53:45 +00:00
|
|
|
- (BOOL)touchesShouldCancelInContentView:(__unused UIView *)view
|
2015-02-20 04:10:52 +00:00
|
|
|
{
|
|
|
|
//TODO: shouldn't this call super if _shouldDisableScrollInteraction returns NO?
|
|
|
|
return ![self _shouldDisableScrollInteraction];
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Automatically centers the content such that if the content is smaller than the
|
|
|
|
* ScrollView, we force it to be centered, but when you zoom or the content otherwise
|
|
|
|
* becomes larger than the ScrollView, there is no padding around the content but it
|
|
|
|
* can still fill the whole view.
|
|
|
|
*/
|
|
|
|
- (void)setContentOffset:(CGPoint)contentOffset
|
|
|
|
{
|
|
|
|
UIView *contentView = [self contentView];
|
|
|
|
if (contentView && _centerContent) {
|
|
|
|
CGSize subviewSize = contentView.frame.size;
|
|
|
|
CGSize scrollViewSize = self.bounds.size;
|
2016-06-03 23:52:17 +00:00
|
|
|
if (subviewSize.width <= scrollViewSize.width) {
|
2015-02-20 04:10:52 +00:00
|
|
|
contentOffset.x = -(scrollViewSize.width - subviewSize.width) / 2.0;
|
|
|
|
}
|
2016-06-03 23:52:17 +00:00
|
|
|
if (subviewSize.height <= scrollViewSize.height) {
|
2015-02-20 04:10:52 +00:00
|
|
|
contentOffset.y = -(scrollViewSize.height - subviewSize.height) / 2.0;
|
|
|
|
}
|
|
|
|
}
|
2015-08-24 10:14:33 +00:00
|
|
|
super.contentOffset = contentOffset;
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
2016-10-27 16:17:22 +00:00
|
|
|
- (void)setFrame:(CGRect)frame
|
|
|
|
{
|
2017-07-18 21:33:52 +00:00
|
|
|
// Preserving and revalidating `contentOffset`.
|
2017-07-18 21:33:51 +00:00
|
|
|
CGPoint originalOffset = self.contentOffset;
|
2017-07-18 21:33:52 +00:00
|
|
|
|
2016-10-27 16:17:22 +00:00
|
|
|
[super setFrame:frame];
|
2017-07-18 21:33:52 +00:00
|
|
|
|
|
|
|
UIEdgeInsets contentInset = self.contentInset;
|
|
|
|
CGSize contentSize = self.contentSize;
|
2018-01-10 20:07:33 +00:00
|
|
|
|
2017-09-05 23:23:56 +00:00
|
|
|
// If contentSize has not been measured yet we can't check bounds.
|
|
|
|
if (CGSizeEqualToSize(contentSize, CGSizeZero)) {
|
|
|
|
self.contentOffset = originalOffset;
|
|
|
|
} else {
|
|
|
|
// Make sure offset don't exceed bounds. This could happen on screen rotation.
|
|
|
|
CGSize boundsSize = self.bounds.size;
|
|
|
|
self.contentOffset = CGPointMake(
|
|
|
|
MAX(-contentInset.left, MIN(contentSize.width - boundsSize.width + contentInset.right, originalOffset.x)),
|
|
|
|
MAX(-contentInset.top, MIN(contentSize.height - boundsSize.height + contentInset.bottom, originalOffset.y)));
|
|
|
|
}
|
2016-10-27 16:17:22 +00:00
|
|
|
}
|
|
|
|
|
2016-09-27 13:19:45 +00:00
|
|
|
#if !TARGET_OS_TV
|
2018-07-23 20:17:33 +00:00
|
|
|
- (void)setCustomRefreshControl:(UIView<RCTCustomRefreshContolProtocol> *)refreshControl
|
2015-11-19 19:13:42 +00:00
|
|
|
{
|
2018-07-23 20:17:33 +00:00
|
|
|
if (_customRefreshControl) {
|
|
|
|
[_customRefreshControl removeFromSuperview];
|
2015-11-19 19:13:42 +00:00
|
|
|
}
|
2018-07-23 20:17:33 +00:00
|
|
|
_customRefreshControl = refreshControl;
|
|
|
|
[self addSubview:_customRefreshControl];
|
2015-11-19 19:13:42 +00:00
|
|
|
}
|
2017-08-07 06:44:37 +00:00
|
|
|
|
|
|
|
- (void)setPinchGestureEnabled:(BOOL)pinchGestureEnabled
|
|
|
|
{
|
|
|
|
self.pinchGestureRecognizer.enabled = pinchGestureEnabled;
|
|
|
|
_pinchGestureEnabled = pinchGestureEnabled;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)didMoveToWindow
|
|
|
|
{
|
|
|
|
[super didMoveToWindow];
|
|
|
|
// ScrollView enables pinch gesture late in its lifecycle. So simply setting it
|
|
|
|
// in the setter gets overriden when the view loads.
|
|
|
|
self.pinchGestureRecognizer.enabled = _pinchGestureEnabled;
|
|
|
|
}
|
2016-09-27 13:19:45 +00:00
|
|
|
#endif //TARGET_OS_TV
|
2015-11-19 19:13:42 +00:00
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
@end
|
|
|
|
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
@interface RCTScrollView () <RCTUIManagerObserver>
|
|
|
|
|
|
|
|
@end
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
@implementation RCTScrollView
|
|
|
|
{
|
|
|
|
RCTEventDispatcher *_eventDispatcher;
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
CGRect _prevFirstVisibleFrame;
|
|
|
|
__weak UIView *_firstVisibleView;
|
2015-02-20 04:10:52 +00:00
|
|
|
RCTCustomScrollView *_scrollView;
|
|
|
|
UIView *_contentView;
|
|
|
|
NSTimeInterval _lastScrollDispatchTime;
|
2015-11-03 22:45:46 +00:00
|
|
|
NSMutableArray<NSValue *> *_cachedChildFrames;
|
2015-02-20 04:10:52 +00:00
|
|
|
BOOL _allowNextScrollNoMatterWhat;
|
2015-08-13 14:41:42 +00:00
|
|
|
CGRect _lastClippedToRect;
|
2016-04-01 13:53:08 +00:00
|
|
|
uint16_t _coalescingKey;
|
2016-04-28 14:43:24 +00:00
|
|
|
NSString *_lastEmittedEventName;
|
2016-05-12 19:16:42 +00:00
|
|
|
NSHashTable *_scrollListeners;
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
- (instancetype)initWithEventDispatcher:(RCTEventDispatcher *)eventDispatcher
|
|
|
|
{
|
2015-06-15 14:53:45 +00:00
|
|
|
RCTAssertParam(eventDispatcher);
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
if ((self = [super initWithFrame:CGRectZero])) {
|
|
|
|
_eventDispatcher = eventDispatcher;
|
Add 'contentInsetAdjustmentBehavior' (new in iOS 11) to ScrollView
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
2017-07-31 19:10:11 +00:00
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
_scrollView = [[RCTCustomScrollView alloc] initWithFrame:CGRectZero];
|
2017-07-18 21:33:51 +00:00
|
|
|
_scrollView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
|
2015-02-20 04:10:52 +00:00
|
|
|
_scrollView.delegate = self;
|
|
|
|
_scrollView.delaysContentTouches = NO;
|
Add 'contentInsetAdjustmentBehavior' (new in iOS 11) to ScrollView
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
2017-07-31 19:10:11 +00:00
|
|
|
|
|
|
|
#if defined(__IPHONE_OS_VERSION_MAX_ALLOWED) && __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
|
|
|
|
// `contentInsetAdjustmentBehavior` is only available since iOS 11.
|
|
|
|
// We set the default behavior to "never" so that iOS
|
|
|
|
// doesn't do weird things to UIScrollView insets automatically
|
|
|
|
// and keeps it as an opt-in behavior.
|
|
|
|
if ([_scrollView respondsToSelector:@selector(setContentInsetAdjustmentBehavior:)]) {
|
2018-06-20 16:50:29 +00:00
|
|
|
if (@available(iOS 11.0, *)) {
|
Add 'contentInsetAdjustmentBehavior' (new in iOS 11) to ScrollView
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
2017-07-31 19:10:11 +00:00
|
|
|
_scrollView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;
|
2018-06-20 16:50:29 +00:00
|
|
|
}
|
Add 'contentInsetAdjustmentBehavior' (new in iOS 11) to ScrollView
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
2017-07-31 19:10:11 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
_automaticallyAdjustContentInsets = YES;
|
2017-06-08 18:49:39 +00:00
|
|
|
_DEPRECATED_sendUpdatedChildFrames = NO;
|
2015-02-20 04:10:52 +00:00
|
|
|
_contentInset = UIEdgeInsetsZero;
|
2015-03-25 22:01:00 +00:00
|
|
|
_contentSize = CGSizeZero;
|
2015-08-13 14:41:42 +00:00
|
|
|
_lastClippedToRect = CGRectNull;
|
2015-03-11 02:03:59 +00:00
|
|
|
|
2015-03-30 11:58:02 +00:00
|
|
|
_scrollEventThrottle = 0.0;
|
2016-05-06 10:18:20 +00:00
|
|
|
_lastScrollDispatchTime = 0;
|
2015-08-17 14:35:34 +00:00
|
|
|
_cachedChildFrames = [NSMutableArray new];
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2016-05-12 19:16:42 +00:00
|
|
|
_scrollListeners = [NSHashTable weakObjectsHashTable];
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
[self addSubview:_scrollView];
|
|
|
|
}
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
2015-08-24 10:14:33 +00:00
|
|
|
RCT_NOT_IMPLEMENTED(- (instancetype)initWithFrame:(CGRect)frame)
|
|
|
|
RCT_NOT_IMPLEMENTED(- (instancetype)initWithCoder:(NSCoder *)aDecoder)
|
2015-06-15 14:53:45 +00:00
|
|
|
|
2018-01-30 03:10:33 +00:00
|
|
|
static inline void RCTApplyTransformationAccordingLayoutDirection(UIView *view, UIUserInterfaceLayoutDirection layoutDirection) {
|
2017-02-02 17:51:19 +00:00
|
|
|
view.transform =
|
|
|
|
layoutDirection == UIUserInterfaceLayoutDirectionLeftToRight ?
|
|
|
|
CGAffineTransformIdentity :
|
|
|
|
CGAffineTransformMakeScale(-1, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)setReactLayoutDirection:(UIUserInterfaceLayoutDirection)layoutDirection
|
|
|
|
{
|
|
|
|
[super setReactLayoutDirection:layoutDirection];
|
|
|
|
|
2018-01-30 03:10:33 +00:00
|
|
|
RCTApplyTransformationAccordingLayoutDirection(_scrollView, layoutDirection);
|
|
|
|
RCTApplyTransformationAccordingLayoutDirection(_contentView, layoutDirection);
|
2017-02-02 17:51:19 +00:00
|
|
|
}
|
|
|
|
|
2016-11-18 22:33:23 +00:00
|
|
|
- (void)setRemoveClippedSubviews:(__unused BOOL)removeClippedSubviews
|
|
|
|
{
|
|
|
|
// Does nothing
|
|
|
|
}
|
|
|
|
|
2016-06-07 07:08:16 +00:00
|
|
|
- (void)insertReactSubview:(UIView *)view atIndex:(NSInteger)atIndex
|
2015-02-20 04:10:52 +00:00
|
|
|
{
|
2016-06-07 07:08:16 +00:00
|
|
|
[super insertReactSubview:view atIndex:atIndex];
|
2016-09-27 13:19:45 +00:00
|
|
|
#if !TARGET_OS_TV
|
2018-07-23 20:17:33 +00:00
|
|
|
if ([view conformsToProtocol:@protocol(RCTCustomRefreshContolProtocol)]) {
|
|
|
|
[_scrollView setCustomRefreshControl:(UIView<RCTCustomRefreshContolProtocol> *)view];
|
|
|
|
if (![view isKindOfClass:[UIRefreshControl class]]
|
|
|
|
&& [view conformsToProtocol:@protocol(UIScrollViewDelegate)]) {
|
|
|
|
[self addScrollListener:(UIView<UIScrollViewDelegate> *)view];
|
|
|
|
}
|
2016-09-27 13:19:45 +00:00
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
{
|
2016-01-04 15:59:10 +00:00
|
|
|
RCTAssert(_contentView == nil, @"RCTScrollView may only contain a single subview");
|
|
|
|
_contentView = view;
|
2018-01-30 03:10:33 +00:00
|
|
|
RCTApplyTransformationAccordingLayoutDirection(_contentView, self.reactLayoutDirection);
|
2016-01-04 15:59:10 +00:00
|
|
|
[_scrollView addSubview:view];
|
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)removeReactSubview:(UIView *)subview
|
|
|
|
{
|
2016-06-07 07:08:16 +00:00
|
|
|
[super removeReactSubview:subview];
|
2016-09-27 13:19:45 +00:00
|
|
|
#if !TARGET_OS_TV
|
2018-07-23 20:17:33 +00:00
|
|
|
if ([subview conformsToProtocol:@protocol(RCTCustomRefreshContolProtocol)]) {
|
|
|
|
[_scrollView setCustomRefreshControl:nil];
|
|
|
|
if (![subview isKindOfClass:[UIRefreshControl class]]
|
|
|
|
&& [subview conformsToProtocol:@protocol(UIScrollViewDelegate)]) {
|
|
|
|
[self removeScrollListener:(UIView<UIScrollViewDelegate> *)subview];
|
|
|
|
}
|
2016-09-27 13:19:45 +00:00
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
{
|
2016-01-04 15:59:10 +00:00
|
|
|
RCTAssert(_contentView == subview, @"Attempted to remove non-existent subview");
|
|
|
|
_contentView = nil;
|
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
2016-06-07 07:08:16 +00:00
|
|
|
- (void)didUpdateReactSubviews
|
2015-02-20 04:10:52 +00:00
|
|
|
{
|
2016-11-18 22:33:23 +00:00
|
|
|
// Do nothing, as subviews are managed by `insertReactSubview:atIndex:`
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
2017-12-12 02:49:54 +00:00
|
|
|
- (void)didSetProps:(NSArray<NSString *> *)changedProps
|
|
|
|
{
|
|
|
|
if ([changedProps containsObject:@"contentSize"]) {
|
|
|
|
[self updateContentOffsetIfNeeded];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-15 14:53:45 +00:00
|
|
|
- (BOOL)centerContent
|
|
|
|
{
|
|
|
|
return _scrollView.centerContent;
|
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
- (void)setCenterContent:(BOOL)centerContent
|
|
|
|
{
|
|
|
|
_scrollView.centerContent = centerContent;
|
|
|
|
}
|
|
|
|
|
2015-05-13 16:24:29 +00:00
|
|
|
- (void)setClipsToBounds:(BOOL)clipsToBounds
|
|
|
|
{
|
2015-08-24 10:14:33 +00:00
|
|
|
super.clipsToBounds = clipsToBounds;
|
|
|
|
_scrollView.clipsToBounds = clipsToBounds;
|
2015-05-13 16:24:29 +00:00
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
- (void)dealloc
|
|
|
|
{
|
|
|
|
_scrollView.delegate = nil;
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
[_eventDispatcher.bridge.uiManager.observerCoordinator removeObserver:self];
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)layoutSubviews
|
|
|
|
{
|
|
|
|
[super layoutSubviews];
|
|
|
|
RCTAssert(self.subviews.count == 1, @"we should only have exactly one subview");
|
|
|
|
RCTAssert([self.subviews lastObject] == _scrollView, @"our only subview should be a scrollview");
|
2015-07-30 00:19:46 +00:00
|
|
|
|
2016-09-27 13:19:45 +00:00
|
|
|
#if !TARGET_OS_TV
|
2016-03-08 12:00:02 +00:00
|
|
|
// Adjust the refresh control frame if the scrollview layout changes.
|
2018-07-23 20:17:33 +00:00
|
|
|
UIView<RCTCustomRefreshContolProtocol> *refreshControl = _scrollView.customRefreshControl;
|
|
|
|
if (refreshControl && refreshControl.isRefreshing) {
|
2016-03-08 12:00:02 +00:00
|
|
|
refreshControl.frame = (CGRect){_scrollView.contentOffset, {_scrollView.frame.size.width, refreshControl.frame.size.height}};
|
|
|
|
}
|
2016-09-27 13:19:45 +00:00
|
|
|
#endif
|
2016-11-18 22:33:23 +00:00
|
|
|
|
|
|
|
[self updateClippedSubviews];
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
2015-08-13 14:41:42 +00:00
|
|
|
- (void)updateClippedSubviews
|
|
|
|
{
|
2016-11-18 22:33:23 +00:00
|
|
|
// Find a suitable view to use for clipping
|
|
|
|
UIView *clipView = [self react_findClipView];
|
|
|
|
if (!clipView) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-09-25 16:05:36 +00:00
|
|
|
static const CGFloat leeway = 1.0;
|
2015-08-13 14:41:42 +00:00
|
|
|
|
|
|
|
const CGSize contentSize = _scrollView.contentSize;
|
|
|
|
const CGRect bounds = _scrollView.bounds;
|
|
|
|
const BOOL scrollsHorizontally = contentSize.width > bounds.size.width;
|
|
|
|
const BOOL scrollsVertically = contentSize.height > bounds.size.height;
|
|
|
|
|
|
|
|
const BOOL shouldClipAgain =
|
|
|
|
CGRectIsNull(_lastClippedToRect) ||
|
2016-06-15 14:59:17 +00:00
|
|
|
!CGRectEqualToRect(_lastClippedToRect, bounds) ||
|
2015-08-13 14:41:42 +00:00
|
|
|
(scrollsHorizontally && (bounds.size.width < leeway || fabs(_lastClippedToRect.origin.x - bounds.origin.x) >= leeway)) ||
|
|
|
|
(scrollsVertically && (bounds.size.height < leeway || fabs(_lastClippedToRect.origin.y - bounds.origin.y) >= leeway));
|
|
|
|
|
|
|
|
if (shouldClipAgain) {
|
2016-11-18 22:33:23 +00:00
|
|
|
const CGRect clipRect = CGRectInset(clipView.bounds, -leeway, -leeway);
|
|
|
|
[self react_updateClippedSubviewsWithClipRect:clipRect relativeToView:clipView];
|
2015-08-13 14:41:42 +00:00
|
|
|
_lastClippedToRect = bounds;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
- (void)setContentInset:(UIEdgeInsets)contentInset
|
|
|
|
{
|
2016-07-18 18:50:31 +00:00
|
|
|
if (UIEdgeInsetsEqualToEdgeInsets(contentInset, _contentInset)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-05-07 23:38:29 +00:00
|
|
|
CGPoint contentOffset = _scrollView.contentOffset;
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
_contentInset = contentInset;
|
2015-05-07 23:38:29 +00:00
|
|
|
[RCTView autoAdjustInsetsForView:self
|
|
|
|
withScrollView:_scrollView
|
|
|
|
updateOffset:NO];
|
|
|
|
|
|
|
|
_scrollView.contentOffset = contentOffset;
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
2017-01-27 18:09:20 +00:00
|
|
|
- (BOOL)isHorizontal:(UIScrollView *)scrollView
|
|
|
|
{
|
|
|
|
return scrollView.contentSize.width > self.frame.size.width;
|
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
- (void)scrollToOffset:(CGPoint)offset
|
|
|
|
{
|
|
|
|
[self scrollToOffset:offset animated:YES];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)scrollToOffset:(CGPoint)offset animated:(BOOL)animated
|
|
|
|
{
|
|
|
|
if (!CGPointEqualToPoint(_scrollView.contentOffset, offset)) {
|
2016-05-06 10:18:20 +00:00
|
|
|
// Ensure at least one scroll event will fire
|
|
|
|
_allowNextScrollNoMatterWhat = YES;
|
2015-02-20 04:10:52 +00:00
|
|
|
[_scrollView setContentOffset:offset animated:animated];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-27 18:09:20 +00:00
|
|
|
/**
|
|
|
|
* If this is a vertical scroll view, scrolls to the bottom.
|
|
|
|
* If this is a horizontal scroll view, scrolls to the right.
|
|
|
|
*/
|
|
|
|
- (void)scrollToEnd:(BOOL)animated
|
|
|
|
{
|
|
|
|
BOOL isHorizontal = [self isHorizontal:_scrollView];
|
|
|
|
CGPoint offset;
|
|
|
|
if (isHorizontal) {
|
2017-06-22 01:18:59 +00:00
|
|
|
CGFloat offsetX = _scrollView.contentSize.width - _scrollView.bounds.size.width + _scrollView.contentInset.right;
|
|
|
|
offset = CGPointMake(fmax(offsetX, 0), 0);
|
2017-01-27 18:09:20 +00:00
|
|
|
} else {
|
2017-06-22 01:18:59 +00:00
|
|
|
CGFloat offsetY = _scrollView.contentSize.height - _scrollView.bounds.size.height + _scrollView.contentInset.bottom;
|
|
|
|
offset = CGPointMake(0, fmax(offsetY, 0));
|
2017-01-27 18:09:20 +00:00
|
|
|
}
|
|
|
|
if (!CGPointEqualToPoint(_scrollView.contentOffset, offset)) {
|
|
|
|
// Ensure at least one scroll event will fire
|
|
|
|
_allowNextScrollNoMatterWhat = YES;
|
|
|
|
[_scrollView setContentOffset:offset animated:animated];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
- (void)zoomToRect:(CGRect)rect animated:(BOOL)animated
|
|
|
|
{
|
|
|
|
[_scrollView zoomToRect:rect animated:animated];
|
|
|
|
}
|
|
|
|
|
2015-09-04 12:50:01 +00:00
|
|
|
- (void)refreshContentInset
|
|
|
|
{
|
|
|
|
[RCTView autoAdjustInsetsForView:self
|
|
|
|
withScrollView:_scrollView
|
|
|
|
updateOffset:YES];
|
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
#pragma mark - ScrollView delegate
|
|
|
|
|
2016-04-28 14:43:24 +00:00
|
|
|
#define RCT_SEND_SCROLL_EVENT(_eventName, _userData) { \
|
|
|
|
NSString *eventName = NSStringFromSelector(@selector(_eventName)); \
|
|
|
|
[self sendScrollEventWithName:eventName scrollView:_scrollView userData:_userData]; \
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#define RCT_FORWARD_SCROLL_EVENT(call) \
|
2016-05-12 19:16:42 +00:00
|
|
|
for (NSObject<UIScrollViewDelegate> *scrollViewListener in _scrollListeners) { \
|
|
|
|
if ([scrollViewListener respondsToSelector:_cmd]) { \
|
|
|
|
[scrollViewListener call]; \
|
|
|
|
} \
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
2016-04-28 14:43:24 +00:00
|
|
|
#define RCT_SCROLL_EVENT_HANDLER(delegateMethod, eventName) \
|
|
|
|
- (void)delegateMethod:(UIScrollView *)scrollView \
|
|
|
|
{ \
|
|
|
|
RCT_SEND_SCROLL_EVENT(eventName, nil); \
|
|
|
|
RCT_FORWARD_SCROLL_EVENT(delegateMethod:scrollView); \
|
|
|
|
}
|
|
|
|
|
|
|
|
RCT_SCROLL_EVENT_HANDLER(scrollViewWillBeginDecelerating, onMomentumScrollBegin)
|
|
|
|
RCT_SCROLL_EVENT_HANDLER(scrollViewDidZoom, onScroll)
|
2015-02-20 04:10:52 +00:00
|
|
|
|
2016-05-12 19:16:42 +00:00
|
|
|
- (void)addScrollListener:(NSObject<UIScrollViewDelegate> *)scrollListener
|
|
|
|
{
|
|
|
|
[_scrollListeners addObject:scrollListener];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)removeScrollListener:(NSObject<UIScrollViewDelegate> *)scrollListener
|
|
|
|
{
|
2016-07-11 20:28:13 +00:00
|
|
|
[_scrollListeners removeObject:scrollListener];
|
2016-05-12 19:16:42 +00:00
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
- (void)scrollViewDidScroll:(UIScrollView *)scrollView
|
|
|
|
{
|
2015-03-11 02:03:59 +00:00
|
|
|
[self updateClippedSubviews];
|
2015-02-20 04:10:52 +00:00
|
|
|
NSTimeInterval now = CACurrentMediaTime();
|
|
|
|
/**
|
2015-03-30 11:58:02 +00:00
|
|
|
* TODO: this logic looks wrong, and it may be because it is. Currently, if _scrollEventThrottle
|
2015-02-20 04:10:52 +00:00
|
|
|
* is set to zero (the default), the "didScroll" event is only sent once per scroll, instead of repeatedly
|
|
|
|
* while scrolling as expected. However, if you "fix" that bug, ScrollView will generate repeated
|
|
|
|
* warnings, and behave strangely (ListView works fine however), so don't fix it unless you fix that too!
|
|
|
|
*/
|
|
|
|
if (_allowNextScrollNoMatterWhat ||
|
2015-03-30 11:58:02 +00:00
|
|
|
(_scrollEventThrottle > 0 && _scrollEventThrottle < (now - _lastScrollDispatchTime))) {
|
2015-03-11 02:03:59 +00:00
|
|
|
|
2017-06-08 18:49:39 +00:00
|
|
|
if (_DEPRECATED_sendUpdatedChildFrames) {
|
|
|
|
// Calculate changed frames
|
|
|
|
RCT_SEND_SCROLL_EVENT(onScroll, (@{@"updatedChildFrames": [self calculateChildFramesData]}));
|
|
|
|
} else {
|
|
|
|
RCT_SEND_SCROLL_EVENT(onScroll, nil);
|
|
|
|
}
|
2015-07-07 14:38:24 +00:00
|
|
|
|
|
|
|
// Update dispatch time
|
|
|
|
_lastScrollDispatchTime = now;
|
|
|
|
_allowNextScrollNoMatterWhat = NO;
|
|
|
|
}
|
|
|
|
RCT_FORWARD_SCROLL_EVENT(scrollViewDidScroll:scrollView);
|
|
|
|
}
|
|
|
|
|
2015-11-03 22:45:46 +00:00
|
|
|
- (NSArray<NSDictionary *> *)calculateChildFramesData
|
2015-07-07 14:38:24 +00:00
|
|
|
{
|
2015-11-03 22:45:46 +00:00
|
|
|
NSMutableArray<NSDictionary *> *updatedChildFrames = [NSMutableArray new];
|
2015-06-15 14:53:45 +00:00
|
|
|
[[_contentView reactSubviews] enumerateObjectsUsingBlock:
|
|
|
|
^(UIView *subview, NSUInteger idx, __unused BOOL *stop) {
|
2015-03-11 02:03:59 +00:00
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
// Check if new or changed
|
|
|
|
CGRect newFrame = subview.frame;
|
|
|
|
BOOL frameChanged = NO;
|
2016-07-07 19:36:56 +00:00
|
|
|
if (self->_cachedChildFrames.count <= idx) {
|
2015-02-20 04:10:52 +00:00
|
|
|
frameChanged = YES;
|
2016-07-07 19:36:56 +00:00
|
|
|
[self->_cachedChildFrames addObject:[NSValue valueWithCGRect:newFrame]];
|
|
|
|
} else if (!CGRectEqualToRect(newFrame, [self->_cachedChildFrames[idx] CGRectValue])) {
|
2015-02-20 04:10:52 +00:00
|
|
|
frameChanged = YES;
|
2016-07-07 19:36:56 +00:00
|
|
|
self->_cachedChildFrames[idx] = [NSValue valueWithCGRect:newFrame];
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
2015-03-11 02:03:59 +00:00
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
// Create JS frame object
|
|
|
|
if (frameChanged) {
|
|
|
|
[updatedChildFrames addObject: @{
|
|
|
|
@"index": @(idx),
|
|
|
|
@"x": @(newFrame.origin.x),
|
|
|
|
@"y": @(newFrame.origin.y),
|
|
|
|
@"width": @(newFrame.size.width),
|
|
|
|
@"height": @(newFrame.size.height),
|
|
|
|
}];
|
|
|
|
}
|
|
|
|
}];
|
2015-03-11 02:03:59 +00:00
|
|
|
|
2015-07-07 14:38:24 +00:00
|
|
|
return updatedChildFrames;
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView
|
|
|
|
{
|
|
|
|
_allowNextScrollNoMatterWhat = YES; // Ensure next scroll event is recorded, regardless of throttle
|
2016-04-28 14:43:24 +00:00
|
|
|
RCT_SEND_SCROLL_EVENT(onScrollBeginDrag, nil);
|
2015-02-20 04:10:52 +00:00
|
|
|
RCT_FORWARD_SCROLL_EVENT(scrollViewWillBeginDragging:scrollView);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset
|
|
|
|
{
|
2015-09-23 18:43:57 +00:00
|
|
|
// snapToInterval
|
|
|
|
// An alternative to enablePaging which allows setting custom stopping intervals,
|
|
|
|
// smaller than a full page size. Often seen in apps which feature horizonally
|
|
|
|
// scrolling items. snapToInterval does not enforce scrolling one interval at a time
|
|
|
|
// but guarantees that the scroll will stop at an interval point.
|
|
|
|
if (self.snapToInterval) {
|
|
|
|
CGFloat snapToIntervalF = (CGFloat)self.snapToInterval;
|
|
|
|
|
|
|
|
// Find which axis to snap
|
2017-01-27 18:09:20 +00:00
|
|
|
BOOL isHorizontal = [self isHorizontal:scrollView];
|
2015-09-23 18:43:57 +00:00
|
|
|
|
|
|
|
// What is the current offset?
|
2017-03-29 13:59:45 +00:00
|
|
|
CGFloat velocityAlongAxis = isHorizontal ? velocity.x : velocity.y;
|
2015-09-23 18:43:57 +00:00
|
|
|
CGFloat targetContentOffsetAlongAxis = isHorizontal ? targetContentOffset->x : targetContentOffset->y;
|
|
|
|
|
|
|
|
// Offset based on desired alignment
|
|
|
|
CGFloat frameLength = isHorizontal ? self.frame.size.width : self.frame.size.height;
|
|
|
|
CGFloat alignmentOffset = 0.0f;
|
2017-03-29 13:59:45 +00:00
|
|
|
if ([self.snapToAlignment isEqualToString: @"center"]) {
|
2015-09-23 18:43:57 +00:00
|
|
|
alignmentOffset = (frameLength * 0.5f) + (snapToIntervalF * 0.5f);
|
2017-03-29 13:59:45 +00:00
|
|
|
} else if ([self.snapToAlignment isEqualToString: @"end"]) {
|
2015-09-23 18:43:57 +00:00
|
|
|
alignmentOffset = frameLength;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Pick snap point based on direction and proximity
|
2017-03-29 13:59:45 +00:00
|
|
|
CGFloat fractionalIndex = (targetContentOffsetAlongAxis + alignmentOffset) / snapToIntervalF;
|
|
|
|
NSInteger snapIndex =
|
|
|
|
velocityAlongAxis > 0.0 ?
|
|
|
|
ceil(fractionalIndex) :
|
|
|
|
velocityAlongAxis < 0.0 ?
|
|
|
|
floor(fractionalIndex) :
|
|
|
|
round(fractionalIndex);
|
|
|
|
CGFloat newTargetContentOffset = (snapIndex * snapToIntervalF) - alignmentOffset;
|
2015-09-23 18:43:57 +00:00
|
|
|
|
|
|
|
// Set new targetContentOffset
|
|
|
|
if (isHorizontal) {
|
|
|
|
targetContentOffset->x = newTargetContentOffset;
|
|
|
|
} else {
|
|
|
|
targetContentOffset->y = newTargetContentOffset;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-15 19:16:07 +00:00
|
|
|
NSDictionary *userData = @{
|
|
|
|
@"velocity": @{
|
|
|
|
@"x": @(velocity.x),
|
|
|
|
@"y": @(velocity.y)
|
|
|
|
},
|
|
|
|
@"targetContentOffset": @{
|
|
|
|
@"x": @(targetContentOffset->x),
|
|
|
|
@"y": @(targetContentOffset->y)
|
|
|
|
}
|
|
|
|
};
|
2016-04-28 14:43:24 +00:00
|
|
|
RCT_SEND_SCROLL_EVENT(onScrollEndDrag, userData);
|
2015-02-20 04:10:52 +00:00
|
|
|
RCT_FORWARD_SCROLL_EVENT(scrollViewWillEndDragging:scrollView withVelocity:velocity targetContentOffset:targetContentOffset);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate
|
|
|
|
{
|
|
|
|
RCT_FORWARD_SCROLL_EVENT(scrollViewDidEndDragging:scrollView willDecelerate:decelerate);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)scrollViewWillBeginZooming:(UIScrollView *)scrollView withView:(UIView *)view
|
|
|
|
{
|
2016-04-28 14:43:24 +00:00
|
|
|
RCT_SEND_SCROLL_EVENT(onScrollBeginDrag, nil);
|
2015-02-20 04:10:52 +00:00
|
|
|
RCT_FORWARD_SCROLL_EVENT(scrollViewWillBeginZooming:scrollView withView:view);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)scrollViewDidEndZooming:(UIScrollView *)scrollView withView:(UIView *)view atScale:(CGFloat)scale
|
|
|
|
{
|
2016-04-28 14:43:24 +00:00
|
|
|
RCT_SEND_SCROLL_EVENT(onScrollEndDrag, nil);
|
2015-02-20 04:10:52 +00:00
|
|
|
RCT_FORWARD_SCROLL_EVENT(scrollViewDidEndZooming:scrollView withView:view atScale:scale);
|
|
|
|
}
|
|
|
|
|
2016-05-06 10:18:20 +00:00
|
|
|
- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView
|
|
|
|
{
|
|
|
|
// Fire a final scroll event
|
|
|
|
_allowNextScrollNoMatterWhat = YES;
|
|
|
|
[self scrollViewDidScroll:scrollView];
|
2016-05-12 19:16:42 +00:00
|
|
|
|
2016-05-06 10:18:20 +00:00
|
|
|
// Fire the end deceleration event
|
|
|
|
RCT_SEND_SCROLL_EVENT(onMomentumScrollEnd, nil);
|
|
|
|
RCT_FORWARD_SCROLL_EVENT(scrollViewDidEndDecelerating:scrollView);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)scrollViewDidEndScrollingAnimation:(UIScrollView *)scrollView
|
|
|
|
{
|
|
|
|
// Fire a final scroll event
|
|
|
|
_allowNextScrollNoMatterWhat = YES;
|
|
|
|
[self scrollViewDidScroll:scrollView];
|
2016-05-12 19:16:42 +00:00
|
|
|
|
2016-05-06 10:18:20 +00:00
|
|
|
// Fire the end deceleration event
|
2017-07-24 07:23:59 +00:00
|
|
|
RCT_SEND_SCROLL_EVENT(onMomentumScrollEnd, nil);
|
2016-05-06 10:18:20 +00:00
|
|
|
RCT_FORWARD_SCROLL_EVENT(scrollViewDidEndScrollingAnimation:scrollView);
|
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
- (BOOL)scrollViewShouldScrollToTop:(UIScrollView *)scrollView
|
|
|
|
{
|
2016-05-12 19:16:42 +00:00
|
|
|
for (NSObject<UIScrollViewDelegate> *scrollListener in _scrollListeners) {
|
|
|
|
if ([scrollListener respondsToSelector:_cmd] &&
|
|
|
|
![scrollListener scrollViewShouldScrollToTop:scrollView]) {
|
|
|
|
return NO;
|
|
|
|
}
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
return YES;
|
|
|
|
}
|
|
|
|
|
2015-06-15 14:53:45 +00:00
|
|
|
- (UIView *)viewForZoomingInScrollView:(__unused UIScrollView *)scrollView
|
2015-02-20 04:10:52 +00:00
|
|
|
{
|
|
|
|
return _contentView;
|
|
|
|
}
|
|
|
|
|
|
|
|
#pragma mark - Setters
|
|
|
|
|
|
|
|
- (CGSize)_calculateViewportSize
|
|
|
|
{
|
|
|
|
CGSize viewportSize = self.bounds.size;
|
|
|
|
if (_automaticallyAdjustContentInsets) {
|
|
|
|
UIEdgeInsets contentInsets = [RCTView contentInsetsForView:self];
|
|
|
|
viewportSize = CGSizeMake(self.bounds.size.width - contentInsets.left - contentInsets.right,
|
|
|
|
self.bounds.size.height - contentInsets.top - contentInsets.bottom);
|
|
|
|
}
|
|
|
|
return viewportSize;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (CGPoint)calculateOffsetForContentSize:(CGSize)newContentSize
|
|
|
|
{
|
|
|
|
CGPoint oldOffset = _scrollView.contentOffset;
|
|
|
|
CGPoint newOffset = oldOffset;
|
|
|
|
|
|
|
|
CGSize oldContentSize = _scrollView.contentSize;
|
|
|
|
CGSize viewportSize = [self _calculateViewportSize];
|
|
|
|
|
|
|
|
BOOL fitsinViewportY = oldContentSize.height <= viewportSize.height && newContentSize.height <= viewportSize.height;
|
|
|
|
if (newContentSize.height < oldContentSize.height && !fitsinViewportY) {
|
|
|
|
CGFloat offsetHeight = oldOffset.y + viewportSize.height;
|
|
|
|
if (oldOffset.y < 0) {
|
|
|
|
// overscrolled on top, leave offset alone
|
|
|
|
} else if (offsetHeight > oldContentSize.height) {
|
|
|
|
// overscrolled on the bottom, preserve overscroll amount
|
|
|
|
newOffset.y = MAX(0, oldOffset.y - (oldContentSize.height - newContentSize.height));
|
|
|
|
} else if (offsetHeight > newContentSize.height) {
|
|
|
|
// offset falls outside of bounds, scroll back to end of list
|
|
|
|
newOffset.y = MAX(0, newContentSize.height - viewportSize.height);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOL fitsinViewportX = oldContentSize.width <= viewportSize.width && newContentSize.width <= viewportSize.width;
|
|
|
|
if (newContentSize.width < oldContentSize.width && !fitsinViewportX) {
|
|
|
|
CGFloat offsetHeight = oldOffset.x + viewportSize.width;
|
|
|
|
if (oldOffset.x < 0) {
|
|
|
|
// overscrolled at the beginning, leave offset alone
|
|
|
|
} else if (offsetHeight > oldContentSize.width && newContentSize.width > viewportSize.width) {
|
|
|
|
// overscrolled at the end, preserve overscroll amount as much as possible
|
|
|
|
newOffset.x = MAX(0, oldOffset.x - (oldContentSize.width - newContentSize.width));
|
|
|
|
} else if (offsetHeight > newContentSize.width) {
|
|
|
|
// offset falls outside of bounds, scroll back to end
|
|
|
|
newOffset.x = MAX(0, newContentSize.width - viewportSize.width);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// all other cases, offset doesn't change
|
|
|
|
return newOffset;
|
|
|
|
}
|
|
|
|
|
2015-03-25 22:01:00 +00:00
|
|
|
/**
|
|
|
|
* Once you set the `contentSize`, to a nonzero value, it is assumed to be
|
|
|
|
* managed by you, and we'll never automatically compute the size for you,
|
|
|
|
* unless you manually reset it back to {0, 0}
|
|
|
|
*/
|
|
|
|
- (CGSize)contentSize
|
2015-02-20 04:10:52 +00:00
|
|
|
{
|
2015-03-25 22:01:00 +00:00
|
|
|
if (!CGSizeEqualToSize(_contentSize, CGSizeZero)) {
|
|
|
|
return _contentSize;
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
2017-02-02 17:51:19 +00:00
|
|
|
|
|
|
|
return _contentView.frame.size;
|
2015-02-20 04:10:52 +00:00
|
|
|
}
|
|
|
|
|
2017-12-12 02:49:54 +00:00
|
|
|
- (void)updateContentOffsetIfNeeded
|
2015-03-25 22:01:00 +00:00
|
|
|
{
|
|
|
|
CGSize contentSize = self.contentSize;
|
|
|
|
if (!CGSizeEqualToSize(_scrollView.contentSize, contentSize)) {
|
|
|
|
// When contentSize is set manually, ScrollView internals will reset
|
|
|
|
// contentOffset to {0, 0}. Since we potentially set contentSize whenever
|
|
|
|
// anything in the ScrollView updates, we workaround this issue by manually
|
|
|
|
// adjusting contentOffset whenever this happens
|
|
|
|
CGPoint newOffset = [self calculateOffsetForContentSize:contentSize];
|
|
|
|
_scrollView.contentSize = contentSize;
|
|
|
|
_scrollView.contentOffset = newOffset;
|
|
|
|
}
|
|
|
|
}
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
|
2018-01-18 21:51:43 +00:00
|
|
|
// maintainVisibleContentPosition is used to allow seamless loading of content from both ends of
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
// the scrollview without the visible content jumping in position.
|
2018-01-18 21:51:43 +00:00
|
|
|
- (void)setMaintainVisibleContentPosition:(NSDictionary *)maintainVisibleContentPosition
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
{
|
2018-01-18 21:51:43 +00:00
|
|
|
if (maintainVisibleContentPosition != nil && _maintainVisibleContentPosition == nil) {
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
[_eventDispatcher.bridge.uiManager.observerCoordinator addObserver:self];
|
2018-01-18 21:51:43 +00:00
|
|
|
} else if (maintainVisibleContentPosition == nil && _maintainVisibleContentPosition != nil) {
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
[_eventDispatcher.bridge.uiManager.observerCoordinator removeObserver:self];
|
|
|
|
}
|
2018-01-18 21:51:43 +00:00
|
|
|
_maintainVisibleContentPosition = maintainVisibleContentPosition;
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#pragma mark - RCTUIManagerObserver
|
|
|
|
|
|
|
|
- (void)uiManagerWillPerformMounting:(RCTUIManager *)manager
|
|
|
|
{
|
|
|
|
RCTAssertUIManagerQueue();
|
|
|
|
[manager prependUIBlock:^(RCTUIManager *uiManager, NSDictionary<NSNumber *, UIView *> *viewRegistry) {
|
|
|
|
BOOL horz = [self isHorizontal:self->_scrollView];
|
2018-01-18 21:51:43 +00:00
|
|
|
NSUInteger minIdx = [self->_maintainVisibleContentPosition[@"minIndexForVisible"] integerValue];
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
for (NSUInteger ii = minIdx; ii < self->_contentView.subviews.count; ++ii) {
|
|
|
|
// Find the first entirely visible view. This must be done after we update the content offset
|
|
|
|
// or it will tend to grab rows that were made visible by the shift in position
|
|
|
|
UIView *subview = self->_contentView.subviews[ii];
|
|
|
|
if ((horz
|
|
|
|
? subview.frame.origin.x >= self->_scrollView.contentOffset.x
|
|
|
|
: subview.frame.origin.y >= self->_scrollView.contentOffset.y) ||
|
|
|
|
ii == self->_contentView.subviews.count - 1) {
|
|
|
|
self->_prevFirstVisibleFrame = subview.frame;
|
|
|
|
self->_firstVisibleView = subview;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}];
|
|
|
|
[manager addUIBlock:^(RCTUIManager *uiManager, NSDictionary<NSNumber *, UIView *> *viewRegistry) {
|
2018-01-18 21:51:43 +00:00
|
|
|
if (self->_maintainVisibleContentPosition == nil) {
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
return; // The prop might have changed in the previous UIBlocks, so need to abort here.
|
|
|
|
}
|
2018-01-18 21:51:43 +00:00
|
|
|
NSNumber *autoscrollThreshold = self->_maintainVisibleContentPosition[@"autoscrollToTopThreshold"];
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
// TODO: detect and handle/ignore re-ordering
|
|
|
|
if ([self isHorizontal:self->_scrollView]) {
|
|
|
|
CGFloat deltaX = self->_firstVisibleView.frame.origin.x - self->_prevFirstVisibleFrame.origin.x;
|
|
|
|
if (ABS(deltaX) > 0.1) {
|
|
|
|
self->_scrollView.contentOffset = CGPointMake(
|
|
|
|
self->_scrollView.contentOffset.x + deltaX,
|
|
|
|
self->_scrollView.contentOffset.y
|
|
|
|
);
|
2018-01-18 21:51:43 +00:00
|
|
|
if (autoscrollThreshold != nil) {
|
|
|
|
// If the offset WAS within the threshold of the start, animate to the start.
|
|
|
|
if (self->_scrollView.contentOffset.x - deltaX <= [autoscrollThreshold integerValue]) {
|
|
|
|
[self scrollToOffset:CGPointMake(0, self->_scrollView.contentOffset.y) animated:YES];
|
|
|
|
}
|
|
|
|
}
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
CGRect newFrame = self->_firstVisibleView.frame;
|
|
|
|
CGFloat deltaY = newFrame.origin.y - self->_prevFirstVisibleFrame.origin.y;
|
2018-01-18 21:51:43 +00:00
|
|
|
if (ABS(deltaY) > 0.1) {
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
self->_scrollView.contentOffset = CGPointMake(
|
|
|
|
self->_scrollView.contentOffset.x,
|
|
|
|
self->_scrollView.contentOffset.y + deltaY
|
|
|
|
);
|
2018-01-18 21:51:43 +00:00
|
|
|
if (autoscrollThreshold != nil) {
|
|
|
|
// If the offset WAS within the threshold of the start, animate to the start.
|
|
|
|
if (self->_scrollView.contentOffset.y - deltaY <= [autoscrollThreshold integerValue]) {
|
|
|
|
[self scrollToOffset:CGPointMake(self->_scrollView.contentOffset.x, 0) animated:YES];
|
|
|
|
}
|
|
|
|
}
|
new feature to support smooth bi-directional content loading
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
2018-01-13 03:07:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}];
|
|
|
|
}
|
2015-03-25 22:01:00 +00:00
|
|
|
|
2015-03-13 23:17:21 +00:00
|
|
|
// Note: setting several properties of UIScrollView has the effect of
|
|
|
|
// resetting its contentOffset to {0, 0}. To prevent this, we generate
|
|
|
|
// setters here that will record the contentOffset beforehand, and
|
|
|
|
// restore it after the property has been set.
|
|
|
|
|
Removed defaultViews
Summary:When a component prop is set to null/undefined, and doesn't have a default value specified in `getDefaultProps`, the null value is sent over the bridge as a sentinel to reset to the original native value.
On iOS this is handled by creating a default view instance for each view type. The default view is then used to look up the unmodified value for any prop that is reset.
This is rather expensive however, as it means that for complex views (e.g. WebView, MapView), a minimum of two instances will be created even if only one is needed, and the default view will remain even after all actual view instances have been released.
This diff replaces the default view mechanism with a system where the default value of each prop is recorded the first time it is set. This avoids the need to keep an extra copy of the whole view.
The only exception is for props that use the `RCT_CUSTOM_VIEW_PROPERTY` macro, which includes the default view as part of the interface. To avoid a breaking change, a default view will still be created for views that use this macro, but only if they are sent a null value (so very rarely, in practice). In a future update we may deprecate or replace `RCT_CUSTOM_VIEW_PROPERTY` if there are significant benefits to doing so.
Reviewed By: javache
Differential Revision: D3012115
fb-gh-sync-id: 259348e54aa8342f444ad182b6f883d2dd684973
shipit-source-id: 259348e54aa8342f444ad182b6f883d2dd684973
2016-03-09 16:55:45 +00:00
|
|
|
#define RCT_SET_AND_PRESERVE_OFFSET(setter, getter, type) \
|
|
|
|
- (void)setter:(type)value \
|
|
|
|
{ \
|
|
|
|
CGPoint contentOffset = _scrollView.contentOffset; \
|
|
|
|
[_scrollView setter:value]; \
|
|
|
|
_scrollView.contentOffset = contentOffset; \
|
|
|
|
} \
|
|
|
|
- (type)getter \
|
|
|
|
{ \
|
|
|
|
return [_scrollView getter]; \
|
|
|
|
}
|
|
|
|
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setAlwaysBounceHorizontal, alwaysBounceHorizontal, BOOL)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setAlwaysBounceVertical, alwaysBounceVertical, BOOL)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setBounces, bounces, BOOL)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setBouncesZoom, bouncesZoom, BOOL)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setCanCancelContentTouches, canCancelContentTouches, BOOL)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setDecelerationRate, decelerationRate, CGFloat)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setDirectionalLockEnabled, isDirectionalLockEnabled, BOOL)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setIndicatorStyle, indicatorStyle, UIScrollViewIndicatorStyle)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setKeyboardDismissMode, keyboardDismissMode, UIScrollViewKeyboardDismissMode)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setMaximumZoomScale, maximumZoomScale, CGFloat)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setMinimumZoomScale, minimumZoomScale, CGFloat)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setScrollEnabled, isScrollEnabled, BOOL)
|
2016-09-27 13:19:45 +00:00
|
|
|
#if !TARGET_OS_TV
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setPagingEnabled, isPagingEnabled, BOOL)
|
Removed defaultViews
Summary:When a component prop is set to null/undefined, and doesn't have a default value specified in `getDefaultProps`, the null value is sent over the bridge as a sentinel to reset to the original native value.
On iOS this is handled by creating a default view instance for each view type. The default view is then used to look up the unmodified value for any prop that is reset.
This is rather expensive however, as it means that for complex views (e.g. WebView, MapView), a minimum of two instances will be created even if only one is needed, and the default view will remain even after all actual view instances have been released.
This diff replaces the default view mechanism with a system where the default value of each prop is recorded the first time it is set. This avoids the need to keep an extra copy of the whole view.
The only exception is for props that use the `RCT_CUSTOM_VIEW_PROPERTY` macro, which includes the default view as part of the interface. To avoid a breaking change, a default view will still be created for views that use this macro, but only if they are sent a null value (so very rarely, in practice). In a future update we may deprecate or replace `RCT_CUSTOM_VIEW_PROPERTY` if there are significant benefits to doing so.
Reviewed By: javache
Differential Revision: D3012115
fb-gh-sync-id: 259348e54aa8342f444ad182b6f883d2dd684973
shipit-source-id: 259348e54aa8342f444ad182b6f883d2dd684973
2016-03-09 16:55:45 +00:00
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setScrollsToTop, scrollsToTop, BOOL)
|
2016-09-27 13:19:45 +00:00
|
|
|
#endif
|
Removed defaultViews
Summary:When a component prop is set to null/undefined, and doesn't have a default value specified in `getDefaultProps`, the null value is sent over the bridge as a sentinel to reset to the original native value.
On iOS this is handled by creating a default view instance for each view type. The default view is then used to look up the unmodified value for any prop that is reset.
This is rather expensive however, as it means that for complex views (e.g. WebView, MapView), a minimum of two instances will be created even if only one is needed, and the default view will remain even after all actual view instances have been released.
This diff replaces the default view mechanism with a system where the default value of each prop is recorded the first time it is set. This avoids the need to keep an extra copy of the whole view.
The only exception is for props that use the `RCT_CUSTOM_VIEW_PROPERTY` macro, which includes the default view as part of the interface. To avoid a breaking change, a default view will still be created for views that use this macro, but only if they are sent a null value (so very rarely, in practice). In a future update we may deprecate or replace `RCT_CUSTOM_VIEW_PROPERTY` if there are significant benefits to doing so.
Reviewed By: javache
Differential Revision: D3012115
fb-gh-sync-id: 259348e54aa8342f444ad182b6f883d2dd684973
shipit-source-id: 259348e54aa8342f444ad182b6f883d2dd684973
2016-03-09 16:55:45 +00:00
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setShowsHorizontalScrollIndicator, showsHorizontalScrollIndicator, BOOL)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setShowsVerticalScrollIndicator, showsVerticalScrollIndicator, BOOL)
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setZoomScale, zoomScale, CGFloat);
|
|
|
|
RCT_SET_AND_PRESERVE_OFFSET(setScrollIndicatorInsets, scrollIndicatorInsets, UIEdgeInsets);
|
2015-02-20 04:10:52 +00:00
|
|
|
|
Add 'contentInsetAdjustmentBehavior' (new in iOS 11) to ScrollView
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
2017-07-31 19:10:11 +00:00
|
|
|
#if defined(__IPHONE_OS_VERSION_MAX_ALLOWED) && __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
|
|
|
|
- (void)setContentInsetAdjustmentBehavior:(UIScrollViewContentInsetAdjustmentBehavior)behavior
|
|
|
|
{
|
|
|
|
// `contentInsetAdjustmentBehavior` is available since iOS 11.
|
|
|
|
if ([_scrollView respondsToSelector:@selector(setContentInsetAdjustmentBehavior:)]) {
|
|
|
|
CGPoint contentOffset = _scrollView.contentOffset;
|
2018-06-20 16:50:29 +00:00
|
|
|
if (@available(iOS 11.0, *)) {
|
|
|
|
_scrollView.contentInsetAdjustmentBehavior = behavior;
|
|
|
|
}
|
Add 'contentInsetAdjustmentBehavior' (new in iOS 11) to ScrollView
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
2017-07-31 19:10:11 +00:00
|
|
|
_scrollView.contentOffset = contentOffset;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2016-04-28 14:43:24 +00:00
|
|
|
- (void)sendScrollEventWithName:(NSString *)eventName
|
2016-04-01 13:53:07 +00:00
|
|
|
scrollView:(UIScrollView *)scrollView
|
|
|
|
userData:(NSDictionary *)userData
|
|
|
|
{
|
2016-04-28 14:43:24 +00:00
|
|
|
if (![_lastEmittedEventName isEqualToString:eventName]) {
|
2016-04-01 13:53:08 +00:00
|
|
|
_coalescingKey++;
|
2016-04-28 14:43:24 +00:00
|
|
|
_lastEmittedEventName = [eventName copy];
|
2016-04-01 13:53:08 +00:00
|
|
|
}
|
2016-04-28 14:43:24 +00:00
|
|
|
RCTScrollEvent *scrollEvent = [[RCTScrollEvent alloc] initWithEventName:eventName
|
|
|
|
reactTag:self.reactTag
|
2017-07-15 03:54:46 +00:00
|
|
|
scrollViewContentOffset:scrollView.contentOffset
|
|
|
|
scrollViewContentInset:scrollView.contentInset
|
|
|
|
scrollViewContentSize:scrollView.contentSize
|
|
|
|
scrollViewFrame:scrollView.frame
|
|
|
|
scrollViewZoomScale:scrollView.zoomScale
|
2016-04-28 14:43:24 +00:00
|
|
|
userData:userData
|
|
|
|
coalescingKey:_coalescingKey];
|
2016-04-01 13:53:13 +00:00
|
|
|
[_eventDispatcher sendEvent:scrollEvent];
|
2016-04-01 13:53:07 +00:00
|
|
|
}
|
|
|
|
|
2015-02-20 04:10:52 +00:00
|
|
|
@end
|
2015-05-28 03:15:33 +00:00
|
|
|
|
|
|
|
@implementation RCTEventDispatcher (RCTScrollView)
|
|
|
|
|
2016-04-01 13:53:13 +00:00
|
|
|
- (void)sendFakeScrollEvent:(NSNumber *)reactTag
|
2015-05-28 03:15:33 +00:00
|
|
|
{
|
2016-04-28 14:43:24 +00:00
|
|
|
// Use the selector here in case the onScroll block property is ever renamed
|
|
|
|
NSString *eventName = NSStringFromSelector(@selector(onScroll));
|
|
|
|
RCTScrollEvent *fakeScrollEvent = [[RCTScrollEvent alloc] initWithEventName:eventName
|
|
|
|
reactTag:reactTag
|
2017-07-15 03:54:46 +00:00
|
|
|
scrollViewContentOffset:CGPointZero
|
|
|
|
scrollViewContentInset:UIEdgeInsetsZero
|
|
|
|
scrollViewContentSize:CGSizeZero
|
|
|
|
scrollViewFrame:CGRectZero
|
|
|
|
scrollViewZoomScale:0
|
2016-04-28 14:43:24 +00:00
|
|
|
userData:nil
|
|
|
|
coalescingKey:0];
|
2016-04-01 13:53:13 +00:00
|
|
|
[self sendEvent:fakeScrollEvent];
|
2015-05-28 03:15:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@end
|