Building a Native OS X Desktop App: First Impressions

Comment

Comment by Pat Niemeyer on October 17, 2009 at 4:10am

This is a completely different issue from the declarative vs. visual building. But what you are saying is that views never have any logic and they are always static building blocks to be assembled by controllers. This may be true of simple views, but in general they are going to require more structure, including potentially their own internal view-models and view specific logic. (For example, most of those things on your Interface Builder palette fall into this category). Having a controller constructing a view in too fine grained a way breaks encapsulation and blurs the boundary between the views and controllers.

Anyway, the original point (mine anyway) was that MXML is fantastic and in my opinion much more transparent and useful than serializing everything into a binary NIB. GUIs are good at laying visual things out visually; Languages are good at describing abstract concepts (e.g. bindings and behavior). Parts of GUI development fall into each category. Being able to go back and forth between the visual and a *declarative* description of a GUI is very powerful and not at all fragile, as would be editing generated code that does not properly represent structure.

Comment by Martin Pilkington on October 17, 2009 at 1:49am

In reality, in any non-trivial application, you can never do everything from UI builder. There are almost always parts of the UI that need to be built dynamically based on parameters, context, etc. You often have to do refactoring that cuts across many components and is much easier to do in code. As such, the ability to easily flip between the UI builder and the markup is very valuable. If you spend some time with the newer systems that facilitate this (Flex w/ FlexBuilder, WPF or Silverlight with Expression / VisualStudio, etc.) the advantages will become readily apparent.

In which case those dynamically built UIs should be built within controllers, not in the view. If you are dynamically adding or removing UI elements in your UI this is the responsibility of the view controller. So you either add a controller object and bind to it to hide elements based on context, or you can use the more flexible way of modifying them in code.

There should be a clear separation between code and UI building. If these things need to be done in the UI markup, then they should have a UI in the builder for doing them. Otherwise they should be done in code in your controllers.

Comment by Konstantin A Lukin on October 16, 2009 at 7:01pm

Stuart Malin: I agree! Yet there are so many things calling me, and I know their learning curves are deep. I wish I were younger and had my swifter mind, that there were more free hours in a day to explore, and that I knew of some compass for assessing true utility and potential in advance.

I agree. It is not easy to find the right path. That's why we are all blogging here about our illuminating ideas, where the right answer is somewhere between the lines :)

Stuart Malin: As for Google's expanding market share: they are ill-representational of an adoptable business case because their business model uses immense profits from one product area (online advertising) to fund initiatives in other areas... that have no revenue. Expanding market share without a revenue model is unsustainable. That said, Google has been exemplary for injecting advertising into other online services (e.g. maps). I do not know what their economic model might be for Android (other than an app store for developers), and whether that can become a self -sustaining activity.

I'd rather call Google un-orthodox.. but there is nothing wrong with that if it brings in the cash :) I also think that their advertising business would not be so successful if they did not offer their 'free' suite of products.., because truly there is nothing that's free. Everything has a price, and in advertising business, customer's attention has undeniable value.. That being sad, Google is certainly capturing the attention of developers worldwide..

Comment by Daniel Leuck on October 16, 2009 at 2:41pm

Martin Pilkington: The point is, if the GUI editor is any good you shouldn't need to drop down to editing the MXML to enter binding expressions, do refactoring etc.

In reality, in any non-trivial application, you can never do everything from UI builder. There are almost always parts of the UI that need to be built dynamically based on parameters, context, etc. You often have to do refactoring that cuts across many components and is much easier to do in code. As such, the ability to easily flip between the UI builder and the markup is very valuable. If you spend some time with the newer systems that facilitate this (Flex w/ FlexBuilder, WPF or Silverlight with Expression / VisualStudio, etc.) the advantages will become readily apparent.

Pat Niemeyer: I'll have to do a proper blog post on it someday...

We look forward to it!

Comment by Martin Pilkington on October 16, 2009 at 6:53am

@Pat: The point is, if the GUI editor is any good you shouldn't need to drop down to editing the MXML to enter binding expressions, do refactoring etc. You can enter bindings for Cocoa in interface builder and Xcode's refactoring support refactors NIBs as well.

@Stuart: It depends what you are doing. If you replaced an NSTableView with lots of views then you'd see a slow down. If you replaced it with lots of layer backed views you wouldn't, but you would gain lots of extras in the form of animation. This is why there is no UICell on the iPhone. It is Core Animation that makes the difference.

Comment by Stuart Malin on October 16, 2009 at 6:46am

Not in my experience on the Mac: I can feel the performance difference in UI responsiveness. I'm talking about a situation where I've replaced thousands of views with 5. All those original views consume a heckuva lot of memory, and result in a ganglia of references.

Comment by Pat Niemeyer on October 16, 2009 at 6:44am

It's not just about the UI... MXML is an entire declarative complement to ActionScript... It allows you to do the parts of your app that make sense in a declarative context in XML... both GUI elements and non GUI.

I think you may be thinking of editing generated procedural code (e.g. Java or Obj-c) and there I'd agree... you fill in the boxes that the editor gives you or you give up. But this is completely different... In Flex, bouncing between the GUI builder and the markup is a one keystroke and it's very useful. I use the GUI editor to do layout and visual tweaks but I usually go back to the MXML to enter binding expressions or do other setup that takes more advantage of the language editor features (e.g. type completion, etc.). I can also do many kinds of refactoring in MXML more easily than the GUI editor... And the MXML is so concise (again, it's magical) that it is not that difficult to do.

I can even initialize static parts of the UI components from custom classes that I've written in ActionScript... This is a natural consequence of the fact that MXML is a complete solution and not just a GUI markup syntax... but it totally amazed me. All new components that I make (in MXML or AS) show up in the GUI editor and can be used immediately... And I can go back to the MXML to initialize them with arbitrary AS classes. For example if my Widget requires an array of Foo objects as data and they happen to be static in a given case I can construct them declaratively in the XML.

I'll have to do a proper blog post on it someday...

Comment by Martin Pilkington on October 16, 2009 at 6:29am

For all intents and purposes NSCell is no longer needed. It was useful in the 80s and early 90s when computers were quite slow, but with computing power now there's not a huge benefit. This is why the iPhone has completely forgone them in favour of layer backed views.

Comment by Stuart Malin on October 16, 2009 at 6:24am

@Martin I agree - one should never need to edit structures produced by UI editor.

That said, my most sophisticated interface constructs are completely computed. This is the case especially for repeated layout, such as in tables, of complex entities. Now, this could be done (and I have so done) by constructing an NSView in IB, and then instantiating repeatedly, but Views are a heavyweight object, and so in some cases I handle the NSCell directly, and composite the visual presentation for rendering, and overlay in a single NSView for interaction. This approach is not for the faint of heart, but does provide massive performance benefits. Someday when I get back on island, perhaps I'll do a presentation on such technique.

Comment by Martin Pilkington on October 16, 2009 at 6:12am

@Pat Any UI editor that leads you to edit its output by hand fails at its job. The advantage of IB is that you never need to drop down into the NIB file to edit it.

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page