To some this may sound like a daft question. I've searched around, and found little, mostly because I cannot find the appropriate search terms.
Here what I want to do is:
The application begins at view A.
View A launches view B, and view B launches view C.
Is their a way for view C to return directly back to A without dismissing itself and thus exposing B. For example a main menu button.
You can call popToRootViewControllerAnimated: if you have a UINavigationController. If you specify NO to animate it, then it will just jump back to the root without showing B first.
I have discovered a solution to my problem. Its a bit dirty, (and I''ll probably get shot down in flames for it) but works very well under tests and is very quick to implement. Here's how I did it.
In my app I have a Singleton class called GlobalVars (I use this for storing various global settings). This class holds a boolean called home_pressed and associated accessors (via synthesise). You could also store this value in the application delegate if you wish.
In every view controller with a main menu button, I wire the button to the homePressed IBAction method as follows. First setting the global homePressed boolean to YES, then dismissing the view controller in the usual way, but with NO animation.
-(IBAction) homePressed: (id) sender
{
[GlobalVars _instance].homePressed = YES;
[self dismissModalViewControllerAnimated: NO];
}//end homePressed
In every view controller except the main menu I implement the viewDidAppear method (which gets called when a view re-appears) as follows.
-(void) viewDidAppear: (Bool) animated
{
if ([GlobalVars _instance].homePressed == YES)
{
[self dismissModalViewController: NO];
}
else
{
//put normal view did appear code here/
}
}//end viewDidAppead
In the mainMenu view controller which is the root of the app, I set the global homePressed boolean to NO in its view did appear method as follows
-(void) viewDidAppear: (Bool) animated
{
if ([GlobalVars _instance].homePressed == YES)
{
[GlobalVars _instance].homePressed == NO;
}
else
{
//put normal view did appear code here/
}
}//end viewDidAppear
There, this enables me to go back to the root main menu of my app from any view further down the chain.
I was hoping to avoid this method, but its better than re-implementing my app which is what I'd have to do if I wanted use the UINavigationController solution.
Simple, took me 10 minutes to code in my 9 view app. :)
One final question I do have, would my solution be OK with the HIG?
Related
I'm calling a method from another controller, but for some reason it does not work. The NSLog works fine but myButton is not showing up.
First controller .h:
-(void) buttonChange;
First controller .m
-(void)buttonChange {
myButton.hidden=NO; //this is not getting executed
NSLog(#"it's working");
}
- (void)viewDidLoad{
myButton.hidden=YES; //initially hidden
//....other codes
}
Second controller:
FirstController *theButtonInstance = [[FirstController alloc] init];
[theButtonInstance buttonChange]; //all works fine when I call this, but button is not showing up
Place this line myButton.hidden=YES; in init method of FirstController.
You're creating your instance of FirstController, but viewDidLoad hasn't run yet. Then immediately, you're setting hidden to NO. Later, viewDidLoad will be called, and it will set hidden back to YES before the view appears. You have to wait until viewDidLoad is called before you can correctly set hidden, and it won't get called right at the creation of the controller. You could do something like:
[self performSelector:#selector(buttonChange) withObject:nil afterDelay:3.0] ;
To see your button not appear then appear 3 seconds later.
If you want to create a new instance of your FirstController (what you currently do like Undo already mentioned) you don´t have to call [theButtonInstance buttonChange]; but set theButtonInstance.myButton.hidden = NO; after you created the new instance of FirstController
You can create a BOOL property in FirstViewController.h. And set that property to NO before pushing the controller. After that go to the viewDidLoad method in FirstViewController and write the if condition whether to hide or show the button based on that property. Hope that works for you. Let me know if you need code for this.
I have a cameraViewController that is essentially a barcode scanner. I also have 3 view controllers (A, B and C) each with a button that lead to this cameraViewController.
When cameraViewController scans a barcode, it does the following:
if (self.detectionString != nil)
{
[self.delegate cameraViewController:self withCardNumber:self.detectionString];
[self.navigationController popViewControllerAnimated:YES ];
break;
}
It has a delegate and sends the detected string back to the previous/parent view controller.
All three viewControllers have the following methodimplemented:
#pragma mark - CameraViewControllerDelegate
- (void)cameraViewController:(CameraViewController *)cameraViewController withCardNumber:(NSString *)number
{
self.CardNumbertext.text = number ;
}
So both methods work with cameraViewController and viewControllerA. However, when the parentViewController is B or C, the cameraViewController still pops back to the right controller but the delegate function does not run. What am I doing wrong?
It's iffy to have just one instance of cameraViewController and three different view controllers that "fight over it" by each setting the cameraVC's delegate to themselves. I think it's a better use of system resources and better architecture if each of the A, B, C viewcontrollers responds to the button press by instantiating a new instance of CameraViewController and setting that instance's delegate to self. This should fix your issue and improve memory management/leak issues as well.
Post a notification to NSNotificationCenter, it's a much better solution to this problem :)
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/nsnotificationcenter_Class/Reference/Reference.html
If you want keep the current implementation then update the delegate when you are presenting ViewController A,B and C. From the way you described in the question seems like you need to do this in -(void)viewWillAppear or -(void)viewDidAppear. Or use the notification manager as the OP suggested or else use blocks.
I have a UIActivity subclass that creates its own activityViewController:
- (UIViewController *)activityViewController {
WSLInProgressViewController* progressView = [[[WSLInProgressViewController alloc] init] autorelease];
progressView.message = [NSString stringWithFormat:NSLocalizedString(#"Posting to %#...",#"Posting to..."),
self.activityType];
return progressView;
}
I've add a full repro on GitHub.
According to the documentation, you aren't supposed to dismiss this manually. Instead, the OS does that when you call activityDidFinish:. This works fine when ran on an iPhone.
When I say "works," this is the sequence of events that I'm expecting (and see on the iPhone):
Display the UIActivityViewController
User presses my custom activity
My view controller appears
I call activityDidFinish:
My custom view controller is dismissed
The UIActivityViewController is also dismissed
However, when I run this same code on the iPad Simulator -- the only difference being that I put the UIActivityViewController in a popup, as the documentation says you should -- the activityViewController never dismisses.
As I say, this is code wo/the popUP works on the iPhone and I have stepped through the code so I know that activityDidFinish: is getting called.
I found this Radar talking about the same problem in iOS6 beta 3, but it seems such fundamental functionality that I suspect a bug in my code rather than OS (also note that it works correctly with the Twitter and Facebook functionality!).
Am I missing something? Do I need to do something special in the activityViewController when it's run in a UIPopoverViewController? Is the "flow" supposed to be different on the iPad?
The automatic dismissal only appears to happen when your 'activity' controller is directly presented, not wrapped in anything. So just before showing the popup it's wrapped in, add a completion handler
activity.completionHandler = ^(NSString *activityType, BOOL completed){
[self.popup dismissPopoverAnimated:YES];
};
and you'll be good.
I see the question is quite old, but we've been debugging the same view-controller-not-dismissing issue here and I hope my answer will provide some additional details and a better solution than calling up -dismissPopoverAnimated: manually.
The documentation on the UIActivity is quite sparse and while it hints on the way an implementation should be structured, the question shows it's not so obvious as it could be.
The first thing you should notice is the documentation states you should not be dismissing the view controller manually in anyway. This actually holds true.
What the documentation doesn't say, and what comes as an observable thing when you come across debugging the non-dissmissing-view-controller issue, is iOS will call your -activityViewController method when it needs a reference to the subject view controller. As it turns out, probably only on iPad, iOS doesn't actually store the returned view controller instance anywhere in it's structures and then, when it wants to dismiss the view controller, it merely asks your -activityViewController for the object and then dismisses it. The view controller instantiated in the first call to the method (when it was shown) is thus never dismissed. Ouch. This is the cause of the issue.
How do we properly fix this?
Skimming the UIActivity docs further one may stumble accross the -prepareWithActivityItems: method. The particular hint lies along the following text:
If the implementation of your service requires displaying additional UI to the user, you can use this method to prepare your view controller object and make it available from the activityViewController method.
So, the idea is to instantiate your view controller in the -prepareWithActivityItems: method and tackle it into an instance variable. Then merely return the same instance from your -activityViewController method.
Given this, the view controller will be properly hidden after you call the -activityDidFinish: method w/o any further manual intervention.
Bingo.
NB! Digging this a bit further, the -prepareWithActivityItems: should not instantiate a new view controller each time it's called. If you have previously created one, you should merely re-use it. In our case it happily crashed if we didn't.
I hope this helps someone. :)
I had the same problem. It solved for me saving activityViewController as member and return stored controller. Activity return new object and dismiss invoked on new one.
- (UIViewController *)activityViewController {
if (!self.detaisController) {
// create detailsController
}
return self.detailsController;
}
I pass through the UIActivity to another view then call the following...
[myActivity activityDidFinish:YES];
This works on my device as well as in the simulator. Make sure you're not overriding the activityDidFinish method in your UIActivity .m file as I was doing previously. You can see the code i'm using here.
a workaround is to ask the calling ViewController to perform segue to your destination ViewController via - (void)performActivity although Apple does not recommend to do so.
For example:
- (void)performActivity
{
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
{
[self.delegate performSomething]; // (delegate is the calling VC)
[self activityDidFinish: YES];
}
}
- (UIViewController *)activityViewController
{
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone)
{
UIViewController* vc=XXX;
return vc;
}
else
{
return nil;
}
}
Do you use storyboards? Maybe in your iPad storyboard, the UIActivityIndicatorView doesn't have a check on "Hides When Stopped"?
Hope it helps!
So I had the same problem, I had a custom UIActivity with a custom activityViewController and when it was presented modally it would not dismiss not matter what I tried. The work around I choose to go with so that the experience remained the same to the user was to still use a custom UIActivity but give that activity a delegate. So in my UIActiviy subclass I have the following:
- (void)performActivity
{
if ([self.delegate respondsToSelector:#selector(showViewController)]) {
[self.delegate showViewController];
}
[self activityDidFinish:YES];
}
- (UIViewController *)activityViewController
{
return nil;
}
Then I make the view controller that shows the UIActivityViewController the delegate and it shows the view controller that you would otherwise show in activityViewController in the delegate method.
what about releasing at the end? Using non-arc project!
[progressView release];
Many Users have the same problem as u do! Another solution is:
UIActivityIndicatorView *progress= [[UIActivityIndicatorView alloc] initWithFrame:CGRectMake(125, 50, 30, 30)];
progress.activityIndicatorViewStyle = UIActivityIndicatorViewStyleWhiteLarge;
[alert addSubview:progress];
[progress startAnimating];
If you are using storyboard be sure that when u click on the activityind. "Hides When Stopped" is clicked!
Hope that helped...
I'm developing an app that needs to pick up a JPEG from a web site on start-up.
The splash screen displays, then the app attempts to get a web address from a file. If the file is missing I open a modal view (as UIModalPresentationFormSheet) that has a text view for the user to type in an address - the address is then saved to a file.
The user taps the OK button, and an attempt is made to get the JPEG. If the address was wrong, or the JPEG is not on the web server, the modal dialog must re-open so the user can change the web address to the correct one.
The splash screen view controller contains these methods:
- (void)openAddressDialog
{
serverView *viewController = [[serverView alloc]init];
[viewController setServerAddress:[businessLogic serverAddress]];
[viewController setDelegate:self];
[viewController setModalPresentationStyle:UIModalPresentationFormSheet];
[self presentModalViewController:viewController animated:YES];
}
Interestingly, when I called the openAddressDialog method from the viewDidLoad method the modal view did not appear. I had to move it to the viewDidAppear method. So presumably the view has to be in a particular state before it will entertain modal views.
- (void)closeDialog:(UIViewController *)dialogController:(Boolean)actionRequired
{
// If action required, get the server address from the dialog
if (actionRequired)
{
serverView *viewController = (serverView *)dialogController;
NSString *address = [[viewController serverAddress]copy];
[businessLogic setServerAddress:address];
[self dismissModalViewControllerAnimated:YES];
if (![logoImage image])
{
[logoImage setImage:[businessLogic eventLogo]];
if (![logoImage image])
{
[self openAddressDialog];
}
}
}
else
{
exit(0);
}
}
This is the delegate method called back from the modal view when the user has touched OK or Cancel. The actionRequired param indicates that OK was tapped. And if so, the new server address is picked up from the modal view, and the modal view is dismissed. An attempt is made to get the JPEG from the new address (in a business rules class), and if still no file can be found, the first method shown above (openAddressDialog) is called again so the user can correct the address again.
The modal view appears fine the first time, but will not reappear if the user entered the wrong address. Does this have something to do with me attempting to represent the modal view so quickly after dismissing it?
I'm quite new to iPad development, so would appreciate any advice.
One other thing, which demonstrates my inexperience of C++ perhaps, is ... if I declare a private method in the m file, let's call it
- (void) methodB
and that method calls another private method, let's call it
- (void) methodA
methodA must be defined earlier in the m file than methodB. If I also want methodA to call methodB I reach an impasse. The only way around that I am aware of is to declare methodB in the h file - which makes it public. How do I code this scenario so the outside world can see neither of the methods?
if use to create nib to serverView then do like this
serverView *viewController = [[serverView alloc]initWithNibName:#"serverView" bundle:nil];
I am working on an iOS app that uses a very common Core Data based tableview to display items and when one it selected, it shows a more detailed view, much like the Contacts app. The detail view itself is a programmatically generated grouped table with a custom (nib-defined) view for a header that has a picture and a name. Some of the cells in the table are custom cells that have a label name and a textbox value. In "edit" mode, the editable table cells (and the name in the header) have .clearButtonMode set to UITextFieldViewModeAlways to show that they are editable.
I am currently using the same view controller to display the detailed information, edit the information, and add a new record to the original list.
When a new item is being added, the view controller is created modally with a custom init overload that sets a flag in the view controller to indicate that it is adding the record. This allows it to start in edit mode and if edit mode is left, the model view is dropped away. The right menubar button is the usual Edit/Done, and the left one is a cancel button. When an existing item is being edited, the left button (normal back button) is replaced with a cancel button.
I am starting to have second thoughts as to whether or not having one view controller handle three different modes is the way to go. There are few issues that I am not sure how to handle.
1) How do I tell if edit mode is left by hitting "Done"? Is there an action for it? If cancel is hit, the action either dismisses itself (add mode) or restores the previous values leaves edit mode. I suppose I could put a check in my setEditing override to handle it, but it seems that there should be a better way.
2) When edit mode is entered and I set the editable text fields to UITextFieldViewModeAlways, is there a way to animate the appearance of the 'X' buttons so that they fade in with the editing indicators on the regular cells?
Are there easy solutions to these problems or is my 3-in-1 view controller a bad idea? It doesn't seem right to remake the same view for different modes, but having multiple modes for a view controller seems to be a bit of a hassle.
jorj
I like the 3-in-1 approach and use it all the time. There are lots of advantages: one xib, one view controller, one simple protocol between the list and detail view controllers. Yes, there are a few more checks like if (self.editing) ... but I like that better than more view controllers and xibs.
To help with adding I expose a BOOL that the delegate can set.
#property (nonatomic) BOOL adding;
1) The built-in editButtonItem does not allow you to intercept it before setEditing:animated: This is problematic when you are doing data validation after Done is tapped. For that reason I rarely use editButtonItem and use my own Edit, Done, and Cancel buttons with their own action methods. See below.
2) For this I like UITableView's reloadSections:withRowAnimation. It might work in your case.
- (void)edit:(id)sender
{
self.editing = YES;
}
- (void)done:(id)sender
{
// data validation here
if (everythingChecksOut)
{
//save here
} else {
return; //something didn't validate
}
//if control reaches here all is good
//let the delegate know what happened...
if (self.adding) {
[self.delegate didFinishAddingWithData:self.yourData];
} else {
[self.delegate didFinishEditingWithData:self.yourData];
}
self.adding = NO;
self.editing = NO;
}
- (void)cancel:(id)sender
{
[self.view endEditing:YES]; //in theory, forces the view that is editing to resign first responder
//in practise I find it doesn't work with the YES parameter and I have to use my own flag
// roll back any changes here
self.editing = NO;
if (self.adding) //let the delegate know we cancelled the add...
{
[self.delegate didCancelAdd];
}
}
- (void)setEditing:(BOOL)editing animated:(BOOL)animated
{
[super setEditing:editing animated:animated];
//set your nav bar title
[self.tableview.editing = editing]; //you may or may not require this
[self.tableview reloadSections... withRowAnimation:yourChoice];
if (editing)
{
//install your Done and Cancel buttons
} else {
//remove Cancel and put the Edit button back
}
}
Then in viewDidLoad...
- (void)viewDidLoad
{
[super viewDidLoad];
//whatever else you do
if (self.adding)
{
self.editing = YES;
}
}
I haven't fully understood the questions you have raised, but here are some thoughts on structure which are probably more useful in the first instance...
It seems you are doing too much with a single UITableViewController and inevitably you will end up with lots of if statements and confusing code. I'd break it down into two separate UITableViewControllers, one to handle the main view (and any subsequent editing mode you require) and then another to handle the detail view. Either or both of these could then use nibs as you require.
Using two controllers like this will allow you to simply push the second detailViewController onto a navigation stack, rather than presenting it modally which doesn't seem like the obvious thing to do in this instance.
However, if you would prefer it to be presented modally, you could write a protocol for the detailView which sends messages in the event of 'Cancel', 'Edit' or 'Done' buttons being pushed. The first viewController could then implement the protocol and receive these events.
I hope that helps...