Im presenting a UIViewController with a UIModalPresentationCustom presentation style and the presented UIViewController has it's main view's backgroundColor set to clearColor. I need to allow interactions to the UIViewController that sits below. Is this possible?
The reason Im doing this is that I have a map that needs to persistently sit below a presented UINavigationController and I need to allow interactions with it. The presented views may have content that scrolls above it, and at that time I'd like interactivity to stop (which it should by default).
You might be able to do something like this by messing with hitTest, though I wouldn't rely on that.
It seems like a popover with 'passthroughViews' might serve your purposes better. If you can't deal with the arrow, you can always set a custom UIPopoverBackgroundView.
Related
For those that use the iOS Calendar a lot, you know that when you change the orientation of the phone, another view is presented. I am not sure oof this is changing to a subview, a new UIViewController, size classes or some programatic voodoo that Apple has spun.
I can do some of the features with a subview that changes constrains on orientation change, but that is about it. It looks crude and I thought there might be a better way to imitate the Calendar App.
It most likely uses UISplitViewController to achieve this effect. This lets you display two child view controllers side by side.
You can change its preferredDisplayMode property to show or hide secondary (or primary) view controller or set it to .automatic to let it choose the most appropriate layout for the available space.
I have two view controllers :
- UITableViewController
- UIViewController
UIViewController i present modally over UITableViewController which can be swiped to expand (like in iOS Maps app).
Problem is in Voice-Over. When it activates, the focus is on UIViewController, but left swipe does not take it to UITableViewController.
Note: I can interact with UITableViewController in the background when UIViewController is presented modally as I pass the touches dropped in UIViewControllers transparent area.
According to the way you implemented your view controllers, a quick view to the accessibilityElementsHidden and accessibilityViewIsModal properties may help.
Take a look at:
This article in the Implementing accessible modal views section to understand the way the latter property works with a clever, interactive and pedagogical illustration.
These many useful examples including code and illustrations.
There are some great answers relating to when to use a UIViewContoller vs. a UIView. For example here and here.
The general gist is that a UIVIewController should be used to control a full screen of data, because
It is designed to handle rotation. Only one UIViewController should be on the screen at once because only the newest will be notified that the rotation occurred.
To stay true to the MVC paradigm, your business logic should live in a UIViewController, while only display and interaction logic should live in a UIView. Presumably business logic relates to what's on the entire screen.
My question is, given this, how do I structure an app with left-right paging between several top-level views?
I want to create an interface with several UITableViews holding a list of recipes. The user swipes left and right to navigate between lists. There is a common menu on the bottom that stays fixed no matter what.
My initial thought is to use one UIVIewController for the UIScrollView, then add subviews from there.
However I'd really like each list to have its own UIViewController, so it can handle its own rotation, and hold business logic like its own REST methods. It would seem to be a pain to have the top-level UIViewController handle the rotation of a child subview, and it would seem to be a violation of MVC to put the logic anywhere else.
Is there a way to structure an app so that multiple UIViewControllers live inside a UIScrollView, or would it appropriate to use a series of top-level UIViewControllers and UISwipeGestureRecognizer to simulate the paging effect of the UIScrollView?
Thanks.
A couple of thoughts:
If targeting iOS 5 and higher, I'd suggest using a UIPageViewController which is designed for precisely this UI (swiping back and forth between UIViewController instances). You would then have a separate UIViewController for each recipe. In iOS 5, you only have UIPageViewControllerTransitionStylePageCurl transition style, but in iOS 6, you also have UIPageViewControllerTransitionStyleScroll.
For more information, see the Page View Controller section of the View Controller Catalog for iOS.
This is much simpler than writing your own scroll view based solution. If you "roll your own" with a UIScrollView, you'll want to remove instances that have scrolled off screen (by registering as the scroll view's delegate and responding to scrollViewDidScroll) so you don't use up memory unnecessarily.
If you do add child view controllers to your scroll view, don't forget to call the appropriate custom container calls. Specifically, as you add view controllers to your scroll view, make sure you call the following (assuming controller is the child controller and self is the main view controller):
[self addChildViewController:controller];
[self.scrollView addSubview:controller.view];
[controller didMoveToParentViewController:self];
And as you respond to scrollViewDidScroll to remove view controllers that are no longer visible, do the appropriate removal calls, e.g.:
[controller willMoveToParentViewController:nil];
[controller.view removeFromSuperview];
[self removeChildViewController:controller];
For information about why it's important to call these custom container calls, see WWDC 2011 video Implementing UIViewController Containment.
I definitely wouldn't recommend using a UINavigationController, though, because it will keep all of the previous pages in memory.
I believe for the requirements you're talking about you could use a UINavigationController. It will give you the "left-right" paging that you want and you can use a UIViewController for each of your recipes.
Also, I think you want to use a UIScrollView because it lets you perform a "swipe" gesture. If that's the case you could also add a UISwipeGestureRecognizer to your view controllers and every time the gesture is recognized call pushViewController:animated: and popViewControllerAnimated: to perform navigation between your recipes.
This is just and idea.
Hope this helps!
As far as I see, there are 2 good options:
Using a root UINavigationController and push/pop child
ViewControllers depending on the direction of the swipe gesture
(recognized by UISwipeGestureRecognizer, just as you said).
Using a root UIViewController with a UIScrollView and adding the child
viewcontroller views as subviews of the scrollview. To handle
orientation changes, you could pass the orientation-change
UIViewController methods (willRotateToInterfaceOrientation,
didRotateFromInterfaceOrientation) to the child controllers, so they
can handle them.
I hope I helped
Firstly, you should be aware that since iOS 5 it's been possible to include child view controllers inside your main view controller.
https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/CreatingCustomContainerViewControllers/CreatingCustomContainerViewControllers.html
So it seems to me that a good options would be to have a paged UIScrollView as your main controller, and then to put instances of your child controller onto each page.
Since that could all be a little memory intensive, you should really only have three instances at any one time (one being displayed, and one one either side so that they're ready if the user starts to scroll). The Apple demo project shows you how to configure a scroll view like that:
https://developer.apple.com/library/ios/samplecode/PageControl/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007795
Hope that helps.
I am subclassing UIApplication to intercept and display touches in my TouchDisplay view. I would like to extend the Application, Window, Delegate or Main ViewController in order to keep my TouchDisplay view on top of all other views. As my and most other applications work, views and controllers are added and removed all the time. I figure the correct answer will be able to deal with these additions and removals and stil keep the TouchDisplay view on top.
Thanks for your help,
Joe
Here are a few approaches you could take for this:
If you're targeting iOS 5+ and iPad only, you can make a top-level view controller which has two contained view controllers. The first would be a view controller for your "TouchDisplay" view. The second would be the application's normal root view controller. (i.e. your existing main view controller; you'll need to set definesPresentationContext to YES on this view controller) Since you're writing the container view controller, you can order those two subviews however you like. There is a WWDC 2011 Talk on view controller containment that goes into great detail about this. This is the most "correct" approach IMHO, because it gives you a view controller for your TouchDisplay view, handles rotation and generally plays nice with others. (This only works on iPad, because on iPhone a new modal view always covers the full screen.)
A more straight-forward approach is to simply add your TouchView to your existing top-level UIWindow as a subview with addSubview:. Most applications don't actually remove the top-level view controller or add new top-level ones; they just present other view controllers from it. A view you add in the top-level window will stay above those. Of course, your app may not follow this rule, in which case you might try option #3 instead. This has rotation gotchas (your view will not auto-rotate when the device rotates, so you need to do this yourself.) You could also force your view back to top, say, on a 1-second timer, if you are having issues with other things covering it. This is also not as nice as option #1 because you don't get a UIViewController, just a UIView.
The most extreme approach is that you can create another UIWindow and give it a higher window level, such as UIWindowLevelAlert and put your TouchDisplay view in that. You can then make the window background transparent, and it will stay above your normal app content. There are lots of gotchas here, especially about auto-rotation and which window is the keyWindow (which is why you should use #1 or #2 instead if you can).
After some time I was able to get my app working. I have made an easy to use overlay that shows touch feedback over your existing application.
You can download the project here:
https://github.com/megaplow/FingerTracks/tree/master/FingerTracks
Happy coding,
Joe
I need to implement a navigation based app with a custom made button bar that stays on the vertical size of the screen, similar to Reeder iPad app (see Reeder screenshot).
What is the best way to achieve that result? I thought about adding the bar as a subview of the UINavigationController and calling its methods (like pushViewController:animated:) via the parentViewController reference from my button bar view controller, but it seems a bit convoluted.
Might work, but dangerous: set a transform on the CALayer object of the UINavigationBar. A transform that rotates the bar by "-1 * M_PI_2" would be almost right, you might need to translate it a few pixels too, to get the position correct.
Definitely works, but more effort: render a custom navbar, implement the delegate protocol from UINavigationController, and listen to the nav changing, and implement your own animations inside the callbacks.
(I've done the latter method to provide custom UINavigationBars - it works fine)
The only caveat with latter method is that your animations might pause / delay because by default they wait for each other to finish. If you look at the UIView animations, there's a setting that says "play immediately, even if other animations are in progress", and you might need to set that to YES.