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.
Related
What I'm looking to do is create some kind of master view, that would have the same header (with a logo), footer (with some text and a button), background image and navigation (not a navigation bar, just a few buttons) on every view.
You could think of what I'm after doing is like a PowerPoint presentation. Create a master slide that's layout is used through every slide, you create a new slide and it takes across all the masters properties (header, footer, background etc) and then it's just the content that changes on each new slide.
However, I'm not too sure how I would do this in an iOS application. I've had a look on Google searching many different phrases but all seem to be about iPad split views and using cells of a tableview, which isn't what I'm after.
All I can think to do is create a single view controller class, with a view, and then add a sub UIView for each page I want (about 15-20), but with the one class, and every page having different content and a lot of code required for each one, that's going to get messy! Or I simply recreate the footer and header etc on every view controller, so if there were to be a change, then I'd have 20 views (more if it grows) to edit! So I'm just wondering if there's a simple way of getting what I'm after.
The app will be for iPad only, and I can use any OS up to 5, so xibs or storyboards are fine. And this won't be on the app store if that helps.
I've done a quick drawing below. The master view with all my bits to be used on each page, and then content slides that will slot in and out of the mater's content area.
Check out Containment View Controllers. This kind of presentation is exactly what they are designed to handle. There is a really nice WWDC presentation from 2012 I believe that illustrates how these work. There are also several tutorials online if you search.
maybe the best option is to create a master detail page. Then for each new page, call the master?
If u want to show header and footer view in whole apps then add header and footer view in window not in view controller i think it will work
In an iOS Tabbed Application I'm making, I've got tabs to load different viewControllers, which is pretty standard. What I'd like to do is make a few buttons (with images on them) load up another view with the button image maximized to the screen. However, I'm not really sure how to go about doing this. I don't want a new tab for this, I just want another view to show the full image, and then a button to return to the tabbed view. I've experimented a bit with making a subview to do this, and I've attempted to change the main viewport to the new view, with no success. If someone could point me in the right direction, and maybe give me a solid concept as a jumping-off point, I would really appreciate it.
And to clarify, I'm not looking for "the best way", per se. I'd be willing to accept a quick and dirty fix. But if you know of more than one way to handle this situation, I would appreciate whichever one you personally think is better.
I would do it by creating a UINavigationController to use as the primary tab view. When you want to show the full screen button, you create a new UIViewController subclass (below) and push it. That class will return YES for the method "hidesBottomBar" (its something like that).
This new view controller will be a traditional controller. You can create a UIImageView to fill the view (or you can probably replace the view with the imageView). In the viewDidLoad you'll set the UIImage of the view (or you can enter its name in the nib).
When someone clicks on the button, then you'll pop that view and return to your tabbed view (where the tab bar is showing).
I did something like this (not a big button), so I know the tab bar can be made to hide on the push. You can also hide the navigation bar so it never is even show (again, not 100% sure at the moment how to do it but its possible).
I'm working on an app that needs many TabBar Items (6 or 7). I don't think users like to click the "More" button on TabBars, so I'm wondering how to make my own TabBar that slides from left to right, so one can easily access all the buttons on the tabbar without pressing "More."
Thanks!
I agree with the other answer that it's a bad idea from a design standpoint.
Nevertheless, the technical answer is that you can simply embed a UITabBar in a UIScrollView. If you set the tab bar's width and the scroll view's contentSize appropriately, the tab bar will be scrollable. You will probably want to turn off bouncing and scroll indicators.
I didn't try it with a UITarBarController.
Opinions on whether this is a good idea or not aside
A simple carousel should be fairly simple to implement from scratch using a UIScrollView with UIButton subviews. which will provide all the scroll mechanics for you
As a sample idea.
A UISCrollView which spans the width of the device.
N buttons across the scroll content pane
Restrict scroller to horizontal scrolling.
Provide selected and unselected images for the buttons
Create glue code to ensure only one button is selected at a time (like Radio buttons)
But I do agree with the other posters that its a bad UI idea. Id be thinking UIToolbar for this.
Apart from considerations about UX and UI guidelines, a way you can implement such thing is implementing a tab bar from scratch. You can even find a tutorial here for iOS5.
Actually, implementing a tab bar and a tab bar controller is not difficult as it may appear at first sight, but given the effort involved, you could also ask you what value this kind of design add to your app and to the user experience.
In any case, if you decide to go for this path (a scrollable tab bar), I would suggest to make it such that the user cannot be misguided into thinking it's a standard tab bar.
That's against about every design guideline ever written for iOS.
(I know that Gift Plan for iOS has a scrollable tab bar, but it never hides items from the user.)
The HOW to do it has been accepted,
MOBILE DESIGN PATTERNS are not cast in concrete - it is about what is appropriate for YOUR app.
It used to be that web pages scrolled vertically and side-scrolling was frowned on.
But the tablet has been a game changer - people EXPECT to swipe side to side.
A comment on one case when scrolling tab view is actually highly appropriate ..
(a) Look at xFeed in App Store
This has 10+ topics like News Sports ... , easy to scroll to topic and click takes you to RSS feeds under it.
This is truly convenient for user, and in my opinion appropriate.
The alternative is to go back and forth between a menu of some kind and the target view - which could be a 2nd option, but from a quick browse experience this is good.
(b) USA Today is another example - even on its main website, has the < > arrows to scroll between topics or you can click on tabs at top. Admittedly the tabs themselves don't scroll, but you get the idea. The entire site, and the mobile experience for USA Today is strongly optimized around side swipeing between chapters.
(c) Presentations and content sites have come to be side scrolling as well.
(d) FINALLY on a Human Happiness viewpoint! People WANT TO TOUCH and PLAY with their mobile stuff. Not just tap!
So mobile touch is quite happy here. One more thing to swipe and slide :)
Here is a link of project with custom scrollable tab bar:
github - scrollable tab bar by BananaDev
It's free and provides a wide variety of customization options allowing you to fully change control.
I have a UITabBarController displaying a number of settings-screens in my app. I want them to be shown on just a part of the screen for layout reasons. In fullscreen, the lists become unreadable (too wide), there are just a few controls per page making the page feel very empty, and the tabbar buttons are far away from the content (Fitts law).
Using presentModalViewController with the UIModalPresentationFormSheet style gives me the size I want. I do this on top of an empty background, since in my case it doesn't make sense to display anything behind it. The "real" working area is displayed with another presentModalViewController in fullscreen mode on top of it all.
This works but feels like a hack. One problem is, I can't make the background behind the settings dialog move in the transition to fullscreen with the UIModalTransitionStyleFlipHorizontal style.
TL;DR
Can I embed a UITabBarController non-fullscreen in another "background"-view? I can't find any information of how I would do this.
Can I embed a UITabBarController non-fullscreen in another "background"-view? I can't find any information of how I would do this.
Why don't you try it out?
Create a container view of the size you want the tab bar controller to have.
Create the tab bar controller.
[containerView addSubview:tabBarController.view];
I'm working with Xcode doing a Ipad app.
i simply want user to click anywhere on screen (not counting text fields) to perform some IBAction.I'm using an invisible button that covers my whole view.
Since I have some text fields in my view,i need to add this invisible button to the background of my user interface. I cant seem to find this option in the button attributes? any help?
Just set the button's type to custom.
Did you try setting the opacity of the button to zero?
I guess i got your point. You just want to put the UIButton(invisible) on the back of all the UITextField. The simple solution to this is open the Document Window in the IB. Now expand the view tree in the list view. Just drag your UIButton above the UITextFields and set the alpha value for the button in the property to be zero.
Hope this helps!!
iPad users don't "click". They "tap" or "touch".
In Interface Builder, I believe views are constructed with a z-index from top to bottom as they appear in the document window, so dragging your button so that it appears as the first subview of your main view should be a quick fix for this.
Have you considered other approaches? This doesn't sound like standard behaviour for an app and will probably cause havoc with anybody using Voice Over. What are you trying to accomplish?