First off all I don't have much experience in Mac Desktop Programming. I only worked on iOS apps.
Now I would like to make a desktop application that helps me develop iOS apps. To do that I would need to display a UIView (loaded from a xib) on the desktop, similar to how interface builder works.
As far as I know desktop applications use NSView. Is there any way to display a UIView inside a NSView?
EDIT: Is there any way to convert a UIView to a NSView?
EDIT2: Is there any way to write plugins/extensions for Interface Builder?
EDIT3: I'm trying to build an application that would make the development of certain iOS apps(presentation apps) easier. For example an app that displays multiple views in a scrollview, each view having some graphical elements that are animated and some buttons that make a popup appear. This kind of apps are easy to develop but tedious. I would like to make a tool that would help me build such apps faster.
Thanks.
UIKit (the iOS UI framework, including UIView) does not run on OS X (the Mac desktop OS). There have been several efforts to create a 3rd party UIKit port to OS X. Of these, Chameleon may be the most advanced. It still implements only about 60% of UIKit (according to the project page), but has been used in shipping applications. It was developed by the makers of Twitterific to port their iOS app to OS X, and I believe is still the foundation of that product on the desktop.
Converting UIView to NSView
There is no way to "convert" a UIView to an NSView. Since you can't load UIKit on OS X (or AppKit on iOS), there's no way to instantiate a UIView and then walk its view hierarchy to instantiate an equivalent NSView. Of course, since the semantics of UIView are different from NSView, it's unclear whether there could be a deterministic mapping. NSView hierarchies are view-based, whereas UIView hierarchies make much more pervasive use of CoreAnimation layers. NSView has its roots in the NeXT AppKit framework. There are a number areas where AppKit is showing its age. UIKit is a fresh start, "fixing" many of these legacy issues in AppKit (of course, introducing it's own future "legacy" issues).
It may be possible to parse the XIB, instantiating roughly equivalent NSViews where there is a meaningful mapping from UIView to NSView. Custom UIViews will be completely off the table in this scheme, and there won't be any way to (easily) match look and feel without writing custom NSViews for each UIView (ala the Chameleon project).
IB plugins
Interface Builder 3 did suppert a plugin architecture. With Xcode 4, Interface Builder no longer supports third-party plugins. Sorry.
Edit
Unfortunately, I don't believe Chameleon can load views from XIBs, so you may have to contribute to the project if you want to load XIB views instead of instantiating them in code... as Ashley points out, you may be diving into a very deep rabbit hole.
NO. UIView only work on iPhone. Use NSView on mac.
Given your description of the app you're trying to build, I might suggest that you write XIB XML directly, rather than trying to manipulate UIViews on OS X. You might use the emulator to lay out the controls, then generate a serialized representation of the hierarchy (position, etc.) on the device. You could generate XIB XML from that serialization, either on the device or on your desktop after pulling the serialized form back from the emulator.
No, there isn't. One is part of the Cocoa (Mac) framework, the other is in CocoaTouch (iOS).
Not sure what you mean by convert a UIView to a NSView
What are you trying to achieve? Perhaps there are other ways to accomplish your goal.
You might want to check out http://chameleonproject.org/
Related
I have lots of views - sub classes (UILabel, UIVIew, UIButton etc) using core graphics (within drawrect).
These show fine within normal interface builder.
However they do not show in the preview assistant editor for the storyboard (where you can see how views should look on actual devices).
I've been doing some research and found posts suggesting prepareForInterfaceBuilder should be used. However this doesn't show in preview for me.
I asked this question some years ago, IB_DESIGNABLE, having views show in preview? however I can't reproduce this, I'm not convinced it did work back then either.
I'm still following the same approach, with a framework and that link shows my implementation.
I know that prepareForInterfaceBuilder should be used to do something different, to show something basic. Therefore I believe that core graphics won't work.
However, I can't even get a simple change in background color to work in the preview, although it does work in normal interface builder.
I would like to know if this is a bug (that core graphics can not be used in preview) or still a limitation in xcode?
At the very least I'd like to do something simple (like a change in background color). I have a lot of views and an impossible task to make auto layout changes.
Previously I was producing lots of screen shots, different devices, languages etc (via automation) just so I could see my auto layout changes, which is really slow way to work.
I can verify this is a long standing bug. Apple doesn't care. Custom view be damned. All those dollars spent for more broken Xcode functionality.
Android?
Daniel
I've been frustrated by the lack of extensibility categories give the developer. I cannot override getters or setters, let alone define new properties. The question is:
"Is it possible to do these things WITHOUT subclassing a UIKit component like UIView?"
Subclassing UIView has its disadvantages, too. I cannot force components of UIKit that subclass UIView (e.g. UIImageView) to instead subclass my subclass of UIView. Categories really do work best for what I'm adding to the UIView class, but the limitations I stated earlier are too restricting for my tastes.
Any help would be great!
Without answering how to do it, I can refer to an interview with Loren Bricther:
He built his own version of the user interface framework, the software
that sits right above the graphics processor on an iOS device. Apple
creates that for developers — it was completely unnecessary for him to
do this. But this is the kind of thing he considers “fun.”
“It’s insane,” he admitted. “But I wanted to experiment with different ways of driving graphics … Apple’s [UIKit] is the best, but I wanted to try.” The experiment was a resounding success — and now has a million guinea pigs testing his code via Letterpress. And, he said, “there have been zero issues” with what he built.
So it is possible. Letterpress is built this way.
I've currently an App (with a lot of View Controllers, ...) what uses the "discontinued" Facebook three20 Library and any storyboard, xib file.
Now I need to update this App, the Deployment Target will be iOS 7 and I have to build it with XCode 5.
So my questions:
Is using the Storyboard a good Idea? Would you suggest me to recreate all View Controllers in the Interface Builder?
--
Another question: when adding a Label Programmatically using iOS 7 feature
self.edgesForExtendedLayout = UIRectEdgeAll;
how do I set the Frame for this Element? Need I determine if I am in Landscape, Portrait and Add the 20+44 for example manually to the y-Axis to start under the NavBar or are there better ways to solve this problem?
Storyboards are good, and you should absolutely use them in any future app you make. Whether or not you should rebuild a current app to use storyboards is a question of how big the app currently is, how much bigger it might get, how much longer you'll support it, etc.
If the app is already pretty massive and it won't necessarily grow much at all from here, it's probably not worth the effort to convert over to storyboards.
If the app is only a handful of view controllers, but you have big future plans for it, I'd take the time to convert it over to storyboards so that all the future development will go faster/easier.
I don't deny storyboards but I respect the custom view approach. It means I am creating my each & every component programmatically via code, be it a UILabel or a UITableView. Aligning code with ios7 specific requirements can also be handelled & controlled at granular level using custom View approach.
To your questions about setting frames for the element or detecting device orientation can very well be detected & adopted by writing code.
You can search more help as the information is available all around on programming aspects of iOS.
I am curious to know if anyone has any experience comparing the load time performance of iPhone apps with views laid out in NIBs vs. views laid out entirely programmatically (here is a similar question).
Is there really any advantage of views laid out entirely programmatically over views laid out in NIB ?
According to Apple, XIB file loading time is longer than build UI programmatically.
Saw that in a WWDC lecture.
If performance is what counts, build your UI in code and not in IB.
There are some advantages by doing it on code:
Better to work with several people. It's easier to resolve conflicts when committing to a repository.
You rely on what you see on the code, and not in something hidden in the nib file (some pesky option you select without being aware). You have: what you see is what you get.
With nib:
I would say it's faster to develop.
The code it's not so "polluted" with every single detail about your interface.
I also would stay it's easier for people who don't have a lot of experience.
About performance, you can actually check this.
When I was beginning to learn iOS programming, I was building UI in xib file. But when I had developed some projects, I began to just write code to implement my UI.
There are some benefit through building UI programmatically:
First, by writing code, you have the view hierarchy clearly in you mind, and the view hierarchy can be important to efficiently implement your UI.
Second, if your UI is complicated, for example, with some animation or transform, you will benefit quite a lot from coding UI. Even sometimes you may not use UIView to build UI, you may use CALayer to accomplish some effect, which can not built by xib file.
Furthermore, when you get used to building UI programmatically, you will love it, because you can just code in the .m file and has no need to worry about the xib file.
However, if you are just a beginner in iOS programming, just fine to get start with xib file.
(Apple now provide StoryBoard, I have not learned about it, you may learn it to find if there is anything new.)
IMO a mix of both would be the right choice. Using interface builder for defining the basic layout (i.e a xib that doesn't change much over time) and default options of views and for the rest can be done programmatically (specific tweaks and effects). This should solve the source control and performance problems to some extend.
Although once we start off creating views programmatically ,we continue doing it for every time not realizing that the same thing could be done with much less effort in Interface Builder. After all if it's a GUI we are building it's better to have a visual reference.
Our company is developing a quite large app for the iPad. Eventually we want to be able to customize the UI per customer (tenant) and maybe even per user (of that customer). We started off in HTML5 but are moving to native.
I've done some reading on downloading XML from the server (or even generated XIB/NIB files) and dynamically adding those to your app.
Now with iOS 5 (and even further in 6) storyboarding is playing a big role.
My questions:
- Would it be better to use (multiple?) storyboards or XIBs?
- What are my options for both if I want to deliver a dynamic user interface?
I'm not looking for a magic pill, nor a discussion on HTML5 vs native, just some information on how I could deliver a dynamic interface and what techniques could help in doing so.
my response to your two questions is:
storyboard is great for scene management; it creates a visual connection between
your various scenes/views. i prefer to use storyboard for as much of my UI as possible.
however, there are elements that i have in some apps that pick up existing or reusable
or otherwise dynamic XIBs. i simply tie these together with my storyboards by loading
the XIBs in code at the location at which i want them. so, my ultimate answer for your
first question is "both", where storyboards are used where possible, and XIBs used for
dynamic scenes/views.
your options for dynamic user interface include at least the following two options (of which, as stated above, i prefer the second):
create all code using XIB files, and perform all UI transitions without storyboards
in code
create as much UI as you know will remain relatively static in terms of relationships
between viewControllers with storyboard, and then load the dynamic parts of the UI
using initWithNibName:bundle:
finally, you can use multiple storyboards if the situation warrants, and this could even apply to dynamic UI, whether it comes from re-usable components created elsewhere in storyboard and maintained separately, or storyboard XML (if you look at storyboard source, it is just XML under the hood) whether acquired from something that generated or wherever. you can even decide to manage your UI with multiple storyboards at the design phase if your app will have several complicated interconnected view-controller scenes (e.g. each tab in a UITabBarController may have its own storyboard, where each storyboard's scene rootController is connected/loaded when a tab is chosen).
StoryBoard all the way! I use to absolutely dislike storyboards, but then i got use to them and now i love them. Storyboards are the way to go.
Layout seems a really powerful framework for developing dynamic GUIs on iOS.
DISCLAIMER: I'm not the author of that framework; the author is Nick Lockwood, who seems to have an account here on SO. I found both this question and Nick Lockwood's Layout framework by googling "ios dynamic gui".
I haven't tried it yet, but it looks really promising.
The project is even hosted at GitHub here, and it has a MIT license.