Here is what I am trying to do.
When I receive the push notification and I tap I want to show a specific screen in my app. I found a lot about it but I am having trouble due to the complexity of the structure of my application.
Here is how the app is structured:
LoginViewController
RevealViewController (https://github.com/John-Lluch/SWRevealViewController)
UITabbarController
NavigationController
ViewController (This is a table view)
DetailViewContorller
I want to pass some arguments to the DetailViewContorller so I can make sure I get the right results when opening the screen.
Here is the screenshot of my app structure
application Folow
With the following code in my AppDelegate:
let storyboard = UIStoryboard(name: "Main", bundle: nil)
let tb = storyboard.instantiateViewControllerWithIdentifier("TabBarVC") as! UITabBarController
tb.selectedIndex = 1
window?.rootViewController? = tb
I have managed to get to the tabbar when tapping on the notification but I am not happy with the results. I am still having the following issues:
the revealViewController is nil so I am not able to open my setting panel
I still don't get to the DetailViewController which is at the bottom of my view hierarchy
Any hint will be appreciated.
I had a similar issue although my flow was a bit different. I ended up handling Push Notification event (when user taps on it) and storing the object at the app delegate level. In each view controller that appeared after that (in ViewDidLoad() method) I would check for that object and figure out whether to redirect the flow to the next view controller. To help with this, my notifications had a type associated with them. Unfortunately, I was not able to find a better solution.
P.S. It also appears like you're instantiating View Controllers in code and I was using Storyboards. However, the basic idea is the same. I ended
#MK_Dev, Thanks for your suggestion but I was looking for something easier to manage.
This has actually helped me.
Get top most UIViewController
Here is what I did:
if var topControl = UIApplication.sharedApplication().keyWindow?.rootViewController {
while let presentedContreller = topControl.presentedViewController{
topControl = presentedContreller
}
if topControl.childViewControllers[0].isKindOfClass(MyCustomClassVC) {
// Check if the user is already on the VC we are trying to open
let chatController = topControl.childViewControllers[0] as! MyCustomClassVC
// ... any additional code you need to add here ...
}
}
Related
I am having a weird issue where my app crashes when I am trying to push a new view controller. I have set up a swipe gesture and want to segue to another view controller when a swipe is detected. When I run these 2 lines of code ...
let viewController:ViewController = ViewController()
self.navigationController?.pushViewController(viewController, animated: true)
The app crashes not specifically on either of those lines of code but rather in my ViewController class when in my viewDidLoad method I run this piece of code...
imageView.layer.masksToBounds = true
If I comment that out it crashes when I set the auto-correction type of my textField. What am I doing wrong?
First place I look when the view immediately crashes is in the Outlets for that ViewController in InterfaceBuilder. I look for anything that shows up with an exclamation mark. That usually means I renamed an outlet or broke a connection somehow. Delete anything broken by pressing the little x by the item that's messed up. I'll attach a photo so you can see.
It seems you're loading a ViewController that exists in storyboard with
let viewController:ViewController = ViewController()
which will result in nil outlets , so you have to use
let viewController = storyboard.instantiateViewController(withIdentifier: "VCID") as! ViewController
and give that vc a storyboard identifier like VCID
I think I have solved the issue but it has a weird side effect. Instead of using the line of code in #Sh_Khan's answer, I used ...
let viewController = nav?.storyboard!.instantiateViewController(withIdentifier: "mainVC") as! ViewController
The variable nav is equal to the navigation controller of the current view-controller. This seems to work without any hiccups but for some reason the back button does not disappear from the navigation controller after the segue is preformed. Does anybody know a solution to this, if so leave a comment and I will update my answer.
EDIT:
Another issue is that it wipes everything changed on that ViewController by the user clear. Is there another way to instantiate a ViewController without clearing it?
Follow what #Sh_Khan has said and in addition to that make sure that the view that you are making the push segue from is embedded in a Navigation controller.
I am having a few issues accessing the tab bar from the App Delegate to setup the Home Screen Quick Actions. Here is the line of code that I am using to access the tab bar. It is returning false.
guard let tabBarController = self.window?.rootViewController as? UITabBarController else {return false}
My tab bar is not my initial VC when the app launches. I have a loading screen during which we authenticate the user token and then it goes to either the login screen or the tab bar controller (which is also the main part of the app) depending on whether the token gets authenticated.
What is best practice for setting up an app with a login screen? The way we are doing it now works fine but I can change it if there is a better way. We are also using Branch for deep linking.
This is a opinion based question and might exist multiple answer to it each of which might be suitable for some specific scenario.
Approach 1 :
This is my personal Favorite does not mean that this is the only proper way of doing it. I prefer replacing the application's rootView Controller either with LoginVC or TabBarVC based on wether the token is valid or not. There are multiple answers in SO explaining how can u replace the application's rootVC with proper animation. Pasting the same code would be redundant here.
Why I use this approach?
Keeps my applications navigation controller stack clean and I don't keep any additional VC's in memory than whats actually required.
Approach 2 :
This is what many people use for the simplest reason that its simple to use but I personally doesn't prefer it. Modally present either Login VC or Tab bar (both of them might be embedded with UINavigationController obviously and you modally present their NavController's which obviously loads its embedded view controller).
Pros:
Easy to code.
You can always be sure that app's rootVC is always fixed and it has presented either LoginVC or TabBarVC. So parsing and accessing the VC's becomes fairly simple.
Cons:
The Landing VC which modally presents unnecessarily remains in Applications Navigation stack through out the apps life cycle. I clearly don't favor this.
EDIT :
As OP has clearly mentioned that he is using approach 2 and wants to know how to access specific VC in tab bars selected index am updating the code show the same.
Code is not intended for Copy paste, code might contain syntactic error. Code provided below is only intended for providing the idea.
Assuming your LandVC does not have UINavigationController embedded to it.
if let landVC = UIApplication.shared.keyWindow?.rootViewController {
if let presentedVC = landVC.presentedViewController {
if presentedVC is LoginVC {
//this is login VC
}
else if presentedVC is UITabBarController {
let currentlySelectedVC = (presentedVC as! UITabBarController).viewControllers?[(presentedVC as! UITabBarController).selectedIndex]
//now check what type VC it is and use it accordingly
}
}
}
I've got a serious problem with my iOS app.
I have a login logic in my application. When logging in and then logging out, some view controllers are not destructing. This causes some issues, for example, some events that I emit using NSNotifcationCenter are emitted few times. These issues are avoidable, but I really want a solution to avoid some view controllers to stay open in the background without me controlling it.
The way control the login logic is as follows:
In the app delegate start function, if the user is already logged in, I set the root view controller to the main usable view controller. Therefore, I'm not doing anything and the root view controller is set to the login view controller navigation controller through the storyboard.
When the user logs off, I use a modal segue to transition the view controller back to the login view controller navigation controller.
As you may understand I'm using storyboards, swift and the newest iOS.
My logout code is segue that take me to the LoginViewControler:
self.performSegueWithIdentifier("Logout", sender: self)
My app delegate code:
if (userDefaults.valueForKey("uid") != nil) {
let tabBarView = UIStoryboard(name: "Main", bundle: nil).instantiateViewControllerWithIdentifier("TabBarViewController") as! TabBarViewController
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
appDelegate.window?.rootViewController = tabBarView
}
What am I doing wrong?
I would appreciate help :)
EDIT
I even tried just setting the root view controller in the logout action and that didn’t help either. How’s that even possible?
This is how I do the logout now:
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
let newRootViewController = self.storyboard?.instantiateViewControllerWithIdentifier("LoginNavigationController") as! UINavigationController
appDelegate.window!.rootViewController = newRootViewController
Adam H. is right. If that doesn't work, then check for IBOutlets and delegates that have strong relationships, and change them to weak relationships. i.e.
#IBOutlet weak var collectionView: UICollectionView!
Without the weak keyword the view controller will never be disposed.
Depending on how your project is setup, if you are using a navigation controller (which I recommend) every time someone logs out you would put
dispatch_async(dispatch_get_main_queue()) {
self.navigationController.popToRootViewControllerAnimated(true)
}
That will pop everything off the navigation stack, which will dispose of all view controllers (unless you have strong relations, then they won't be disposed)
No matter how you choose to manage your trasitions , don't forget to add/ remove the observer whenever the view controller apear/disappear.
If the logged in screen presents the login screen and the login screen presents the logged in screen then you will have a cycle that keeps piling on new view controllers. To solve this, one must not present the other, but unwind to it. Another possibility is to hold instances of each as singletons and only present those.
I implemented something like that not long ago and to me it seems you're abusing the UINavigationController life cycle.
After reading your question twice, if I understand it correctly, it seems you're initializing your login view controller as a UINavigationController which stacks-up view controllers. Once user logs out, you're keeping the stack, adding more ViewControllers to the stack using the performSegue.
You can avoid it by using two different scenes -
1) Login View Controller which stands by it self.
2) Main flow of your app - can start with UITabController/ UINavigationController, both or whatever.
In AppDelegate you check -
If user is logged in - do your logics and set the app rootVC to the main flow vc.
Otherwise you set the loginVC (UIViewController) to be the root.
This also allows you to pop the login VC anywhere in the main flow, when needed, without interfering with the main flow.
In your case the loginVC is always UINavigationController's root so you must popToRootVC every time you wish to see it or performSegue to it which is worse because then you create another instance of a UINavigationController and resources never get deallocated.
Obviously in programming, in most cases, there are many solutions to one problem. I'm sure your problem can be solved using your flow. I just think it's bad experience to stack a loginVC over a navigation controller.
Part of the problem is that setting a new rootViewController on the UIWindow doesn't remove the view hierarchy from the old root view controller. That leaves all sorts of strong references hanging around, and if you use Xcode's view debugging, you can see that the the old view hierarchy is still sitting there, behind the new rootViewController's view hierarchy.
Something like this should fix the problem for you and allow your view controllers to deinit:
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
let newRootViewController = self.storyboard?.instantiateViewControllerWithIdentifier("LoginNavigationController") as! UINavigationController
appDelegate.window??.rootViewController?.view.removeFromSuperview()
appDelegate.window??.rootViewController?.dismissViewControllerAnimated(false, completion: nil)
appDelegate.window??.rootViewController = newRootViewController
get rid of ARC file by file in build settings or wholesale
per project (it seems that you can have non ARC project but have weak references
while at it: not sporting I suppose but you can have both).
Then override retain and release in the problematic view controller
and see who hold the extra reference by breaking in the overriden
retain and release. It should be an eduficational experience.
The lazy approach is to kill ARC just for the VC in question.
I'd be curious to see how this works for VCs written in swift ;-)
Me thinks it's yet another reason to stay in objc domicile a while longer
until/if swift compiler and runtime solidifies (if ever).
Hope this helps anyone.
PS: It takes forever to compile some swift file in my project and I have NO
idea which swift file is causing this. Duh.
As yet indicated there aren't a lot informations for provide correctly the solution to your question.
I can suggest you to change your approach. I made a similar workflow using a UINavigationController (navigationController) launched from AppDelegate, inside of if we are logged in I put as ViewControllers :
(where self is navigationController and rootViewController is another UINavigationController)
self.setViewControllers[loginViewController, rootViewController]
If your are not logged in you put only loginViewController:
self.setViewControllers[loginViewController]
in this case you can put the rootViewController where the user is logged in.
This is my 2cent.
I like having a root VC which is just blank. When the app starts, root VC immediately displays login VC as a child VC of root VC. When the user successfully authenticates, the login VC notifies root VC, which then adds main VC as a child of root VC, transitions (with a nice animation) from login VC to main VC (using [self transitionFromViewController: toViewController: duration: options: animations: completion:]), and then removes login VC as a child and discards it. On logout, main VC notifies root VC which then does the same thing in reverse. So most of the time you only have either login VC or main VC instantiated; the only time they are both instantiated is during the transition.
I find segues are useful for building quick prototypes, but for production apps I prefer not to use them.
I Guess the ViewControllers Stack of you will go like this:
- 1st launch: LoginVC
- After login: LoginVC - TabarVC
- Click Logout: LoginVC - TabarVC - LoginVC
....
So your below code should work:
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
let newRootViewController = self.storyboard?.instantiateViewControllerWithIdentifier("LoginNavigationController") as! UINavigationController
appDelegate.window!.rootViewController = newRootViewController
but it's not:(. In my opinion, You should always let the tabarVC rootViewController. And check in TabarVC, if user is not loged-in or user pressed logout, Present loginVC and dismiss it instead of performSegue.
You must remove your :
self.performSegueWithIdentifier("Logout", sender: self)
Instead of it, you can overriding this segue method, this is enough:
override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
userDefaults.removeObjectForKey("uid")
if segue.identifier == "Logout" {
let newRootViewController = segue.destinationViewController
// newRootViewController is optional in case you want to pass vars
// do whatever you want with your newRootViewController
}
}
About your NSNotification there are two methods to remove it:
NSNotificationCenter.defaultCenter().removeObserver(self, name: "NotificationIdentifier", object: nil)
NSNotificationCenter.defaultCenter().removeObserver(self) // Remove from all notifications being observed
In Swift, you can put the removeObservers in the new and special deinit method.
I think my problem is best expressed by first giving an outline of what I'm trying to accomplish and then giving my implementation, followed by the problem I've ran into.
Goal
I'm attempting to make a profile page within my iOS app that can be instantiated from the Storyboard, given a user ID, and then fetch all the meta data from the server.
Implementation
In my storyboard, I have designed the ViewController and linked the ImageViews, buttons et cetera as #IBOutlets. The user's (person using the app.) homepage is instantiated by the Storyboard, but the rest are pushed in by code. In order to grab the data, I have a function loadDataForID(ID: Int)
Now, the problem I have is that #instantiateViewControllerWithIdentifier(String) returns a UIViewController that I cannot upcast to my ProfileViewController, in order to call the data fetching function.
So, my next thought was to manually create the ProfileViewController, call the helper function and then push the view, but then I ran into another problem: since all the views are #IBOutlets, and this controller wasn't instantiated by the Storyboard, they're all nil references.
As I'm new to iOS development, I'm almost certain there's a better way to implement this, but I'm completely stuck; I don't know where to go from here. Is there a way around these issues or should I do things a different way?
You can cast instantiateViewControllerWithIdentifier(String) as ProfileViewController as shown into below code:
let storyboard = UIStoryboard(name: "Main", bundle: nil)
let profileVC = storyboard.instantiateViewControllerWithIdentifier("ProfileViewControllerID") as! ProfileViewController
//Now you can access property of ProfileViewController here
self.presentViewController(profileVC, animated: true, completion: nil)
I upgraded my Swift app to Xcode 7 / Swift 2.0 and now suddenly certain segues in my app no longer work.
I have a segue popping up a "Check In" modal and it works perfectly, but then I have another segue popping up a "Check Out" modal that's near identical and it doesn't launch and the app is frozen.
I re-created the segue from scratch, confirmed that it is identical to the "Check In" one, and it still doesn't work.
I also, instead, tried launching a blank view instead of my Check Out modal and it works fine.
There are no errors, it just freezes, I did confirm that the "prepareForSegue" portion is being called correctly but the "viewDidLoad" portion of my modal is not being invoked.
FYI, I have auto-layout turned off.
Does your "Check Out" modal have a UITextView? If it does, then there's a bug in Xcode 7 / iOS9 where you cannot launch a modal (or any root view) that contains a UITextView if you have set a default text value in storyboard.
A work around is to make sure your UITextView in storyboard is either blank or has the default Lorem Ipsem value and instead, set the text programmatically in code on viewDidLoad.
Hopefully this bug will be fixed soon.
I suspect there is infinite loop somewhere in you "Check Out" controller code. Try pausing app in debugger after presenting controller (when it freezes) and check stacktrace. If it doesn't help, try commenting-out code line-by-line in viewDidLoad and viewWillAppear to find line causing freeze.
I had this problem, try with this
dispatch_async(dispatch_get_main_queue(), { () -> Void in
let viewController:UIViewController = UIStoryboard(name: "Main", bundle: nil).instantiateViewControllerWithIdentifier("Storyboard Id")
self.presentViewController(viewController, animated: true, completion: nil)
})
You just have to give a storyboard id in your view and normally it's working.
My app was working perfectly in iOS8. Its flow was:
VC: View Controller, NVC: Navigation View Controller, ER: Embedded root relationship between NVC and VC, PS: Push Segue, PG: Programmatic presentation
NVC1---(ER)->VC1---(PS)->NVC2---(ER)->VC2 and so on.
The problem was that VC1-(PS)->NVC2 segue did not work, there was no freeze. vc1.prepareForSegue() was executed, but VC2 was not presented. I experimented and found that I did not have the UITextView problem mentioned here.
By following the breadcrumbs outlined below, I got it work after hours of trying in the following way (code at the end):
NVC1---(ER)->VC1---(PG)->VC2
Here are the steps:
As mentioned in Segue issue in iOS9, multiple NVCs are out of style (shame on Apple for suddenly ditching what is actually recommended in your online tutorial and making apps break!). So I modified
NVC1---(ER)->VC1--(PS)->VC2 while VC2 was still embedded in NVC2. I got errors
similar to the StackOverflow post on view not in hierarchy. So I started doing the transition programmatically and after tackling present vs. push ViewController issue that results in "tried to push modally on active view controller" message and then ViewController lifecycle issues that result in "Unbalanced calls to begin/end appearance transactions" messages, I got the following code working. Based on this experience, I really think Apple should have left a working thing alone in Xcode7/iOS9 update.
//*********** VC1.swift. A translation of working code
class VC1:UIViewController{
private var viewController2:VC2?
private var showVC2: Bool = false
override func viewWillAppear(animated: Bool) {
super.viewWillAppear(animated)
if(showVC2) {
showVC2 = false
self.pushVC2()
}
}//viewWillAppear
private var info:String? // info from incoming user action.
#IBAction unwindToVC1FromUserAction(incomingSegue: UIStoryboardSegue?) {
// Do app-specific stuff to get info from incomingSegue and
// store in self.info variables.
let myboard: UIStoryBoard = self.storyboard!;
self.viewController2 = myboard.instantiateViewControllerWithIdentifier(
"VC2 Storyboard ID") as! VC2
self.prepareVC2() // Pass info to VC2.info, stuff you would have done in prepareForSegue
showVC2= true
} //unwind
private func prepareVC2() {
self.viewController2.info = self.info // etc..
}
private func pushVC2() {
self.navigationController!.pushViewController(viewController2!, animated:false)
}
} //class
I had this, but it was none of the above. My segue call happened to be inside a block. When I moved the call to the main thread I saw that I had a 'NSUnknownKeyException' error in the new View Controller. Being inside the block seemed to prevent the error from registering in Xcode, so the app just appeared to hang without any errors.
Once that was resolved the original code worked fine.