I am making a SpriteKit game I was wondering if there was a way to prevent more than one touch at a time.
in my game an object gets added at every touch and I kinda don't want that. (even though its hilarious) if there is a way how do I do it? what would I use? and could you point me in the right direction? and I know that there are ways to do it as I have seen multiple games with that feature.
would I put something into 'appdelegate.swift' to prevent that or would it have something to do with the 'touches began' function I have tried several methods but none seem to work also I have searched all over google but to no avail.
if somebody could help me with this I would appreciate it but its not really that important as it doesn't upset the balance of the game at all.
You can use multipleTouchEnabled property of a UIView:
When set to YES, the view receives all touches associated with a
multi-touch sequence and starting within the view's bounds. When set
to NO, the view receives only the first touch event in a multi-touch
sequence that start within the view's bounds. The default value of
this property is NO.
Use it like this self.view.multipleTouchEnabled = false, where self is a scene.
Related
I use SCNTransaction to move game objects. More specifically, when the player taps somewhere on the screen, the object will move towards that destination. But sometimes the player may make a wrong move, so I want to create a button which can terminate all SCNTransactions.
However, unlike SKAction, which can be terminated with a simple line - self.removeAllActions(), SCNTransaction cannot be terminated or even paused from the outside according to the Apple Developer Documentation. Even worse, I find that before the object reaches its destination, its position has already changed to the destination's position, so I cannot simply use another SCNTransaction to counteract the ongoing one after knowing the object's current position.
Can anybody give me some hints? Thanks a lot.
SCNTransaction and its animation principles follow the one of Core Animation and CATransaction. To stop an animation you will have to set the model value to the current presentation value. For instance:
node.position = node.presentation.position
But if you are familiar with SKAction and would like to implement the same logic in your SceneKit app, you might want to have a look at SCNAction. They work identically.
I have been only using Xcode 5 for a little while now and I need help when it comes to auto scrolling a UIScrollView. I am using a single view application. I need the screen to scroll down at a pace that speeds up incrementally. Also I need the screen to keep progressing even when the screen is touched. If someone can explain which code goes where it would be great! Your help will be greatly appreciated. :)
Check out this library: https://github.com/danielamitay/DAAutoScroll
It stops to scroll when the user touches the screen and that's the only solution I see possible. I don't even see why you wouldn't want the user to be able to stop the scrolling..
OK, just adding this from your duplicate question.
I suspect the Piano Tiles game is actually using something like Sprite Kit.
This allows a lot more control over thing like "scrolling" speed.
Instead of using a UIScrollView you would use an SKNode as a layer with the buttons added to that parent layer.
Then using the update game loop you can incrementally increase the speed of the movement based on the time since the game started.
In essence... don't use UIScrollView, don't use UIKit, use SpriteKit.
I can see a few options:
1) suggested by Fogmeister, use Sprite Kit instead.
2) see setContentOffset
3) just use a normal view as parent, then have another child view on top with the full content (would be longer than the parent view), create a NSTimer to periodically call a method which scrolls the child view in whatever direction and speed as required.
Note that might need something on top to mask around the child view from showing the suppose-to-be-hidden sections of the child view.
Hope this helps
When I demo my touch apps to remote teams the people on the other end dont know where I am touching. To remedy this, I have been working on an event intercepting view/window that can display touches over applications. No matter how may variations on nextResponder I call, I am unable to react to the touch and pass it along to the controllers underneath. Specifically scroll views dont react nor do buttons.
Is there a way to take an event, get its position, then pass it along to what ever component would have been responding to it initially (the controller underneath)?
Update:
I am making some progress with a UIView. The new view is always returning NO to pointInside.This works great for when the touch starts, but it doesnt track moves or releases. Is there a strategy to adding gesture recognizers to the touch in order to track its event lifecycle?
Joe
You could try creating your own subclass of UIApplication that overrides sendEvent:. Your implementation should call [super sendEvent:event] as well as process the event as needed.
Update your main.m and pass the name of you custom UIApplication class as the 3rd parameter to the call of UIApplicationMain.
After some more due diligence, I found my oversight. In the layer that was on top and displaying the touches, user interaction needed to be set to false. Once I set that to false, I was able to use that layer for display while catching events on the layers below. The project still isn't done but I am one step closer.
Take care,
Joe
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.
Imagine a view with, say, 4 subviews, next to each other but non overlapping.
Let's call them view#1 ... view#4
All 5 such views are my own UIView subclasses (yes, I've read: Event Handling as well as iOS Event Guide and this SO question and this one, not answered yet)
When the user touches one of them, UIKit "hiTests" it and delivers subsequent events to that view: view#1
Even when the finger goes outside view#1, over say view#3.
Even if this "drag" is now over view#3, view#1 still receives touchesMoved, but view#3 receives nothing.
I want view#3 to start replying to the touches. Maybe with a "touchedEntered" of my own, together with possibly a "touchesExited" on view#1.
How would I go about this?
I can see two approaches.
side step the problem and do all the touch handling in the parent
view whenever I detect a touchesMoved outside of view#1 bounds or,
transfer to the parent view telling it to "redispatch". Not very
clear how such redispatching would work, though.
For solution #2 where I am getting confused is not about the forwarding per se, but how to find the UIVIew I want to forward to. I can obviously loop through the parent subviews until I find one whose bounds/frame contain the touch, but I am wondering if I am missing something, that Apple would have already provided but I cannot relate to this problem.
Any idea?
I have done this, but I used CALayers instead of sub-UIViews. That way, there is no worries about the subviews catching/redispatching events to the parent UIView. You might not be able to do that, but it does simplify things. My solution tended to use CGRectContainsPoint() a lot.
You may want to read Event Handling again, as it comes pretty close to answering your question:
A touch object...is associated with its hit-test view for its
lifetime, even if the touch represented by the object subsequently
moves outside the view.
Given that, if you want to accomplish your goal of having different views react to the user's finger crossing over them, and if you want to do it within the touch-handling mechanism provided by UIView, you should go with your first approach: have the parent view handle the touch. The parent can use -hitTest:withEvent: or -pointInside:withEvent: as it's tracking a touch to determine if the touch is in one of the subviews, and if so can send an appropriate message.