Ok, I have a somewhat trivial question that bugs me. When I present a new UIView, should that view control how its displayed and removed?
It feels like that would be a good idea, the view becomes self contained. Similar to UIAlertView:
[alertView show];
But on the other hand, it feels like something else should control it and should not be left to itself.
[self.view addSubview:newView];
[UIView animateWithDuration...];
Or is this 6 one way, half a dozen the other?
UIAlertView is a special case—it gets added to its own window, not any existing part of your view hierarchy. If you’re not doing anything special like that, your second example is the correct approach.
That said, if this view is a custom class that you’re going to use in multiple places and want to behave consistently, it should control its own presentation. For instance, UIActionSheet’s -showInView: method takes care of adding itself as a subview, positioning itself, animating in, and so on.
Related
I want to ask a simple question how can I temporary bring a subview to front to view its element without changing its position by dragging and dropping. The problem i face all the time is i forgot to put the views back to there position and that causes lot of trouble specially if you are working on the view that have large number of subviews.
Question : Is there any shortcut or any functionality that can show the view temporary without dragging, changing its frame or making any changes in its hierarchy.
For a view controller like this :-
FYI, for those who are wondering, the view closest to the bottom of the list (on the left) will show in the front. So in the case below, view 'a' will be in front of 'b' and 'b' will be in front of 'c'
XIB:
If you need your views to be readily accessible for viewing/editing without having to rearrange them, I would actually recommend breaking them out into their own view and then stitching them together in the correct order in your code. This will ensure that all elements will be put in the proper order and will always be easily editable. Something like this:
And then in your code, in somewhere like viewDidLoad:
[self.view addSubview:view2];
[self.view addSubview:view3];
I want to make a pretty interface. So after reflexion, I decide to make a pattern with to axes but with some essential points. The red screen is the primary screen, all start by this one.
We can only make this two move : red to another color and another color to red. And change are made with GestureRecognizer.
I also want to switch view by seeing the two at the same time. Obviously, it's following my finger and I can stay in this state.
Do you think that 5 viewController witch are all load at the start and we came to these with pretty segue (maybe custom) is possible ? And if yes, do you have an idea of how to make this ?
As a first thought I think you want to make a custom view controller navigation controller. Like UINavigationController, UITabBarController or UIPageViewController.
I'd also use a scroll view over a gesture recogniser maybe?
Either way it's gonna be a lot of work which means there are many many different ways to do it.
It sounds like you have a decent idea of how you want it to work. Give it a whirl and see what happens. I reckon you can have a decent bash at it.
If you get stuck let us know and we'll try to help :)
I am developing a little MS tweak that adds a view on the Springboard. I want it to be constantly updated so I called it into the
- (void)showSpringBoardStatusBar
Then I create and add the view using this:
[[UIApplication sharedApplication].keyWindow addSubview:view1];
Is this the right way?
But the problem is this view uses a low alpha level to be transparent and every time the view is updated by the showSpringBoardstatus bar another UIView is added onto of it eventually just making the view solid. This also is uneconomical in terms of memory. so then I went back an added what I thought would remove the code:
view1 = nil;
[view1 removeFromSuperview];
But it seems like this doesn't make a difference as it is still there and nothing changes.
I have been searching for the last few days for anything to help me with this but got nothing out of it. All I can think of is that I can't remove an added subview from a key window like I would from a normal view or I just don't how to do it correctly.
Any help would be appreciated. Thank you.
Setting view1 to nil and than calling "removeFromSuperView" might be a bad idea. How about adding the view only once, keeping a reference and updating this reference constantly without adding it to keyWindow again?
So, I have a setup where an UIPopoverController presents information at the cursor in a text view. When the cursor moves, I present it again. But this is jarring, and I'd like for the popover to move in a smooth, animated fashion. Will I really have to do that manually by using a series of presentFromRect calls, or is there a better way?
Unfortunately UIPopovers are not designed to be moved around like that.
The only way to do that without presenting it all over again is to write your own UIPopover replacement and animate its position using the standard CAAnimation or UIKit animation techniques.
If think you cannot do that without use presentFromRect. But if you really want to do this, create your own. Recreate the look of a popover controller using a UIView and track the touches. You can use an alternative like WEPopover.
I know what I want to do, but I'm stumped as to how to do it: I want to implement something like the iOS multitasking gestures. That is, I want to "steal" touches from any view inside my view hierarchy if the number of touches is greater than, say, two. Of course, the gestures are not meant to control multitasking, it's just the transparent touch-stealing I'm after.
Since this is a fairly complex app (which makes extensive use of viewController containment), I want this to be transparent to the views that it happens to (i. e. I want to be able to display arbitrary views and hierarchies, including UIScrollViews, MKMapViews, UIWebViews etc. without having to change their implementation to play nice with my gestures).
Just adding a gestureRecognizer to the common superview doesn't work, as subviews that are interaction enabled eat all the touches that fall on them.
Adding a visually transparent UI-enabled view as a sibling (but in front) of the main view hierarchy also doesn't work, since now this view eats all the touches. I've experimented with reimplementing touchesBegan: etc. in the touchView, but forwarding the touches to nextResponder doesn't work, because that'll be the common superview, in effect funnelling the touches right around the views that are supposed to be receiving them when the touchView gives them up.
I am sure I'm not the only one looking for a solution for this, and I'm sure there are smarter people than me that have this already figured out. I even suspect it might not actually be very hard, and just maybe my brain won't see the forest for the trees today. I'm thankful for any helpful answers anyway :)
I would suggest you to try using method swizzling, reimplementing the touchesbegan on UIView. I think that the best way is to store in a static shared variable the number of touches (so that each view can increment/decrement this value). It's just a very simple idea, take it with a grain of salt.
Hope this helps.
Ciao! :)
A possible, but potentially dangerous (if you aren't careful) approach is to subclass your application UIWindow and redefine the sendEvent: method.
As this method is called for each touch event received by the app, you can inspect it and then decide to call [super sendEvent:] (if the touch is not filtered), or don't call it (if the touch is filtered) or just defer its call if you are still recognizing the touch.
Another possibility is to play with the hitTest:withEvent: method but this would require your stealing view to be placed properly in the subview, and I think it doesn't fit well when you have many view controllers. I believe the previous solution is more general purpose.
Actually, adding a gesture recognizer on the common superview is the right way to do this. But it sound like you may need to set either delaysTouchesBegan or cancelsTouchesInView (or both) to ensure that the gesture recognizer handles everything before letting it through to the child views.