Date
1 - 11 of 11
Segue
|
Gerriet M. Denkmann
iOS 11, Xcode 10
I have an UITableViewController and the UITableViewCells have a Detail Accessory with an accessory action = Navigation Controller Show Detail The UITableViewController does prepareForSegue. The Storyboard Segue is of Kind Show Detail (e.g. Replace) and it Animates. But: the Detail View slides in from *below* (expect: from right); sliding the Detail View from left to right does *not* get back to the UITableViewController and on top there is no “< Master” button which does the same. I tried to copy the Master-Detail App (supplied by Xcode) as closely as possible. Everything looks the same, but it behaves differently. What am I doing wrong? Gerriet. |
|
|
|
Steve Mills
On Sep 19, 2018, at 05:14:11, Gerriet M. Denkmann <g@...> wrote:
Perhaps you just need to provide a custom transition animation. See this guide: https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/CustomizingtheTransitionAnimations.html -- Steve Mills Drummer, Mac geek |
|
|
|
Alex Zavatone
Change the Kind of the segue. You’re going to want it set to Show (e.g. Push).
toggle quoted message
Show quoted text
Also check below in the right panel and see which Presentation and which Transition you use.
|
|
|
|
Gerriet M. Denkmann
On 19 Sep 2018, at 20:35, Steve Mills via Groups.Io <sjmills@...> wrote:The Xcode template Master-Detail App does it without custom transition animation. It uses: Master : UITableViewController → UINavigationController → Detail : UIViewController Detail slides in from right, and the user can remove the topmost view controller using the back button in the navigation bar or using a left-edge swipe gesture. The only way I got it to work: Master : UITableViewController → Detail : UIViewController Storyboard Segue Kind = Show (e.g. Push) Transition Style and Presentation of Master seems to have no effect. Gerriet. |
|
|
|
I'm not sure I am understanding your problem correctly, but I am wondering about the exact layout of your storyboard. Specifically, are you using a UISplitViewController? The Push (Detail) segue is specific to it.
On an iPhone (particularly in portrait mode), the push-detail segue looks like a simple push, but it is not. You can see this when running on an iPad in Simulator, where you will see both the TableViewController and the Detail controller (in whole or with part of it covered by the TableViewController) side by side. The push detail segue brings the detail controller to the front, covering (hiding) the TableViewController. On a phone, this just looks like a push. If you don't have a split-view controller, then the segue can't do that (i.e., it can't call UISplitViewController.showDetailViewController) and is apparently doing a simple UIViewController.present instead. If I'm off on a mistaken tangent here, please excuse the waste of bandwidth. Rick Aurbach |
|
|
|
Gerriet M. Denkmann
On 20 Sep 2018, at 22:19, Rick Aurbach via Groups.Io <rlaurb@...> wrote:You are quite right. The Xcode template “Master-Detail App” uses a SplitViewController, and it works fine. And it works for both iPad and iPhone. But you can do (iPhone only ?) without a SplitViewController as well: UINavigationController → UIViewController (Master) → UIViewController (Detail) works as expected. Three important points: 1. The Master *must* be preceded by an UINavigationController 2. There must be *no* UINavigationController between Master and Detail. 3. The Segue Master to Detail *must* be of Kind: Show (e.g. Push) This is probably self-evident (and probably also well documented), but it took me more than a day to figure this out. Kind regards, Gerriet. |
|
|
|
Quincey Morris
On Sep 20, 2018, at 22:50 , Gerriet M. Denkmann <g@...> wrote:
It is self-evident after you read the documentation, but it takes about a day to read the documentation …
… and if you’d spent the day reading the documentation, it wouldn’t have taken a day to figure out. ;) TBH, it’s a bit frightening how abstruse the controller interactions have become on iOS over the years. If you study the master-detail app template in Xcode, you’ll see that it gives the iPad *both* a split view controller *and* a navigation controller, and it switches between the two dynamically, depending on how the split view interacts with a compact dimension. If you want to make your head hurt, you can spend another day figuring out how the machinery in the App Delegate and the MasterViewController, and the cross-linked navigation controllers in the storyboard all work together to do some very clever things. I particular like this comment in the helper method near the end of the App Delegate: // Return true to indicate that we have handled the collapse by doing nothing; the secondary controller will be discarded. |
|
|
|
Dave
A day is a day, so no gain either way and that assumes that the documentation is accurate (which it may be in this case but in so many other cases its not or at least ambiguous).
I’ve been looking over the pro and cons of using storyboards and for the life of me I can’t see what is gained by using them? I thought it would make development quicker but actually I don’t think that do you save time using a Storyboard. IMO, using old old fashioned NIB and code is the same or quicker than using a NIB that the while thing is so much more maintainable and reliable. Unless I’m missing something…… Cheers Dave |
|
|
|
Fritz Anderson
I can't answer for your habits of thought. A constellation of XIBs plus code to coordinate them could possibly reproduce the user's experience of an application built with storyboards. (I'm sure I'm forgetting something, don't hit me, I wear glasses.) My thoughts in no good order:
toggle quoted message
Show quoted text
It's cognitively easier to coordinate the appearance and flow of an application in a single window. If the design is too big for a single view, you can link to another storyboard. Not every controller transition fits the model of a simple segue, but most do. Those transitions are so routine you may not even realize they're in your app. You can create them by hand, but drawing and configuring a line is five minutes, not thirty (> O(n)), and easier to maintain. Most remaining potential segues (such as jumps between branches of a hierarchy) aren't that hard to subclass, and again you have a picture. I don't want even to think about handmade unwind segues. I don't want to think hard about managing potentially-broad nav hierarchies that might change during development, without segues, so yes my concerns about segues are relevant to good (reliable, maintainable) practice. Embedded controllers, one example: A static-cell UITableView must be run by UITableViewController, which can't include auxiliary controls like Cancel/Save. Embed it in a wrapper controller with a toolbar. The scene for the table controller follows the size of the embedding view. Scene layout. If a controller is stacked in a nav controller within a tab controller, you get the correct aperture for free, even if you change the wrapper controllers. Also, the root views of children of tab controllers include the icon and label of the corresponding tab. This is orthogonal to whether you use Auto Layout. This is dangerously close to an insult — I don't intend one, this is for the archive — but make sure it's not just a matter of sentiment. You still run into people who won't use Instruments (except at release minus one week) or even a debugger, because they feel moment-to-moment pressure telling them they don't have time to learn. I'm not saying storyboards solve every problem or obviate every XIB. — F On Oct 3, 2018, at 8:55 AM, Dave <dave@...> wrote: |
|
|
|
Dave
Hi,
I think you misunderstood what I meant, of course there maybe complex situations where using Storyboard/Segues/Auto-layout are a good idea, and one you describe maybe the best (or only) way to do it. What I meant is that if you have a very simple case (on the Mac) whereby you just want a Splash Screen to display for a few seconds and then another window to appear (think a board game), then really what is the point of using a Storyboard (apart from the fact that this is the default action in XCode if you create a new single window App)? I’m asking if there are any benefits or if you *have* to use storyboards in order to make it work correctly. The reason I ask, is because as an experiment (in a Test App) I broke the components of the Storyboard XCode generated into separate NIBs and the App that worked using a Storyboard began to behave differently and I’m trying to figure out if somehow a Storyboard is *needed* to make Manual Layout work. By this I mean something that uses the: -(void) resizeWithOldSuperviewSize:(NSSize) theOldSuperViewSize; way of doing things, rather than “layout” and constraints. This is dangerously close to an insult — I don't intend one, this is for the archive — but make sure it's not just a matter of sentiment. You still run into people who won't use Instruments (except at release minus one week) or even a debugger, because they feel moment-to-moment pressure telling them they don't have time to learn.I really can’t see what could be construed at an insult! But why would you run instruments unless they is a problem? I used to run it quite often in order to check for leaks, but since ARC has been around I’ve not found the need. Especially since I “Analyse” quite often. As for the using the debugger, I don’t know any developer that doesn’t use it, however, if you sprinkle Logging about the place, this can be quicker at identifying where the problem lies than stepping through with the debugger. I’ve found a combination of the two to be the most effective tool in debugging. All the Best Dave |
|
|
|
Alex Zavatone
Please pardon this little sidetrack from this storyboard discussion. Why? Well, the UIViewController header comments of course. If you invoke this method with a nil nib name, then this class' -loadView method will attempt to load a NIB whose name is the same as your view controller's class. This means that the storyboard can exist as a visual representation of your app and its screen flow and you can use XIBs for each screen and they will automatically take the place of your scene’s top level view if you simply delete the top level view of your scene. It is (was) that simple. In fact, IIRC, this has been that way since at least 2008. This means that on larger teams, there are no storyboard merge conflicts at all if each developer keeps to their own XIB. Just set the top level class of the scene to the class in the storyboard and do the same in the XIB. Everything just loads and works. Let multiple developers work in multiple XIBs. Now, this changed somewhat in Swift and the Swift implementation looks very close to Objective-C, so it shouldn’t be too hard to see if a similar approach works in Swift. It’s much much easier just using the storyboards as skeletons and keeping all the top level views in individual XIBs. Segues work as they are expected to, everything else works just as it is expected to. It’s nice. Hope this helps someone else. Cheers, Alex
|
|
|