-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split the storyboard in multiple storyboards to help collaboration on application maintenance #51
Comments
This modification must be done iteratively. The bad news is that some controller are loaded dynamically by code, and it will require changes to those code section, and must be tested thoroughly to make sure everything work as intended. Will do a first round and see what are the next steps. |
…boards (Aircraft, AddAircraft, ChangeUnit, ListMaintenanceIssues, TNIPicker, and ViewJourneLogEntries). Plus related code changes to load view controller from those storyboards.
…o the EditCadetNavigationController (moved out of iPadStoryboard). In EditCadet storyboard, created a custom identifier to CadetFyingRecords and CadetAttendanceRecord for ease of reference. Moved scenes around to increase clarity.
Worth noting is that SwiftUI does not use Storyboards, so it depends how long you plan to continue to use them whether this proposal is worthwhile. SwiftUI is still a fairly new and immature technology, but it does have potential... |
Just looked to what SwiftUI is. Awesome. Not sure though I would convert what already exist into SwiftUI. In green field project, I would not hesitate with going with SwiftUI. Making things easier to work with seems a better investment. No? It seems to me there is so many things hidden in the storyboard (eg. transition in code). Great work! But need a way to share the knowledge and make it easy to maintain. I'm still curious about your views on this. Lets continue the discussion. |
Yeah, I'm not suggesting we convert what we have to SwiftUI for no reason, but I wonder if that's the way to go as things get worked on or as new content is added. I haven't had a chance to really work with SwiftUI yet so I'm not sure if I'd recommend it at this point. |
I suggest to continue splitting the main storyboard into smaller ones, as it makes maintenance earier, reduce load time and makes every storyboard independent from each other. Anyway, when I get more time. |
The main goal is this split is to help maintenance to the application story boards. Working on a single big storyboard is not practical if we want to work collaboratively ad not source control friendly.
It will also help understand the interactions by reducing complexity of storyboards and storyboards will load more quickly.
The text was updated successfully, but these errors were encountered: