nuno / TiCollectionView

UICollectionView / GridView for Appcelerator Titanium
MIT License
111 stars 43 forks source link

Horizontal direction not working unexpected #58

Open HazemKhaled opened 8 years ago

HazemKhaled commented 8 years ago

I'm using CollectionView in same app sometime vertical and some times horizontal, unfourtunilty some time the property ignored for no reason, in same page i've 5 instances in same screen, 3 working fine (horizontal) and 2 ignoring the property from the proxy.

I'm sure @philet have same issue, and his workaround by set horizontal ad default value, but it's not enough in case i need both vertical and horizontal in same app

From

[TiUtils intValue:[[self proxy] valueForKey:@"scrollDirection"] def:kScrollVertical];

To

[TiUtils intValue:[[self proxy] valueForKey:@"scrollDirection"] def:kScrollHorizontal];

Any help

philet commented 8 years ago

Yes, I had the same problem and indeed hardcoded the horizontal direction as a default value as I only needed this. Would be great though to make the configuration work correctly.

hansemannn commented 7 years ago

@HazemKhaled Can you give a (full) example code that fits in an app.js? Either it's because the constants are defined incorrectly or executed on the wrong thread. Thx!

ottopic commented 7 years ago

Hello @hansemannn, can you help other contributors to understand what's the problem of issue #73?

Thanks in advance

rlustemberg commented 6 years ago

@hansemannn Problem is caused by _collectionView being instantiated before the properties have been set. (void)_initWithProperties:(NSDictionary *)properties in the proxy is being called after initialization of _collectionView, so the scrollDirection property on the proxy is always null. I'm looking for ways of making sure that it doesn't happen.

hansemannn commented 6 years ago

Maybe move to _initWithPageContext:args: ? Thats called first, so you could get the properties from there. I‘m not planning to do that, but am happy to help in these kind of proxy questions

rlustemberg commented 6 years ago

The funny thing is that when configurationSet is invoked by TiCollectionviewCollectionView , the dynProps from TiProxy have not been set yet. It happens at a later stage. I'll do a quick and dirty solution for the scrollDirection property by adding a public property 'scrollDirection' to the TiCollectionviewCollectionView and setting it from the proxy. I don't like the approach and won't submit a PR for that. If you think it's acceptable, then I'll refactor the code and apply same approach to the remaining 'kLayoutTypeWaterfall' properties (which are also not set by the time the UICollectionView is instantiated).

rlustemberg commented 6 years ago

I think I know exactly what causes it: When invoking [super _initWithProperties:properties] on the proxy, it will eventually end up setting the 'templates' property, which uses a setter which ends up instantiating the collectionView before the remaining dynProps have been set, creating a race condition. I think if we avoid setting the templates at that stage, we can provide a more elegant fix for the issue.

rlustemberg commented 6 years ago

Ok, last comment. It's more complicated than my previous statement. The collectionView property is called at least 5 times before all of the dynProps are set. Either we figure out a way to prevent that, or we use an alternative for setting up the properties on the constructor

hansemannn commented 6 years ago

Lets do a lazy initializer that invokes the required properties, wouldn‘t that help?

- (UICollectionView *)collectionView
{
  if (_collectionView == nil) {
    // Initialize
  }

  return _collectionView;
}
rlustemberg commented 6 years ago

It's already implemented with a lazy initializer. The problem is that it's invoked before all the dynProps have been set.

All of these methods are called before the dynProps are fully set. When the dyn props are being set, the setters end up calling self.collectionView on the view class. I think the quick and dirty solution of dealing with the 'creation only' properties in a diferent way to ensure they are available in time might be the simplest one, departing a bit from the pattern of using initializeWithProperties.

rlustemberg commented 6 years ago

'Creation time' properties include all of the waterfall attributes. I am using at the moment a personalised version with the quick and dirty fix, dealing only with the scrollDirection issue