IOS Navigator strategies.
IOS Navigator strategies.
- Subject: IOS Navigator strategies.
- From: Alex Zavatone <email@hidden>
- Date: Wed, 09 Jul 2014 13:26:40 -0400
I was just asked to do a last minute extension of our iOS app's UI flow and noticed something that opens up an interesting issue in iOS navigator driven UIs.
We have a situation where in the first section of the app, it's a perfect linear navigation stack. Buuuuut…
But, after this part of the app, it's a condition of "this part of our app is over, we need to branch to a new navigation process for the next phase".
Now, I have experimented with this with a Settings module where the app presents a view controller within another storyboard and this has its own nav controller and wonderfully, it simply works like a charm. In memory it seems to just sit on top of the previous navigation controller flow until it is dismissed.
In the condition where one part of the app ends, we don't need any of the previous navigation controller and its VC stack to stay in memory at all after we've completed it.
It would seem to make sense to take an image of the screen, create a fresh navigation controller and present its first view controller in a fresh storyboard. At least that's what the voices in my head tell me and gosh darn it, those voices are pretty persuasive.
In all seriousness, is this supported? Does this sound like a valid or proper approach?
I've really been enjoying the flexibility of branching off to new view controllers in fresh nav stacks in other storyboards and it really facilitates a modular approach + allows multiple developers to work on their own section of the app without much of a file collision.
My only concern is that when we present a VC like this, the memory used for the initial nav controller is going to stay allocated, but some type of approach to facilitate working like this offers great flexibility in building iOS apps on a component basis in multi developer teams.
Feedback on the validity/stupidity of my quest is welcome.
Cheers,
Alex Zavatone.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden