Not sure what's going on here, but my iPhone apps nav bar shows back and the title of my detail view controller even when I'm back to the original view. It wasn't happening earlier, it has changed recently (but not sure when exactly).
E.g. I click on a row, view the didSelectRow XIB and then click back on the NavBar controller, but it still shows back even though the view does change back to the original table view. I then have to press back again and then it clears.
Update: It's as if its trying to go back three times instead of two. Because, if you visit another row without removing the back button, it stores it as if you need to go back twice.
It works fine in portrait mode.
Any ideas?
Not all the tables had been set to auto-rotate, so their views were still staying portrait.
Related
I ran into a problem while programming on the new Xcode 5 and iOS 7.
The App is basically some ViewControllers showing different information and they are linked with a TabBarController.
Now, the problem is, that whenever I compile, at first the initial view appears as it should, but when I switch to another tab and go back the view changes.
I have set up the constraints so that the lower part should stick to the bottom and the MapView changes height according to the screen size.
I'm wondering if it is possible to start my app with all my tabs in the "up" state and show a "landing" view to the user. Kind of like a welcome/quick start. When they select one of the tabs, it switches views as normal.
Will you point me in the right direction?
Kind of like this:
If you're using a UITabBar/UITabBarController, I think you must have the selectedIndex set to some legal value. I don't think this is possible, nor can I find an app on my iPhone or iPod that mimics the behaviour you're looking for.
(The App Store app is as close as it gets, where it looks like it has an empty tab bar before it loads data from the Internet, but it could very well be that they are just re-using the Default.png and superimposing an activity indicator during loading.)
Note that if you tried to submit your app to Apple, they could easily reject it for using non-standard UI.
The way I would probably do this is to create a new ViewController that's just for this screen, but make sure it's last in the viewControllers array managed by the UITabBarController. That way, when you show the tab bar on the screen, you get the 4 tabs and the more button, but the currently selected view controller is not in the bar, meaning that all of the other tabs are unselected.
Once the user has satisfied the condition for showing the screen, you can discretely remove the view controller from the tab bar, and the user will never be the wiser.
I have a fairly simple iPhone application that I want to have run on both the iPhone and the iPad. I'd like to just have the iPad version be a bigger version of the iPhone version, scaled up or not -- I'm working on an iPad-specific version of the app that makes better use of the interface, but wanted to make sure my existing customers have something in the meantime.
The app is a simple tab-based application, and within each tab is a navigation controller that presents a table view, each of which can drill down a couple of layers. Everything mostly works -- I have a couple of instances of views not filling the space available, but I can fix that. My biggest problem right now is that the navigation controllers universally break when I try using them. Once I drill down a level or two, I suddenly won't be able to come back up again.
Let me try to explain in more detail:
One tab starts off with a "year" table view, showing all years that have entries; if you tap a year, it pushes another table view with all months in that year that have entries; if you tap a month, it pushes another table view that shows the individual entries; if you tap an entry, it pushes a view (a UIWebView, with some extra widgets) that shows an entry's details.
Each push is done with [self.navigationController pushViewController: foo animated: YES]. The three table view controllers I mentioned above are all created from the same nib (in fact, everything pushed onto a navigation controller in any tab is loaded from the same nib). Since I know there are only up to three levels of navigation, I just allocated three identical view controllers and use one, two, or three depending on how many entries there are.
Popping these controllers off using the "back" button seems to universally mess up the state of the view controller. So, if I drill down to the third view -- showing everything in a single month -- I won't be able to pop all the way back up to the first view: the back button stops working if I pop up one level.
Another example in another tab: it's one table view that you can tap any entry on, and a new view controller will be pushed that shows the details of that entry. If I tap an entry, tap the back button, then tap the entry again, no back button appears, or sometimes, the text that would go inside the back button appears, but no button appears!
This behavior happens if I try running the iPhone app in scaled mode (built with base SDK 4.0, supporting OS 3.2) or in native mode (built with base SDK 3.2). It runs without problems on the iPhone. I'm kind of at a loss here, because this stuff always "just worked" out of the box, mostly from the defaults that were set up back when I first created the project.
My programmer's instincts are telling me that I'm doing something very wrong in my view navigation, and that the iPad is just exposing it, but I can't figure out what it is.
Has anyone run into an issue like this, or suggest something it might be or some better way to debug what's going on?
The issue was that I had a category on NSMutableArray, which added stack-like methods push and pop. Removing this category class fixed this issue.
WTF, though.
In my application I am parsing XML to create a UITableView. When a user selects a row it changes the file that it is parsing and reloads the UITableView.
I want to create a back button so that the user can go back the the previous XML page they were viewing.
In short how can I tell the navigation controller to create a back arrow for this page when all i am doing is reloading my UITableView?
I'd strongly suggest building another controller (i.e. UITableViewController) and push that instead of just reloading the table. This makes the button automagically, and (major plus here), it animates the whole digging down / stepping back in a way that the user is expecting it.
As a side note, I didn't manage to get a back-style button once I tried it, just a plain normal button (make a new button and set it at the navigation bar).
What you're describing is a navigation. Rather than reloading the table's data, simply push a new view controller onto the navigation stack every time a row is tapped. This is a fundamental pattern in iPhone development. Here is Apple sample code for a multi-level drill down table view.
My application is pretty simple: it starts up with a view controller that holds a table view (in grouped view layout) with a few options. When the user taps on one of the options, I push another view controller onto my navigation controller.
This second view controller simply displays a UIImageView, and the user can change the screen orientation on this view controller between portrait/landscape modes. This works just fine, and all is happy.
However, if the user taps on the "Back" button on my navigation bar while on the landscape mode, the first controller's layout is all messed up. See below for before/after screenshots:
(source: pessoal.org)
(source: pessoal.org)
Any clues on how to force the first view controller (second screenshot in this post) to stay within the portrait screen orientation?
There does not appear to be a way to do this using the documented methods.
I have filed a bug for this: rdar://6399924
"There is no way to always restrict a UIViewController to one orientation"
You can see it on open radar (along with a link to sample code to reproduce the problem) here: http://openradar.appspot.com/radar?id=697
Like someone on the open radar suggested, a workaround is to disable "back" button while in non-portrait:
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation{
// don't let user press "back" button in landscape - otherwise previous view and the rest of the application
// will also be in landscape which we did not feel like testing yet
self.navigationController.navigationBarHidden = (UIInterfaceOrientationPortrait != self.interfaceOrientation);
}
There is a solution to do that : it's to use a view controller and adding its view to the window. then in that controller you force landscape in the shouldAutorotate... methode. It works fine, but be sure it's necessary for your project to use that, because it's not very smart to force the user to turn his iPhone. By the way, here is an example code if you need it.
http://www.geckogeek.fr/iphone-forcer-le-mode-landscape-ou-portrait-en-cours-dexecution.html
I wasn't able to get this to work the way I wanted. You ought to be able to set a particular orientation for a ViewController, but the NavigationController doesn't seem to always do the right thing.
I ennded up re-designing my screens so that they all work in either orientation. That might be extra work, but it "feels" more natural, anyway.