-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Storyboard support + storyboard example #33
Conversation
Storyboard support via custom segue and category extension. No changes to core MMDrawerController required. Added new example project to demonstrate capability.
Yeah that's definitely not what I meant by "close". This is interesting, we'll have to take a look. |
While I was excited to get this e-mail, I've dug too deep into programmatically coding my app. In any case i will have a look at this :D |
I wonder if this would be better off as an extension, rather than a first party member of the library... I would rather try to offload that to @TomSwift rather than bring it in the main library since it looks like there isn't a publicly supported way to support relationships in a storyboard for custom container view controllers. Also, since we don't use story boards, it keeps it out of the core... @TomSwift would you be willing to maintain it in your own namespace and releasing a podspec for it? |
Well, I guess I could do that. But I explicitly did this in a category extension so that it wouldn't impact your core (you don't need to include the category module in your target if you don't want the pollution). (An improved version would require a change to your core; specifically by exposing an init method that doesn't require the centerViewController to be supplied up front.) There's really nothing wrong with supporting Storyboards in this manner. The technique isn't ideal but it's not depending on any undocumented behaviors. I'd also ague that discoverability will suffer. Folks who want to use MMDrawerController with their storyboard will have to somehow discover my repository/podspec. If/when Apple supports embed-relationships for custom containers (they actually do, but not programmatically) then the core could adopt that support making this extension moot - unless the developer is targeting a lesser SDK version. In this case the extension could ultimately it could be deprecated from the library. |
@TomSwift You actually listed several reasons to include it as an extension :)
In terms of discoverability, I have no problem creating a section in the readme directing folks to your podspec/repo for that support. CocoaPods makes it EASY to bring it in, so I'm not worried about that. I'm leaning towards declaring Storyboards aren't officially supported due to the lack of available API from Apple, but direct them to your podspec for a workaround in the mean time. Thoughts? |
Okay fine. I'll create a podspec and post my extension as a separate project. Apple does have support in Storyboards for view controller containment via "embed segues". You could leverage this by exposing the This would use Apple's Storyboard support for view controller containment as intended. It differs from "native container controllers" (i.e. Whether this is better than my current extension is arguable. It's a little more work for the user/developer, but it makes use of "embed segues" as intended vs overloading the meaning of standard "storyboard segues". If you like this approach better and think you'd integrate it into the core then I'd be happy to get it working and make a new pull request. Otherwise we'll just do the separate extension that I already created. For my own purposes I'm happy with what I've got. I'd only explore this new route if you thought you'd integrate it in core. |
Could you point me to some documentation from Apple where it says that is the way to do it for custom container view controllers? I'd like to give it a read through to make sure I understand that. Also, bare with me on this issue. You are talking to someone who preaches "No Storyboard or Nibs!!!!", so I'm a little hard headed when it comes to this topic 👴 |
I understand where you're coming from - I've taken your stance before and still do on certain projects. Especially if you're on a team, Storyboards can be problematic. But they (and nibs) can make layout tasks and maintenance simpler esp. for things like table view cells. Contrary to expectations, they are often more efficient than hand-coded UI. And...people use them. 'Nuff said on that. Embed segues are not well documented. From the XCode 4.5 release notes:
And, from WWDC 2012: https://developer.apple.com/videos/wwdc/2012/?id=407 |
It looks like Embed Segues are iOS 6 only, right? |
No, I don't think so. You need Xcode 4.5 or better for the Storyboard editor support, but as long as your target supports view controller containment (which is iOS 5 or better) I think you're good to go. |
I haven't had a chance to listen to the WWDC video yet, but it looks like it is in the "New in iOS 6" section of the slides. |
Watched the storyboard video linked above yesterday. Embedding segues looks like an iOS 6+ feature (see 32:40 in video). I'm going to take a closer look at storyboards today to learn some more. |
You are correct. I made a test app using embed segue's and it runs in iOS6 but not in iOS5.1. So this approach would be 6.x only. And here's some confirmation: http://stackoverflow.com/questions/12868255/nsinvalidunarchiveoperationexception-with-containerview |
Wow thats exactly what I am looking for... It is so much easier to get things done on IB... mocking screens are just ready.... but I not gonna start a discussion about this here. Any updates on this? I want to see if this is worth better than the JASidePanels... but I need it to work with storyboards. |
@cytryn I'm planning on talking with some Apple peeps at WWDC to find out the 'best' way to do this for a custom container view controller. It looks like Embed Segues are currently the 'best' option, but they are iOS 6 only so that would need to go into an extension to allow the core to continue to work with iOS 5. I asked @TomSwift to see if he could roll his solution into an extension for the time being, until I can get more clarity on how this should be supported in the core going forward. |
I am building an app that initially used JASidePanels with its unconnected storyboards, but I switched over to MMDrawerController after I discovered Tom Swift's categories for using storyboards and segues. |
Maybe it is better to create subspec for this patch? |
Hey @ArtFeel, I'd like to see it for now an official extension, and leave it out of the subspec. Revving a subspec requires revving the whole podspec, to I would like to limit that if possible. |
@kcharwood - what did the Apple peeps say at WWDC? To me it looks like there's no new support in XCode5/iOS7 for embed or relationship segues... |
There is not. Several made the comment that they don't use storyboards :) I feel like the best way would be Embed Segues, and since they are iOS 6 only, it should live as an external dependent podspec. |
@TomSwift Did you ever make any progress on this? Have you published an extension for this? I'd love to link to it. |
I like Tom's approach. IB is used by everyone and makes things easier to see. |
No, I haven't yet posted a separate repository for this. Sorry. Mainly I think that my MMDrawerController+Storyboard is a bit fragile on its own. Because it depends on a copy/paste of code from the initWithCenterViewController:leftDrawerController:rightDrawerController, and on your non-public method -setupGestureRecognizers. If you change any of that then the extension will likely break. In fact, having just looked, it seems you HAVE changed the init sequence, and now the extension IS broke. Easy to fix, but this is what my concern is about. As @jonasman suggests, if you implemented initWithCoder: in the core then all that is required of MMDrawerController+Storyboard is to implement awakeFromNib to trigger the segues. |
I'd be willing to take a Pull Request that just implements |
@TomSwift since you dont have issues enable in your repo i write it here. In your prepare to segue your assert is breaking apps that want to segue to other VCs from the Drawer.
|
@TomSwift is there anything else here that needs to be done for now? Have you podspec'd your solution? I'd love to drop it in the readme. |
Okay, I finally got around to doing this. I submitted a pull request for adding initWithCoder: support into the core library. And I created a github repo for my MMDrawerController+Storyboard category, with a podspec. I haven't submitted the podspec yet; I'd prefer to do that once the initWithCoder: pull is accepted and a new version tagged. With the version tag I can make my podspec reference a version dependency on MMDrawerController to the version that has initWithCoder. My repo is here: https://github.com/TomSwift/MMDrawerController-Storyboard |
@TomSwift thanks for your work on this. Any progress on getting this included or added to the core, or as a separate pod? |
It looks like the pod was merged into the cocoa pods spec repo a couple of weeks ago: http://cocoapods.org/?q=MMDrawer |
correct. My first podspec! |
This was / is certainly my case. It's not clear whether MMDrawerController supports storyboards on it's own (guessing it doesn't considering @kcharwood's stance) thus making the whole ordeal pretty confusing. So, here's a vote to have this library support storyboards. It seems clear the community is continuing to move in that direction. A hard stance of "no storyboards" seems less than ideal. |
MMDrawerController looks really nice. It's a bit of a let-down to discover this thread and the lack of built-in Storyboard support. I'll add my vote here for integrating the Storyboard goods by default. :) |
Did something like this, and its working.
|
Thanks @KanybekMomukeyev, that works great with storyboard. No extension needed :) |
for those of you who want to implement something like what @KanybekMomukeyev posted here for your initial to be clear, this doesn't require the category by @TomSwift mentioned above. not sure which way is "better" |
I added basic storyboard support via a category extension on MMDrawerController. No changes were required to the core MMDrawerController itself. I also included a new example to showcase this new capability.
Apple doesn't support programatic "embed" segue outlet definition, which would be desirable. Because of this we have to use custom segue's, and this places one extra work item on the user - they must set a segue identifier for each "center", "left", and "right" segue connector.
This could be considered a "hack", but I think it addresses the current desire by some developers to be able to define their interface 100% in a storyboard.
I'm happy to address any issues or desired changes.