So, in Xcode Swift code, you simply drag a UI component to the text editor and create an IBOutlet like #IBOutlet weak var myLabel:UILabel
My questions are:
I read that IBOutlet resolve to nothing during compile time. It's only a keyword for Xcode itself. I assume Xcode generated some code when I drag the UI. So, where is the code and what does it look like?
Say, if I don't have Xcode, where/how should I write code to connect UI with it's behavior programmatically?
After all, is it possible to write, compile, deploy IOS projects without Xcode?
Thanks,
This related question answers about how to program in Xcode not using its storyboard by configuring Xcode.
True, IBOutlet doesn't do anything. In Objective-C this is defined as a macro and will be replaced by nothing while compiling. There is no special code. Interface Builder on the other hand sees this and allows connections for those properties to be configured. The information which outlet property is connected to which object then is saved in the nib file while compiling. After the system loaded all those objects it steps through the saved connection and sets the outlet properties to the appropriate objects using the regular setValue:forKey: mechanism.
You can see this in action if you implement a custom setter for one of your outlets and set a breakpoint on that.
All this is only necessary to support Interface Builder. If you don't use it you don't need the concept of outlets - you just keep references to the objects you need later after you created them.
The same thing also applies to IBAction. In Objective-C this is again defined to be void via a macro. Interface builder sees them and allows you to make connections there. While the nib files are loaded these are connected by sending the addTarget:action:forControlEvents: message to the control this action is connected to. If you don't use IB you can send this message yourself to make the connection.
Related
Prior to Xcode 11 I could easily attach a view (label, switch, e.t.c) to an IBOutlet defined on a superclass, if I had the inspector window open and command clicked to my view (In this case a subclass of a UITableViewCell subclass it would open the superclass in the inspector window and I could attach to the IBOutlet. In Xcode 11 however it seems that when command clicking through to the "definition" this opens in the LHS panel, which replaces my storyboard or xib file with the views superclass.
Is there any way to open the superclass alongside the xib/storyboard any more in Xcode 11? My framework is a pre-compiled framework so I can't access the source files to open them in a new panel in Xcode.
Thought it might be wise to include a class hierarchy
LargeHeaderTableViewCell -> TableViewCell -> UITableViewCell
TableViewCell is within a pre-compiled framework (Installed using Carthage)
Edit:
To frustrate matters further... I can get the class definition of TableViewCell open next to my xib file (In a panel), however it seems you can only attach to IBOutlets in the assistant editor, not in a standard Xcode panel/tab/whatever you call it.
Found an answer (eventually) in here
I realize that this question was posted a while ago, but since I just
struggled with the same issue and finally came up with a solution, I
figured I would still post my findings...
I understand the problem to be as follows (at least that's the one I
solved):
How to have class A inherit from class B, with each class having its
own XIB file with the some common IBOutlet properties? The goal being
to be able to have the super class handle the actions related to the
IBOutlets that are common to its subclass(es), while still being able
to use Interface Builder to design the interface for the
subclass(es).*
In order to do so:
Make the IBOutlet connections in the superclass from the superclass'
XIB files Make the IBOutlet connections in the subclass from the
subclass' XIB files, with the same IBOutlet property names as in the
superclass for the ones you need to inherit. Delete the declaration of
the IBOutlet variables in the subclass
It's a well known feature in XCode that we can hold control an object from interface builder to swift file to make a connection..
Is there any shortcut to make the connecttion by default an action instead of outlet ...? this is useful when dragging UIButtons.
Regarding custom shortcuts, As far as i heard. Probably No.
Many developers have had this problem. fortunately Xcode 10 is here to help! Now, if you command-drag above the first function, it'll default as an outlet. Below the first function, the default is an action. Brilliant!
I'm looking for a solution specifically for the issue with a Swift3 UIViewController having IBOutlets defined, but dragging actions from storyboard does not connect them to existing outlets. I can add new outlets, just with different name, and they work (still cant re-connect them later).
I see old solutions for objective-C dealing with headers and source files, but a swift is a single file per class.
Is there a way to fix "can't connect IBOutlet to swift file" issue?
but dragging actions from storyboard does not connect them to existing outlets
I've noticed this too. But it's not a difficult problem. Here's what to do:
Look carefully at the gutter next to the outlet in the code. There is a circle. Drag from that circle (no need for control-drag) to the view in the Interface Builder canvas.
I'm new to programming, and I'm trying to understand this concept in Swift IOS. What are the benefits of HAVING to use IBaction and IBoutlet to connect things like UIButtons and UILabels to my code?
Why don't they just let us set UI objects equal to a name like button1 or label1 so we can use those names to call and mutate them in my code?
You don't. IBAction and IBOutlet is how storyboard and xib files created with Interface Builder (IB) link to the implementation files when unarchiving the XML dictionaries of the nibs. However, creating views and controllers with layouts in code is entirely permitted and even a common pattern for project management in teams.
Personally, I do like using Interface Builder for the visual aspect of laying out my views, and it helps reduce the size of my controller files because it allows me to put my layout and color settings into Storyboards and xibs. But, some developers will argue this is actually a drawback, since it obfuscates some of the functionality of your controllers from the uninitiated. There are strong arguments for avoiding the use of Interface Builder when working in teams, but it really boils down to strategy and preference.
They're just tags Xcode uses to link the code and the storyboard / XIB. Functionally they do nothing. They help you as the developer to know what is / isn't / can / can't be connected between the visual representation of your UI and the code driving it.
I downloaded a project from GitHub and I'm experiencing some problems when detecting where a referencing outlet comes from.
This is an UIImage called "backgroundImage".
This is a UIViewController called "WalkthroughPageContentViewController".
"backgroundImages" has two outlets references, one of which is connected to the "WalkthroughPageContentViewController" UIViewController.
But there isn't any #IBOutlet connection here.
So where does the first referencing outlet come from?
I had a quick look at this project, and the answer is that the referencing outlet doesn't come from anywhere. It's broken. If you examine the destination, the you'll see that Xcode knows this is a problem:
And if you open up the WalkthroughPageContentViewController.swift file, and add an outlet called backgroundImage, then close and reopen the file, you'll find it's magically been linked back up to the Storyboard:
So, I'd surmise that at some point, there was an outlet in the file called backgroundImage, which was hooked up to the Storyboard, but then it was later deleted, leaving the project in this state.
This is pretty common when editing projects in Xcode. The Storyboard connections are basically just stored in XML in the .xib file, and there's no magic two-way connection between them and the code at design time, so if you delete the lines of code that they point to, you'll end up in this state.