texturegroup / texture Goto Github PK

View Code? Open in Web Editor NEW

7.9K 178.0 1.3K 133.46 MB

Smooth asynchronous user interfaces for iOS apps.

Home Page: https://texturegroup.org/

License: Other

Objective-C 27.19% Ruby 0.15% Objective-C++ 68.92% C++ 0.03% Shell 0.20% Swift 3.40% C 0.11%

asyncdisplaykit texture pinterest uikit rendering

texture's People

Contributors

Stargazers

Watchers

Forkers

garrettmoon johndpope atomtickets lappp9 dickyj podaenur pavelgnatyuk k06a dymv alvincrisuy hanton george-gw nguyenhuy rewcraig fruitcoder alexfedosov poonamdhomane fsmorygo manicakes matrixy dungnc cesteban djblake irshadpc daokunbai hannahcarney kukupigs zhbyak grabble timstarockz kb100824 lujianrong rickie1219 fanlilinsaber mixlan123 olivierobert mainstayz davevdveen thanhphong-tran xzoscar1988 amegias kevinls-coder nogginme niuxinghua rainhees rcancro juliuswskool zuoguoqing ckekebit snapsapp tuanla-mobilus sumitjain7 sergeypetrachkov graceydb jaichaudhry 1amageek viveco aiephoenix linwenbang dimazen wildcatip dennishappy niubilitya sd10 mingor vitalybaev suprie hannahmbanana jaideves jingyuzhao maybeiamme santensuru kavin-zhou imaduddinaf wucanqi idefix60 seropusha pacek teslaios nuglif ay8s liam-i hongtenglu martinjkelly blueghost56 benjamin-chang jayhuo junyoungit vanney9 stt-tech lavedi zhuzhengwei renwoxing sergeynewcastle z624821876 saik0s lingyehan langziguilai wsdwsd0829 idomgini

texture's Issues

[ASDataController] "Move" Operations Animate Incorrectly (Delete + Insert)

From @Adlai-Holler on October 2, 2015 21:12

This is a minor issue but I want to get it on the board while we're thinking through table view updates in #684 / #693. It results from us splitting moves into delete+insert in ASDataController.

I believe this issue is important because it highlights a really common architectural problem when dealing with table views: interpreting changes merely as array updates and discarding change metadata. For example, interpreting move as delete,insert or interpreting a reload section as remove all items, add all items which ignores section metadata like header views.

Since our updates are already required to be on the main thread, maybe we should split each intercepted call into two parts: the intact update, which we forward to the table view, and the array update where we interpret the update as above (e.g. move -> delete + insert).

Naturally all this applies to collection views as well.

Copied from original issue: facebookarchive/AsyncDisplayKit#698

LineSpacing issue in NSMutableParagraphStyle with ASTextNode

When an attributed string has different fontSize for words, lineSpacing property of NSMutableParagraphStyle is not working with ASTextNode. This is reproducible in
ASDKgram also.

Here is the code snippet which I used to reproduce this issue. I am trying to bring lines closer by giving lineSpacing = 0 but seems like it is not working. To reproduce it in ASDKgram just change descriptionAttributedStringWithFontSize method implementation in PhotoModel.m

- (NSAttributedString *)descriptionAttributedStringWithFontSize:(CGFloat)size {  
  NSArray *fontPerLineArray = @[@{@"Dicover new" : [NSNumber numberWithFloat:70]},
                                @{@"people near" : [NSNumber numberWithFloat:42]}, 
                                @{@"your location" : [NSNumber numberWithFloat:10]}];
  
  __block NSMutableAttributedString *attString = [[NSMutableAttributedString alloc] initWithString:@""];
  
  [fontPerLineArray enumerateObjectsUsingBlock:^(id  _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
    [obj enumerateKeysAndObjectsUsingBlock:^(NSString * _Nonnull lineText, id  _Nonnull obj, BOOL * _Nonnull stop) {
      NSMutableAttributedString *newAttributedString = [[NSMutableAttributedString alloc] initWithString:[NSString stringWithFormat:@"%@%@", lineText, idx == [fontPerLineArray count] - 1 ? @"" : @" "]];
      [newAttributedString addAttributes:@{NSForegroundColorAttributeName:[UIColor blackColor], NSFontAttributeName:[UIFont systemFontOfSize:[obj integerValue]]} range:NSMakeRange(0, lineText.length)];
      [attString appendAttributedString:newAttributedString];
    }];
  }];
  
  NSMutableParagraphStyle *paragraphStyle = [NSMutableParagraphStyle new];
  paragraphStyle.alignment = NSTextAlignmentCenter;
  paragraphStyle.lineSpacing = 0;
  [attString addAttribute:NSParagraphStyleAttributeName value:paragraphStyle range:NSMakeRange(0, attString.length)];
  return attString;
}

Attaching the screenshot of ASDKgram feed with ASTextNode having text with different font sizes.

IGListKit-integrated-scrolling slightly choppier than stock counterpart

In the ASDKgram example project, if you scroll in the "ASDK" then the "ListKit" tab, you can perceive a small performance drop in the ListKit version. The difference isn't enormous, but it's enough that it's ever so slightly "jumpy" at times (to be fair it's still great, just not as buttery smooth as the primary tab).

I posted two time profiles, one of each tab (attached) in the Slack, and @appleguy was kind enough to look at them and stated:

so, something is definitely not working optimally - for some reason the collection view sizeForItem: is hitting actual layout calculations rather than cached / layout-ahead

adding,

There have been changes in the Collection stack recently, and I can’t say for sure what it is. The non-IGListKit trace seems to lack this problem (with just a very quick look, maybe not definitive) so it could be that something in listkit is triggering a layout invalidation or moving ahead a call that normally waits

IGListKit is delightful, and the integration alongside Texture is sublime and life changing, but this small nitpick is ever so slightly unfortunate, so I've created an issue as requested. :)

Time Profiles:
listkit-vs-stock-texture-profiles.zip

[Yoga] Update to the current framework version (1.3.0) requires changing import path.

This is a copy of facebookarchive/AsyncDisplayKit#3248

On AsyncDisplayKit v. 2.2, Xcode 8.3.1

I'm testing Yoga for for some non-AsyncDisplayKit views, but not for any actual AsyncDisplayKit views.

AsyncDisplayKit 2.2 is installed with the Core subspec.
Yoga 1.3.0 is also installed by Cocoapods.

I wanted to update Yoga to the latest 1.3.0, but have run into a compile problem in ASDisplayNode+Beta.h and probably also elsewhere as Yuga has changed it's path names from#import <Yoga/Yoga.h> in 1.0.2 to #import <yoga/Yoga.h> in 1.3.0.

./Pods/AsyncDisplayKit/AsyncDisplayKit/ASDisplayNode+Beta.h:17:9: 
Non-portable path to file '<yoga/Yoga.h>'; specified path differs in case from file name on disk

I think the -Wno-nonportable-include-path warning is new with Xcode 8.3.

Is there a ways to prevent this when AsyncDisplayKit is installed without the Yoga subspec? The __has_include(<Yoga/Yoga.h>) check does not seem to work in this case.

Alternatively upgrade the Yoga podspec and the code to the later version

UICollectionReuseableView layoutAttributes unrecognized selector

Just updating to use Texture within Buffer. We're hitting a crash that looks to have been introduced here... 3164d8d

We're using IGListKit with Texture if that has any effect at all.

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001169de111 libobjc.A.dylib`objc_exception_throw
    frame #1: 0x000000011749c134 CoreFoundation`-[NSObject(NSObject) doesNotRecognizeSelector:] + 132
    frame #2: 0x00000001173b3840 CoreFoundation`___forwarding___ + 1024
    frame #3: 0x00000001173b33b8 CoreFoundation`__forwarding_prep_0___ + 120
  * frame #4: 0x00000001100ad487 Buffer`::-[ASCollectionView collectionView:willDisplaySupplementaryView:forElementKind:atIndexPath:](self=0x00007ff782855a00, _cmd="collectionView:willDisplaySupplementaryView:forElementKind:atIndexPath:", collectionView=0x00007ff782855a00, view=0x00007ff781db5450, elementKind="UICollectionElementKindSectionHeader", indexPath=0xc000000000000016) at ASCollectionView.mm:1123
    frame #5: 0x000000011494a9b4 UIKit`-[UICollectionView _createPreparedSupplementaryViewForElementOfKind:atIndexPath:withLayoutAttributes:applyAttributes:] + 1724
    frame #6: 0x0000000114965425 UIKit`-[UICollectionView _viewAnimationsForCurrentUpdate] + 4595
    frame #7: 0x000000011496ac7f UIKit`__71-[UICollectionView _updateWithItems:tentativelyForReordering:animator:]_block_invoke.2012 + 197
    frame #8: 0x00000001140cfd3e UIKit`+[UIView(Animation) performWithoutAnimation:] + 90
    frame #9: 0x00000001149698b9 UIKit`-[UICollectionView _updateWithItems:tentativelyForReordering:animator:] + 3856
    frame #10: 0x0000000114963bbf UIKit`-[UICollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:animator:] + 17030
    frame #11: 0x000000011496c259 UIKit`-[UICollectionView _endUpdatesWithInvalidationContext:tentativelyForReordering:animator:] + 71
    frame #12: 0x000000011496c5a0 UIKit`-[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:animator:] + 437
    frame #13: 0x000000011496c3c8 UIKit`-[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:] + 91
    frame #14: 0x000000011496c34a UIKit`-[UICollectionView _performBatchUpdates:completion:invalidationContext:] + 74
    frame #15: 0x000000011496c29f UIKit`-[UICollectionView performBatchUpdates:completion:] + 53
    frame #16: 0x00000001100a6c96 Buffer`::-[ASCollectionView _superPerformBatchUpdates:completion:](self=0x00007ff782855a00, _cmd="_superPerformBatchUpdates:completion:", updates=0x00000001100b9710, completion=0x00000001100ba9c0)(), void (^)(BOOL)) at ASCollectionView.mm:779
    frame #17: 0x00000001100b95ee Buffer`::__59-[ASCollectionView rangeController:didUpdateWithChangeSet:]_block_invoke((null)=<unavailable>) at ASCollectionView.mm:1877
    frame #18: 0x00000001100b936b Buffer`ASPerformBlockWithoutAnimation(withoutAnimation=NO, block=0x00000001100b93a0) block_pointer) at ASInternalHelpers.h:78
    frame #19: 0x00000001100b91ef Buffer`::-[ASCollectionView rangeController:didUpdateWithChangeSet:](self=0x00007ff782855a00, _cmd="rangeController:didUpdateWithChangeSet:", rangeController=0x00006100002a6ae0, changeSet=0x0000610000347220) at ASCollectionView.mm:1868
    frame #20: 0x00000001101a58a5 Buffer`::-[ASRangeController dataController:didUpdateWithChangeSet:](self=0x00006100002a6ae0, _cmd="dataController:didUpdateWithChangeSet:", dataController=0x000060000010fed0, changeSet=0x0000610000347220) at ASRangeController.mm:499
    frame #21: 0x00000001100cf503 Buffer`::__40-[ASDataController updateWithChangeSet:]_block_invoke_3((null)=0x00006080006630c0) at ASDataController.mm:583
    frame #22: 0x000000011017f5b4 Buffer`::__30-[ASMainSerialQueue runBlocks]_block_invoke((null)=<unavailable>) at ASMainSerialQueue.mm:62
    frame #23: 0x0000000117fb64a6 libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #24: 0x0000000117fdf05c libdispatch.dylib`_dispatch_client_callout + 8
    frame #25: 0x0000000117fc040b libdispatch.dylib`_dispatch_main_queue_callback_4CF + 411
    frame #26: 0x00000001173f1909 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
    frame #27: 0x00000001173b7ae4 CoreFoundation`__CFRunLoopRun + 2164
    frame #28: 0x00000001173b7016 CoreFoundation`CFRunLoopRunSpecific + 406
    frame #29: 0x0000000118d9ca24 GraphicsServices`GSEventRunModal + 62
    frame #30: 0x00000001140180d4 UIKit`UIApplicationMain + 159
    frame #31: 0x000000010f973801 Buffer`main(argc=1, argv=0x00007fff502942e0) at main.m:14
    frame #32: 0x000000011802b65d libdyld.dylib`start + 1

  thread #2, queue = 'com.apple.libdispatch-manager'
    frame #0: 0x0000000118342dc6 libsystem_kernel.dylib`kevent_qos + 10
    frame #1: 0x0000000117fd0efb libdispatch.dylib`_dispatch_mgr_wait_for_event + 66
    frame #2: 0x0000000117fca872 libdispatch.dylib`_dispatch_mgr_invoke + 197
    frame #3: 0x0000000117fca6a7 libdispatch.dylib`_dispatch_mgr_thread + 54

  thread #3
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #5
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #6, name = 'com.apple.uikit.eventfetch-thread'
    frame #0: 0x000000011833a34a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x0000000118339797 libsystem_kernel.dylib`mach_msg + 55
    frame #2: 0x00000001173b82e4 CoreFoundation`__CFRunLoopServiceMachPort + 212
    frame #3: 0x00000001173b77a9 CoreFoundation`__CFRunLoopRun + 1337
    frame #4: 0x00000001173b7016 CoreFoundation`CFRunLoopRunSpecific + 406
    frame #5: 0x0000000112ac6480 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 274
    frame #6: 0x0000000112b4bae9 Foundation`-[NSRunLoop(NSRunLoop) runUntilDate:] + 87
    frame #7: 0x0000000114a88931 UIKit`-[UIEventFetcher threadMain] + 118
    frame #8: 0x0000000112ad5fb1 Foundation`__NSThread__start__ + 1197
    frame #9: 0x00000001183769af libsystem_pthread.dylib`_pthread_body + 180
    frame #10: 0x00000001183768fb libsystem_pthread.dylib`_pthread_start + 286
    frame #11: 0x0000000118376101 libsystem_pthread.dylib`thread_start + 13

  thread #7
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #8
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #9, name = 'com.apple.NSURLConnectionLoader'
    frame #0: 0x000000011833a34a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x0000000118339797 libsystem_kernel.dylib`mach_msg + 55
    frame #2: 0x00000001173b82e4 CoreFoundation`__CFRunLoopServiceMachPort + 212
    frame #3: 0x00000001173b77a9 CoreFoundation`__CFRunLoopRun + 1337
    frame #4: 0x00000001173b7016 CoreFoundation`CFRunLoopRunSpecific + 406
    frame #5: 0x000000011160fdff CFNetwork`+[NSURLConnection(Loader) _resourceLoadLoop:] + 406
    frame #6: 0x0000000112ad5fb1 Foundation`__NSThread__start__ + 1197
    frame #7: 0x00000001183769af libsystem_pthread.dylib`_pthread_body + 180
    frame #8: 0x00000001183768fb libsystem_pthread.dylib`_pthread_start + 286
    frame #9: 0x0000000118376101 libsystem_pthread.dylib`thread_start + 13

  thread #10, name = 'GAIThread'
    frame #0: 0x000000011833a34a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x0000000118339797 libsystem_kernel.dylib`mach_msg + 55
    frame #2: 0x00000001173b82e4 CoreFoundation`__CFRunLoopServiceMachPort + 212
    frame #3: 0x00000001173b77a9 CoreFoundation`__CFRunLoopRun + 1337
    frame #4: 0x00000001173b7016 CoreFoundation`CFRunLoopRunSpecific + 406
    frame #5: 0x0000000112ac6480 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 274
    frame #6: 0x0000000112ac635b Foundation`-[NSRunLoop(NSRunLoop) run] + 76
    frame #7: 0x000000010feb3cde Buffer`+[GAI threadMain:] + 62
    frame #8: 0x0000000112ad5fb1 Foundation`__NSThread__start__ + 1197
    frame #9: 0x00000001183769af libsystem_pthread.dylib`_pthread_body + 180
    frame #10: 0x00000001183768fb libsystem_pthread.dylib`_pthread_start + 286
    frame #11: 0x0000000118376101 libsystem_pthread.dylib`thread_start + 13

  thread #11, queue = 'com.apple.CoreText.MorxConversion'
    frame #0: 0x0000000112973dec CoreText`MorxLigatureSubtableBuilder::From(long, unsigned int, unsigned int, TInlineVector<std::__1::vector<unsigned short, std::__1::allocator<unsigned short> >, 30ul> const&, std::__1::__wrap_iter<LigInput*>, std::__1::__wrap_iter<LigInput*>, std::__1::vector<unsigned short, std::__1::allocator<unsigned short> > const&) + 1102
    frame #1: 0x0000000112978197 CoreText`MorxTableBuilder::From(TFont const&, OTL::GCommon::Header const*, void const*, OTFeaturesMap&) + 8899
    frame #2: 0x000000011297a456 CoreText`ConvertGSUBToMorxInternal(TFont const&, __CFData const*) + 1170
    frame #3: 0x00000001128c3fe6 CoreText`___Z18ConvertToMorxAsyncPK8__CTFont_block_invoke + 80
    frame #4: 0x0000000117fb64a6 libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #5: 0x0000000117fdf05c libdispatch.dylib`_dispatch_client_callout + 8
    frame #6: 0x0000000117fbd94f libdispatch.dylib`_dispatch_queue_serial_drain + 221
    frame #7: 0x0000000117fbe669 libdispatch.dylib`_dispatch_queue_invoke + 1084
    frame #8: 0x0000000117fc0ec4 libdispatch.dylib`_dispatch_root_queue_drain + 634
    frame #9: 0x0000000117fc0bef libdispatch.dylib`_dispatch_worker_thread3 + 123
    frame #10: 0x0000000118376616 libsystem_pthread.dylib`_pthread_wqthread + 1299
    frame #11: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #12
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #13
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #14
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #15, name = 'com.squareup.SocketRocket.NetworkThread'
    frame #0: 0x000000011833a34a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x0000000118339797 libsystem_kernel.dylib`mach_msg + 55
    frame #2: 0x00000001173b82e4 CoreFoundation`__CFRunLoopServiceMachPort + 212
    frame #3: 0x00000001173b77a9 CoreFoundation`__CFRunLoopRun + 1337
    frame #4: 0x00000001173b7016 CoreFoundation`CFRunLoopRunSpecific + 406
    frame #5: 0x0000000112ac6480 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 274
    frame #6: 0x000000011003243e Buffer`-[_SRRunLoopThread main](self=0x000060800009b2b0, _cmd="main") at SRWebSocket.m:1903
    frame #7: 0x0000000112ad5fb1 Foundation`__NSThread__start__ + 1197
    frame #8: 0x00000001183769af libsystem_pthread.dylib`_pthread_body + 180
    frame #9: 0x00000001183768fb libsystem_pthread.dylib`_pthread_start + 286
    frame #10: 0x0000000118376101 libsystem_pthread.dylib`thread_start + 13

  thread #16, name = 'com.apple.CFSocket.private'
    frame #0: 0x0000000118341eb6 libsystem_kernel.dylib`__select + 10
    frame #1: 0x00000001173ee6d9 CoreFoundation`__CFSocketManager + 665
    frame #2: 0x00000001183769af libsystem_pthread.dylib`_pthread_body + 180
    frame #3: 0x00000001183768fb libsystem_pthread.dylib`_pthread_start + 286
    frame #4: 0x0000000118376101 libsystem_pthread.dylib`thread_start + 13

  thread #17
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #18
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #19
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #20
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #21
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #22
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #23
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #24
    frame #0: 0x000000011834244e libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x0000000118376695 libsystem_pthread.dylib`_pthread_wqthread + 1426
    frame #2: 0x00000001183760f1 libsystem_pthread.dylib`start_wqthread + 13

  thread #25, name = 'com.squareup.SocketRocket.NetworkThread'
    frame #0: 0x000000011833a34a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x0000000118339797 libsystem_kernel.dylib`mach_msg + 55
    frame #2: 0x00000001173b82e4 CoreFoundation`__CFRunLoopServiceMachPort + 212
    frame #3: 0x00000001173b77a9 CoreFoundation`__CFRunLoopRun + 1337
    frame #4: 0x00000001173b7016 CoreFoundation`CFRunLoopRunSpecific + 406
    frame #5: 0x0000000112ac6480 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 274
    frame #6: 0x0000000113df6a63 Smooch`-[_SKTSRRunLoopThread main] + 283
    frame #7: 0x0000000112ad5fb1 Foundation`__NSThread__start__ + 1197
    frame #8: 0x00000001183769af libsystem_pthread.dylib`_pthread_body + 180
    frame #9: 0x00000001183768fb libsystem_pthread.dylib`_pthread_start + 286
    frame #10: 0x0000000118376101 libsystem_pthread.dylib`thread_start + 13

