I have a situation here which I am trying to resolve, but it seams I am missing something.
My architecture of the application is as following:
AppDelegate (TabBarController)
Navigation Controller
Viewcontroller one
Viewcontroller two
Viewcontroller three
Viewcontroller
Since I have lot of text validations and scrolling enabled, I am using a custom uiscrollview for viewcontroller one, two and three. In the custom uiscollview I am utilizing the code from Apple which causes scrollview to scroll if the textfield is being hidden behind the keyboard. The problem which I am occuring at this point is that I have the viewcontroller one working fine, but when it comes to viewcontroller two and three, it does see's that custom view controller after debugging, and reaches the point of "setContentOffSet" but not animating the scrollview, but just displaying the keyboard.
If anyone had this issue before, I would like to see what might I be missing here?
Related
Before Starting I want to make sure one thing whether we can make the ViewController transparent (alpha), as far my knowledge it is NO.
I have a ViewController which consists of 8 UIButton objects over it. Whenever I press Button1, Button2 I am loading a ViewController. Since the ViewController cannot be made transparent, I just moved that View to my HomeViewController.xib and I am loading the view using -addSubView:. And I am changing the alpha value to make it as transparent.
But the thing is in Button1 View and Button2 View, in both views I am having table view. When I bring everything to the same HomeViewController class , I am having too much of code in a single class.
Is there any way to do this?? Adding many Views in the same ViewController not a problem, but it increases the code too. Which looks ugly. Please help me out.
If I have confused about my question here I am giving a short description of what I would like to do
Whenever I press a Button in ViewController, I want to load a View/ViewController Transparently.
Before Starting I want to make sure one thing whether we can make the
ViewController transparent (alpha), as far my knowledge it is NO.
You can't adjust a view controllers alpha directly. You can adjust a view controllers view properties alpha, ex: myViewController.view.alpha, and you can do this for any view that you want except for your root view (the bottom of the view stack). Lowering your root views alpha would allow the user to see the springboard through your app.
But the thing is , In Button1 View and Button2 View , in both views I
am having table view. When I bring everything to the same
HomeViewController class , I am having too much of code in a single
class.
Is there any way to do this ?? Adding Many Views in the same
ViewController not a problem, but it increases the code too. Which
looks ugly. Please help me out.
I'm not sure I understand the problem here. As long as you format your code correctly and keep well organized this isn't a problem. I personally have used view controllers in excess of 15k lines of code and never had a problem, and I'm sure there are developers that have used way more.
If I have confused about my question here I am giving a short
description of what I would like to do Whenever I press a Button in
ViewController , I want to load a View/ViewController Transparently.
Continue the way you have been describing. (adding alpha adjusted UIView's as subviews) There is nothing wrong with this approach.
(my first question here ;)
I am trying to implement the functionality that you can see in mail: where there is a up en down button to load previous or next mail.
In my case I have a UITableView with around 100 entries and if you select a row, a huge empty UIScrollView is loaded. And shown at the right offset where a DetailView is loaded. In this huge scrollview (with paging enabled) each page is the size of the screen.
The DetailView contains a UIScrollview in which the content (text) and some buttons to do stuff (mail, open link in safari etc) are displayed.
I use a (DetailView *)dequeueRecycledPage method that uses an NSSet so there are max 3 UIViewControllers alive. (current, previous, next). For fast response.
The buttons in the navbar will tell the huge scrollview to "scrollRectToVisible:animated:YES" so the user sees the new view slide in.
Right now my DetailView is subclassed from UIView, and it works. But I don't want a lot of delegation for the button actions in this DetailView. I'd rather have the DetailView handle them.
So I would like to subclass my DetailView from UIViewController.
But then we have the huge empty scrollview with 3 UIViewControllers (only 1 displayed at a time). But maybe that Apple is not keen on this, or maybe I run into trouble somehow.
So my question comes down to this:
Can a UIScrollView contain more than one UIViewControllers (only 1 displayed at a time)
Or is this "not done" or simply wrong?
thanks in advance for your help,
G
While it is theoretically possible for one UIScrollView to contains the UIViews of 3 different UIViewControllers, it is not necessarily the best practice for what you are trying to accomplish.
Typically, a better design would be to have your UIScrollView belong to a UIViewController and then you can add whatever UIViews (or subclasses there of) to your UIScrollView. Instead of creating 3 different UIViewControllers and adding their views to your UIScrollView, you could simply create 3 different UIViews and add those views to your UIScrollView.
I know you can have two (thus multiple) views within one scroll view, the company I work for has done it a couple of times.
I'm not sure what the exact code is, but you'll probably want something like:
myScrollView.addSubView(viewName).
To hide the view, do this:
if (logicToHideViewIsTrue) {
[viewName setHidden:YES];
}
More information can be found here
Generally, a UIViewController encompasses an entire screen and only one should be visible at a time. The way to implement the Mail app view involves a UINavigationController, a UIViewController and a UIScrollView.
The UIViewController should add the Up/Down buttons to the navigation toolbar.
The UIViewController has a view that should be a UIScrollView. When an Up/Down button is press, the UIViewController should receive this message and then tell the UIScrollView to change it's view to the new content.
I have a tab bar app that works. Each tab is a UINavigationController whose root view is some kind of UIViewController, often a UITableViewController.
There are instances in the app where I want to display a full-screen "veil" with a message about what's happening until some operation completes. The point is to swallow up any touches on the UI that would navigate away from where the operation started.
The veil is a UIView subclass. There is one singleton instance of the class. When displayed, I insert it as a subview of the UITabBarController view. The view appears over the entire UI, tab bar included. Great!
Here's the problem. I can tap the tabs and the UI changes. What I would have expected is that my veil view would have just swallowed up the touches.
I have implemented in my veil class the various touches{Began|Ended|Moved|Canceled} methods (as do-nothing methods), but the touches are still picked up by the tab bar, and frankly by any object under whereever I happen to touch.
I've also tried overriding a number of other methods including nextResponder, hitTest:withEvent:, etc, to no avail.
I am a little stumped at this point. I'm hoping someone will have some sage advise. :-)
Thanks.
It's not safe to modify the view hierarchy of framework classes. You would be much better-served simply adding it as a subview of the window itself. As for consuming touches, if making this change doesn't work, then you should also verify that userInteractionEnabled is set to YES on the view. You should not have to actually implement any touch-related methods.
I also had this problem and came up with a hacky solution. In the init of your custom UIView class, create a dummy UIView that's impossible to hit, for example [[UIView alloc] initWithFrame:CGRectMake(-1, -1, 0, 0)]. Or actually, I think any UIView not attached to the window works. Then, in hitTest:withEvent:, have it return the dummy view for every point not in your area of interest.
I have application with multiple UIViewControllers using navigation controller. UIViewController contains tableView, searchbar (that I can show/hide) and toolbar. All of this is added as subviews to its view. All this subviews are created after UIViewController is initialized and their content depend on UIVievController's content.
It works fine expect one problem. When I play with my app a little, move back and forth, open some modal views etc sometimes after navigating back to my root VC all it's subviews dissapear and all I get is white screen.
I double checked all my code and I can't find source of problem (I certainly don't remove them myself). I wasn't able to find exact patern how to reproduce this, it seems random. Any idea why iphone would remove my subviews from VC? I would post some code, but I don't want to put it all here and I am not sure which part is important, so if you wish to see some, let me know
Add your views in loadView or viewDidLoad: when viewDidUnload is called, the view is released, so they need to be created again when the view is shown again.
I'm doing an iPad tech demo and I'm running into a serious technical problem.
I have an app concept that leverages UISplitViewController, but NOT as the primary controller for the entire app.
The app flow could be described roughly as this:
Home screen (UIViewController)
List->Detail "Catalog" (UISplitViewController)
Super Detail Screen (UIViewController but could conceivable also be a child of SplitView).
The problem is in the flow between Home and Catalog. Once a UISplitViewController view is added to the UIWindow, it starts to throw hissy fits.
The problem can be summarized at this:
When a UISplitView generates a popover view, it appears to then be latched to its parent view. Upon removing the UISplitView from the UIWindow subviews, you will get a CoreGraphics exception and the view will fail to be removed.
When adding other views (presumably in this case, the home screen to which you are returning), they do not autorotate, instead, the UISplitView, which has failed to be removed due to a CG exception, continues to respond to the rotation instead, causing horrible rendering bugs that can't be just "dealt with". At this point, adding any views, even re-adding the SplitView, causes a cascade of render bugs.
I then tried simply to leave the SplitView ever present as the "bottom" view, and keeping adding and removing the Home Screen from on top of it, but this fails as SplitView dominates the Orientation change calls, and Home Screen will not rotate, even if you call [homeScreen becomeFirstResponder]
You can't put SplitView into a hierarchy like UINavigationController, you will get an outright runtime error, so that option is off the table. Modals just look bad and are discourages anyway.
My presumption at this moment is that the only proper way to deal with this problem is so somehow "disarm" UISplitViewController so that it can be removed from its parent view without throwing an unhandled exception, but I have no idea how.
If you want to see an app that does exactly what I need to do, check out GILT Groupe in the iPad app store. They pulled it off, but they seem to have programmed an entire custom view transition set.
Help would be greatly appreciated.
Apple states:
The split view controller’s view
should always be installed as the root
view of your application window. You
should never present a split view
inside of a navigation or tab bar
interface.
This does mean it should be root view and not subview of another view. Even though they add:
You should never present a split view inside of a navigation or tab bar interface
That does not mean you can add it as a subview of any other controller either. (sorry)
I have a feeling that what you are experiencing is the byproduct of trying to do so. I am actually surprised that GILT Groupe's app did not get rejected. Apple has a tendency to enforce these HIG guidelines rather strictly lately. They (as you found out already) cause a rather nasty runtime error when you attempt to add them to a NavigationController.
I've solved this for myself... actually worked around... by presenting all other possible full screen views as modals of the SplitView...
This is an unsavory way of doing things in my book, but Apple leaves you little choice if you want to leverage a SplitView only "sometimes" within an app.
I had some success by creating a second UIWindow. I associate the UISplitViewController with that, and switch it out with the main window when I want to show the splitview. It seems to work they way I wanted, except for a slight delay in rotations and a log message about "wait_fences".
Unless your developing for jail-broken devices then bending apples rules/wishes isn't a good idea. Like Jann and Jasconius state above this means keeping a splitView controller view root, not over-using modals (vague) and not using multiple windows.
Also, the Gilt app is only available in the US
I'v been trying to find a solution too and have ended up programatically removing views from the window like Tuannd talks about but the landscape rendering bug is unforgivable.
#Jasconius, What is the max number of modals are you are presenting at any time?
I am struggling with this same issue. I've been trying various things poking at the UISplitViewController as a black box and see how it reacts.
I seem to have come up with a solution to my case which seems to be working satisfactorily.
The key appears to be that the first view added to the UIWindow is the only view properly initialized. All the problems I've had tend to stem from incorrect notification of the orientation of the device. The first view added, apparently has this correctly configured.
In my case I didn't want the UISplitView as the first view. The following is working for me.
The app delegate application:didFinishLaunching method is special. Adding the view to the UIWindow must occur here. If it is done elsewhere it does not get configured properly.
Essentially the magic sauce, is have the split view be the first view added to the window. Its then ok to remove it as long as you retain the UISplitViewController. From then on you can swap other views in and out, including the UISplitView and most things seem to be ok.
I've still run into a few issues. Popovers on views other than the split view are confused on the views frames and location of toolbar buttons and will display in the wrong location. I place then in a specific location and that seems to handle that case.
If a popover on the split view is still displayed, and you try to view another view, the orientation of the second view is confused and shows up sideways. If that view is accessed before the popup is displayed, all is well. I've fixed this my manually dismissing the popover before switching to any other view.
Here's the code if it helps. All the controllers are instance variables of appDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// This also seems to work as good magic. Seems to set orientation and size properties that persist.
[window addSubview:splitViewController.view];
[splitViewController.view removeFromSuperview];
[self switchToNewViewController:firstController];
[window makeKeyAndVisible];
return TRUE;
}
- (void)switchToNewViewController:(UIViewController *)newViewController {
[popoverController dismissPopoverAnimated:FALSE];
if (newViewController != currentViewController) {
[currentViewController removeFromSuperview];
currentViewController = newViewController;
[window addSubView:newViewController.view];
}
}
Just wanted to say that I was running into these same issues, found this forum topic, and followed the advice from g051051 above. This is working perfectly for me. I am not seeing any glitch, and no messages about wait_fences in the console of the device.
I simply used IB to create two UIWindow objects in the main XIB, created as normal the UISplitViewController and then also an instance of my other controller derived from UIViewController (which I am using for full screen display). I have simply hooked them up by attaching the rootViewController for each UIWindow to its appropriate controller.
In application:didLaunch...: method I can decide which window to send the makeKeyAndVisible method and which to set to hidden. When the user want to switch back and forth I simply have to send makeKeyAndVisible to one and set the hidden property on the other, that's all there is to it.
As indicated all of the rotation related messages are sent to each controller appropriately, regardless of which one is associated with the currently visible window.
Anyway, works great for me, and actually quite easy to set up.