Im making an endless type game where the view scrolls similar to like doodle jump except it scrolls down vertically not up vertically. How do you accomplish this? Should I set Up a scroll view and and use the methods to manual scroll? I just feel like that would cause a memory leak after some time
This is not a ScrollVIew, this is just OpenGL, or framework based on it (like aforementioned Cocos2D)
Related
I've seen iOS apps that allow users to scroll around a view that is larger than the screen itself, without seeming to implement a UIScrollView mechanic. So for example, the actual image displayed on the screen is double the width of the screen, and the user can pan left and right to view all the content. Is this just a case of making the ViewController's width twice that of the screen and allowing some kind of panning via gesture recognizers? With what I'm trying to do, it seems like this would be easier that implementing a UIScrollView...
Implementing scrollview is much easier than handling pan gesture, when Apple has given built-in functionality then why you do not want to use it?
You can either use UIPangestureRecognizer or UIscrollview. The Latter option is very simple.
I have a paged scroll view in my app and it works almost perfectly... Usually one page looks like this:
There is no content below this, but when i move it as if it should scroll down (clicking and swiping upwards) it stops moving at this stage:
It's as if its decided that that is an acceptable page loaction or something. If i drag it part way up it snaps the rest of the way up, and if i drag it part way down it snaps all the way down.
Why is it considering this an acceptable place to stop? Is there an easy property to set im missing? Or is there a way to allow only horizontal scrolling?
Thanks
Check the contentSize property of the scroll view. That determines how far it will scroll, and you can manually set it to control exactly where it will scroll to.
Is the scroll view on 0,0 on the canvas? It looks like it is not actually centered on the screen.
I'm developing my first iPhone app and I would greatly appreciate you guy's input on a problem I'm having.
I'm looking to implement scrolling both horizontally and vertically. I want the horizontal scrolling to be paged, without the vertical one being paged (scrolling "normally"). A single UIScrollView with pagingEnabled set to YES will page in both directions. The natural solution would be to nest a UIScrollView inside another one, however when I do that, I can't get the "inner" UIScrollView to scroll at all. Seems the outer one is "eating" up all the tap events, like in:
UIScrollView : paging horizontally, scrolling vertically?
I read something about "inner scrolling" being improved upon in SDK 3.0 and actually when I add an inner UITableView instead of a UIScrollView the scrolling works flawlessly. Since UITableView subclasses UIScrollView I imagine that my desired behavior should be achievable by making my own subclass of UIScrollView.
Is this the right approach? If so, what should this subclass look like?
This works out of the box with the SDK now. See Scrolling Madness and Apple's UIPageControl sample for guidelines on how to implement paged horizontal scrolling with a view controller for each page.
The nested UIScrollViews you add as subviews to your outer UIScrollView should have the same frame heights as the container. If you do this then the outer UIScrollView will pass through the vertical scrolling events to the subview. My app has three levels of UIScrollView and UIWebView nesting and I've found Cocoa is really intelligent about passing the events to the one I want as long as I set my frame sizes so that only one view is really scrollable (contentSize > frame) on each axis.
If you are trying something like Twitter profile UI I achieved this by putting header view and bottom scrollview in a a parent scrollview and underlaying another scrollview behind.
Underlaying scrollview is responsible for the adjusting content offsets of header and bottom. Its contentsize is also adjusted by the inner item heights.
It looks complicated when I tell, better see the code
https://github.com/OfTheWolf/Twitterprofile
I've been using this great lib by Andrey Tarantsov for months: SoloComponents
You can use it as an "horizontal UITableView" with support for pagination and view recycling.
Well made and perfectly cocoa-style designed.
Based on Dylan's answer, in my case, I actually also had to make content size heights equal for both parent and nested UIScrollViews to make nested UIScrollView to scroll vertically. Making only "the same frame heights as the container" as Dylan explained was not enough:
parentScrollView.contentSize = CGSizeMake(parentScrollView.contentSize.width, desiredContentHeight);
nestedScrollView.contentSize = CGSizeMake(nestedScrollView.frame.size.width, desiredContentHeight);
What Dylan says. And, perhaps of interest on this topic - you do not need to enable scrolling in the master "paging" UIScrollView, just enable paging and direction lock. This seems to assure that all vertical scrolling cues go to the nested, fixed-size, vertical-scrolling NSScrollViews. It works back to at least iOS 9.
They "brush" the subject in this thread, but it does not really answer much:Stackoverflow UIScrollView question
I have a UIScrollView and a UIPageControl working together to present a set of views.
(Standard "Home screen" swipe style, in lack of better words)
Each of these views, inside the scrollView, has a thin menu in the bottom part, that can also be swiped from side to side. If anyone remember the previous FaceBook app, this also had a menu that could be swiped horizontally, however, not incased in another scrollView, but the idea is similar.
So the outer scrollView will scroll the entire view, including the view containing the inner scrollView, but the inner scrollView will only change a menu inside the view.
I already did a proof of concept test of this, what happens, is that delegate methods gets called in both the scrollViews no matter where on the screen the swipe takes place, and the innermost scrollView will crash the app when swiped left to right, but not right to left…
I sort of get the feeling that this can be done, but that Im going about it the wrong way.
Is there a way to set which area of the screen reacts to swipes? i.e. decide that the upper ¾ of the screen will call one set of delegate methods and the bottom ¼ will call another set.
Maybe through some sort of mediator that catches the swipes before they are "processed" and then determines which scrollView should react?
Hope someone can point me in a good direction on this one, thanks:)
What about de-nesting the scroll views? Instead of embedding a scrollview inside another scrollview, make them same-level siblings of a parent UIView.
In support of your nesting though, I can think of the App Store app which lets you scroll screen shots horizontally while the app description scrolls vertically.
I'm working on an iPhone game, and trying to use a UIScrollView to display some icons, which I then want to enable the user to drag off the bar being scrolled, onto another view (basically, dragging them from their hand into play on the game board). The problem is that the UIScrollView clips everything outside it's own bounds.
Here is a picture of what I'm trying to do:
Functionally, it actually works, in that you can drag the icons up to the white board fine...but you can't see them as you are dragging...which is not acceptable.
Does anyone know if you can temporarily disable the clipping that a scroll view does, or is there some way to get around it? Hacky or not, I would really like to make it happen.
Does anyone have any other possible solutions for this? Or maybe any alternate approaches? I've considered if maybe a page view might work, but haven't tried it yet...and it's not at all as good of a solution as the scroll view.
Worst case I can just go back to not having the bar scrollable, but that really puts a damper on some of my game mechanics, and I'm really not too excited about that.
I think you're looking for the clipsToBounds property of UIView. I've used it successfully with UIScrollView:
scrollView.clipsToBounds = NO;
However, the dragging you want to do from the scroll view to the game view may require you to remove the icon view from the scroll view, place it in the superview at a position corresponding to its visible position within the scroll view (calculated using the scroll view's origin and content offset), and have that track the user's finger movements. On a release of the touch, either drop it on the game view at the proper position or return it to the scroll view.
I'm not 100% sure I understand the question but I think you should look into the z order of the scrollview and the whiteboard. It may be that the drag is just going behind the whiteboard.
Failing that, it would be useful to see all the bounds of your view heirarchy.
I also think a better solution allround might be to create a "sprite" to animate underneath the players finger - you could offset the drawpoint of the sprite from the touchlocation so that the player can see what they are dragging.