Sometimes calling setNeedsLayout does not re-trigger layoutSpecThatFits

In my project, each cell represents a specific URL. In this particular case, I make an API call to figure out what the URL represents, and re-layout the cell based on the new information I receive. It's very similar in concept to ASDKgram and how it fetches the comments specific to a post, and re-layouts the cell upon receiving.

It works great 90% of the time, but every so often, if I put a breakpoint at my setNeedsLayout call (once the cell has found out what it represents), and another at my overridden layoutSpecThatFits method, I see that the latter is never called, and I'm not sure why given that most of the time it acts as I would expect.

In the cell's init, I perform the network call, and in its completion handler I create the new node (important to note perhaps that this is the first time this node is created; it's nil prior to this as the node instantiated is dependent on what the API returns). I then call setNeedsLayout immediately, and then layoutSpecThatFits should pick up on the fact it's not nil and then include it in the node hierarchy.

If I log these calls, it looks like this when it works as expected:

layoutSpecThatFits called.
layoutSpecThatFits called.
setNeedsLayout called.
layoutSpecThatFits called.
layoutSpecThatFits called.

and when not:

layoutSpecThatFits called.
layoutSpecThatFits called.
setNeedsLayout called.

In the example project below, you can see by restarting the app a few times, that normally, the network call is received, the cell performs another layout pass, and the cell shows the new information. However, if you restart it enough (sometimes takes 5+, and is much easier to replicate on a device rather than the simulator), you'll see it won't show the image after the API call returns:

I'm really at wit's end trying to figure out what may be causing it. It should already be in the view hierarchy at the time it's called so it's not as if setNeedsLayout is being called on a non-visible node. It's totally possible (even likely) that it's something I'm doing accidentally to cause this, but any light anyone could shine onto the issue would be greatly appreciated.

