When you build a tab application, should each tab be a view or a window?
Many developers say your app should only have one window with many views. Other developers say use windows for each tab.
Which is correct practice?
The general rule with iOS apps is that you want one UIWindow instance per physical screen. Until iOS added better multiscreen support, and the newer hardware was able to natively support app mirroring, most apps used one window, unless it explicitly supported a second display.
It follows then, that you want one UITabBarController to show instances of UIViewController objects. This rule should hold true regardless of the SDK you're using to write your apps, assuming that titanium maps its classes back to their native Objective-C counterparts.
The window doesn't have many views in a normal app, its simply hosts views while being displayed. I have never heard of using windows in tab views, I have several apps out that use tabbarcontrollers and I always use UIViewController subclasses (or UINavigationController subclasses) with a view in its nib - all works perfectly fine.
Related
Until XCode 6.2 beta 3 I was able to navigate in the hierarchy and push new interfaces from a button on any of my two pages relationated interfaces controllers.
Such as this:
This used to make such a weird result as stated here
But now, this appears to be a no go. Xcode doesn't state anything on this matter to alert, it just do nothing when you tap on the button that push the new interface.
I can only change that push for a modal to get it work.
But that is limiting my navigation stack as modal are final nodes of the navigation tree.
Also, this is a no go too:
XCode is forcing me to obtain this result only if that push is changed for a modal!!!!
Any workaround please!
This is tying my hands at my back.
You can't do what you are describing, and it is by design. If you were able to do it in a previous Xcode beta, Apple presumably saw that as a bug. They have been quite explicit that you can choose either page-based or hierarchical-interfaces, and that these are mutually exclusive. Both have the ability to present a modal view at any time.
From the Apple Watch Programming Guide:
Interface Navigation
For WatchKit apps with more than one screen of content, you must choose a technique for navigating between those screens. WatchKit apps support two navigation styles, which are mutually exclusive:
Page-based. This style is suited for apps with simple data models where the data on each page is not closely related to the data on any other page. A page-based interface contains two or more independent interface controllers, only one of which is displayed at any given time. At runtime, the user navigates between interface controllers by swiping left or right on the screen. A dot indicator control at the bottom of the screen indicates the user’s current position among the pages.
Hierarchical. This style is suited for apps with more complex data models or apps whose data is more hierarchical. A hierarchical interface always starts with a single root interface controller. In that interface controller, you provide controls that, when tapped, push new interface controllers onto the screen.
Apps can use modal presentations to supplement their base navigation style. Modal presentations are a way to interrupt the current user workflow to request input or display information. You can present interface controllers modally from both page-based and hierarchical apps. The modal presentation itself can consist of a single screen or multiple screens arranged in a page-based layout.
How to create an application to support multiple windows.
So that user can create new or close window simultaneously in the same app like we can see in browsers.
Any suggestion is appreciated.
as of iOS13 and XCode11 you can create multiple window apps for iPad OS by setting the Enable Multiple Windows property in info.plist to YES.
You don't want to use multiple windows. The app could have multiple windows but this wouldn't give you the effect you want (or would be an abusive way of creating it).
Instead, what you want is a container view controller which manages, in a custom way, a number of child view controllers. Think about how a tab view controller works - you want the same thing, just presented in a different way.
Taks a look at HGPageScrollView for inspiration and reuse.
I am trying to implement a tab-style navigation system in my app (similar to the iOS UITabBarController). The functionality I am trying to create is that each tab holds it's own stack of screens, so that if one switches tabs the user changes to a different stack and can navigate back and forth independently of the other tabs, all the while showing a single tab bar at the top or bottom of the screen.
I have seen this functionality in apps such as Dropbox, but I am not sure if its possible to have multiple stacks or the behaviour is simply clever management of a single stack.
Any thoughts would be very much appreciated.
No, there is only one stack of screens and RIM OS does not support multiple screen stacks.
And you should follow some rules to work with this single stack. For instance, to show previous screen, you need to pop (close) topmost one.
If you do not pop screens, but create more and more new ones, without closing old screens, then you will get OutOfMemoryException.
You will need to redesign your app, use custom Manager class instances and compose your own interface to implement the way of appearance you need.
EDIT: You can have as many in-memory lists of screen objects as you wish, or until they fit to the device memory. But RIM OS allows only one stack of visible screens.
I have an iOS app that I created with Xcode 4.0’s “Window-based Application” template. It worked fine back then and it was using the iOS 4.3 SDK. This is an app that simply puts the buttons, labels, etc. directly onto a window. No view controllers—no nothing.
But now that I’ve upgraded to Xcode 4.2 (and its iOS 5.0 SDK), and I run the app, this message gets logged to the console when the app launches in the simulator:
“Applications are expected to have a root view controller at the end of application launch”
To be sure, the app continues to work, but this rather bothersome log gets printed out on every launch.
Why is this happening? Why does iOS 5.0 prefer/request view controllers?
I don't know specifically why the message is logged, but integration between UIWindow and UIViewController has been increasing over the last several iterations of iOS. iOS 4 added a rootViewController property to UIWindow. The two classes work together to manage view rotation. Given the new capabilities that iOS 5 introduced to UIViewController (specifically, the ability to create your own container view controllers), it's clear that the relationship between the two classes will continue to evolve. As you've said, your app continues to function in iOS 5, so having a root view controller isn't a hard and fast requirement yet. Perhaps there are features planned for future iOS versions that will depend on having a view controller available.
I don’t have anything against them, and I will use them if iOS wants
me to. I was just curious about the above behavior.
I'd interpret the logged message as a gentle but persistent nudge from Apple toward providing a root view controller. Most apps already use view controllers anyway, so this isn't a big change, but there are probably a number of apps out there that don't properly set the window's rootViewController property to their top-level view controller.
You have just Connected your "view" with "File Owner".....just remove that connection and run your app.click your view and see the connections inspector area and remove that connection which I told..I dont know exactly what reason..but i had this issue and i cleared.
May be you have used some tableview or some other views in it.So the app. needs a view controller to launch.If you remove that connection then it will run what you wrote in a code only...
Let me tell you the reason.
In former edition, Window-based Application is used to build multi-view applications.But in Xcode 4.2,the Window-based Application does not exist any more. Empty Application is designed to establish a multi-view program.
The difference between Window-based Application and Empty Application is that the former has a main window, the MainWindow.xib.
When the program starts, iPhone build the main window firstly. The content in the MainWindow will be loaded and built.But if you want more functions, e.g. multi-view, you still have to new a root view controller. Root view controller can help manage the views in your program. In the new edition,Xcode 4.2, a root view controller is expected.
In the new edition, there is not a MainWindow.xib in Empty Application.The AppDelegate create a window instead. And it wants a root view controller. So the best way is to create a UIViewController Subclass with XIB for interface for MainWindow. But in the old edition, XIB is not needed.
So get it? Without a root view controller, you are not going to receive an error, but you can hardly do any thing without one. That's why the warning always come out.
We are creating an iPad application that uses multiple SplitViewController. From the Apple documentation I understand that the SplitViewController needs to be the rootViewController of the window.
Does anyone have any experience or suggestions on how to create a navigation scheme that switches between multiple SplitViewControllers?
Its seems that this is not a supported design. We have since decided to use one SplitViewController at the root, and swap out it's views when the screen changes. This seems to work pretty well.