Does Infragistics publish any best practices for using the various NUCLiOS views with Apple's auto layout? If not, when is this planned? I'm building a library for managing auto layout NSLayoutConstraints programmatically and NUCLiOS auto layout best practices would be useful to me. I've tried moving away from autoresizingMask for IGChartView and IGRangeSelectorView but I am missing something with regards to how the frames are maintained internally. I would be willing to consult with the NUCLiOS team on how to convert the masks to NSLayoutConstraints, or to create a hybrid solution. Cheers.
Hi Caylan,
We do not have any best practices published for using Apple's AutoLayout system as there isn't anything special to our controls in that regard, as they're just UIView's and thus automatically get that behavior for free. And Apple already has quite a detailed explanation of how to use it.
That being said, I can't rule out the fact that there could very well be an issue with one of our controls, and if so, we'll definitely look into asap.
So, are you running into a specific issue with one of our controls, or are you just looking for a little guidance in general on how to create a specific layout using that system.
Either way, i'd be happy to help you. Just let me know how you're looking to lay out your view, a screenshot would probably be best. Also, the platform you're using would also be helpful (Objective-C or Xamarin.iOS)
Thanks,
-SteveZ
Stephen. Thanks for the reply. All of my development has been in Auto Layout. I'm not familiar with Springs and Struts (S&S) and autoresizing masks. I'm not sure where to "draw the line" so to speak, between the two layout systems.
For an example, each orange rect in the below image is a UIView in IB. The top UIView will be a container (property on the VC named self.chartViewContainer) for IGChartView (instance variable infraChart) and the bottom UIView will be a container (property on the VC named self.rangeViewContainer) for IGRangeSelectorView (instance variable rangeSelectorView).
Note: The numbers on the bottom 0...1000 are just UILabels and are not a part of the Infragistics NUCLiOS
In all of the examples I've seen, the preferred way to set this up using Springs&Struts (S&S) in viewWillAppear is:
infraChart.frame = CGRectMake(0, 0, self.chartViewContainer.frame.size.width - 25, self.chartViewContainer.frame.size.height);
infraChart.autoresizesSubviews = UIViewAutoresizingFlexibleHeight|UIViewAutoresizingFlexibleWidth;
rangeSelectorView.frame = CGRectMake(10, 0, self.rangeViewContainer.frame.size.width - 10, self.rangeViewContainer.frame.size.height);
rangeSelectorView.autoresizingMask = UIViewAutoresizingFlexibleHeight|UIViewAutoresizingFlexibleWidth;
You can see from the above that the chart is inset 25 points from the right. The range selector is inset 10 points from the left and right.
My question is: If I manage the auto layout externally that affects the size/layout of the orange UIViews, what is the preferred method to control the interior of the UIViews and they're associated NUCLiOS views?
Correct. The range selector's chart is messed up when the range selector is sized/positioned using auto layout constraints. The thing is, I have not modified the sample code for the "chartViewSelector."
chartViewSelector = [[IGChartView alloc] init];
rangeSelectorView.contentView = chartViewSelector;
NSLog(@"chartViewSelector translates:%x", chartViewSelector.translatesAutoresizingMaskIntoConstraints);
Ah, on second thought... check this out.
When I log that...
2014-02-18 11:04:54.121 130499[44720:70b] <IGChartView: 0x91f3b10; frame = (0 0; 914 153); autoresize = H; layer = <CALayer:
0x91f3bd0>>
Unfortunately, setting the autoresizingMask to UIViewAutoresizingFlexibleHeight|UIViewAutoresizingFlexibleWidth did not widen the range selector's contentView chart. In my best estimation, it seems the range selector's contentView has it's own logic for sizing the frame. Bummer.
Thoughts?
I just took a look at the source, and there is a bug. Looks like we didn't set the autoresizingMask properly for the contentView's width.
It's a minor issue that we can fix for you quickly.
Thanks for bringing it to your attention.
Awesome. Glad to hear it. Reply to this when it makes its way into a maintenance release?