I haven't notice an issue in my iPad App, where two popovers are visible at once. Because of that, my App got rejected with this comment:
The iPad Human Interface Guidelines state that only one popover element should be visible onscreen at a time. In your application, the user can display two popovers at the same time. See the attached screenshot.
First of all, I would move the settings button to the right-side in the new version, but what if News popover is open and I tab the settings button -- what is expected behavior regarding their human guidelines? 1. Should I dismiss the News popover before I present the settings popover or 2. could I just do nothing, since the other popover is active?
I strongly guess that the first is right, but I would like to do it right this time. Thank you.
To quote Apple's Interface Guidelines:
Avoid providing a “dismiss popover” button. A popover should close automatically when its presence is no longer necessary.
If a user taps the "Settings" button, then assume the user would like the settings to be viewable and dismiss the first popover. Visa Versa for the other button.
Yes, you should simply dismiss the news popover before the settings are shown.
Related
I have an iPad app that presents a UITextField inside a UIPopover when a button is tapped. This button is near the bottom of the screen. So, the user taps the button, the popover appears and becomes the first responder, which causes the keyboard to appear. This, in turn, causes the popover to move up as the keyboard slides in. This works fine, except for VoiceOver.
It appears that VoiceOver gets confused by the moving view. It starts to describe the new text field, but then stops mid-word as soon as it starts to move.
Does anyone know of a good work-around. The best I've come up with so far is to listen for UIKeyboardDidShowNotification and then find some way to kick VoiceOver to talk again, though I'm not sure how to kick VoiceOver into action.
You can inform VoiceOver of changes to your screen layout by using the accessibility notifications - UIAccessibilityLayoutChangedNotification or UIAcessibilityScreenChangedNotification would be good candidates.
I'm developing an iPhone (iOS 5+) app using storyboards. The first screen of the app is a splash/login screen that checks for Facebook credentials and enables you to read and accept Terms And Conditions. In case there are valid stored credentials and the TOC has been previously accepted, this view automatically makes a modal segue (using a cross dissolve effect) to the first "real" application view, a tab bar controller with three tabs.
I'm currently implementing backgrounding and foregrounding logic. The problem is that when pressing the home button and then coming back, the login screen is briefly shown before the correct pre-backgrounding view is restored. (The Default.png of the app is of the login screen background, so it might be either that or a backgrounding-time screenshot of the actual login screen; I haven't tested replacing Default.png yet to tell the difference.)
Why is this? As far as I can tell, backgrounding the app should just take a screenshot of the view that is visible on the screen when, say, hitting the home button, and restore that prior to restoring the actual view functionality when coming back to the foreground. In this case that would be one of the tabs of the tab bar controller. Is the modal segue between the login screen and the tab bar controller the culprit here, or something else?
(I've always felt that the cross dissolve modal segue from the login screen to the first "useful" screen is a bit dirty, since IMHO a modal segue seems to imply that what your segueing to is something you'll later dismiss to get back to the "from" screen. What I'm doing now is just leaving the target of the modal segue visible indefinitely. If that is the problem here, I'd love it if someone would suggest a better method of displaying, transitioning away from and "jettisoning" the login screen.)
OK, turns out this was just a simulator/device discrepancy regarding Default.png. This comment on another question made me think to check. Time to file a bug report.
If I recall correctly, Apple has some old demo code which "remembers" which view a navigation controller was showing before it went into the background.
By way of disclaimer, I haven't worked with storyboards, so I don't know the specifics of doing what you're trying to do.
If it were me, I'd create the view controller or controllers at launch, and then only add the login screen if deemed necessary by the app delegate's logic. Only then, after setting up the view hierarchy, do I present everything.
This accomplishes two things. My login screen only exists and is visible if necessary. Additionally, the login screen won't flash unessecarily. Oh, and as a third benefit, you can present any view you like.
I'd suggest, assuming the aforementioned demo code doesn't work for you, that you'll want to save some sort of reference, tag, or ID of the currently visible view in NSUserDefaults and read that out when setting up your view hierarchy on launch.
I'm working on a iPhone app which shows an mobile webform in a UIWebView. I'm using a default iOS layout with a navigation and tab bar.
The mobile webform is displayed in a UIWebView in the white area. Since the webform has a lot of input fields, we really need as must space for it as possible. Because of this, we are planing to remove the tabs in the bottom. Over time, there will be more tabs/sections, so it is not a solution to just add a button for each section in the left side of the navigation bar. On a iPad a popover could easily be used to handle this.
Is there a standard iOS layout mechanism to handle this change of sections/views without using tabs?
You could do something long the lines of Path or the new Facebook app and have the "table of contents" behind the Navbar and the navbar slides away (along with the child view) to reveal it. When done right (ie smoothly) I think the effect is really cool.
This would also work great as you add more and more options, since the table could just scroll.
Here is a framework that might be you started: http://www.cocoacontrols.com/platforms/ios/controls/iiviewdeckcontroller
I would consider replacing the navigation bar's title with a control that lets you switch between tabs. You can assign the bar's titleView property to a control or a button and it will generally do the right thing.
If you're limited to 2-3 tabs, you could simply use a UISegmentedControl.
If you want more, you could use a button which, when tapped, pops up a view that allows you to select the view you want. This could be a modal table view, or you could slide up a UIPickerView from the bottom of the screen, similar to the keyboard.
I use this technique in an app of my own, screenshots here. Tapping the button cycles between views (in this case, I'm changing the contents of the table cells); tap-and-hold slides up a picker.
Another possibility would be to arrange your different forms on pages in a scroll view with a page control at the bottom, à la Weather. The best option, though, if you’re going to have a particularly long list and want to keep your screen real estate, is probably the FB/Path-style sidebar table.
I ended up using a UIActionSheet but I think it in other situations would be more stylish to use a controller like the IIViewDeckController.
I am working on an app for iPad. In one class, I have used a scroll view at the bottom of the screen. This scroll view has some buttons. Those button play a video or open a PDF file. When user frequently taps on those button the app crashes. I have no idea why is it happening. Can any one please tell me why is it happening and how can I fix this crash?
Regards
PC
You should track the state of your view. Which button was pressed last, and don't allow it to be pressed again until.
a) it is done loading the pdf/video
and/or
b) another button has been pressed
You might have to be more strict than that, but we cannot help more than that at this point as Till mentions in your comments
In the iPhone Objective-C app, I want to pop-up a window (which is smaller than the main view, and the app does not stop running) when a button is tapped, with textField for the user to input text, and dismiss it when it is done.
This is widely used but I really cannot google the relevant content out.
What view should I use to connect it with the button? AlertView (which seems you cannot add dialogue in), ModalView?
Are there relevant info somewhere?
Thanks.
Make the popup it's own, full-sized window. Put a UIImageView in behind your popup screen, and duplicate the results of the normal window. That way, it will look like a popup window, but it still has the proper animation speed and everything. If you do it as a real popup, the game itself will slow down and look jumpy.
You can create any view and use UIViewController's presentModalViewController: to display a modal view controller (and even animate it).