Sample project:
TextureTest.zip
(Just run pod install; uses most recent version of Texture. There's some other files inside that are part of the model and for API calls, but really the only relevant files are LargePostCellNode and PostsViewController. It may take a few restarts of the app to show the issue.)

[ASDisplayNode] `cancelAsyncDisplay` must clear dirty contents of layer

From @molon on November 26, 2015 13:20

Hi,
There's a ASTextNode in a ASLazyLoadCellNode.
I try to set attributedString to it at the end of table view.
Then I insert new rows.

This is just the happen scene upon.

debug below:
some test I added:

break at the function

the output, we can see it breaks before the last isCancelledBlock

We can see that the willMoveToWindow:(window is nil) is called because of inserting rows.
it cause cancelAsyncDisplay to be called. This led to dirty contents of layer.

Then the last isCancelledBlock will return YES. The last draw attributedString will be ignored. So it layer.content is stale(dirty) now.

__enterHierarchy will be called when willMoveToWindow(window is not nil).
setNeedsDisplay is called in __enterHierarchy when layer.content == nil.
But the layer.content==nil can only ensure the layer will be redraw when nil, not stale(dirty).
And It's really dirty sometimes.
eg:
updateVisibleNodeIndexPaths will lead to recursivelyClearContents with some indexPaths. it's ok.
But [_layoutController indexPathsForScrolling:_scrollDirection viewportSize:viewportSize rangeType:rangeType] will return indexPaths which not visible sometimes, thus these rows will be remove from window by configureContentView:forCellNode: but havn't clear content.
So the rows will not be redisplay. I think it's a BUG.

In summary, the cancelAsyncDisplay only cancel the next drawing of layer, but! but! not clear the dirty contents of layer. So it will be not redraw because it's contents not nil ,when the layer display again,

I think views is not necessary to call cancelAsyncDisplay after removing from a window unless we can throw the dirty contents away.
It will cause some unforeseen circumstances.

Copied from original issue: facebookarchive/AsyncDisplayKit#889

Synchronous Cell Nodes May Trigger Assertion Failure When Deleted or Reload from Collection

I've found the issue facebookarchive/AsyncDisplayKit#2855 and at the same time, reload section also trigger this problem.

Is there any progress on this one?

Thanks.

[ASDisplayNode] Locking on isSynchronous is avoidable and sometimes deadlocks.

I attempted converting it to a const flag, but there are a couple places this doesn't work - mainly the setViewBlock: method (can we get rid of those / why do they exist?)

It would work for all use cases to convert it to a std::atomic.

Unless we make a change, there does exist a scenario where we can deadlock due to hitting isSynchronous.

(lldb) bt all
* thread #1: tid = 0x31f6, 0x0000000180b03f6c libsystem_kernel.dylib`__psynch_mutexwait + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x0000000180b03f6c libsystem_kernel.dylib`__psynch_mutexwait + 8
    frame #1: 0x0000000180bd239c libsystem_pthread.dylib`_pthread_mutex_lock_wait + 96
    frame #2: 0x0000000180bd257c libsystem_pthread.dylib`_pthread_mutex_lock_slow + 296
  * frame #3: 0x00000001015d5d48 App`ASDN::Mutex::lock(this=0x000000015925c458) + 60 at ASThread.h:198
    frame #4: 0x00000001015d5ce0 App`ASDN::Locker<ASDN::Mutex>::Locker(this=0x000000016fddf4b0, l=0x000000015925c458) + 68 at ASThread.h:84
    frame #5: 0x00000001015d2d1c App`ASDN::Locker<ASDN::Mutex>::Locker(this=0x000000016fddf4b0, l=0x000000015925c458) + 64 at ASThread.h:83
    frame #6: 0x0000000101611f48 App`::-[ASDisplayNode isSynchronous](self=0x000000015925c450, _cmd="isSynchronous") + 80 at ASDisplayNode.mm:753
    frame #7: 0x0000000101627428 App`shouldDisableNotificationsForMovingBetweenParents(from=0x000000015925c450, to=0x0000000157d2df10) + 148 at ASDisplayNode.mm:2453
    frame #8: 0x000000010162716c App`::-[ASDisplayNode _insertSubnode:atSubnodeIndex:sublayerIndex:andRemoveSubnode:](self=0x0000000157d2df10, _cmd="_insertSubnode:atSubnodeIndex:sublayerIndex:andRemoveSubnode:", subnode=0x00000001591b9fa0, subnodeIndex=1, sublayerIndex=1, oldSubnode=0x0000000000000000) + 2276 at ASDisplayNode.mm:2636
    frame #9: 0x000000010162bcc4 App`::-[ASDisplayNode _insertSubnode:atIndex:](self=0x0000000157d2df10, _cmd="_insertSubnode:atIndex:", subnode=0x00000001591b9fa0, idx=1) + 1992 at ASDisplayNode.mm:2931
    frame #10: 0x00000001017759d0 App`::-[ASLayoutTransition applySubnodeInsertions](self=0x00000001592a84a0, _cmd="applySubnodeInsertions") + 840 at ASLayoutTransition.mm:112
    frame #11: 0x0000000101775648 App`::-[ASLayoutTransition commitTransition](self=0x00000001592a84a0, _cmd="commitTransition") + 68 at ASLayoutTransition.mm:95
    frame #12: 0x000000010161e5a0 App`::-[ASDisplayNode _completeLayoutTransition:](self=0x0000000157d2df10, _cmd="_completeLayoutTransition:", layoutTransition=0x00000001592a84a0) + 216 at ASDisplayNode.mm:1767
    frame #13: 0x000000010161e434 App`::-[ASDisplayNode _completePendingLayoutTransition](self=0x0000000157d2df10, _cmd="_completePendingLayoutTransition") + 276 at ASDisplayNode.mm:1749
    frame #14: 0x0000000101614e08 App`::-[ASDisplayNode _locked_measureNodeWithBoundsIfNecessary:](self=0x0000000157d2df10, _cmd="_locked_measureNodeWithBoundsIfNecessary:", bounds=(origin = (x = 0, y = 0), size = (width = 768, height = 40))) + 2540 at ASDisplayNode.mm:1045
    frame #15: 0x0000000101614238 App`::-[ASDisplayNode __layout](self=0x0000000157d2df10, _cmd="__layout") + 660 at ASDisplayNode.mm:960
    frame #16: 0x000000010170fb48 App`::-[_ASDisplayLayer layoutSublayers](self=0x0000000157e2bbf0, _cmd="layoutSublayers") + 440 at _ASDisplayLayer.mm:132
    frame #17: 0x0000000183a495d0 QuartzCore`CA::Layer::layout_if_needed(CA::Transaction*) + 292
    frame #18: 0x0000000183a49490 QuartzCore`CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 32
    frame #19: 0x0000000183a48ac0 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 252
    frame #20: 0x0000000183a48820 QuartzCore`CA::Transaction::commit() + 500
    frame #21: 0x0000000183a9c190 QuartzCore`CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 592
    frame #22: 0x00000001811e1e54 IOKit`IODispatchCalloutFromCFMessage + 372
    frame #23: 0x0000000180f09030 CoreFoundation`__CFMachPortPerform + 180
    frame #24: 0x0000000180f217d4 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 56
    frame #25: 0x0000000180f20f0c CoreFoundation`__CFRunLoopDoSource1 + 436
    frame #26: 0x0000000180f1ec64 CoreFoundation`__CFRunLoopRun + 1800
    frame #27: 0x0000000180e48c50 CoreFoundation`CFRunLoopRunSpecific + 384
    frame #28: 0x0000000182730088 GraphicsServices`GSEventRunModal + 180
    frame #29: 0x000000018612a088 UIKit`UIApplicationMain + 204
    frame #30: 0x000000010008d198 App`main(argc=1, argv=0x000000016fde3a00) + 236 at main.m:41
    frame #31: 0x00000001809e68b8 libdyld.dylib`start + 4

  thread #27: tid = 0x3300, 0x0000000180b03f6c libsystem_kernel.dylib`__psynch_mutexwait + 8, queue = 'com.apple.root.default-qos'
    frame #0: 0x0000000180b03f6c libsystem_kernel.dylib`__psynch_mutexwait + 8
    frame #1: 0x0000000180bd239c libsystem_pthread.dylib`_pthread_mutex_lock_wait + 96
    frame #2: 0x0000000180bd257c libsystem_pthread.dylib`_pthread_mutex_lock_slow + 296
    frame #3: 0x00000001015d5d48 App`ASDN::Mutex::lock(this=0x0000000157d2df18) + 60 at ASThread.h:198
    frame #4: 0x00000001015d5ce0 App`ASDN::Locker<ASDN::Mutex>::Locker(this=0x000000016eb05830, l=0x0000000157d2df18) + 68 at ASThread.h:84
    frame #5: 0x00000001015d2d1c App`ASDN::Locker<ASDN::Mutex>::Locker(this=0x000000016eb05830, l=0x0000000157d2df18) + 64 at ASThread.h:83
    frame #6: 0x00000001016267bc App`::-[ASDisplayNode subnodes](self=0x0000000157d2df10, _cmd="subnodes") + 68 at ASDisplayNode.mm:2558
    frame #7: 0x0000000101612ca0 App`::-[ASDisplayNode sublayoutElements](self=0x0000000157d2df10, _cmd="sublayoutElements") + 68 at ASDisplayNode.mm:844
    frame #8: 0x00000001017336bc App`::ASLayoutElementPerformBlockOnEveryElement(element=0x0000000157d2df10, block=0x00000001016fa700)(id)) + 208 at ASLayoutElement.mm:32
    frame #9: 0x0000000101733780 App`::ASLayoutElementPerformBlockOnEveryElement(element=0x0000000157d2b8a0, block=0x00000001016fa700)(id)) + 404 at ASLayoutElement.mm:33
    frame #10: 0x00000001016fa69c App`::ASTraitCollectionPropagateDown(root=0x0000000157d2b8a0, traitCollection=<unavailable>) + 172 at ASTraitCollection.m:23
    frame #11: 0x00000001016163c8 App`::-[ASDisplayNode calculateLayoutThatFits:](self=0x000000015925c450, _cmd="calculateLayoutThatFits:", constrainedSize=(min = (width = 768, height = 0), max = (width = 768, height = 1.7976931348623157E+308))) + 2992 at ASDisplayNode.mm:1152
    frame #12: 0x0000000101615670 App`::-[ASDisplayNode calculateLayoutThatFits:restrictedToSize:relativeToParentSize:](self=0x000000015925c450, _cmd="calculateLayoutThatFits:restrictedToSize:relativeToParentSize:", constrainedSize=(min = (width = 768, height = 0), max = (width = 768, height = 1.7976931348623157E+308)), parentSize=(width = 768, height = 1.7976931348623157E+308)) + 428 at ASDisplayNode.mm:1092
    frame #13: 0x0000000101613910 App`::-[ASDisplayNode layoutThatFits:parentSize:](self=0x000000015925c450, _cmd="layoutThatFits:parentSize:", constrainedSize=(min = (width = 768, height = 0), max = (width = 768, height = 1.7976931348623157E+308)), parentSize=(width = 768, height = 1.7976931348623157E+308)) + 1724 at ASDisplayNode.mm:901
    frame #14: 0x00000001016375a0 App`::-[ASDisplayNode measureWithSizeRange:](self=0x000000015925c450, _cmd="measureWithSizeRange:", constrainedSize=(min = (width = 768, height = 0), max = (width = 768, height = 1.7976931348623157E+308))) + 136 at ASDisplayNode.mm:3990
    frame #15: 0x0000000101613224 App`::-[ASDisplayNode layoutThatFits:](self=0x000000015925c450, _cmd="layoutThatFits:", constrainedSize=(min = (width = 768, height = 0), max = (width = 768, height = 1.7976931348623157E+308))) + 120 at ASDisplayNode.mm:876
    frame #16: 0x00000001016db260 App`::-[ASDataController _layoutNode:withConstrainedSize:](self=0x00000001513c6200, _cmd="_layoutNode:withConstrainedSize:", node=0x000000015925c450, constrainedSize=(min = (width = 768, height = 0), max = (width = 768, height = 1.7976931348623157E+308))) + 708 at ASDataController.mm:175
    frame #17: 0x00000001016dc060 App`::__45-[ASDataController _layoutNodesFromContexts:]_block_invoke((null)=<unavailable>, i=84) + 972 at ASDataController.mm:205
    frame #18: 0x00000001016e4d64 App`::___ZL15ASDispatchApplymPU28objcproto17OS_dispatch_queue8NSObjectmU13block_pointerFvmE_block_invoke((null)=<unavailable>) + 140 at ASDispatch.h:27
    frame #19: 0x0000000105c61a7c libdispatch.dylib`_dispatch_call_block_and_release + 24
    frame #20: 0x0000000105c61a3c libdispatch.dylib`_dispatch_client_callout + 16
    frame #21: 0x0000000105c70c9c libdispatch.dylib`_dispatch_root_queue_drain + 2344
    frame #22: 0x0000000105c70364 libdispatch.dylib`_dispatch_worker_thread3 + 132
    frame #23: 0x0000000180bcd470 libsystem_pthread.dylib`_pthread_wqthread + 1092
    frame #24: 0x0000000180bcd020 libsystem_pthread.dylib`start_wqthread + 4

  thread #28: tid = 0x331b, 0x0000000180ae9014 libsystem_kernel.dylib`semaphore_wait_trap + 8, queue = 'org.AsyncDisplayKit.ASDataController.editingTransactionQueue:0x1513c6200'
    frame #0: 0x0000000180ae9014 libsystem_kernel.dylib`semaphore_wait_trap + 8
    frame #1: 0x0000000105c73efc libdispatch.dylib`_dispatch_group_wait_slow + 260
    frame #2: 0x00000001016dbbdc App`ASDispatchApply(iterationCount=92, queue=0x0000000105ca9140, threadCount=4, work=0x00000001016dbc94) block_pointer) + 492 at ASDispatch.h:31
    frame #3: 0x00000001016db7ac App`::-[ASDataController _layoutNodesFromContexts:](self=0x00000001513c6200, _cmd="_layoutNodesFromContexts:", elements=92 elements) + 916 at ASDataController.mm:191
    frame #4: 0x00000001016dae50 App`::-[ASDataController batchLayoutNodesFromContexts:batchSize:batchCompletion:](self=0x00000001513c6200, _cmd="batchLayoutNodesFromContexts:batchSize:batchCompletion:", elements=92 elements, batchSize=92, batchCompletionHandler=0x00000001016e00d4) + 1092 at ASDataController.mm:160
    frame #5: 0x00000001016dffec App`::__40-[ASDataController updateWithChangeSet:]_block_invoke.193((null)=<unavailable>) + 360 at ASDataController.mm:490
    frame #6: 0x0000000105c61a7c libdispatch.dylib`_dispatch_call_block_and_release + 24
    frame #7: 0x0000000105c61a3c libdispatch.dylib`_dispatch_client_callout + 16
    frame #8: 0x0000000105c6e554 libdispatch.dylib`_dispatch_queue_drain + 1036
    frame #9: 0x0000000105c6572c libdispatch.dylib`_dispatch_queue_invoke + 464
    frame #10: 0x0000000105c61a3c libdispatch.dylib`_dispatch_client_callout + 16
    frame #11: 0x0000000105c70c9c libdispatch.dylib`_dispatch_root_queue_drain + 2344
    frame #12: 0x0000000105c70364 libdispatch.dylib`_dispatch_worker_thread3 + 132
    frame #13: 0x0000000180bcd470 libsystem_pthread.dylib`_pthread_wqthread + 1092
    frame #14: 0x0000000180bcd020 libsystem_pthread.dylib`start_wqthread + 4

[ASCollectionView] Use UICollectionViewLayout invalidation events to relayout

From @levi on September 28, 2015 16:39

Issue #690 brought up a good point I've been thinking about as I was putting together the supplementary view architecture briefly this weekend. The current data controller integration with ASCollectionView reiles upon layout invalidation from reloading/inserting/deleting/moving items or @nguyenhuy's new relayout items based upon the collection view's bounds changes. These behaviors closely model the specific implementation of a table view, but it's clear as we have begun to mature the behavior of our collection view most of the sizing events and values (namely constrainedSizeForNode:) have been built around the powerful Collection view layouts.

I've been doing a bit of research into the invalidateLayout and invaldateLayoutWithContext: methods. While the provided context is not as granular as I initially hoped, I believe these events are great candidates for us to use as hooks for relayout events in the collection view's data controller.

Moreover, as we query the collection view for constrained sizes I think we should start asking the collection view layout for specific values. This will move the layout (constrainedSizeForNode:) code we currently have in ASCollectionView into a separate place that is specific to the current collection view layout.

With that, a couple of solutions have come to mind:

Make ASDataController an abstract class that table view and collection view have concrete implementations of. This will give each view the ability to add custom behavior such as supplementary views for collection views and header/footer nodes for tables views.
Once that we have a concrete ASCollectionDataController with supplementary view support, the data controller interfaces with a strategy object that provides all the necessary answers to questions from the data controller about the current layout. For example, "how many supplementary views are in this section?", "what's the constrained size for this node?". This strategy is provided by the client of ASCollectionView and either set directly as a property on ASCollectionDataController or is composed in ASViewController and its values returned at specific points of the data controllers data source method (I'm leaning toward the latter). The default limitation would be a generic strategy for flow layouts.
We migrate ASCollectionView to start node invalidation and relayout on ‘invalidateLayout‘ events. I already have the proxying of invalidateLayout working in a branch, but it's beyond the scope of implementing supplementary views into ASCollectionView. This will allow us to support ‘itemSize‘ changes in a flow layout, for example, and respect the layout invalidation events that can at times use animation transitions to change the item's sizes.
#1 and #2 is where I'm planning to go this week to get my branch building and running. I feel that it should be a flexible enough solution to test and also to continue composing as custom layout authors investigate using their layouts with supplementary views. #3 is where I'd like to start discussion, as it's a little more involved and not something I'm planning to do this week.

Wrote this on my phone, so let me know if anything doesn't make sense.

Copied from original issue: facebookarchive/AsyncDisplayKit#691

[Yoga BETA] Discussion of evolving prototype Yoga support

Hi,
I am an early user and a serious supporter of ASDK and Yoga.
I am particularly excited when notice that @appleguy is adding Yoga support for ASDK today.

As a users, I has some advices to expect resonance:

ASDK has so many LayoutSpecs (ASStackLayoutSpec,ASInsetLayoutSpec and so on). The more structured, "visually" declarative style also
is great.(

Texture/examples/ASDKgram/Sample/PhotoCellNode.m

Line 185 in 5e354c8

return

)
But since it is based on flexbox , why not just provide basic layout and clear names same with flexbox directly.
After all, flexbox has become a standard. If this is the case, learning costs will be low and readability will be more intuitive for experienced flexbox users, and the final layout codes would like below:

This is my own library based on css-layout , so maybe the advice is just my own feeling because of my habit. Still need resonance, because I want to use ASDK to write all pages in my next project. 😂
We often encounter a scene: a cell's subview need to be hided because of data, so we need to setHidden: for it and change it's layout's margin padding or removeFromSuperview. It's so troublesome. So I advise to add a property layoutInvalid, a simple layout switch is used temporarily.

Add Target on ASControl Node not responding

I added this line in LikeNode of SocialApp Layout sample,but its not working i tried creating new class again but that doesn't help.. I am not getting clue why its not calling this "likeTapped" Method
I posted this question on slack too, but no response, home somebody will this fix for me,i tried all the way i can

 [self addTarget:self action:@selector(likeTapped:) forControlEvents:ASControlNodeEventTouchUpInside];
 
 -(void)likeTapped:(id)sender {
     NSLog(@"Like Tapped");
}

Discussion: alternative to completion handlers on reload/endUpdates, etc

From @eanagel on July 26, 2015 15:53

I've been thinking about this since adding the completion handlers for reloadData and endUpdates and #581 by @frankenthumb got me thinking about it more. The essential issue is that, without these completion handlers, there is no guarantee that the UITableView's data is in sync with the asyncDataSource. You can handle some things by always relying on ASTableView (or ASCollectionView) as the source of truth for your data, but sometimes you just need them to be in sync. (My #1 use case is positioning to a specific row after reload.)

I've been thinking it might be simpler and more elegant to introduce a new method that solves this problem more generally. One that basically says "run this block when all changes up to this point have been committed." Technically, that's what these completion blocks are, but they are only available for these two methods currently.

I've been struggling with what this method sholud be called, but let's say we call it -(void)syncEditsWithCompletion:(void (^)())completion;. This would call completion on the main thread as soon as all currently scheduled updates (which should include reloadData begin/endUpdates or any of the editing commands) have completed and before any others have been initiated.

@appleguy I'm thinking we can just schedule this completion on the editingTransationQueue to accomplish this easily. That would work, right? I'm also wondering exactly how reloadData works W.R.T. the editingTransactionQueue and if that approach would work with that.

Would love some feedback on this idea.

Copied from original issue: facebookarchive/AsyncDisplayKit#587

Crash when using ASTableNode convert(_ rect:,from:) with ASCellNode method

I tried to retrieve the frame of an ASCellNode within its container ASTableNode. I need this to animate transition of the cell to next screen.

When I called tableNode.convert(cell.frame, from: cell), I expected to return the cell frame in the table coordinate. instead I get error: Could not find a common ancestor between node1: <MyCellNode: 0x7fee331bb000> and node2: <ASTableNode: 0x7fee32e0d5d0>

This is weird, can a table node not the ancestor of a cell node?

This can be reproduced by adding two lines to AsyncDisplayKit/examples/ASViewControllerSample/ViewController.m

- (void)tableNode:(ASTableNode *)tableNode didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    // add these two lines to get the Rect of the cell node... 
    // it will crash the app when user tap a row
    ASCellNode* cell = [tableNode nodeForRowAtIndexPath:indexPath];
    CGRect rect = [tableNode convertRect:cell.frame fromNode:cell];

    NSString *imageCategory = self.imageCategories[indexPath.row];
    DetailRootNode *detailRootNode = [[DetailRootNode alloc] initWithImageCategory:imageCategory];
    DetailViewController *detailViewController = [[DetailViewController alloc] initWithNode:detailRootNode];
    detailViewController.title = [imageCategory capitalizedString];
    [self.navigationController pushViewController:detailViewController animated:YES];
}

ASMultiplexImageNode holds reference of _downloader

From @samw723 on June 23, 2015 10:38

I found if set self to ASMultiplexImageNode like
[[ASMultiplexImageNode alloc] initWithCache:nil downloader:self]
, the downloader holds reference while deinit

id _downloader; // seems not __weak

Could someone modify to use __weak on _downloader?

Copied from original issue: facebookarchive/AsyncDisplayKit#502

[ASLabelNode] Create a simpler alternative to ASTextNode

From @secretiverhyme on December 11, 2014 23:49

ASTextNode's attributedString API is overkill for a simple, uniformly-styled label. Consider—

ASLabelNode *label = [[ASLabelNode alloc] init];
label.textColor = [UIColor grayColor];
label.font = [UIFont systemFontOfSize:12.0f];
label.text = @"hello";

—versus—

ASTextNode *label = [[ASTextNode alloc] init];
NSDictionary *attributes = @{ NSForegroundColorAttributeName: [UIColor grayColor],
                                         NSFontAttributeName: [UIFont systemFontOfSize:12.0f] };
NSAttributedString *attributedString = [[NSAttributedString alloc] initWithString:@"hello"
                                                                       attributes:attributes];

Copied from original issue: facebookarchive/AsyncDisplayKit#152

ASNetworkImageNode in swift load gif not animating

This is my code

let imageNode = ASNetworkImageNode()

        imageNode.url = URL(string: "https://media.giphy.com/media/l2R0aKwejYr8ycKAg/giphy.gif")
        imageNode.delegate = self
        imageNode.frame = view.bounds
        imageNode.autoresizingMask = [.flexibleWidth, .flexibleHeight]
        imageNode.contentMode = .scaleAspectFit
        view.addSubnode(imageNode)

ASTextKitFontSizeAdjuster longest word

The ASTextKitFontSizeAdjuster class tries to find te longest word to prevent character wrapping. This is done by finding the longest word in terms of character count. For a monospaced font this is correct but not for proportional font. For instance the word 'Thanksgiving' counts 12 characters but is in terms of size longer than 'Tellerfleisch' which counts 13 characters.

So you may end up in the following situation:
Thanksgivin
g
Tellerfleisch

Also a NSAttributedString can contain multiple styles. The current implementation assumes that the style of first occurrence of the longest word is the style of the complete text. So the current implementation isn't accurate.

I implemented a version which checks the actual width of the different words. This comes with a performance penalty, but is accurate.

UIKit semantics for when "visibleIndexPaths" is valid are not clear (.visibleNodes)

From @nvh on October 20, 2015 8:11

Although it maybe doesn't make sense to call it directly in the performBatchUpdates block
- (void)collectionView:(ASCollectionView *)collectionView willDisplayNodeForItemAtIndexPath:(NSIndexPath *)indexPath; is called before the batch update completes as well, which can lead to this crash when calling 'visibleNodes' inside that delegate function:

2015-10-20 09:45:54.936 demo-app[99621:4521736] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 5 beyond bounds [0 .. 4]'
*** First throw call stack:
(
    0   CoreFoundation                      0x0000000106c44f65 __exceptionPreprocess + 165
    1   libobjc.A.dylib                     0x00000001066bedeb objc_exception_throw + 48
    2   CoreFoundation                      0x0000000106b28a94 -[__NSArrayM objectAtIndex:] + 212
    3   AsyncDisplayKit                     0x0000000106231662 -[ASDataController nodeAtIndexPath:] + 118
    4   AsyncDisplayKit                     0x000000010620bea0 -[ASCollectionView nodeForItemAtIndexPath:] + 28
    5   AsyncDisplayKit                     0x000000010620bb8f __32-[ASCollectionView visibleNodes]_block_invoke + 33
    6   CoreFoundation                      0x0000000106b86d7d __53-[__NSArrayI enumerateObjectsWithOptions:usingBlock:]_block_invoke + 77
    7   CoreFoundation                      0x0000000106b86c4f -[__NSArrayI enumerateObjectsWithOptions:usingBlock:] + 207
    8   AsyncDisplayKit                     0x000000010620bafe -[ASCollectionView visibleNodes] + 175
    9   demo-app                            0x0000000102de26cd _TFC10demo_app26ViewController18updateVisibleNodesfS0_FT_T_ + 157
    10  demo-app                            0x0000000102de3b92 _TFC10demo_app26ViewController14collectionViewfS0_FTGSQCSo16ASCollectionView_33willDisplayNodeForItemAtIndexPathGSQCSo11NSIndexPath__T_ + 50
    11  demo-app                            0x0000000102de3bf7 _TToFC10demo_app26ViewController14collectionViewfS0_FTGSQCSo16ASCollectionView_33willDisplayNodeForItemAtIndexPathGSQCSo11NSIndexPath__T_ + 71
    12  AsyncDisplayKit                     0x000000010620c417 -[ASCollectionView collectionView:willDisplayCell:forItemAtIndexPath:] + 169
    13  UIKit                               0x00000001040e92f1 -[UICollectionView _createPreparedCellForItemAtIndexPath:withLayoutAttributes:applyAttributes:isFocused:] + 2017
    14  UIKit                               0x00000001040ffef9 -[UICollectionView _viewAnimationsForCurrentUpdate] + 7236
    15  UIKit                               0x000000010410380b __62-[UICollectionView _updateWithItems:tentativelyForReordering:]_block_invoke1580 + 197
    16  UIKit                               0x0000000103984eec +[UIView(Animation) performWithoutAnimation:] + 65
    17  UIKit                               0x0000000104102c8e -[UICollectionView _updateWithItems:tentativelyForReordering:] + 2946
    18  UIKit                               0x00000001040fdd0c -[UICollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:] + 15456
    19  UIKit                               0x0000000104104c3e -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:] + 415
    20  UIKit                               0x0000000104104a7c -[UICollectionView _performBatchUpdates:completion:invalidationContext:] + 74
    21  UIKit                               0x0000000104104a1f -[UICollectionView performBatchUpdates:completion:] + 53
    22  AsyncDisplayKit                     0x000000010620ce67 -[ASCollectionView rangeController:endUpdatesAnimated:completion:] + 369
    23  AsyncDisplayKit                     0x00000001062367ef __66-[ASRangeController dataController:endUpdatesAnimated:completion:]_block_invoke + 57
    24  AsyncDisplayKit                     0x000000010620f7c0 _Z37ASDisplayNodePerformBlockOnMainThreadU13block_pointerFvvE + 53
    25  AsyncDisplayKit                     0x000000010623676e -[ASRangeController dataController:endUpdatesAnimated:completion:] + 120
    26  AsyncDisplayKit                     0x000000010622f10a __50-[ASDataController endUpdatesAnimated:completion:]_block_invoke_3 + 57
    27  libdispatch.dylib                   0x000000010b8acef9 _dispatch_call_block_and_release + 12
    28  libdispatch.dylib                   0x000000010b8cd49b _dispatch_client_callout + 8
    29  libdispatch.dylib                   0x000000010b8b534b _dispatch_main_queue_callback_4CF + 1738
    30  CoreFoundation                      0x0000000106ba53e9 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
    31  CoreFoundation                      0x0000000106b66939 __CFRunLoopRun + 2073
    32  CoreFoundation                      0x0000000106b65e98 CFRunLoopRunSpecific + 488
    33  GraphicsServices                    0x0000000108baead2 GSEventRunModal + 161
    34  UIKit                               0x00000001038df676 UIApplicationMain + 171
    35  demo-app                          0x00000001031d0e1d main + 109
    36  libdyld.dylib                       0x000000010b90192d start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

Copied from original issue: facebookarchive/AsyncDisplayKit#755

Crash in ASRunLoopQueue.mm line 270

ASRunLoopQueue.mm line 270
-[ASRunLoopQueue processQueue]

Pinterest 1 (pinterest)
Issue #161748 (Level 1)

System: 9.3.3 (13G34) 9.3.3 (13G34) on Apple iPhone 6 (arm64)
Storage: disk 33% free (3951 MB) and memory 6% free (226 MB)
Orientation: device is portrait and UI is portrait
Session: 1011ce535ff34084b0ffef6ade2dc6ec_0d6cdab239624d62b83bce44eff6b0bd_0_v1
Timestamp: 2017-04-17T11:28:43.000Z

[Thread 0] Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000001365d788
  0 libobjc.A.dylib                6453648272 objc_msgSend + 16
  1 Foundation                     6473769012 -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:] + 356
  2 Foundation                     6473068480 -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 64
  3 Foundation                     6473759544 _NSSetPointValueAndNotify + 284
  4 UIKit                          6552282908 -[UIScrollView(UIScrollViewInternal) _adjustContentOffsetIfNecessary] + 60
  5 UIKit                          6549898028 -[UIScrollView(UIScrollViewInternal) _stopScrollingNotify:pin:tramplingDragFlags:] + 460
  6 UIKit                          6549897504 -[UIScrollView removeFromSuperview] + 40
  7 UIKit                          6548949284 -[UIView dealloc] + 952
  8 Foundation                     6473427408 -[NSConcretePointerArray replacePointerAtIndex:withPointer:] + 192
> 9 Pinterest                      4302444428 -[ASRunLoopQueue processQueue] (ASRunLoopQueue.mm:270)
 10 CoreFoundation                 6463342376 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
 11 CoreFoundation                 6463333580 __CFRunLoopDoObservers + 372
 12 CoreFoundation                 6463334652 __CFRunLoopRun + 928
 13 CoreFoundation                 6462458960 CFRunLoopRunSpecific + 384
 14 GraphicsServices               6488572040 GSEventRunModal + 180
 15 UIKit                          6549397640 UIApplicationMain + 204
 16 Pinterest                      4295564372 main (main.m:74)
 17 libdispatch.dylib              6457862328  + 0

[Thread 1] com.apple.libdispatch-manager
  0 libsystem_kernel.dylib         6459036888 kevent_qos + 8
  1 libdispatch.dylib              6457739224 _dispatch_mgr_invoke + 232
  2 libdispatch.dylib              6457669192 _dispatch_source_invoke + 50

[Thread 2]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 3] com.apple.NSURLConnectionLoader
  0 libsystem_kernel.dylib         6458920920 mach_msg_trap + 8
  1 libsystem_kernel.dylib         6458920532 mach_msg + 72
  2 CoreFoundation                 6463343712 __CFRunLoopServiceMachPort + 196
  3 CoreFoundation                 6463334756 __CFRunLoopRun + 1032
  4 CoreFoundation                 6462458960 CFRunLoopRunSpecific + 384
  5 CFNetwork                      6470327244 +[NSURLConnection(Loader) _resourceLoadLoop:] + 412
  6 Foundation                     6473956940 __NSThread__start__ + 1000
  7 libsystem_pthread.dylib        6459865896 _pthread_body + 156
  8 libsystem_pthread.dylib        6459865740 _pthread_body + 154
  9 libsystem_pthread.dylib        6459854888 thread_start + 4

