I tried to find answer for this question, but i couldnt find.
I'm developing an application what's using tabBarController as main navigation, and there are also navigationControllers in every Tab.
I would like to make a little 30px height news-scroller view under the navigationBar on every screen, but this scroller should be application-level, because it should show the same text on every view, and should change the text in the same time. I dont think that making 9 scrollerView and connect them somehow isnt the best way.
Is there any woraround for this in iOS?
Thank you in advance.
Probably the best way would be to subclass a UIViewController and add scrollView in top of the view (bellow the navigationBar). After that connect the scrollView instance with single (app wide) scrollView data model instance for example with KVO or Notifications technique. This approuch should fit to MVC pattern.
May be you add your ticker into the main view
Wouldn't it be possible to subclass the tabBarController in order to hold your scrollview as a subview?
Simply speaking in term of architecture it would do the trick. But it could not be as easy to perform as I think. (I am not an interface friend)
Related
So I'm curious. I was looking into a way to create a categories selector similar to the one located at the top of this application: http://itunes.apple.com/us/app/xfeed-rss-reader/id313206921?mt=8 ... 06921?mt=8. Would I tackle this using a Toolbar and elongating it to where the user can 'scroll' side to side for categories? Or a ScrollView with a Tabbar in it? I want to do this the 'proper' way per say and I've seen flags raised about a Tabbar being in a ScrollView.
If I were implementing this, I would create it with a UIScrollView containing UIButtons. UITabBars have some nice integration with UIViewControllers and UINavigationControllers, but the benefits quickly drop off when you need more customizable behavior (left to right scrolling, for instance.). I would normally just put them all in a xib and connect the outlets appropriately, unless it was important that they be dynamic.
You mentioned correctness, so an even more "correct" way is to create a UIControl similar to a UISegmentedControl that handles the creation of properly sized labels, deals with touches appropriately, etc. If you are setting categories dynamically you'll want to override sizeThatFits: and call sizeToFit so you can properly size the content area of your scrollview.
I'm trying to create an app with UITabBarController, in order to use Cocoa's own memory and view controllers management for switching between different view controllers.
However I do need to make a very custom UITabBar, which after much Googling I found out is not possible. Several things are not possible with original UITabBar:
changing position and size of the TabBar,
adding custom (non-tab) elements to the toolbar, such as search/dropdown
Is there any "legal" method of completely changing the design/subviews of TabBar but in the same time making use of UITabBarController and still getting app approved by Apple?
Thank you for your help.
About changing the size you can extend UITabBar and overwrite the function sizeThatFits.
I'm sorry for not having an answer for the other points.
- (CGSize)sizeThatFits:(CGSize)size {
CGSize auxSize = size;
auxSize.height = 54; // Put here the new height you want
return auxSize;
}
I will tell you as soon as I will discover it.
Not much can be customized in tabbar but there are some good examples :-
Custom Tabbar by iDevRecipes
Custom TabBar by brianCollins
It might not be exactly what you need but will give you direction.
Please go to your Contacts app, and choose one of your contacts.
You'll see that the view has labels, buttons and a table view all in the same view. And you can also scroll it around.
I want to set up the same kind of UI.
How would I organize things in interface builder to accomplish this? I would imagine I’d have to create a regular UIViewController subclass, and create a XIB file with a scroll view, which in turn contains the buttons and table view? I tried, but it doesn't give me the desired effect. For example, the view refuses to “bounce” upon scrolling.
You have to create a UITableViewController and create the Table you want.
The buttons are costum Table cells in the UITableView with round rect buttons in it. They have selectors to call methods.
Edit: Wrong answer, poster wants something different, but I'll let the answer stand because people might land here while searching.
What you probably want is the ABPeoplePickerNavigationController. Apple has sample code that demonstrates how to use it.
It might be using tableview or might be just a UIVIew with ScrollView and labels+buttons. You approach is right and it'll bounce if your view size is larger than your screen size
Recently I've been wondering about the fact that that an iOS app only has one UIWindow.
It does not seem to be an issue to create another UIWindow and place it on screen.
My question is kind of vague, but I'm interested in:
What could I potentially achieve with a second UIWindow that cannot be done in other ways?
What can go wrong when using multiple UIWindow instances?
I have seen that people use a 2nd UIWindow to display popover like views on iPhone. Is this a good way of doing it? Why? Why not?
Are there other examples where it is making perfectly sense to have another UIWindow?
It's not that I'm missing something. I have never felt the need to create another UIWindow instance but maybe it would allow doing amazing things I'm not aware of! :-)
I'm hoping that it might help me solve this problem:
I need to add a "cover view" over whatever is currently displayed. It should also work if there are already one or more modal controllers presented. If I add a UIView to the root controller's view, the modal controllers sit on top, so do the popover controllers.
If I present the cover view modally and there is already a modal controller, only part of the screen is covered.
Starting with Rob's answer I played around a bit and would like to write down some notes for others trying to get information on this topic:
It is not a problem at all to add another UIWindow. Just create one and makeKeyAndVisible. Done.
Remove it by making another window visible, then release the one you don't need anymore.
The window that is "key" receives all the keyboard input.
UIWindow covers everything, even modals, popovers, etc. Brilliant!
UIWindow is always portrait implicitly. It does no rotate. You'll have to add a controller as the new window's root controller and let that handle rotation. (Just like the main window)
The window's level determines how "high" it gets displayed. Set it to UIWindowLevelStatusBar to have it cover everything. Set its hidden property to NO.
A 2nd UIWindow can be used to bring views on the screen that float on top of everything. Without creating a dummy controller just to embed that in a UIPopoverController.
It can be especially useful on iPhone where there is no popover controller but where you might want to mimic something like it.
And yes, it solved of course my problem: if the app resigns activation, add a cover window over whatever is currently shown to prevent iOS from taking a screenshot of your app's current content.
A UIWindow can float above other UI elements like the system keyboard.
To address your last paragraph: Make a UIWindow with the same frame as your main window. Set its windowLevel property to UIWindowLevelStatusBar. Set its hidden property to NO.
Here is Apple's Documentation for better understanding UIWindow:
https://developer.apple.com/library/archive/documentation/WindowsViews/Conceptual/WindowAndScreenGuide/WindowScreenRolesinApp/WindowScreenRolesinApp.html
One good though specific reason to use multiple instances of UIWindow is when you need to video record the app screen. You may not want to include certain elements (recording button, recording status, etc.) in the final recorded video, so you can put those elements in a separate UIWindow on top.
In fact, if you are using ReplayKit, you will have to use a separate UIWindow for these excluded UI elements. More info here: https://medium.com/ar-tips-and-tricks/how-to-record-a-screen-capture-with-replaykit-whilst-hiding-the-hud-element-bedcca8e31e
I have one background I want constant to all views; it shouldn't animate out and back to itself. I have another background I want common to another handful of views that layers on top of that one. I could do this cleanly enough by:
a) just having one viewcontroller and managing all the transitions of layered objects within that
b) using separate viewcontollers and managing them programatically
But I don't grok how I can do this with a storyboard proper-like. Do I need to make a custom segue? Is there a certain type of segue it should be, if it's custom (or otherwise)? Is there a best viewcontroller that I do it all inside? (note: there's no "levels" of navigation, tab bar, navbar, etc... though if that's the way to go, with the elements hidden, and that's the "best" way to do it, I suppose that that might be me c)? )
Hope I've explained this well enough. :) I do grok layer transparency, etc, as far as views go....
Thanks!
ETA: After more research, I thought I understood c as the correct answer, (with a nod to set "default" UIViewController background image? ) ~
navigation controller with main background
navigation controller with secondary background elements
subpage 1
subpage 2
subpage 3
other controller
But I'm still hitting a wall. Not grokking the storyboard (IB) way to even add a background to a navigation controller. The number of custom classes I've made and tossed out, now....
See if this is what you need. It is not in storyboard, but should do well enough.
navViewController.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:#"background.jpg"]];
This is what I have done (but only with 1 level of nav controller). You can put this code in AppDelegate.m, or maybe subclass UINavigationViewController and change the view's backgroundColor there (and attach it within StoryBoard)
I guess the problem is StoryBoard still has some limitations. And UINavigationViewController is not an interface element, it is a View Controller. It is simply shown as a simulated element in StoryBoard.)