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
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.
This is hard for me to explain, so please bear with me for a minute.
In Xcode, if it is in full screen mode, showing the app's menu also moves the toolbar down. I have tried to make an NSView move and resize whenever the menu bar is shown, but I cannot figure out how to do it. I think this has something to do with and event, because setting struts and springs in Xcode does not make it move automatically. Can anybody help me figure out what the event is?
Edit: I just re-thought my question, and I have to make a correction. NSToolbar does this on it's own. I want a normal NSView to move and resize itself when the window goes into full screen mode.
I think you might be having the same issue as I was - if so, you need to call [NSToolbar setFullScreenAccessoryView:] on the "accessory view" you want to glue to the bottom of the NSToolbar.
Note that in windowed mode, your accessory view should take up space in the NSWindow's contentView just like any other view, but when you enter fullscreen mode you'll want to remove the accessory view somehow since Cocoa rips it out of your layout and leaves a gap unless you account for that.
I can certainly understand this issue being difficult to explain without having the background knowledge - I had the same problem. :)
Also see: How can I get a two-row toolbar like in Mail.app and Xcode?
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.
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).