I want to have the virtual keyboard appear in my view on load and I want it to say visible for the lifetime of the view. There is a text field and I treat as the primary control for this view.
Initially, I called [self.textField becomeFirstResponder] in -viewWillAppear: following advice I've gotten here. Then, I came up with a different idea: I overloaded UIViewController's -becomeFirstResponder.
- (BOOL)becomeFirstResponder
{
if (self.primeResponder)
return [self.primeResponder becomeFirstResponder];
return [super becomeFirstResponder];
}
I'm not seeing any hidden problems with this, but then again, no one recommends it either. Am I missing something? Is this a bad approach? Please help.
In reviewing my old question, I thought now would be a good time provide an answer to this.
It works and does not have any major drawbacks.
I've had good luck with this method except in a peculiar circumstance. I used this to set a text field in a table view cell as the prime responder. In iOS 6, it didn't load the keyboard or highlight the textfield when the view was pushed onto the navigation controller stack.
See In iOS 6, -[UITextField becomeFirstResponder] doesn't work in -viewWillAppear: for my solution to that problem.
Related
We have a search bar in the table header. When the user taps on it twice quickly on iOS 7, it disappears. Does anyone have any suggestions what we are doing wrong?
After lots of trial and errors, I found that when searchDisplayController ends search, searchbar gets disappear, so I have reinserted the searchbar to table header and it worked for me.
- (void)searchDisplayControllerDidEndSearch:(UISearchDisplayController *)controller
{
self.searchingFetchedResultsController = nil;
if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_6_1) {
[self.tableView insertSubview:self.searchDisplayController.searchBar aboveSubview:self.tableView];
}
return;
}
Hope this helps.
(I posted this same answer to Troubles with UISearchBar \ UISearchDisplayViewController, which seems like a duplicate of this question.)
I encountered the same issue, and noticed that searchDisplayControllerDidEndSearch was being called twice. The first time, the superview of self.searchDisplayController.searchBar is the UITableView, and the second time it's still a UIView.
With Priya's answer, I worry about unintended consequences or unneeded overhead from re-inserting the subview every time the search bar is double-tapped, and I also worry about it breaking with future iOS versions. Fortunately, we can take advantage of the superview strangeness like this:
- (void)searchDisplayControllerDidEndSearch:(UISearchDisplayController *)controller {
if (self.tableView != self.searchDisplayController.searchBar.superview) {
[self.tableView insertSubview:self.searchDisplayController.searchBar aboveSubview:self.tableView];
}
}
If I had to guess what was happening, the UISearchBar is automatically creating a temporary UIView as its superview when it's active – this is the view seen when the search is being performed. While the UISearchBar is being dismissed, the superview gets set back to be the UITableView it had before, unless it gets dismissed so quickly that it was never properly initialized, in which case it cleans up improperly and the UITableView never gets the UISearchBar back as its child.
This solution still isn't ideal, and I think Apple must be doing something different in its own apps because their search bar UX feels a bit better. I think it would be better not to handle the second tap in the first place until the UISearchBar was ready. I tried using the other UISearchBarDelegate methods to do this, but I couldn't find an appropriate hook to override the current behavior.
I have looked at the sample generated by xcode when creating a new UISplitView app on the iPad along with countless other tutorials and the documentation from the apple developer site. I have not seen an example where the UISplitView used was not the root of the application. Is this even possible?
What I am trying to accomplish: I have a UITableView to start out and once an item in the list is selected I would like to display a splitview with two different sets of information that is based on the item that was selected.
I curious if this type of implementation is even possible, or just frowned upon, and why. If it is possible, how would I go about implementing and hooking up a UISplitView to behave in this way?
Edit: I'm updating this with what I have. I can now switch to my UISplitView, though the transition is not animated. What is the way to correctly switch to a UISplitView so the transition is animated?
Code for switching right now:
[appDelegate.window addSubview:appDelegate.splitViewController.view];
appDelegate.window.rootViewController = appDelegate.splitViewController;
EDIT 2: In hopes of bumping this back up so more people see it, I have managed to switch from my navigationController to my splitViewController, but when I add the button to be able to navigate back, nothing I do makes a difference and I seem to be locked in. I tried reverse mirroring the code to switch to the splitViewController, but that had no affect, and I am completely out of ideas. Can anyone shed some light on this?
You should always use SplitViewController as a rootViewController: Split view controller must be root view controller
There may be some hacks around it, but when Apple have a strong recommendation and design guidance, I suggest to try to re-think your design before going against the platform -it should save you effort in the long term.
I recommend using the MGSplitViewController, it also works as a non-rootViewController, even nested into an another MGSplitViewController, and there's i.e. a one-liner for the animation to blend in the Master-View, if that is what you want.
In your UITableView didSelectRowAtIndexPath method you would have something like:
UISplitViewController *mySplitView = [[UISplitViewController alloc] init];
[self.navigationController pushViewController:mySplitView animated:YES];
[mySplitView release];
Probably you'll want to subclass UISplitViewController just like you would other view controllers and set in there the master and detail views and so on.
I have a situation whereby I am adding a view from another viewcontroller to an existing viewcontroller. For example:
//set up loading page
self.myLoadingPage = [[LoadingPageViewController alloc]init ];
self.myLoadingPage.view.frame = self.view.bounds;
self.myLoadingPage.view.hidden = YES;
[self.view addSubview:self.myLoadingPage.view];
Is it possible to set 'self.myLoadingPage' to be the first responder? This is the case whereby the loadingpage view size does not cover the entire size of the existing view and users can still interact with the superview (which is not the desired behaviour). I want to just enable the subview in this case.
When I had a similar problem, I made an invisible UIView that covered the entire screen, I added the large invisible UIView on top of the main view and made the loading view a subview of the invisible UIView.
The simplest solution is to override hitTest method in your loading view to return TRUE. This top view is first in the responder chain, the hitTest method gets called which NORMALLY returns TRUE if the point is within the view and will therefore be handled, returning TRUE regardless means you get the touch event and effectively block the message being resent to the next responder.
Interesting question. I found a similar post with a quote from the Apple Developer Forums on this issue:
To truly make this view the only thing
on screen that can receive touches
you'd need to either add another view
over top of everything else to catch
the rest of the touches, or subclass a
view somewhere in your hierarchy (or
your UIWindow itself) and override
hitTest:withEvent: to always return
your text view when it's visible, or
to return nil for touches not in your
text view.
This would seem to indicate there isn't a terribly straightforward solution (unless there was an API change regarding this made after October, 2010.)
Alternatively, I suppose you could go through all the other subviews in your superview and individually set their userInteractionEnabled properties to NO (but that would probably prove more cumbersome than the quoted solutions).
I would love to see other ways to allow this.
my app has tabBarController with 3 views and in one of them I want to popup a web browser with the ability to return back to the application. To do that I am using UINavigationController.
In myAppDelegate.h I have defined the property UINavigationController *nav and in myAppDelegate.m I have #synthesize nav.
In the class where the webPopup function resides upon pressing the button my code comes to this function.
- (IBAction)showWeb:(id)sender {
myAppDelegate *app=[[UINavigationController alloc] initWIthRootViewController:self];
// because I want to return back to the same view
webController *web = [[webController alloc] initWithStyle:UITableViewStypeGrouped];
[app.nav pushViewController:web animated:YES];
app.nav.view.frame = CGRect(,0,320,430);
[self.view.window addSUbview:app.nav.view];
}
The web popup occurs but it is moved vertically, when I press "back button" my former view appears as well and it is also shifted vertically from what it was before.
After going back and forth few times the thing hangs.
Questions:
1. what can cause the shift?
2. how to avoid when I go "back" to see the title(test from the "back"button, I think this might cause a shift when I go back.
3. how to find out why it hangs after few attempt?
Thanks.
Victor
The line:
myAppDelegate *app=[[UINavigationController alloc] initWIthRootViewController:self];
makes no sense to me. Surely your compiler is warning you about that? What is "myAppDelegate" defined as? Classes should have a capital letter at the front, by the way.
Also, the line
[self.view.window addSUbview:app.nav.view];
is highly suspect, because the UIWindow for your application should have only one child UIView. You shouldn't just add more views willy nilly and expect things to work. It is possible to change the child UIView by removing the old one and adding a new one, but you don't seem to be doing that. Having more than one child UIView of UIWindow gets you into trouble very quickly -- for example, device orientation changing can break.
I'm not exactly clear as to why the app delegate (or the window for that matter) needs to be messed with at all to do what you are trying to do. Sounds like you should just be using standard Nav View Controllers and Web Views.
Also, you are alloc init'ing w/o any memory management.
Is there a way to do a general resignFirstResponder to hide the keyboard regardless of what textfield/view/etc calls it?
Reason is I have a lot of textfields on my view and don't want to have to resignFirstResponder for all textfields to hide the keyboard. Just want a general
[self resignFirstResponder].
Any ideas?
Thanks in advance
I know that this has already been marked as answered, but for those that run into this like I did you can just use the following method on the view that contains the textfields.
- (BOOL)endEditing:(BOOL)force
This method looks at the current view and its subview hierarchy for the text field that is currently the first responder. If it finds one, it asks that text field to resign as first responder. If the force parameter is set to YES, the text field is never even asked; it is forced to resign. UIView Documentation
[self.view endEditing:YES];
it will hide keyboard when we click on view.
You can dismiss the keyboard without any reference to UITextfield / UITextView with help of below code:
[[[UIApplication sharedApplication] keyWindow] endEditing:YES];
this will dismiss the keyboard globally without the reference.
hope this will help you.
The easiest way to do this is to have a method for whenever you want to dismiss the keyboard that looks like this:
-(void)dismissKeyboard {
[firstField becomeFirstResponder];
[firstField resignFirstResponder];
}
You can check these questions:
Is it possible to make the iPhone keyboard invisible / remove it without resigning first responder?
Hide Input Keyboard on iPhone Without Knowing First Responder?
In summary:
You can call becomeFirstResponder on some other thing that you choose. It could be a UIViewController or a UIView. I had a similar problem before, I needed to make my keyboard go away when I was pushing my view controller back to its caller, without knowing which textfield was the first responder. Then, on viewWillAppear of my view controller which I was returning back, I called [self becomeFirstResponder] and the keyboard of the pushed view was gone. Because this made whichever text field was it loose being the first responder
In my own app when I had more than one text field and would like to make the keyboard go away regardless which of the fields called it, I would just wrote a method and let each and every of them resignFirstResponder.
I assume that as a programmer, you should have the clear knowledge how many text fields are on your view controller and how you can access them, otherwise it'll get messed up and you app won't look good... :-P