This question is about general cocoa design principles. In my app, each IGFlowLayoutViewCell is fairly complex. Usually, I would thin out the complexity by embedding childViewControllers. But this isn't straightforward when all I have is a UIView. How do you usually design around this? I thought about stashing a dictionary of all the VCs and manually assigning the cell to the VC's view property... Any and all suggestions are appreciated.
Hi Caylan,
Assuming i'm understanding the question correctly, if you have you complex cells, i recommend that you extend the IGFLowLayoutViewCell class, to handle the logic within the cell, as opposed to just assigning content to it.
For example, when you asked a while back about nesting IGFlowLayoutView's, i created a ChildFlowLayoutViewCell class that contained and managed the child IGFlowLayoutView.
Are you displaying different types of views in each of your cells?
-SteveZ
This is a tough question for me to describe. I was already subclassing IGFLowLayoutViewCell and it worked fine, right up until I wanted to embed a VC I had laying around. So, imagine that each IGFLowLayoutViewCell is a "device" with signal strength and battery level. I already have those view controllers built, but I'm finding it non-intuitive on how I can "embed" them inside a IGFLowLayoutViewCell (UIView subclass). So again, my problem is trying to make sense of the MVC design pattern when all I have is one UIView.
I think what it amounts to is somehow leveraging the IGFlowLayoutView's delegate methods to perform some kind of "custom container" logic.
https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/CreatingCustomContainerViewControllers/CreatingCustomContainerViewControllers.html
I think I found the solution.
wrong way: assigning the cell to the VC’s view property.
correct way: assign the VC's view to the cell’s contentView property.
Can you think of any other considerations?
Here's what I have so far:
return cell;
Hey Caylan,
I wouldn't constantly change the contentView of the cell. You pay performance hits for constantly modifying the visual tree.
Instead, you should only set the contentView, if it wasn't already set.
Also, it looks like with this code you wind up creating a SemiNodeViewController for every single sensor you have in your underlying data. Perhaps you have only a few sensors, so it isn't that bad, however, it probably won't scale if you eventually need to add a bunch more in the future.
So, i guess what i'm recommending is something like this:
This looks good at first glance. Thanks for taking a crack at it. I'm being pulled in a few different directions but this project is getting more and more attention as we move into the summer months.
I am just checking the progress of this issue. Did Steve’s suggestion helped you solve your issue? Do you need any additional assistance?
Thank you for using Infragistics.