My question is similar to this one, but not exactly answered there.
What I want to do, is to convert an existing navigation-based app with different UIToolbars at the bottom of the individual UITableViews into an app that has a UITabbar interface. One of the tabs shall show the same hierachy of UITableView data as the existing app (which displays some kind of hierarchical data), whereas the others will be assigned something else (say: Settings, Help, ...) that is of no concern here. The idea is to allow the user to quickly switch to the "Help"-Screen from whatever stage of the navigation stack - and back.
For example, using 3 Tabs:
1. Database root (UIToolbar) - folder 1 (UIToolbar) - file 1.1
- file 1.2
- folder 2 (UIToolbar) - file 2.1
- file 2.2
2. Help (no UIToolbar)
3. Settings (no UIToolbar)
I have never seen such a design in any existing app, although the question cited above suggests that it might in fact be possible to keep the existing UIToolbars from the old app and simply place them above the tab bar.
Is this
technically possible (without problems e.g. with device rotation)?
allowed by Interface guidelines?
Although sample code would be appreciated, I mostly would like to find out whether it is worth trying to build an app like this - or whether such a design is a bad idea in the first place.
You can have a UITabBar anywhere, you just won't be using its controller. You will have to write your own controller and handle what happens during device rotation (or use iOS 6's auto layout features).
I tried it out, and now I can answer my own question:
It's possible, and there are no problems with device rotation, if you make sure that the views for every single tab can rotate.
Although it looks a bit unusual, I find it very usable. Of course, it costs some vertical space.
As for the implementation, I found it to be surprisingly simple:
All I had to do was to use Interface Builder to insert a UITabBarController in place of my original main UIViewController and move the latter to the first tab of the former. Then create some more tabs with UIViewControllers inside and rename their classes to those of my other existing UIViewControllers. Finally set the associated NIB-Files for all these controllers manually in the relevant interface builder inspector pane (because they are now no longer instantiated by my code) and change one single line of code to make the UITabBarController the root controller.
Result: the UIToolbar appears above the UITabbar for the first tab, but not for the others. Its position is fixed (when scrolling a list or similar), but it autorotates together with the tab bar and everything else.
Related
I have been asked this question many times in the interview searched every where didn't get any proper answer.So finally posting this question here.
You may go through this.
Yes, you can have multiple windows. A key window is the one who receives the user input.
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 in portrait implicitly. It does not rotate.
You'll have to add a controller to 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 for 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.
Generally one application require only 1 UIWindow, but still there may be some scenarios where you need to use multiple UIWindow in one application.
For example, you wish to show a view on the top of system AlertViews, or can the default Keyboard.
UIWindows are the special UIViews, for which their display order is controlled by .windowLevel property.
You don't need to add a new UIWindow as a subview of any of view. You can simply create a new UIWindow and call either window setHidden:NO or window makeKeyAndVisible depend on the level, you have given to it.
There are three default window enum levels defined:
UIWindowLevelNormal
UIWindowLevelStatusBar
UIWindowLevelAlert
Of course it can have multiple windows. Just, only one to be displayed at a time, that's the keyWindow. You can have multiple windows stored in array or whatsoever, and make them keyWindow when you want to display them.
And, yeah, read the documentation #Mannopson suggested, it's very useful.
I have quite a few labels and buttons on my view controller and I have an image and I have set it to the back in the layers part on the left. How ever when I make it bigger it seems to go to the front and block the images. I have tried multiple codes from other people who have the same problem, but it still doesn't work. I am using Xcode 8, Swift, iOS.
In interface builder you can change the order of what is in front or behind by changing the order of the views as they appear in the Document Outline...
The higher up the list they appear, the further towards the back they are.
I know this has been asked before, but none of these solutions work, and that's the reason of my posting. Please do not close before considering my case.
My plist already has UIViewControllerBasedStatusBarAppearance = false.
I have already tried applying deltas, but to no result.
Changing the top level view frame in ViewWillAppear (like self.view.frame) did not succeed.
I thought of increasing the view height (storyboard attribute inspector), in combination with deltas, but my top level view X, Y are disabled in storyboard attribute inspector.
My main view doesn't have any children views because I load them into main view either dynamically or load them from XIBs which are again shared by more than view controllers. These XIBs provide layout for both Portrait and Landscape. I don't know what approach is ideal for this kind of configuration, but I would like it better if solution lies along these lines.
This approach worked partially, but gave me inconsistent results.
What makes the solution tricky is the fact that I have to support all 4 orientations - this is something I handle in code via didRotate and willRotate delegates for my other views, but failing to do it for statusbar.
Please help...
Could this link be of any help?
You might have to use the new setEdgesForExtendedLayout: method to get this working consistently?
Also, have a look at these official docs if you haven't already done so.
I ended up writing my own function to shift my all subviews (remember, not top level views whose frame is fixated by IB).
It didn't spoil my work but imagine if this was the case for a very big project with so many screens, the limitations would have made it a nightmare.
I'm currently working on an iOS app that is pretty much supposed look and work like an already existing android app.
As a part of that, I'd like to make the top navigation look the same, but since iOs devices do not provide a hardware or software integrated back button, I'd also like to keep the back button navigation that's common to iOs apps.
I've tried numerous attempts to achieve it, but I'll stick with the latest I'm working on since it looks the most promising. I've started to work on a custom UINavigationBar class that overrides the initWithCoder: and layoutSubviews: methods. The result is as follows:
As you can see, the back button now overlaps the application icon. What I'm looking for is a way to make the button and the text to scale into the space right of the application icon. I've tried to handle this in layoutSubviews: but the superclass logic appears to be rather complex, I was not able to reproduce it's functionality (in particular it seems to be working with some private variables I don't have access to).
I also tried manipulating self.frame before calling [super layoutSubviews] but apart from endless loops I was not able to achieve anything in that direction.
I'd be happy if anyone could point me into the right direction.
If I understand your problem correctly, I think you could do this by adding a custom titleView to the UINavigationItem, and have an image view (on the left side for the icon) and a label (for the title) as subviews. This would replace the default title.
Consider the following two toolbars that are in the same project of mine:
Notice that these toolbars look different? The problem is that they were both created by dragging and dropping them into IB, and I didn't change any of there associated properties. All that I did change was adding the flex controller, and change the text on the initial UIButtonBarItem. Other than that, these Toolbars have not been modified and, furthermore, I've verified that their properties are exactly the same in the Attribute inspector.
How or why are they different? Furthermore, how can I get the first, bluish UIToolbar to look like the grey one since the available Black Opaque and Black Translucent styles look nothing like the grey one?
Am I missing something? This doesn't make any since.
I've found why this is happening but I'm a bit clueless on how to change this. See this, new question regarding a fix for this issue.
These Toolbars are changed due to internal Xib settings that are specified when the Xib is created. In the first example, when I created the UIViewController I must have unchecked the Target for iPad check box, even this is for an iPad project.
This changed the default size of the initial UIView that was in the Nib. I always cut off the statusbar and set the view to be freeform in sizing as soon as I create a UIView within a Xib file, so I can never tell by looking at my views whether they were targeted for the iPad or not.
When I created the second UIViewController object, I checked the Targeted for iPad option. Now, my toolbar is styled with a grey tone.
The lesson learned is obvious-- if you want consistency in the default style of your objects that you pull from the IB Toolbox, be sure to create your UIViewControllers, specifically targeted for the iOS device. If you've made the same mistake that I have, follow the linked question above for how to revert your UIViewController and Xib file to the other style of View Controller.