[Thread 4] com.twitter.crashlytics.ios.MachExceptionServer
  0 Pinterest                      4306014612 CLSProcessRecordAllThreads + 1000568
  1 Pinterest                      4306014612 CLSProcessRecordAllThreads + 1000568
  2 Pinterest                      4306014288 CLSProcessRecordAllThreads + 1000244
  3 Pinterest                      4305950736 CLSHandler + 936692
  4 Pinterest                      4305930164 CLSMachExceptionServer + 916120
  5 libsystem_pthread.dylib        6459865896 _pthread_body + 156
  6 libsystem_pthread.dylib        6459865740 _pthread_body + 154
  7 libsystem_pthread.dylib        6459854888 thread_start + 4

[Thread 5]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 6] com.apple.CFSocket.private
  0 libsystem_kernel.dylib         6459032388 __select + 8
  1 CoreFoundation                 6463369672 __CFSocketManager + 648
  2 libsystem_pthread.dylib        6459865896 _pthread_body + 156
  3 libsystem_pthread.dylib        6459865740 _pthread_body + 154
  4 libsystem_pthread.dylib        6459854888 thread_start + 4

[Thread 7]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 8] AVAudioSession Notify Thread
  0 libsystem_kernel.dylib         6458920920 mach_msg_trap + 8
  1 libsystem_kernel.dylib         6458920532 mach_msg + 72
  2 CoreFoundation                 6463343712 __CFRunLoopServiceMachPort + 196
  3 CoreFoundation                 6463334756 __CFRunLoopRun + 1032
  4 CoreFoundation                 6462458960 CFRunLoopRunSpecific + 384
  5 libAVFAudio.dylib              6570957280 GenericRunLoopThread::Entry(void*) + 164
  6 libAVFAudio.dylib              6570780508 CAPThread::Entry(CAPThread*) + 84
  7 libsystem_pthread.dylib        6459865896 _pthread_body + 156
  8 libsystem_pthread.dylib        6459865740 _pthread_body + 154
  9 libsystem_pthread.dylib        6459854888 thread_start + 4

