I have a page enabled scrollview on an iPad. On the first page, I have a child scrollview that scrolls horizontally through image buttons. The buttons scroll the outer scroll view to the correct page. Its basically like a table of contents that jumps to the correct page.
My end goal is to be able to categorize the buttons seen in the child scroll view. So there would be a segmented control that changes what buttons you can see. So maybe one category would be ALL, and another category would be A-M, and another would be N-Z for example.
My question is, should I use a uiscrollview or a uitableview?
Right now I use a scrollview and it is really easy to get the buttons in. I could implement the different categories kind of gimmicky by having all of the buttons in the scrollview and then just showing or hiding the buttons accordingly. I feel that it'd be bad memory usage though.
For a uiscrollview i was looking at using EasyTableView, butI'm not 100% sure if this is compatible with what i want to do or if it'd even be better.
Any ideas for what the best way to implement this is? Specifically, I'm not sure of the best way to change the buttons when I change categories.
Thanks!
Use a tableview when you are dealing with data that is best expressed as sections and rows.
I think for your situation I'd have a UIView subclass that can display the images you need for a given category. Stick that on the outer scrollview as needed. You can keep memory low by only keeping the currently visible view and the ones on either side on the scrollview. When you scroll to a new location you can recreate the view needed for that page, and the ones surrounding it. Then you release the ones that are far away and let the system reclaim their memory if needed.
Related
I need advice on the most pragmatic way to layout the following view. As you can see from the image attached, I have a static logo and text that appears at the top of the view, followed by a variable number of items.
Initially, I was going to use a TableView for the variable number of items, that way I would be able to load any given number of cells at runtime.
My problem is that if I drop a tableView onto this view below my static logo and text, when the user scrolls, the static logo and text will remain fixed. I need both the static logo/text AND the tableView to scroll up.
My next inclination is to use a scrollView, inside which I would place my tableView and static logo.
Is this the most pragmatic way to approach the problem? If so, will there be usability issues when scrolling the scrollView vs scrolling the tableView? In my mind this could get messy.
Any advice on the best way to approach this is greatly appreciated.
Using a table view inside of a scroll view is a bad idea and warned against by Apple in their docs. Basically the internal gesture recognizers can conflict and create a clunky user experience. The best path forward would be to go with the tableview (which is a subclass of scroll view) and have two different kinds of cells– one for the logo and one for the repeating contents at the bottom. Make the first cell the logo and adjust the table view's settings to format it to your heart's content.
I have a UIScrollView with textviews as subviews. Now in my app there are multiple UIScrollViews like these. And depending on the selection I display the appropriate UIScrollView on top of the previous view. This works fine in all cases except when the previous view has been a UIScrollView as well. In this case the behavior I get is of two UIScrollViews stacked on top of each other and both the views capture the scrolling events. The textViews from previous scrollView is also visible (not editable though) and overlaps and causes all sorts of issues. The thing is a full screen UIScrollView placed as subview to a previous view causes problems when the previous view is a full screen UIScrollView as well.
Any pointers on how to overcome this would be great. Is there anyway to notify the parent scrollview of the child's scroll events and move it the exact same way so this mess is masked?
Thanks!
UIScrollView documentation says:
Important: You should not embed UIWebView or UITableView objects in UIScrollView objects. If you do so, unexpected behavior can result because touch events for the two objects can be mixed up and wrongly handled.
As far as I know, it is generally not recommended to embed a UIScrollView subclass instance in a UIScrollView. In one of my projects, which is an IM application, I have a UIScrollView that contains many UITableViews, it works when you try enough but it really takes a lot of effort to handle subtle bugs and make it work properly.
It is really hard to say something useful for your problem without diving in to code, but i can recommend you to not add UIScrollViews one on to another like a stack. I'd try doing it by allowing only one UIScrollView at top, and removing others. When you need to show another one, remove the top one from view hierarchy and add the new one. I wish this helps, good luck.
Found a crude solution by presenting an empty view before I present the next scrollView. Added the scrollView as subview to this empty view (with a BG image) and added the to-be presented scrollView as a subview to it and then presenting this on top of the previous scrollView.
I'm trying to figure out if I can get what I want out of UIScrollView through some trickery or whether I need to roll my own scroll view:
I have a series of items in row that I want to scroll through. One item should always be centered in the view, but other items should be visible to either side. In other words, I want normal scrolling and edge bouncing, but I want the deceleration when the user ends a touch to naturally settle at some specified stop point. (Actually now that I think of it, this behavior is similar to coverflow in this respect.)
I know UIScrollView doesn't do this out of the box, but does anyone have suggestions for how it might be made to do this, or if anyone's spotted any code that accomplishes something similar (I'm loathe to reimplement all the math for deceleration and edge bounce)
Thanks!
There is not a whole lot of trickery to this. Just use an UIScrollView with paging enabled. Make it the size of one of your items, and locate it where you want that item to appear. Next, disable the "Clip Subviews" option on the scroll view (either in IB, or programmatically), and you are all set.
I have a problem, I can't solve properly.
In short: I want to create a single view (say: UIImageView) out of multiple subviews - i.e. it consists out of multiple ImageViews and TextViews. The thing is, I want to sort of 'render' them to be a single View.
Say, I take an image, add some description below, add a title above, and maybe another little image at the bottom. I want this whole thing to be a single UIImage to make it sort of 'listen' to one (e.g.) swiping gesture, which I cant tell to bring the new image to display.
Does anyone know the best way to achieve this? So far my results were fairly poor.
Any hints are welcome!
This is definitely possible. You seem to know about views and subviews, but should also read up on the "UIResponder" class and the "responder chain". The master view that you want to contain them all won't be a UIImageView, though, because that exists to just show an image. You can make all the ones you talk about subviews (addSubview: or in Interface Builder) of a plain UIView that you subclass yourself (say, MyContainerView), which then itself handles the gestures. If you want to take advantage of free scrolling on swipe, you could instead put your container view into a UIScrollView, which has its own set of semantics that you can leverage. For this latter, you should check out Apple's sample code for scroll views (don't have a link handy but should be easy to find) which embeds multiple image views in a scroll view.
For a vertical scroller are there any advantages to using UIScrollView over UITableView?
I ask because I am currently using two vertical UIScrollViews with UIImageViews inside of them and am having memory issues and poor scrolling performance. I am not doing much with the scrollers, only highlighting images as they scroll into the center of the scrollviews and adding a delete button above an image if the user wants to remove it. I've started to look at lazy image loading/reuse and it seems that most of these issues have already been resolved in the UITableView class, so I'm wondering if there's any reason to stick with UIScrollView?
You should be able to use a UIScrolLView with no problem if you just, like you said, lazy load the controllers, when scrolling (assuming your views are full size) you dont need to have more than 3 views loaded at any one time, all you need is the current view, the view that goes behind it and infront of it, as you scroll your view you can unload and load the appropriate views. You should look into Page Control sample application, it does exactly this and you can pretty much get all the lazy loading code from there. Link is here https://developer.apple.com/iphone/library/samplecode/PageControl/index.html