Open HazemKhaled opened 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.
@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!
Hello @hansemannn, can you help other contributors to understand what's the problem of issue #73?
Thanks in advance
@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.
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
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).
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.
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
Lets do a lazy initializer that invokes the required properties, wouldn‘t that help?
- (UICollectionView *)collectionView
{
if (_collectionView == nil) {
// Initialize
}
return _collectionView;
}
It's already implemented with a lazy initializer. The problem is that it's invoked before all the dynProps have been set.
setCanScroll_ (called when the proxy invokes [self initializeProperty:@"canScroll" defaultValue:NUMBOOL(YES)];
)
(void)viewDidAttach
setSections
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.
'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
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
To
Any help