[Thread 9] ASDeallocQueue
  0 libsystem_kernel.dylib         6458920920 mach_msg_trap + 8
  1 libsystem_kernel.dylib         6458920532 mach_msg + 72
  2 CoreFoundation                 6463343712 __CFRunLoopServiceMachPort + 196
  3 CoreFoundation                 6463334756 __CFRunLoopRun + 1032
  4 CoreFoundation                 6462458960 CFRunLoopRunSpecific + 384
  5 CoreFoundation                 6462776228 CFRunLoopRun + 112
  6 Pinterest                      4302442152 -[ASDeallocQueue threadMain] (ASRunLoopQueue.mm:99)
  7 Foundation                     6473956940 __NSThread__start__ + 1000
  8 libsystem_pthread.dylib        6459865896 _pthread_body + 156
  9 libsystem_pthread.dylib        6459865740 _pthread_body + 154
 10 libsystem_pthread.dylib        6459854888 thread_start + 4

[Thread 10]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 11]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 12] Deadlock Detection Thread
  0 libsystem_kernel.dylib         6459032604 __semwait_signal + 8
  1 libsystem_c.dylib              6458102316 nanosleep + 212
  2 Foundation                     6473954040 +[NSThread sleepForTimeInterval:] + 136
  3 Pinterest                      4295972552 +[PIDeadlockDetector detectionThreadLoop:] (PIDeadlockDetector.m:134)
  4 Foundation                     6473956940 __NSThread__start__ + 1000
  5 libsystem_pthread.dylib        6459865896 _pthread_body + 156
  6 libsystem_pthread.dylib        6459865740 _pthread_body + 154
  7 libsystem_pthread.dylib        6459854888 thread_start + 4

[Thread 13]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 14]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 15]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 16]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[Thread 17]
  0 libsystem_kernel.dylib         6459034440 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6459856176 _pthread_wqthread + 1284
  2 libsystem_pthread.dylib        6459854880 start_wqthread + 4

[ASTableView] Consider tradeoffs of an ASCollectionView-based version.

From @smyrgl on December 14, 2015 14:7

This is a discussion point I wanted to bring up as a possible direction for ASTableView and ASCollectionView--if this is inappropriate feel free to delete but I think its something worth considering at this phase of the project.

So right now ASCollectionView wraps UICollectionView and ASTableView wraps UITableView as we all know. But has anyone given any thought to ASTableView simply becoming a subclass of ASCollectionView that uses a very specific UICollectionViewLayout that always uses a fixed width? This has a number of advantages:

Although similar from an API standpoint UICollectionView and UITableView behave quite differently internally, especially with regards to update behaviors and animations. UITableView's chief advantage (besides backwards compatibility which seems like a minor point) is that it is somewhat simpler to get up and running, it provides a more performant way of doing sizing and static cells are very easy to configure. Since none of these really apply to the use cases or patterns we all use ADK for these seem largely irrelevant.
By leveraging UICollectionView ADK could standardize on a single way of doing layout invalidation via UICollectionViewLayoutInvalidationContext rather than the current system that ASCellNode provides of using a layout delegate. This means that layout invalidation and recalculation could be totally seamless.
It would focus the project better by not having to support both the UITableView and UICollectionView wrappers and instead UITableViews would be implemented with just a simple flow layout.
Lots of other potential ancillary benefits.

Although I can't go into any real detail on it I will say that I have seen firsthand this concept working (not using ADK but the principle is similar) with a major iOS developer and it works very well.

I wanted to bring this up as a discussion point because although I'm mired in crunch time for the next few weeks my intention was to carve out some time to contribute some work back into ADK as soon as I free up a bit and this seems like a logical place to start. However it's a big change so it's definitely something that I think is worth a healthy discussion first.

Copied from original issue: facebookarchive/AsyncDisplayKit#938

Is there any textNode supports textAlignment both on vertical and horizontal

From @xiekw2010 on September 15, 2015 3:53

Is there any textNode supports textAlignment both on vertical and horizontal?

Copied from original issue: facebookarchive/AsyncDisplayKit#652

ASCollectionNode BatchUpdates are slow

Hi, We are experiencing some very weird behaviour where ASCollectionNode batchUpdates take 4-5 seconds to complete and during that time our UI is completely blocked (We are using the version 2.3 of Texture). We took the ASDKGram example and added a content view screen (users can click on an item and get to a screen where content is displayed in full screen, they can like a content and the data is updated in current and previous controllers). On most recent iOS version the lag is very little, but it is still noticeable, on an iPhone 5S running iOS 8, the batch updates take a while to complete and during that time the UI is completely unresponsive.

We initially thought that it could be related to how we were handling the whole process of inserting and deleting rows, but it appears even calling the function with no updates is causing the delay.

 collectionNode.performBatch(animated: false, updates: {
            
}, completion: { completion in
  
})

By using the time profiler, it appears that ASSubclassOverridesSelector is the one taking up most of the time when the performBatch is called.

Any help in this regard would be helpful because this is the only thing causing lag in whole application as rest of the app runs smoothly thanks to AsyncDisplayKit / Texture.

Regards

snapchat esque swipe ui demo sample

is there a snapchat like swipe based ui to swipe through videos available thanks

[ReactiveCocoa] Discussing techniques for interoperation between RAC and ASDK.

From @bimawa on November 25, 2015 8:54

I have calculation layouts in Spec`s in one thred, and call with new data and recolculation from another thred. And it make deadlock in mutex. How i can get info about complited colculation all Layouts in self Node?

Now i solve my taks with overading

- (void)layoutDidFinish
{
    [super layoutDidFinish];
    self.isFinalLayoutable = YES;
}

method and set a flag isFinalLayoutable to YES. It`s a good solution or no?
After that i load new data to ASTextNode and recolculate Node again, now its working.

Copied from original issue: facebookarchive/AsyncDisplayKit#886

automaticallyAdjustsContentOffset does not work anymore

I have to insert multiple rows in my ASTableNode on index position 0 without animation and maintaining the users' visible scroll position.

In the latest AsyncDisplayKit (2.2.1) it is working perfectly when using

tableNode.view.automaticallyAdjustsContentOffset = true
tableNode.insertRows(at: prependIndexPaths, with: .none)

In Texture (2.3) I have following bugs

scroll position is jumping when inserting at index position 0 although using tableNode.view.automaticallyAdjustsContentOffset = true
the inserted rows have a transition animation although using UITableViewRowAnimation.none

Why Range Visualization debug feature always showed

I didn't add code [ASDisplayNode setShouldShowRangeDebugOverlay:YES] in AppDelegate.m, even not include AsyncDisplayKit+Debug.h

Slack report: CustomCollectionView-Swift sample crashes

The crash report was posted by dviet on slack:

Crash:

2017-04-18 14:39:48.931 Sample[8738:181740] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Range max width must be infinite or a real positive integer.'

Link:

https://asyncdisplaykit.slack.com/conversation/C0V63R86T/p1492501729673862

[ASRangeController] Clarifications on how working ranges are expected to function (iOS 7)

From @hashemp206 on November 12, 2015 8:12

as it supposed to be pre layouting cells in ASCollectionView works well in iOS 8 and 9 and cells gets layout in advance. but today I test it on my iPhone 4 with iOS 7. cells layout method doesn't called, until I scroll to that cell!
any idea?

Copied from original issue: facebookarchive/AsyncDisplayKit#840

Crash: ASCollectionView.mm line 1123 -[ASCollectionView collectionView:willDisplaySupplementar

Pinterest 42 (com.pinterest.enterprise)
Issue #2763 (Level 1)

System: 10.3.1 (14E304) 10.3.1 (14E304) on Apple iPhone 7 (arm64)
Storage: disk 83% free (25344 MB) and memory 14% free (233 MB)
Orientation: device is portrait and UI is portrait
Session: b5409344b32d4f83b09c5576afb8c9f5_0f43de2d13c74acea83c9e66d6bacc9a_0_v1
Timestamp: 2017-04-19T14:58:04.000Z

[Thread 0] Fatal Exception: NSInvalidArgumentException
-[UICollectionReusableView layoutAttributes]: unrecognized selector sent to instance 0x108d98180
  0 CoreFoundation                 6728298456 __exceptionPreprocess + 0
  1 libobjc.A.dylib                6705628472 objc_exception_throw + 0
  2 CoreFoundation                 6728326900 __methodDescriptionForSelector + 0
  3 CoreFoundation                 6728314700 ___forwarding___ + 0
  4 CoreFoundation                 6727249196 _CF_forwarding_prep_0 + 0
> 5 Pinterest Enterprise           4304483608 -[ASCollectionView collectionView:willDisplaySupplementaryView:forElementKind:atIndexPath:] (ASCollectionView.mm:1123)
  6 UIKit                          6831774764 -[UICollectionView _createPreparedSupplementaryViewForElementOfKind:atIndexPath:withLayoutAttributes:applyAttributes:] + 0
  7 UIKit                          6832104720 -[UICollectionView _viewAnimationsForCurrentUpdate] + 0
  8 UIKit                          6839696328 __71-[UICollectionView _updateWithItems:tentativelyForReordering:animator:]_block_invoke.2012 + 0
  9 UIKit                          6830259708 +[UIView(Animation) performWithoutAnimation:] + 0
 10 UIKit                          6839692364 -[UICollectionView _updateWithItems:tentativelyForReordering:animator:] + 0
 11 UIKit                          6839684332 -[UICollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:animator:] + 0
 12 UIKit                          6839699036 -[UICollectionView _endUpdatesWithInvalidationContext:tentativelyForReordering:animator:] + 0
 13 UIKit                          6839699772 -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:animator:] + 0
 14 UIKit                          6839699356 -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:] + 0
 15 UIKit                          6839699232 -[UICollectionView _performBatchUpdates:completion:invalidationContext:] + 0
 16 UIKit                          6832129368 -[UICollectionView performBatchUpdates:completion:] + 0
 17 Pinterest Enterprise           4304474656 -[ASCollectionView _superPerformBatchUpdates:completion:] (ASCollectionView.mm:779)
 18 Pinterest Enterprise           4304502136 __59-[ASCollectionView rangeController:didUpdateWithChangeSet:]_block_invoke (ASCollectionView.mm:0)
 19 Pinterest Enterprise           4304501676 -[ASCollectionView rangeController:didUpdateWithChangeSet:] (ASInternalHelpers.h:78)
 20 Pinterest Enterprise           4304820784 -[ASRangeController dataController:didUpdateWithChangeSet:] (ASRangeController.mm:499)
 21 Pinterest Enterprise           4304533532 __40-[ASDataController updateWithChangeSet:]_block_invoke_3 (ASDataController.mm:583)
 22 Pinterest Enterprise           4304747256 __30-[ASMainSerialQueue runBlocks]_block_invoke (ASMainSerialQueue.mm:62)
 23 libdispatch.dylib              6710176224 _dispatch_call_block_and_release + 0
 24 libdispatch.dylib              6710176160 _dispatch_client_callout + 0
 25 libdispatch.dylib              6710195688 _dispatch_main_queue_callback_4CF + 0
 26 CoreFoundation                 6727962816 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 0
 27 CoreFoundation                 6727953628 __CFRunLoopRun + 0
 28 CoreFoundation                 6727101844 CFRunLoopRunSpecific + 0
 29 GraphicsServices               6754795636 GSEventRunModal + 0
 30 UIKit                          6830616880 UIApplicationMain + 0
 31 Pinterest Enterprise           4296109028 main (main.m:74)
 32 libdyld.dylib                  6710384028 start + 0

