xib vs Storyboard for Doc based Mac App. looks like the decision has been made for me.

I'm an old school programmer. cut my teeth on the Very first Mac os X server. Back before the dock, Aqua, Xcode.

Nibs and Xibs make sense to me, and they are my preference.


apparently, Apple has decided to kill support for xibs and nibs in document based apps. If that is not the case, then at least: there are no bread crumbs for fixing whatever they broke, in enabling storyboards in Mac OS X Document based apps.

when you load an xib instead of the storyboard, as your document's UI, Save, open, and a host of other menu commands are disabled. the very "Document" behavior associated with NSDocument, doesn't work.


So I am in need of help. Storyboards are infuriating to me, it's an arbitrarly complicated and restricted environment. The simplest and clear things that I have been doing for decades, are now out of my reach. tutorials seem to make dumb front ends that do not actually display data, the documentation seems to show hundreds of exhausting features of IB, but nobody shows how you might ever bind to document data, or even reference the document from your viewcontroller in any way.


i need some hints. breadcrumbs. Some of us out here want to do more than click on glass screens and kill zombies in a physics sim.

Accepted Reply

uh huh. attitude. my attitude. somehow that's the problem here?


John Daniel, maybe you should check the mirror. here's why:

1. IOS is adding direct support for access to the filesystem in ios 11. which means even IOS Apps will support document based apps. it's the next big thing. Announced at WWDC, maybe you heard of it.

2. this is a programming forum, not a psycologists forum.

3. I was very specific about my needs, the only impact you have had on this thread is to make suggestions that do not relate to the issue.

and 4. (my fav) here's the solution to the problem (i figured out the correct search terminology):

https://developer.apple.com/library/content/qa/qa1871/_index.html

it seems that when you make the window, you have to write code to fill the gap created by the deprecation of "file's owner" you don't do it in the window controller, you do it in the container view controller. you set the representedObject to your document data object.


2 lines of code. that's all I needed.


so, there's no need to throw away years of experience, to take up a completely different discepline. Maybe just fine tune that attitude. Don't accept the unofficial company line, the lack of documentation, the lack of interest from others, the voices of people you don't know, asserting that it cannot be done. it's ok John, next time you can maintain a positive attitude that the problem can be solved, this time: I did it for you. you're welcome.

Replies

Hello eblu,

Apple prefers to target the bigger, younger markets. They do this for developers too. They are trying to make the Mac development environment more like the iOS environment to make it easier for iOS developers to write Mac apps. A good, general way to start would be to start developing some iOS apps. As a side benefit, you'll get a market that is 10-20 times the size of the Mac market. I know what you might be thinking. I'm an old-school Mac programmer too. But you did mention "breadcrumbs". That is what you are talking about when you talk about the Mac market. It is just crumbs compared to the iOS market.


I'm in the same boat as you. Maybe start out with some simple storyboard-based apps. Also keep in mind that this new code doesn't have 17 years (or more) years of stability behind it. For example, the template gives you a viewDidLoad() method, but you can't really use it. Although the view has been loaded technically, it hasn't yet been inserted into the view hierarchy at this point. Instead, you can override viewWillAppear() and then you will be able to get a reference to the document like so:

    guard
      let document = view.window?.windowController?.document as? Document
    else
      {
      return
      }


I'm not entirely certain this is the best approach. It was suggested in a Stack Overflow post and meets my needs today. I don't know what tomorrow will bring.

John,

you're kidding, right? Look, I'm a hobbyist developer. But I haven't been in a dark room the last 20 years. I do not need to be lead by the nose to the conclusions you've come to about the Apple dev environment. I don't disagree with everything you've said, but really? Crumbs? You've made ***** assumptions about what I am doing, thrown an oblique insult my way, and insisted that I should change my market approach. If I wanted to-market advice, I would have asked for it in another forum. As is, I am solving a technical problem, there is no market approach. Your advice on that subject is way off. I have an issue with documentation. I need help with that. specifically: how does one bind to a property in the document, from a UI element (say, a tableView) using a storyboard?


I've already discovered that the WindowController document property is not populated. And as a reminder: if you have to set a property After the storyboard/xib is loaded, binding in the storyboard/xib will be fubarred. (though I could reset it... it doesn't stand the NextStep test: if you have to work real hard at it: it's not the right way.)


There is no amount of IOS programming that will enable anyone to develop a Mac Document based app. Simple storyboard apps are trivial easily grasped, been there, done that. We are drowning in tutorials about hooking up a button to an action in a viewcontroller. I have not found a single search term that links to what comes after that, on the desktop. And now... I have no choice. it's either Storyboard or no document based app. I think they messed up the first responder tree, but there's no telling what else is messed up.

I do share your view and frustration. Just a personal experience to report here.


I have developed IOS App and found stroryboard really good.

But when I started developing OSX App, for a pretty technical, multiwindow application, I decided not to go with storyboards that I found pretty unconvenient.

At that time I also decided not to for for document based. Sure, I had to redevelop a few things (I find it was in fact fairly limited), but I gained a lot of freedom. The last move to force storyboard for document based (as far as I understand) just confirms me it was a good choice.


I don't know if you can afford to move away from document based (probably a big deal if the app is already written).

Great attitude!

uh huh. attitude. my attitude. somehow that's the problem here?


John Daniel, maybe you should check the mirror. here's why:

1. IOS is adding direct support for access to the filesystem in ios 11. which means even IOS Apps will support document based apps. it's the next big thing. Announced at WWDC, maybe you heard of it.

2. this is a programming forum, not a psycologists forum.

3. I was very specific about my needs, the only impact you have had on this thread is to make suggestions that do not relate to the issue.

and 4. (my fav) here's the solution to the problem (i figured out the correct search terminology):

https://developer.apple.com/library/content/qa/qa1871/_index.html

it seems that when you make the window, you have to write code to fill the gap created by the deprecation of "file's owner" you don't do it in the window controller, you do it in the container view controller. you set the representedObject to your document data object.


2 lines of code. that's all I needed.


so, there's no need to throw away years of experience, to take up a completely different discepline. Maybe just fine tune that attitude. Don't accept the unofficial company line, the lack of documentation, the lack of interest from others, the voices of people you don't know, asserting that it cannot be done. it's ok John, next time you can maintain a positive attitude that the problem can be solved, this time: I did it for you. you're welcome.

1) iOS has supported document-based apps for years.

2) Could have fooled me.

3) No, you were ranting.

4) I never said it couldn't be done or wasn't straightforward. My suggestion was to study how iOS does things so you would have a better understanding of the modern state of the platform and how things will work in the future rather than being frustrated when they don't work like they did in the past. Bindings themselves were only introduced in 10.3. iOS doesn't have them. Therefore, they aren't necessary and only a small fraction of developers for Apple platforms use them at all. Having a broader understanding of how things work will help you avoid getting stuck in the future and having to rely on finding just the right search terminology.