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.
Related
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.
When a UIView is created using storyboard there are three methods available I would like to know more about: custom, push, and modal. Can someone please explain the purpose and usage of each? Thanks in advance.
Modal:
when you will use style type mode the new screen completely obscures the previous one. The user cannot interact with the underlying screen until they close the modal screen first.
Push
When you use push screen is presented on the navigation stack you can always press the back button to return to the previous screen.
Custom:
In custom you can define your own segue class, where you can define your own way for transition between the screen
I have linked tutorial also in this answer. check it for more details
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.
I've got a tabbed iPad application with just about each tab running a UIWebView. I'm getting all sorts of callbacks, like when a user tries to leave the corporate site (which only displays the company site to users). In this case, I pop up a "toast" style window that tells them to click a button to open the page in Safari. I also pop it up with a spinner and no text to indicate that a page is loading. The approximate look that I'm going for is used in lots of applications, but you can see it best when changing the volume on the iPhone or iPad. It's just a translucent rounded square that fades in and out.
Right now I've got it implemented on one of my tabs, and I did it by creating the objects (a spinner, a label, and a UIImage with the square) and then programmatically hiding and showing them using [UIView beginAnimations] and changing the label's text. It works perfectly but I've got these nagging things hovering over my interface in Xcode, and it takes a lot of setup to accomplish if I wanted it to be in another tab, which I do. I can't help but think that there's a better way to accomplish this. I thought about making and adding a subview, but that would leave a white background to the toast. What I'm thinking is creating some sort of object that I can allocate in a tab's view controller whenever it's needed.
What are your guys ideas, or have you done this in the past? I see it in a lot of prominent applications, like Reeder, so I'm sure it's been done more eloquently than I have done it.
Matt Gallagher has a great class called LoadingView here Showing message over iPhone Keyboard. I use it.
MBProgressHUD is a popular library for this, as well.
I looked at Apple's UIModalTransitionStyle, but didn't see what I was looking for. I want to do the same thing that the Facebook iPhone App does; when you touch on a button on the Facebook's homescreen, the new UIView appears (and then disappears when you are done) from the middle of the screen. I would like to implement similar transitions in my iPhone app, and I was wondering if there was a quick way to do it (already precoded), and if not, how would I code it so I can do the same thing?
Edit: To clarify, the transition should have the UIView grow out of the middle of the screen, and then it fills up the entire view. When the user dismisses the view, the view shrinks into the middle of the screen, getting smaller until it has disappeared. Just like in the Facebook app.
Thank you!
myView.center = parentView.center
where myView is your new UIView that is appearing and parentView is the view that holds the button or else you could reference the application's window.