[Thread 1] Crashed: com.twitter.crashlytics.ios.exception
  0x0000000000000000
  0 Pinterest Enterprise           4309068484 CLSProcessRecordAllThreads + 3401912
  1 Pinterest Enterprise           4309068484 CLSProcessRecordAllThreads + 3401912
  2 Pinterest Enterprise           4309068160 CLSProcessRecordAllThreads + 3401588
  3 Pinterest Enterprise           4309004608 CLSHandler + 3338036
  4 Pinterest Enterprise           4309060504 __CLSExceptionRecord_block_invoke + 3393932
  5 libdispatch.dylib              6710176160 _dispatch_client_callout + 16
  6 libdispatch.dylib              6710230752 _dispatch_barrier_sync_f_invoke + 84
  7 Pinterest Enterprise           4309059132 CLSExceptionRecord + 3392560
  8 Pinterest Enterprise           4309058672 CLSExceptionRecordNSException + 3392100
  9 Pinterest Enterprise           4309057680 CLSTerminateHandler() + 3391108
 10 libc++abi.dylib                6705558996 std::__terminate(void (*)()) + 16
 11 libc++abi.dylib                6705557240 __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) + 134
 12 libobjc.A.dylib                6705628780 _objc_exception_destructor(void*) + 362
 13 CoreFoundation                 6728326900 __methodDescriptionForSelector + 138
 14 CoreFoundation                 6728314700 ___forwarding___ + 916
 15 CoreFoundation                 6727249196 _CF_forwarding_prep_0 + 92
 16 Pinterest Enterprise           4304483608 -[ASCollectionView collectionView:willDisplaySupplementaryView:forElementKind:atIndexPath:] (ASCollectionView.mm:1123)
 17 UIKit                          6831774764 -[UICollectionView _createPreparedSupplementaryViewForElementOfKind:atIndexPath:withLayoutAttributes:applyAttributes:] + 1560
 18 UIKit                          6832104720 -[UICollectionView _viewAnimationsForCurrentUpdate] + 3604
 19 UIKit                          6839696328 __71-[UICollectionView _updateWithItems:tentativelyForReordering:animator:]_block_invoke.2012 + 132
 20 UIKit                          6830259708 +[UIView(Animation) performWithoutAnimation:] + 104
 21 UIKit                          6839692364 -[UICollectionView _updateWithItems:tentativelyForReordering:animator:] + 3164
 22 UIKit                          6839684332 -[UICollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:animator:] + 12952
 23 UIKit                          6839699036 -[UICollectionView _endUpdatesWithInvalidationContext:tentativelyForReordering:animator:] + 92
 24 UIKit                          6839699772 -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:animator:] + 384
 25 UIKit                          6839699356 -[UICollectionView _performBatchUpdates:completion:invalidationContext:tentativelyForReordering:] + 96
 26 UIKit                          6839699232 -[UICollectionView _performBatchUpdates:completion:invalidationContext:] + 84
 27 UIKit                          6832129368 -[UICollectionView performBatchUpdates:completion:] + 64
 28 Pinterest Enterprise           4304474656 -[ASCollectionView _superPerformBatchUpdates:completion:] (ASCollectionView.mm:779)
 29 Pinterest Enterprise           4304502136 __59-[ASCollectionView rangeController:didUpdateWithChangeSet:]_block_invoke (ASCollectionView.mm:0)
 30 Pinterest Enterprise           4304501676 -[ASCollectionView rangeController:didUpdateWithChangeSet:] (ASInternalHelpers.h:78)
 31 Pinterest Enterprise           4304820784 -[ASRangeController dataController:didUpdateWithChangeSet:] (ASRangeController.mm:499)
 32 Pinterest Enterprise           4304533532 __40-[ASDataController updateWithChangeSet:]_block_invoke_3 (ASDataController.mm:583)
 33 Pinterest Enterprise           4304747256 __30-[ASMainSerialQueue runBlocks]_block_invoke (ASMainSerialQueue.mm:62)
 34 libdispatch.dylib              6710176224 _dispatch_call_block_and_release + 24
 35 libdispatch.dylib              6710176160 _dispatch_client_callout + 16
 36 libdispatch.dylib              6710195688 _dispatch_main_queue_callback_4CF + 996
 37 CoreFoundation                 6727962816 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
 38 CoreFoundation                 6727953628 __CFRunLoopRun + 1572
 39 CoreFoundation                 6727101844 CFRunLoopRunSpecific + 424
 40 GraphicsServices               6754795636 GSEventRunModal + 100
 41 UIKit                          6830616880 UIApplicationMain + 208
 42 Pinterest Enterprise           4296109028 main (main.m:74)
 43 libdyld.dylib                  6710384028 start + 4

[Thread 2] com.apple.uikit.eventfetch-thread
  0 libsystem_kernel.dylib         6711374372 mach_msg_trap + 8
  1 libsystem_kernel.dylib         6711373980 mach_msg + 72
  2 CoreFoundation                 6727962248 __CFRunLoopServiceMachPort + 192
  3 CoreFoundation                 6727953116 __CFRunLoopRun + 1060
  4 CoreFoundation                 6727101844 CFRunLoopRunSpecific + 424
  5 Foundation                     6738742628 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 304
  6 Foundation                     6738877236 -[NSRunLoop(NSRunLoop) runUntilDate:] + 96
  7 UIKit                          6840620536 -[UIEventFetcher threadMain] + 136
  8 Foundation                     6739780296 __NSThread__start__ + 996
  9 libsystem_pthread.dylib        6712317788 _pthread_body + 240
 10 libsystem_pthread.dylib        6712317548 _pthread_body + 282
 11 libsystem_pthread.dylib        6712307076 thread_start + 4

[Thread 3] com.apple.NSURLConnectionLoader
  0 libsystem_kernel.dylib         6711374372 mach_msg_trap + 8
  1 libsystem_kernel.dylib         6711373980 mach_msg + 72
  2 CoreFoundation                 6727962248 __CFRunLoopServiceMachPort + 192
  3 CoreFoundation                 6727953116 __CFRunLoopRun + 1060
  4 CoreFoundation                 6727101844 CFRunLoopRunSpecific + 424
  5 CFNetwork                      6735539364 +[NSURLConnection(Loader) _resourceLoadLoop:] + 404
  6 Foundation                     6739780296 __NSThread__start__ + 996
  7 libsystem_pthread.dylib        6712317788 _pthread_body + 240
  8 libsystem_pthread.dylib        6712317548 _pthread_body + 282
  9 libsystem_pthread.dylib        6712307076 thread_start + 4

[Thread 4] com.twitter.crashlytics.ios.MachExceptionServer
  0 libsystem_kernel.dylib         6711374372 mach_msg_trap + 8
  1 libsystem_kernel.dylib         6711373980 mach_msg + 72
  2 Pinterest Enterprise           4308983712 CLSMachExceptionServer + 3317140
  3 libsystem_pthread.dylib        6712317788 _pthread_body + 240
  4 libsystem_pthread.dylib        6712317548 _pthread_body + 282
  5 libsystem_pthread.dylib        6712307076 thread_start + 4

[Thread 5]
  0 libsystem_kernel.dylib         6711496220 __psynch_cvwait + 8
  1 libsystem_pthread.dylib        6712314084 _pthread_cond_wait + 640
  2 libc++.1.dylib                 6705142472 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 56
  3 JavaScriptCore                 6804372632 void std::__1::condition_variable_any::wait<std::__1::unique_lock<bmalloc::Mutex> >(std::__1::unique_lock<bmalloc::Mutex>&) + 112
  4 JavaScriptCore                 6804372492 bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::threadRunLoop() + 168
  5 JavaScriptCore                 6804372204 std::__1::__shared_ptr_emplace<std::__1::mutex, std::__1::allocator<std::__1::mutex> >::~__shared_ptr_emplace() + 34
  6 JavaScriptCore                 6804372892 void* std::__1::__thread_proxy<std::__1::tuple<void (*)(bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>*), bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>*> >(void*) + 92
  7 libsystem_pthread.dylib        6712317788 _pthread_body + 240
  8 libsystem_pthread.dylib        6712317548 _pthread_body + 282
  9 libsystem_pthread.dylib        6712307076 thread_start + 4

[Thread 6] AVAudioSession Notify Thread
  0 libsystem_kernel.dylib         6711374372 mach_msg_trap + 8
  1 libsystem_kernel.dylib         6711373980 mach_msg + 72
  2 CoreFoundation                 6727962248 __CFRunLoopServiceMachPort + 192
  3 CoreFoundation                 6727953116 __CFRunLoopRun + 1060
  4 CoreFoundation                 6727101844 CFRunLoopRunSpecific + 424
  5 AVFAudio                       7164998976 GenericRunLoopThread::Entry(void*) + 164
  6 AVFAudio                       7165155348 CAPThread::Entry(CAPThread*) + 84
  7 libsystem_pthread.dylib        6712317788 _pthread_body + 240
  8 libsystem_pthread.dylib        6712317548 _pthread_body + 282
  9 libsystem_pthread.dylib        6712307076 thread_start + 4

[Thread 7] ASDeallocQueue
  0 libsystem_kernel.dylib         6711374372 mach_msg_trap + 8
  1 libsystem_kernel.dylib         6711373980 mach_msg + 72
  2 CoreFoundation                 6727962248 __CFRunLoopServiceMachPort + 192
  3 CoreFoundation                 6727953116 __CFRunLoopRun + 1060
  4 CoreFoundation                 6727101844 CFRunLoopRunSpecific + 424
  5 CoreFoundation                 6727416224 CFRunLoopRun + 112
  6 Pinterest Enterprise           4304830068 -[ASDeallocQueue threadMain] (ASRunLoopQueue.mm:99)
  7 Foundation                     6739780296 __NSThread__start__ + 996
  8 libsystem_pthread.dylib        6712317788 _pthread_body + 240
  9 libsystem_pthread.dylib        6712317548 _pthread_body + 282
 10 libsystem_pthread.dylib        6712307076 thread_start + 4

[Thread 8]
  0 libsystem_pthread.dylib        6712307064 start_wqthread + 126

[Thread 9]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712307872 _pthread_wqthread + 792
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 10]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712308340 _pthread_wqthread + 1260
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 11]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712308340 _pthread_wqthread + 1260
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 12]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712308340 _pthread_wqthread + 1260
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 13]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712308340 _pthread_wqthread + 1260
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 14]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712308340 _pthread_wqthread + 1260
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 15]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712308340 _pthread_wqthread + 1260
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 16]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712308340 _pthread_wqthread + 1260
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 17]
  0 libsystem_kernel.dylib         6711499400 __workq_kernreturn + 8
  1 libsystem_pthread.dylib        6712308340 _pthread_wqthread + 1260
  2 libsystem_pthread.dylib        6712307068 start_wqthread + 4

[Thread 18] Deadlock Detection Thread
  0 libsystem_kernel.dylib         6711497492 __semwait_signal + 8
  1 libsystem_c.dylib              6710577328 nanosleep + 212
  2 Foundation                     6739776896 +[NSThread sleepForTimeInterval:] + 136
  3 Pinterest Enterprise           4299352616 +[PIDeadlockDetector detectionThreadLoop:] (PIDeadlockDetector.m:134)
  4 Foundation                     6739780296 __NSThread__start__ + 996
  5 libsystem_pthread.dylib        6712317788 _pthread_body + 240
  6 libsystem_pthread.dylib        6712317548 _pthread_body + 282
  7 libsystem_pthread.dylib        6712307076 thread_start + 4

ASPagerNode + GLKViewController (GLKit)

Congratulations, comrades! We're now not ASDK, but Texture =)

So, I've found a problem with implementing such a simple functionality like PageController with GLKViewControllers inside.

Just try the sample below, and you will find that classic UIPageViewController with some GLKViewControllers works well, but ASPagerNode - nope:

https://github.com/stephenkopylov/TextureOpenGLTest

The problem starts when you try to scroll pages back from last - in some cases it just stops render OGL part, in some others - starts to freeze as hell.

Thank you and hope we'll find the root of problem (my app's release is on the next week and this is the last major issue that I have).

Card like layout for tablenode cell

I want to tableview node as card style view ,
I tried it by putting back view to each cell and on that back view put all the data by using overlay function. But it is not working as expected.
Using storyboard it is very easy but I want to stuck to texture framework.
I spend almost 1 day on this. Still not getting solution
Can anybody help me. I need this in urgent basis so ..

If you can provide any sample code snippet

[ASImageNode] Consider automatically applying .tintColor property without setting .imageModificationBlock

From @adremeaux on April 15, 2015 21:10

Here's the code:

    searchIcon = ASImageNode()
    searchIcon.image = UIImage(named: "IconSearch")?.imageWithRenderingMode(UIImageRenderingMode.AlwaysTemplate)
    searchIcon.tintColor = UIColor.redColor()

No matter what color I put in tintColor, it's always tinted pure black. Am I using this improperly or is this attribute not supported?

Copied from original issue: facebookarchive/AsyncDisplayKit#426

[ASMultiplexImageNode] Sometimes the high-res image is not loaded automatically (works with manual -setNeedsDisplay).

From @Adlai-Holler on November 24, 2015 0:7

@appleguy This may be fixed in your working window PR, but I encountered a tough case today. I have a table view whose content is pretty static, and its cells contain multiplex image nodes. Seemingly at random after a lot of browsing around, I got into a state like this:

ASMultiplexImageNode. Showing low-res image on screen.
    loadedImageIdentifier: {high-res ID}
    displayedImageIdentifier: {low-res ID}
    image: {high-res image}
    contents: {low-res image}
    loadingImageIdentifier: nil
    displaySuspended: false
    layer.needsDisplay: false

No threads were doing anything interesting. Since ASImageNode.image was set correctly, the multiplex logic seems to be working right.

The ASImageNode hadn't displayed since getting the high res image set. I ran po [imageNode setNeedsDisplay] and sure enough, the image node re-rendered at full-res. Maybe the range controller suppressed a display and then forgot to come back and redo it?

I'm currently trying to think of a workaround because these blurry images are in a build for investors. ~~I'm thinking I'll override willEnterHierarchy and, with some leeway, make sure that the node has been/will be displayed soon.~~

EDIT: I've come up with a workaround in my app. In our multiplex image node subclass, we do:

override func willEnterHierarchy() {
    super.willEnterHierarchy()
    // Currently we will get added to a range controller's "working window" for pre-rendering. No need to attempt workaround until we're in a real window.
    let isWorkingWindow = layer.rootLayer.bounds == .zero
    if !isWorkingWindow {
        dispatch(after: 0.5) { [weak self] in
            self?.applyMissedRenderWorkaround()
        }
    }
}

private func applyMissedRenderWorkaround() {
    assert(NSThread.isMainThread())

    /// Workaround a rare issue in ASDK 1.9.1 where I may fail to render my most recent loaded image. https://github.com/facebook/AsyncDisplayKit/issues/882
    if let loadedID = loadedImageIdentifier where inHierarchy && !layer.needsDisplay() && !loadedID.isEqual(displayedImageIdentifier) {
        NSLog("WARNING: \(self) entered hierarchy without having rendered its high-res image. Marking as needs render…")
        setNeedsDisplay()
    }
}

extension CALayer {
    var rootLayer: CALayer {
        return superlayer?.rootLayer ?? self
    }
}

Copied from original issue: facebookarchive/AsyncDisplayKit#882

[ASCollectionNode / ASTableNode] Measure scrollable content size (main thread only due to UICV layout?)

From @tettoffensive on November 4, 2015 1:48

I have an ASTableView which in each row has a custom ASCellNode that encapsulates an ASCollectionNode as well as an ASTextNode label.

If I have the data source cached so that is available on initialization it loads up and works fine. I see all the nodes in my ASCollectionView. However, if I turn the caching off so that I need to wait for the network request to come back and call reloadData on the ASCollectionView at this point. And then call reloadData on the ASTableView, then I do not see the nodes of the ASCollectionView but I do see the labels.

I'm wondering what the practice is to make this work. I've tried different orders of reloadData and also reloadDataImmediately

Maybe someone's built an example project for how to do this properly with a dynamic data source? I have anywhere between 0 and 4 collection views that may be unloaded/loaded depending if they have any nodes in them or not.

