I just updated my Xcode to 8.2.1 and migrated my swift codes from 2.2 to 3.0.
After that, I ran into a situation that my top-most view controller was covered by a view (for more detail, please click to see the screenshot of Xcode debug hierarchy view), which never appeared when swift 2.2 was used. The top most VC is a DrawerController from https://cocoapods.org/pods/DrawerController, and is updated to the last version.
Because every touch event was received by the strange view, my app can't
work normally.
Is there any potential reason to make the view there?
Or is there any way to find out where the view come from?
If more information is needed, please let me know.
Thank you in advance.
For lack of reputation, I can't comment.
Have you ever tried to delete this "strange view"? Or just move it on top the UIView that contains your drawer?
I resolved this problem.
In my original codes, I subclassed DrawerController (say, MyDrawerController) and assigned the property centerViewController (the main page shown to the user in DrawerController) in the overrided viewDidLoad() in MyDrawerController. As a result, I ran into the trouble as described in my question above.
What I do to resolve the problem is make a main queue and move the codes which assigning the property centerViewController to the block of the main queue. (Codes of "BEFORE" and "AFTER" like bellow.)
Then, the problem was solved.
Don't know why the "BEFORE" codes worked fine in Swift 2.2 but failed in Swift 3.3. Could anyone tell the difference?
Thanks for your helping.
BEFORE:
class MyDrawerController: DrawerController {
override func viewDidLoad() {
self.centerViewController = aViewControllerInstant
}
}
AFTER:
class MyDrawerController: DrawerController {
override func viewDidLoad() {
DispatchQueue.main.async {
self.centerViewController = aViewControllerInstant
}
}
}
Related
I'm working on an app to have a split view and so far it's working fine, but it's not possible to set the width of the master controller using preferredPrimaryColumnWidthFraction. Another screen in the app already contains a split view and there it's working fine to set the width using the preferredPrimaryColumnWidthFraction (this screen has been built some time back) and when comparing both screens I can't find any difference in the storyboards that would explain this behaviour.
The basic setup in the storyboard is the following:
The controller in the top right is the HelpMenuController:
import Foundation
class HelpMenuController: UITableViewController {
override func viewDidLoad() {
super.viewDidLoad()
self.splitViewController?.preferredPrimaryColumnWidthFraction = 0.3
}
...
}
For the other screen, the call to set the preferredPrimaryColumnWidthFraction happens as well in the viewDidLoad method of the corresponding MasterViewController. Everything seems to be identical, yet for one split view it's working, for the other split view it isn't.
I also tested it by using a customized UISplitViewController and set the preferredPrimaryColumnWidthFraction in it's viewDidLoad method, but this approach didn't work.
Running out of ideas what could cause this issue - did anyone also experience this issue or has an idea about it?
Albert Einstein:
The definition of insanity is doing the same thing over and over and expecting different results.
Sometimes I have the impression for software development it's the other way around: Insanity is doing the same thing over and over again and expecting the same results.
Or in other words: Same same but different.
Okay, so after reading the documentation about UISplitViewController again, I found a solution:
class HelpMenuController : UITableViewController {
override func viewDidLoad() {
super.viewDidLoad()
self.splitViewController?.preferredPrimaryColumnWidthFraction= 0.3
self.splitViewController?.maximumPrimaryColumnWidth = 0.3 * UIScreen.main.bounds.width
}
...
}
For a yet unknown reason to me, the maximum width had to be increased to the desired value for this screen and for the other screen this had not to be done.
I'm just a beginner in Swift coding. My idea is quite simple which is an app with two buttons. When clicked, a textfield will change its text.
In the Main.StoryBoard, I add a textfield and two buttons.
In ViewController.swift file. I write as this:
import UIKit
class ViewController: UIViewController {
#IBOutlet weak var textfield: UITextField!
#IBOutlet weak var button: UIButton!
#IBOutlet weak var button2: UIButton!
#IBAction func action1(_ sender: UIButton) {
textfield.text="you just clicked on button1"
}
#IBAction func action2(_ sender: UIButton) {
textfield.text="you just clicked on button2"
}
}
It is supposed to be all right. However, an error appears which shows:
thread1:signal SIGABRT
in file AppDelegate.swift line:
class AppDelegate: UIResponder, UIApplicationDelegate
What is wrong with my code?
You get a SIGABRT error whenever you have a disconnected outlet. Click on your view controller in the storyboard and go to connections in the side panel (the arrow symbol). See if you have an extra outlet there, a duplicate, or an extra one that's not connected. If it's not that then maybe you haven't connected your outlets to your code correctly.
Just remember that SIGABRT happens when you are trying to call an outlet (button, view, textfield, etc) that isn't there.
For me it wasn't an outlet. I solved the problem by going to the error And reading what it said. (Also Noob..)
This was the error:
And The solution was here:
Just scroll up in the output and the error will be revealed.
To solve the problem, first clean the project and then rebuild.
To clean the project, go to MenuBar: Product -> Clean
Then to rebuild the project, just click the Run button as usual.
A common reason for this type of error is that you might have changed the name of your IBOutlet or IBAction you can simply check this by going to source code.
Click on the main.storyboard and then select open as
and then select source code
source code will open
and then check whether there is the name of the iboutlet or ibaction that you have changed , if there is then select the part and delete it and then again create iboutlet or ibaction.
This should resolve your problem
In my case I wasn't getting error just the crash in the AppDelegate and I had to uncheck the next option: OS_ACTIVITY_MODE then I could get the real crash reason in my .xib file
Hope this can help you too :)
I had the same problem. I made a button in the storyboard and connected it to the ViewController, and then later on deleted the button. So the connection was still there, but the button was not, and so I got the same error as you.
To Fix:
Go to the connection inspector (the arrow in the top right corner, in your storyboard), and delete any unused connections.
If you run into this in Xcode 10 you will have to clean before build. Or, switch to the legacy build system. File -> Workspace Settings... -> Build System: Legacy Build System.
This is a very common error and can happen for multiple reasons. The most common is when an IBOUTLET/IBACTION connected to a view controller in the storyboard is deleted from the swift file but not from the storyboard. If this is not the case, use the log in the bottom toolbar to find out what the error is and diagnose it. You can use breakpoints and debugging to aid you in finding the error.
To find out how to fix the error please use this article that I found on Google: https://rayaans.com/fixing-the-notorious-sigabrt-error-in-xcode
In my case there was no log whatsoever.
My mistake was to push a view controller in a navigation stack that was already part of the navigation stack.
Sometimes it also happens when the function need to be executed in main thread only, so you can fix it by assigning it to the main thread as follows :-
DispatchQueue.main.async{
your code here
}
For me, This error was because i had a prepare segue step that wasn't applicable to the segue that was being done.
long story:
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
let gosetup = segue.destination as! Update
gosetup.wherefrom = updatestring
}
This was being done to all segue when it was only for one. So i create a boolean and placed the gosetup inside it.
In my case, I was using RxSwift for performing search.
I had extensively kept using a shared instance of a particular class inside the onNext method, which probably made it inaccessible (Mutex).
Make sure that such instances are handled carefully only when absolutely necessary.
In my case, I made use of a couple of variables beforehand to safely (and sequentially) store the return values of the shared instance's methods, and reused them inside onNext block.
I had the same problem. In my case I just overwrote the file
GoogleService-Info.plist
on that path:
Platform\ios\YOUR_APP_NAME\Resources\Resources
In my case the files were present without data.
If this crash occurs when accessing a view controller within a package you may have to remove the Class and Storyboard ID from the view controller within the package and then add them again, run the project and the view controller should be found
I have a pretty simple app, with a couple of view controllers. There is a MKMapView in the second view controller. It is set up correctly, and functions fine. The problem is, each time I load its view the Memory usage jumps ~30mb, and never goes back down, so each time i go into the view it keeps jumping and eventually gets super high.
I tried removing the map view when i leave the controller like this:
override func viewWillDisappear(animated: Bool) {
map.removeFromSuperview()
}
but it doesn't have any effect on the memory. The map views delegate is set to its view controller.
I tried checking for leaks using Xcode instruments but didn't find anything.
Does anyone know how to fix this?
Thanks
EDIT:
Adding this seems to work:
func removeNastyMapMemory() {
map.mapType = MKMapType.Hybrid
map.delegate = nil
map.removeFromSuperview()
map = nil
}
override func viewWillDisappear(animated: Bool) {
removeNastyMapMemory()
}
This is not Swift issue, is coming from Objective-C days. The possible ways to handle this issue is depending upon the situation and behavior of the app.
If you're using a Map for multiple times (or places), only create a single (shared) instance of it. Which you can use it whenever you want.
Or If you're only using it for once, then try a solution from here, https://stackoverflow.com/a/25419783/1603234. This may help. Reduce little. But not all.
I am new to both iOS development and programming in general. I need some clarification as to what sort of things should be declared in the viewDidLoad function of a UIViewController subclass
Thanks
In order to properly understand what viewDidLoad does, you should understand the View Controller Lifecycle. The best point to start is reading the Apple Documentation, e.g. the learning guides for developing iOS Apps: https://developer.apple.com/library/prerelease/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/Lesson4.html
Declare elements that don't need to be refreshed or recreated when the view reloads. For instance, viewDidLoad is called only when it is created while viewDidAppear will be called every time the view is shown.
Read up on some apple docs.
Everything you write inside the viewDidLoad function will run the the View(which can be TableView, ViewController & more..) is loaded.
For example, if you got a label called 'label' and you want to set it's by the code so you type:
override func viewDidLoad() {
super.viewDidLoad()
label.text = String("any text here")
}
and then the text of the label will change when the View will load.
Recently I wrote some code where I tried to refer to an outlet on a UIViewController I'd just instantiated with [storyboard instantiateViewControllerWithIdentifier] and modify the subview that the outlet pointed to before presenting the ViewController. It didn't work because the ViewController's view hadn't loaded its subviews yet, including the one that my outlet referred to, so the property just gave me a null pointer.
After (with some struggle) tracking down the cause of my issue in the debugger, I Googled around and learned, through answers like this one, that I can cause the view to load its subviews without being displayed by calling the myViewController.view getter. After that, I can access my outlet without any problems.
It's a clear hack, though, and Xcode - quite rightly - doesn't like it, and angrily protests with this warning:
Property access result unused - getters should not be used for side effects
Is there a non-hacky alternative way to do this that doesn't involved abusing the .view getter? Alternatively, are there canonical/idiomatic patterns for this scenario involving something like dynamically adding a handler to be called as soon as the subviews are loaded?
Or is the standard solution just to replace myViewController.view with [myViewController view] to shut up Xcode's warning, and then live with the hack?
On iOS 9 or newer, one can use:
viewController.loadViewIfNeeded()
Docs: https://developer.apple.com/reference/uikit/uiviewcontroller/1621446-loadviewifneeded
I agree that forcing a view to load should be avoided but I ran into a case where it seemed the only reasonable solution to a problem (popping a UINavigationController containing a UISearchController that had yet to be invoked causes a nasty console says warning).
What I did was use new iOS9 API loadViewIfNeeded and for pre-iOS9 used viewController.view.alpha = 1.0. Of course a good comment above this code will prevent you (or someone else) removing this code later thinking it is unneeded.
The fact that Apple is now providing this API signals it can be needed from time to time.
Not sure how much cleaner this way, but it still works fine:
_ = vc.view
UPD: for your convenience, you can declare extension like below:
extension UIViewController {
func preloadView() {
let _ = view
}
}
You can read explaination by following URL: https://www.natashatherobot.com/ios-testing-view-controllers-swift/
merged Rudolph/Swany answers for pre ios9 deployment targets
if #available(iOS 9.0, *) {
loadViewIfNeeded()
}
else {
// _ = self.view works but some Swift compiler genius could optimize what seems like a noop out
// hence this perversion from this recipe http://stackoverflow.com/questions/17279604/clean-way-to-force-view-to-load-subviews-early
view.alpha = 1
}
If I understand you correctly, I think there's another fairly standard solution: move the outlet modification/configuration code into a viewDidLoad method (of the recently instantiated VC).
The topic is also discussed in this question.
It would require some restructuring, but it might give you a "cleaner" design in terms of MVC if your incoming VC handled its own configuration, and it would avoid the "You should never call this method directly" stricture on loadView.
You can call [myViewController loadView] to explicitly load the view, instead of abusing the .view getter. The .view getter actually calls loadView if necessary when called.
It's still not a very nice solution, since the UIView Documentation's section on loadView explicitly instructs that
You should never call this method directly