I have seen many examples of how to add a SwiftUI view into a UIKit view using Container Views, which assume you have access to the parent UIViewController on the UIKit side. I have a case where I can't do that; specifically, I want to add a SwiftUI view to the MKAnnotationView's detailCalloutAccessoryView, where I just have a UIView to attach to, but no parent UIViewController in UIKit. What should I do in this case?
When looking around, I found a (seemingly) compelling answer: https://github.com/khuffie/swiftui-mapkit-callout
In this solution, you create a UIView from scratch, then create a UIHostingController with the SwiftUI view, and add the UIHostingController's view to the top-level UIView (with auto-layout constraints), and just return the top UIView, without having to do anything with container views (like call didMoveToParentView). And it works, in that it displays the SwiftUI view correctly inside the annotationView callout. BUT when the map is dragged around, the callout view seems to move with it (the UIHostingView from the view debugger), but the underlying SwiftUI view doesn't actually move along with it, so if you have buttons on that SwiftUI view, you can't tap them at the place where they appear.
It's a little strange. This is what I see in the view debugger ... first, with the 'HostingView' selected:
Then selecting the actual SwiftUI View (which doesn't show on screen, but is where all the subviews and tap targets are):
BTW, it can be reproduced with the sample code on the repository itself. When you run the sample app, open the callout button, then drag the map around, then inspect it with the view debugger.
I've created an issue for this at the repository: https://github.com/khuffie/swiftui-mapkit-callout/issues/1
I'm wondering if this issue is happening because the UIHostingController doesn't get added to any parent view controller? Is that a hard requirement that isn't being fulfilled here, or can it work otherwise? Are there any other solutions for this I can try? I've tried doing this without SwiftUI, making a UIView with a subview with buttons on it using Interface Builder, and that view behaves correctly as expected, so I'm guessing there's something about the interface between UIKit and SwiftUI that is messing up. Is there a better way to set that up for this case, where we don't have access to a UIViewController on the UIKit side?
Related
(I have read other questions and answers on this topic, but most are very old and do not relate to iOS 9 or 10.)
The app design calls for the top half of the display to always contain the same content. (An image being edited by the user.)
The bottom half of the display needs a UITableView. When a UITableViewCell is tapped, the bottom section needs to transition to a new UIViewController with slide-on animation, similar to how UINavigationController push segues work.
Problem: only the bottom view needs to transition to the new view controller(s), and back again. The upper half of the view hierarchy needs to remain unaffected. For this reason, I can't place everything inside a UINavigationController, and I can't have a UINavigationBar at the top of the screen.
Question: what approach should I take in such a situation, where I need only one UIView hierarchy to transition in push-segue fashion, but not anything else? Thanks.
Edited with Solution
Solution follows, for those following along at home.
Yes, you can actually use a UINavigationController for the bottom half.
If you are using Storyboards, the easiest way to do this is to use a container view for each part of the screen which you then can embed a UIViewController in for the top part and a UINavigationController in for the bottom part. If you are doing this programmatically, just add the view controllers as child view controllers to your app's initial view controller (see this answer for more info) which is essentially what the Storyboard will do for you automatically when using a container view.
As a child view controller, the UINavigationController will act independently from the top UIViewController and should behave as expected.
I recommend the programatic approach for the following reasons:
It helps you understand the inner workings of child/parent view controllers much better which will likely save you a significant amount of debugging time down the line.
It makes adding/removing/swapping child view controllers as simple as a few lines of code. Trying to do this with Storyboards is notoriously hacky and cumbersome.
It's much easier to keep track of changes using GIT (most mid-size/larger companies actually prohibit Storyboards for this very reason)
If you want change in part of the screen you can use container view. For details refer Swift - How to link two view controllers into one container view and switch between them using segmented control?
You can use multiple view in one view controller and can give animation like push or pop to show or hide it.
Second approach is you can use Container View which will give exact effect like navigation stack.
I am having a hard time understanding why you can put UIViews outside the UIViewController on the storyboard, and what the use case of it might be.
For instance, on the storyboard I can add UIToolbar, UIAcitivtyIndicator and UIProgressView that is outside of the UIViewController. Is this mean there is a way for you to reference those Views that are outside UIViewController and potentially display them somehow either programmatically or embed those like you would do with a ContainerView?
Yes, it absolutely is possible to do what you're describing!
When you add objects that are outside the view controller, they appear in what Apple calls the "Scene Dock". Apple has the following suggested usage for the scene dock:
If a view is not part of the main view hierarchy — such as a pop-up
menu — add the view to the scene dock. In a running app, the system adds
and removes these kind of views from the view hierarchy when they are
opened and closed.
The steps to make this work are below:
Open the storyboard.
Open the utilities area for the workspace window by clicking the
utilities button in the
toolbar.
In the utilities area, select the Object library by clicking the Object Library button in the library bar.
On the storyboard, select the scene to which you will add the extra view.
Drag a view class object from the object library into the the scene dock.
And importantly...
The added view is a part of the view controller. It will be
instantiated along with the rest of the views. You can attach the view
to a property of the view controller that has an IBOutlet. You can add
more than one view to the scene dock.
(These steps were originally copied from here - unfortunately this page seems to have been deleted by Apple at some point).
I have been using this:
UIApplication.sharedApplication().keyWindow?.rootViewController!.view.addSubview(self.customView)
To add a modal view over all the views in the view hierarchy in app.
But this is giving me problem. It adds subview as expected sometimes but sometimes it doesn't' work.
In what case this wont work and what's the best way to add modal view in view hierarchy like UIAlertView.
Depending on what's happening, there can be more than one UIWindow at a time - for example, if a system alert shows up, you will have two separate windows (one for your view controller, one for the alert itself).
A similar example can be made for the system keyboard. If the keyboard has focus, that will be your keyWindow.
A way of making sure you are adding the subview on top of all windows, could be: UIApplication.sharedApplication().windows.last?.addSubview(yourSubView).
I've also seen people using the application delegate, with: UIApplication.sharedApplication().delegate?.window.
Our app has some upper view, that is visible all the time.
This bar has a UITextField, UIButtons, side scroller, and segment control, and they are dynamic.
When you hit them, the view behind them(full screen) is changing.
I was thinking about navigation control, or tab bar, but seems that they can't have a text field and a scroller on them.
So my main thought was to create some COSTUM view of my own.
Question is , how can I create a view in storyboard, and add it as a constant view, than create some other views(+viewcontrollers) that will be changed according to that upper bar?
I want to create 5 views in storyboard, and switch between them according to the bar.
Sounds like a job for a containment view controller to me. I've used technique many times to both create a set of static controls on the screen which you describe and inject reusable content into an app in several locations.
The basic concept is:
Setup you Heads Up Display(HUD) with all the UI you want (this will be your base UIViewController).
Create a UIView in it and call it your contentView or something of the like. This is where all your dynamic content will appear.
Then your backing view controller adds another UIViewController as a child and tell it to show it's view in the contentView you specified.
Your view controller continues to remove and add children putting their content into the contentView as needed.
If you are unfamiliar with the technique there are many tutorials(by NSCookbook) of do a web search for "view controller containment tutorial". There is also a good WWDC (2011) video introducing the concept Session 102 - Implementing UIViewController Containment.
I have created and drawn out a custom UIViewController called AutocompleteVC in my Main storyboard. AutocompleteVC will be used in several different places/storyboards and with different dimensions.
For example, in my Transit storyboard, shown below,, there is a custom UIViewController called TransitVC, shown on the left. In TransitVC, I have a container view with an IBOutlet called autocompleteContainerView. autocompleteContainerView has a segue called autocompleteEmbedSegue to a generic UIViewController, shown on the right in red.
The goal is to have TransitVC hold AutocompleteVC inside autocompleteContainerView. But I'm having trouble getting this to work. The reason I want to do this inside a container view is so I can use autolayout to set constraints on it. Otherwise, I know how to do this purely in code.
I believe my approach might be flawed. What is the correct approach to do this if I want to maximize storyboard usage.
I'm not sure what you are asking. Setting up a parent/child relationship with a container view is very easy, exactly as you have outlined. Just create a container view inside the parent view controller, create the child view controller scene, and then control-drag from the container view to the child view controller to create the embed segue.