Copied from original issue: facebookarchive/AsyncDisplayKit#814

ASNodeController-Based Cells

https://paper.dropbox.com/doc/ASCollectionNode-API-Update-2017-1-qRZxXqN8xr0OGf4Ths1b8

ASTableNode + Multiline text + automaticallyAdjustsScrollViewInsets + device rotation = crash

Hi guys!

So found some problem.
Please check the test project below.
Go to "multiline" screen try to rotate your device/simulator to different orientation and back and you will get crash with:
"*** -[__NSArrayM objectAtIndex:]: index 4 beyond bounds [0 .. 3]'"

The problem is somehow related to automaticallyAdjustsScrollViewInsets flag and ASInsetLayoutSpec inside cell.

Prj: https://github.com/stephenkopylov/TextureTableViewOrientation

[ASRangeController] Clarifications on how working ranges are expected to function (iOS 7)

From @hashemp206 on November 12, 2015 8:12

Copied from original issue: facebookarchive/AsyncDisplayKit#840

Assertion failed: (res == 0), function lock.

ASTheread.h/ l.198 . happens when switching between apps. Hard to reproduce. Texture 2.3

bt all

  thread #1, queue = 'com.apple.main-thread'
    frame #0: 0x1b7b71f0 libsystem_c.dylib`__cxa_finalize_ranges + 262
    frame #1: 0x1b7761b2 libsystem_c.dylib`exit + 12
    frame #2: 0x21304086 UIKit`-[UIApplication _terminateWithStatus:] + 566
    frame #3: 0x214f7cf4 UIKit`__102-[UIApplication _handleApplicationDeactivationWithScene:shouldForceExit:transitionContext:completion:]_block_invoke.2095 + 924
    frame #4: 0x214fadc2 UIKit`_runAfterCACommitDeferredBlocks + 276
    frame #5: 0x214ee0d2 UIKit`_cleanUpAfterCAFlushAndRunDeferredBlocks + 524
    frame #6: 0x2126fcfc UIKit`_afterCACommitHandler + 112
    frame #7: 0x1c00f802 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
    frame #8: 0x1c00da54 CoreFoundation`__CFRunLoopDoObservers + 282
    frame #9: 0x1c00e016 CoreFoundation`__CFRunLoopRun + 1358
    frame #10: 0x1bf610ee CoreFoundation`CFRunLoopRunSpecific + 470
    frame #11: 0x1bf60f10 CoreFoundation`CFRunLoopRunInMode + 104
    frame #12: 0x1d70bb40 GraphicsServices`GSEventRunModal + 80
    frame #13: 0x212dfe82 UIKit`UIApplicationMain + 150
    frame #14: 0x0006f340 hotschedules`main(argc=1, argv=0x01166b18) at main.m:17
    frame #15: 0x1b74e4ea libdyld.dylib`start + 2

  thread #6, name = 'com.apple.uikit.eventfetch-thread'
    frame #0: 0x1b80c900 libsystem_kernel.dylib`mach_msg_trap + 20
    frame #1: 0x1b80c6e0 libsystem_kernel.dylib`mach_msg + 44
    frame #2: 0x1c00fbe2 CoreFoundation`__CFRunLoopServiceMachPort + 144
    frame #3: 0x1c00e064 CoreFoundation`__CFRunLoopRun + 1436
    frame #4: 0x1bf610ee CoreFoundation`CFRunLoopRunSpecific + 470
    frame #5: 0x1bf60f10 CoreFoundation`CFRunLoopRunInMode + 104
    frame #6: 0x1c8b5ab4 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 258
    frame #7: 0x1c8d272c Foundation`-[NSRunLoop(NSRunLoop) runUntilDate:] + 86
    frame #8: 0x21be1888 UIKit`-[UIEventFetcher threadMain] + 128
    frame #9: 0x1c9998aa Foundation`__NSThread__start__ + 1122
    frame #10: 0x1b8d89aa libsystem_pthread.dylib`_pthread_body + 216
    frame #11: 0x1b8d88cc libsystem_pthread.dylib`_pthread_start + 234
    frame #12: 0x1b8d64d8 libsystem_pthread.dylib`thread_start + 8

  thread #8, name = 'GAIThread'
    frame #0: 0x1b80c900 libsystem_kernel.dylib`mach_msg_trap + 20
    frame #1: 0x1b80c6e0 libsystem_kernel.dylib`mach_msg + 44
    frame #2: 0x1c00fbe2 CoreFoundation`__CFRunLoopServiceMachPort + 144
    frame #3: 0x1c00e064 CoreFoundation`__CFRunLoopRun + 1436
    frame #4: 0x1bf610ee CoreFoundation`CFRunLoopRunSpecific + 470
    frame #5: 0x1bf60f10 CoreFoundation`CFRunLoopRunInMode + 104
    frame #6: 0x1c8b5ab4 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 258
    frame #7: 0x1c902d78 Foundation`-[NSRunLoop(NSRunLoop) run] + 80
    frame #8: 0x00772800 hotschedules`+[GAI threadMain:] + 64
    frame #9: 0x1c9998aa Foundation`__NSThread__start__ + 1122
    frame #10: 0x1b8d89aa libsystem_pthread.dylib`_pthread_body + 216
    frame #11: 0x1b8d88cc libsystem_pthread.dylib`_pthread_start + 234
    frame #12: 0x1b8d64d8 libsystem_pthread.dylib`thread_start + 8

  thread #11
    frame #0: 0x1b821808 libsystem_kernel.dylib`__psynch_cvwait + 24
    frame #1: 0x1b8d7cb2 libsystem_pthread.dylib`_pthread_cond_wait + 560
    frame #2: 0x1b8d9034 libsystem_pthread.dylib`pthread_cond_wait + 38
    frame #3: 0x1b273c56 libc++.1.dylib`std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 118
    frame #4: 0x1fec71e8 JavaScriptCore`void std::__1::condition_variable_any::wait<std::__1::unique_lock<bmalloc::Mutex> >(std::__1::unique_lock<bmalloc::Mutex>&) + 88
    frame #5: 0x1fec716c JavaScriptCore`bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::threadRunLoop() + 154
    frame #6: 0x1fec7074 JavaScriptCore`bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>::threadEntryPoint(bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>*) + 20
    frame #7: 0x1fec72b6 JavaScriptCore`void* std::__1::__thread_proxy<std::__1::tuple<void (*)(bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>*), bmalloc::AsyncTask<bmalloc::Heap, void (bmalloc::Heap::*)()>*> >(void*) + 66
    frame #8: 0x1b8d89aa libsystem_pthread.dylib`_pthread_body + 216
    frame #9: 0x1b8d88cc libsystem_pthread.dylib`_pthread_start + 234
    frame #10: 0x1b8d64d8 libsystem_pthread.dylib`thread_start + 8

  thread #12, name = 'WebThread'
    frame #0: 0x1b80c900 libsystem_kernel.dylib`mach_msg_trap + 20
    frame #1: 0x1b80c6e0 libsystem_kernel.dylib`mach_msg + 44
    frame #2: 0x1c00fbe2 CoreFoundation`__CFRunLoopServiceMachPort + 144
    frame #3: 0x1c00e064 CoreFoundation`__CFRunLoopRun + 1436
    frame #4: 0x1bf610ee CoreFoundation`CFRunLoopRunSpecific + 470
    frame #5: 0x1bf60f10 CoreFoundation`CFRunLoopRunInMode + 104
    frame #6: 0x2017ff02 WebCore`RunWebThread(void*) + 426
    frame #7: 0x1b8d89aa libsystem_pthread.dylib`_pthread_body + 216
    frame #8: 0x1b8d88cc libsystem_pthread.dylib`_pthread_start + 234
    frame #9: 0x1b8d64d8 libsystem_pthread.dylib`thread_start + 8

  thread #13, name = 'com.apple.NSURLConnectionLoader'
    frame #0: 0x1b80c900 libsystem_kernel.dylib`mach_msg_trap + 20
    frame #1: 0x1b80c6e0 libsystem_kernel.dylib`mach_msg + 44
    frame #2: 0x1c00fbe2 CoreFoundation`__CFRunLoopServiceMachPort + 144
    frame #3: 0x1c00e064 CoreFoundation`__CFRunLoopRun + 1436
    frame #4: 0x1bf610ee CoreFoundation`CFRunLoopRunSpecific + 470
    frame #5: 0x1bf60f10 CoreFoundation`CFRunLoopRunInMode + 104
    frame #6: 0x1c63e242 CFNetwork`+[NSURLConnection(Loader) _resourceLoadLoop:] + 402
    frame #7: 0x1c9998aa Foundation`__NSThread__start__ + 1122
    frame #8: 0x1b8d89aa libsystem_pthread.dylib`_pthread_body + 216
    frame #9: 0x1b8d88cc libsystem_pthread.dylib`_pthread_start + 234
    frame #10: 0x1b8d64d8 libsystem_pthread.dylib`thread_start + 8

* thread #15, queue = 'org.AsyncDisplayKit.ASDisplayLayer.displayQueue', stop reason = signal SIGABRT
    frame #0: 0x1b821acc libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x1b8da0f6 libsystem_pthread.dylib`pthread_kill + 62
    frame #2: 0x1b7b695a libsystem_c.dylib`abort + 108
    frame #3: 0x1b795e8c libsystem_c.dylib`__assert_rtn + 292
  * frame #4: 0x01490f0a AsyncDisplayKit`ASDN::Mutex::lock(this=0x015f4630) at ASThread.h:198
    frame #5: 0x01490eb2 AsyncDisplayKit`ASDN::Locker<ASDN::Mutex>::Locker(this=0x1944848c, l=0x015f4630) at ASThread.h:84
    frame #6: 0x0149128c AsyncDisplayKit`ASDN::Locker<ASDN::Mutex>::Locker(this=0x1944848c, l=0x015f4630) at ASThread.h:83
    frame #7: 0x01563360 AsyncDisplayKit`::-[ASTextKitContext initWithAttributedString:lineBreakMode:maximumNumberOfLines:exclusionPaths:constrainedSize:](self=0x16eaa460, _cmd="initWithAttributedString:lineBreakMode:maximumNumberOfLines:exclusionPaths:constrainedSize:", attributedString="Label. Row 1. Column 2", lineBreakMode=NSLineBreakByWordWrapping, maximumNumberOfLines=0, exclusionPaths=0x00000000, constrainedSize=(width = 66.5, height = 29)) at ASTextKitContext.mm:37
    frame #8: 0x0156c8e4 AsyncDisplayKit`::-[ASTextKitRenderer initWithTextKitAttributes:constrainedSize:](self=0x06ef5b20, _cmd="initWithTextKitAttributes:constrainedSize:", attributes=0x194488c0, constrainedSize=(width = 66.5, height = 29)) at ASTextKitRenderer.mm:62
    frame #9: 0x01574104 AsyncDisplayKit`rendererForAttributes(attributes=<unavailable>, constrainedSize=(width = 66.5, height = 29)) at ASTextNode.mm:115
    frame #10: 0x01573ed6 AsyncDisplayKit`::-[ASTextNode _rendererWithBoundsSlow:](self=0x171e8200, _cmd="_rendererWithBoundsSlow:", bounds=(origin = (x = 0, y = 0), size = (width = 66.5, height = 29))) at ASTextNode.mm:280
    frame #11: 0x01576052 AsyncDisplayKit`::-[ASTextNode drawRect:withParameters:isCancelled:isRasterizing:](self=0x171e8200, _cmd="drawRect:withParameters:isCancelled:isRasterizing:", bounds=(origin = (x = 0, y = 0), size = (width = 66.5, height = 29)), p=0x00000000, isCancelledBlock=0x0147d729, isRasterizing=NO) at ASTextNode.mm:475
    frame #12: 0x0147cc50 AsyncDisplayKit`::__90-[ASDisplayNode((null)=<unavailable>) _displayBlockWithAsynchronous:isCancelledBlock:rasterizing:]_block_invoke.76() at ASDisplayNode+AsyncDisplay.mm:257
    frame #13: 0x01406aa2 AsyncDisplayKit`::__71-[_ASAsyncTransaction addOperationWithBlock:priority:queue:completion:]_block_invoke((null)=<unavailable>) at _ASAsyncTransaction.mm:432
    frame #14: 0x014047e6 AsyncDisplayKit`::___ZN23ASAsyncTransactionQueue9GroupImpl8scheduleEiPU28objcproto17OS_dispatch_queue8NSObjectU13block_pointerFvvE_block_invoke((null)=<unavailable>) at _ASAsyncTransaction.mm:250
    frame #15: 0x02bea466 libdispatch.dylib`_dispatch_call_block_and_release + 10
    frame #16: 0x02bf4fce libdispatch.dylib`_dispatch_continuation_pop + 480
    frame #17: 0x02bf4d02 libdispatch.dylib`_dispatch_async_redirect_invoke + 580
    frame #18: 0x02bf876a libdispatch.dylib`_dispatch_root_queue_drain + 666
    frame #19: 0x02bf8470 libdispatch.dylib`_dispatch_worker_thread3 + 112
    frame #20: 0x1b8d68ec libsystem_pthread.dylib`_pthread_wqthread + 1040
    frame #21: 0x1b8d64cc libsystem_pthread.dylib`start_wqthread + 8

  thread #16
    frame #0: 0x1b8d64c4 libsystem_pthread.dylib`start_wqthread

  thread #17
    frame #0: 0x1b8d64c4 libsystem_pthread.dylib`start_wqthread

  thread #18, queue = 'org.AsyncDisplayKit.ASDisplayLayer.displayQueue'
    frame #0: 0x1b82257c libsystem_kernel.dylib`__ulock_wake + 8
    frame #1: 0x1b8d35b2 libsystem_platform.dylib`_os_unfair_lock_unlock_slow + 50
    frame #2: 0x1b2f4f26 libobjc.A.dylib`objc_object::sidetable_retain() + 138
    frame #3: 0x0156e3dc AsyncDisplayKit`::-[ASTextKitRenderer drawInContext:bounds:](self=0x06e434e0, _cmd="drawInContext:bounds:", context=0x06e864e0, bounds=(origin = (x = 0, y = 0), size = (width = 686, height = 14.5))) at ASTextKitRenderer.mm:213
    frame #4: 0x015760f6 AsyncDisplayKit`::-[ASTextNode drawRect:withParameters:isCancelled:isRasterizing:](self=0x1717b000, _cmd="drawRect:withParameters:isCancelled:isRasterizing:", bounds=(origin = (x = 0, y = 0), size = (width = 686, height = 14.5)), p=0x00000000, isCancelledBlock=0x0147d729, isRasterizing=NO) at ASTextNode.mm:484
    frame #5: 0x0147cc50 AsyncDisplayKit`::__90-[ASDisplayNode((null)=<unavailable>) _displayBlockWithAsynchronous:isCancelledBlock:rasterizing:]_block_invoke.76() at ASDisplayNode+AsyncDisplay.mm:257
    frame #6: 0x01406aa2 AsyncDisplayKit`::__71-[_ASAsyncTransaction addOperationWithBlock:priority:queue:completion:]_block_invoke((null)=<unavailable>) at _ASAsyncTransaction.mm:432
    frame #7: 0x014047e6 AsyncDisplayKit`::___ZN23ASAsyncTransactionQueue9GroupImpl8scheduleEiPU28objcproto17OS_dispatch_queue8NSObjectU13block_pointerFvvE_block_invoke((null)=<unavailable>) at _ASAsyncTransaction.mm:250
    frame #8: 0x02bea466 libdispatch.dylib`_dispatch_call_block_and_release + 10
    frame #9: 0x02bf4fce libdispatch.dylib`_dispatch_continuation_pop + 480
    frame #10: 0x02bf4d02 libdispatch.dylib`_dispatch_async_redirect_invoke + 580
    frame #11: 0x02bf876a libdispatch.dylib`_dispatch_root_queue_drain + 666
    frame #12: 0x02bf8470 libdispatch.dylib`_dispatch_worker_thread3 + 112
    frame #13: 0x1b8d68ec libsystem_pthread.dylib`_pthread_wqthread + 1040
    frame #14: 0x1b8d64cc libsystem_pthread.dylib`start_wqthread + 8

  thread #19
    frame #0: 0x1b8d64c4 libsystem_pthread.dylib`start_wqthread

  thread #20
    frame #0: 0x1b8d64c4 libsystem_pthread.dylib`start_wqthread

  thread #21, queue = 'io.answers.EventQueue :: NSOperation 0x99735a0 (QOS: BACKGROUND)'
    frame #0: 0x1b822554 libsystem_kernel.dylib`__ulock_wait + 24
    frame #1: 0x02c0eb04 libdispatch.dylib`_dispatch_ulock_wait + 38
    frame #2: 0x02c0ec02 libdispatch.dylib`_dispatch_thread_event_wait_slow + 24
    frame #3: 0x02bf90d8 libdispatch.dylib`_dispatch_barrier_sync_f_slow + 214
    frame #4: 0x1d8c9a46 AssertionServices`-[BKSProcessAssertion invalidate] + 78
    frame #5: 0x212c7130 UIKit`-[_UIBackgroundTaskInfo invalidate] + 38
    frame #6: 0x21508ba0 UIKit`-[UIApplication _endBackgroundTask:] + 68
    frame #7: 0x006ad20c hotschedules`-[ANSActivity endAndInvalidateBackgroundTask] + 126
    frame #8: 0x006ad0e0 hotschedules`-[ANSActivity end] + 24
    frame #9: 0x006aa18a hotschedules`-[ANSActivityOperation main] + 46
    frame #10: 0x1c8c1fa6 Foundation`-[__NSOperationInternal _start:] + 770
    frame #11: 0x1c97bcf8 Foundation`__NSOQSchedule_f + 190
    frame #12: 0x02bf666e libdispatch.dylib`_dispatch_queue_serial_drain + 988
    frame #13: 0x02beda38 libdispatch.dylib`_dispatch_queue_invoke + 872
    frame #14: 0x02bf876a libdispatch.dylib`_dispatch_root_queue_drain + 666
    frame #15: 0x02bf8470 libdispatch.dylib`_dispatch_worker_thread3 + 112
    frame #16: 0x1b8d68ec libsystem_pthread.dylib`_pthread_wqthread + 1040
    frame #17: 0x1b8d64cc libsystem_pthread.dylib`start_wqthread + 8

  thread #22
    frame #0: 0x1b82273c libsystem_kernel.dylib`__workq_kernreturn + 8
    frame #1: 0x1b8d695a libsystem_pthread.dylib`_pthread_wqthread + 1150
    frame #2: 0x1b8d64cc libsystem_pthread.dylib`start_wqthread + 8

[ASTableView] Test project demonstrating undesired animations on empty update transaction.

From @tomizimobile on December 7, 2015 17:29

Using this sample project here: https://github.com/tomizimobile/ASDKSearchIssue, which is using AsyncDisplayKit v1.9.3

Currently, the project is working mostly as expected. I've come across a UI issue when updating the tableView using beginUpdates()/endUpdates() - even though I've set all of my delete/insert animation options to .None, and even after wrapping my beginUpdates()/endUpdates() in UIView.setAnimationsEnabled(false)/UIView.setAnimationsEnabled(true) or UIView.performWithoutAnimation, animations still occur.

In order to get around the animation issue, I tried always calling reloadData() or reloadDataImmediately() instead of calculating which rows/sections should be inserted/deleted. However, when I do this, i get a crash in the delegate method -[tableView:titleForHeaderInSection:], because it's calling it with a section that is out of range of the newly-filtered data. This can be easily reproduced in the sample project by changing line 106 in "ViewController.swift" to: if tableView.numberOfSections == 0 || true.

Copied from original issue: facebookarchive/AsyncDisplayKit#922

ASNetworkImageNode sometime disappeared and restored touch it in ASCellNode when layerBacked is YES

Texture version: 2.3
If I set .layerBacked to NO, no this issue.

The CI Can Fail with a Bizarre Cocoapods Working Tree Issue

#82 (comment)

It's fine to close this and say "not worth the effort" – we've only seen it once. But we should at least give it a look-see. @garrettmoon

What is the best way to display a set of tags but limit to only one line using Texture?

Hi,
I am trying to implement something like the TagListView (https://github.com/ElaWorkshop/TagListView).
I am thinking of using ASCellNode and adding ASButtonNodes. But how do I limit the tags to only one line? Do I keep looping on each addition of the tag button until I find that the size has extended to the second line? And do I do it in the layoutSpecThatFits() method? Will there be a performance penalty?

Thanks,
Dicky

ASPagerNode should behave like UIPageViewController

The lifecycle of ASPagerNode’s ViewController is strange.
It doesn’t call viewDidLoad the first time.
and doesn’t call viewWillDisappear when scrolling.

ASPagerNode should behave like UIPageViewController.

e.g:

When scrolling A to B

A.viewWillDisAppear called
B.viewWillAppear called
A.viewDidDisAppear called
B.viewDidAppear called

ASTableNode swipe-to-delete cell gesture can leave delete action in a partially visible state

When using UITableView's native swipe to delete table cell gesture, a partial swipe gesture either fully shows or hides the actions below the cell's content view.

The same gesture using ASTableNode/ASTableView leaves the cell's content view in a partially open state.

It appears that this functionality is implemented in UITableView's own (private)
implementation of:
-(void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset;

ASTableView overrides this method, which breaks the show/hide functionality. Removing ASTableView's implementation restores the functionality; obviously this is not the solution.

As an ugly solution I have tried creating a category on UITableView to expose the private method and calling [super scrollViewWillEndDragging] at the top of ASTableView's implementation.
This resolves the show/hide problem, but it doesn't seem ideal and I'm not sure of it's impact on other code.

Sample project:
ASTableSwipe.zip

Scrolling ASTableNode in editing mode causes NSRangeException

Put an ASTableNode into editing mode and scroll up/down. An NSRangeException will be produced.

This bug appears to happen if the ASCellNode will have a different height in editing vs. non-editing mode. With the provided example, an ASTextNode with only a few characters does not produce the exception.

2017-04-28 12:50:17.325 ASTableEdit[61429:1412415] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM objectAtIndex:]: index 11 beyond bounds [0 .. 10]'
*** First throw call stack:
(
0 CoreFoundation 0x000000010ce10b0b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x0000000109cc6141 objc_exception_throw + 48
2 CoreFoundation 0x000000010cd4605b -[__NSArrayM objectAtIndex:] + 203
3 UIKit 0x000000010a2d8fdc -[UITableView _updateVisibleCellsNow:isRecursive:] + 2064
4 UIKit 0x000000010a30d97c -[UITableView _performWithCachedTraitCollection:] + 111
5 UIKit 0x000000010a2f4b2a -[UITableView layoutSubviews] + 233
6 AsyncDisplayKit 0x000000010945e76d -[ASTableView layoutSubviews] + 733
7 UIKit 0x000000010a25b20b -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1268
8 QuartzCore 0x000000010dd7b904 -[CALayer layoutSublayers] + 146
9 AsyncDisplayKit 0x00000001092d86b0 -[_ASDisplayLayer layoutSublayers] + 384
10 QuartzCore 0x000000010dd6f526 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 370
11 QuartzCore 0x000000010dd6f3a0 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 24
12 QuartzCore 0x000000010dcfee92 _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 294
13 QuartzCore 0x000000010dd2b130 _ZN2CA11Transaction6commitEv + 468
14 QuartzCore 0x000000010dd2bb37 _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv + 115
15 CoreFoundation 0x000000010cdb6717 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 23
16 CoreFoundation 0x000000010cdb6687 __CFRunLoopDoObservers + 391
17 CoreFoundation 0x000000010cd9b720 __CFRunLoopRun + 1200
18 CoreFoundation 0x000000010cd9b016 CFRunLoopRunSpecific + 406
19 GraphicsServices 0x0000000110707a24 GSEventRunModal + 62
20 UIKit 0x000000010a1980d4 UIApplicationMain + 159
21 ASTableEdit 0x0000000109219767 main + 55
22 libdyld.dylib 0x000000010e06265d start + 1
23 ??? 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

The exception started appearing in Texture 2.3. AsyncDisplayKit 2.2 does not suffer from this issue.

Example:
ASTableEdit.zip

[ASTextNode] has inconsistent line space when add emoji

From @d6u on September 6, 2015 1:58

let fontHeight = CGFloat(19.25)
let fontSize = CGFloat(16)
let lineSpace = CGFloat(10)

// Red Strip

for i in 0...10 {
    let v = UIView(frame: CGRect(x: 0, y: CGFloat(150) + CGFloat(i) * (fontHeight + lineSpace), width: 320, height: fontHeight))
    v.backgroundColor = UIColor.redColor()
    view.addSubview(v)
}

// String

let style = NSMutableParagraphStyle()
style.lineSpacing = lineSpace
let text = NSAttributedString(string: "Lorem Ipsum is simplyry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make 👍 a type specimen book.", attributes: [
    NSFontAttributeName: UIFont.systemFontOfSize(16),
    NSParagraphStyleAttributeName: style
])

// ASTextNode

let textNode = ASTextNode()
textNode.attributedString = text
textNode.measure(CGSize(width: 200, height: CGFloat.max))
textNode.frame = CGRect(origin: CGPoint(x: 50, y: 150), size: textNode.calculatedSize)
textNode.backgroundColor = UIColor.purpleColor()

view.addSubnode(textNode)

// Normal Text Label

let textLabel = UILabel(frame: CGRect(x: 50, y: 150, width: 200, height: 100))
textLabel.attributedText = text
textLabel.numberOfLines = 0
textLabel.sizeToFit()

view.addSubview(textLabel)

So I added two text label with the same attributed string. The line with 👍 won't agree with each other. I also added red strip as reference.

How do I render consistent line space using TextNode? Did I miss some config?

Copied from original issue: facebookarchive/AsyncDisplayKit#639

ASButtonNode and ASCollectionNode Performance

How to reproduce:

Create 100 ASCollectionCellNode which has 2 ASButtonNode in there
At run time, add about 10 ASTextDisplayNode into the ASCollectionCellNode hierarchy
For each of the button nodes, give it a text + image
Let the ASCollection node render and start scrolling real fast. You will notice the frame rate will start dropping.

How to fix:

Specify a preferredSize for the buttons

Notes:
I am using nodeBlockForItemAt and layouting with layoutSpecThatFit. After debug further, I think it may not only related to ASButtonNode but other problems as well. For instance, the frame rate will drop if you are creating too much ASDisplayNode at run time then append it into the ASCollectionCellNode hierarchy. I have a for loop that is creating about 12 ASTextDisplayNode then add it into ASCollectionCellNode hierarchy at run time. However, for some odd reason, if I give a preferred size to the buttons then the issue would be resolved.

It was working fine on 2.1 though.

Code:

    func layoutSpecForAccessoriesNode() -> ASLayoutSpec {

        // *** UNCOMMENT TO GET THIS TO WORK ***//
       // button1.style.preferredSize = CGSize(width: CGFloat(32), height: CGFloat(16))
      // button2.style.preferredSize = CGSize(width: CGFloat(32), height: CGFloat(16))

        let stackLayoutSpec = ASStackLayoutSpec(direction: .horizontal, spacing: CGFloat(StyleDefault.regularMargin.rawValue), justifyContent: .start, alignItems: .start, children: [ button1, button2])
        return ASInsetLayoutSpec(insets: UIEdgeInsets(top: -CGFloat(StyleDefault.regularMargin.rawValue) + CGFloat(StyleDefault.microMargin.rawValue), left: 0, bottom:-CGFloat(StyleDefault.smallMargin.rawValue), right: 0), child: stackLayoutSpec)
    }

Lost all animation(included system animation) when ASCollectionView become table header view

From @tiepvuvan on August 25, 2015 9:43

I've implemented this method in my application

tableView:viewForHeaderInSection: of an ASTableView

Everything work fine if i return an UIView
But when i return a ASCollectionView as Table Header View
My app lost all animation(included system animation like Keyboard, transition...)
This issue only occur in the newest code(branch master), v1.2.3 is working fine

I've search google for this problem, i got this answer, may be helpful

Animations may get disabled for the entire app whenever an attempt is made to animate views on a background thread"

Copied from original issue: facebookarchive/AsyncDisplayKit#628

Type inference via auto_type

Having type inference would be helpful in many cases. Details can be found in this great blog post. Let me know what you all think!

P/S: If we decide to introduce this, we need to update our coding guidelines.