I want to implement a grid view like the one in Pinterest
I thought about implementing as 3 table views. But I was not able to scroll them together well. When I implemented the scrollViewDidScroll and set the contentOffset for the table views other the scrollView , the scrolling became slow and unusable.
Another implementation I did was of was having a set of images to load and calling the viewDraw function in scrollViewDidScroll. The ViewDraw function just draws the necessary images and removes the rest of the images from the memory which were already drawn but wont be visible .
this too makes the ScrollView scrolling slow. And another issue with it is that there are white(background color) patches before the images are drawn.
What should be the best way to implement this grid view ?
Solution 1 (i don't know if this works and I don't like it very much)
How about having 3 vertical table views side by side, but forward any touch events from any tableview to the other ones. I understand that you had performance problems when trying to sync the tableviews, but maybe working on an event level things would work better. Maybe.
Solution 2
Use a UIScrollView (for the scrolling purposes of course). For performance and memory reasons you also need to implement a load-on-demand mechanism so that you don't load all your images at once.
To do this I would create a class, CustomImageStrip that handles a vertical image list. This class works together with the scrollview and uses contentOffset to decide when it is time to load/unload a image from the strip.
By having 3 independent image strip classes, the images can be of any size and don't need to be aligned. But, since they all belong to the same UIScrollView the scrolling will be done simultaneously.
Related
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.
I want to create a scroll view with a massive contentSize that will display content inside it. The content will be mostly text (a few small images will be drawn for content-boundaries).
So, think like a tiled map application, but tiling labels instead of tiled images.
Performance is critical in this application, so I think I should avoid using UILabels or any UIViews at all inside the scroll view.
How can I draw these labels as the user scrolls around? Some options I've considered:
override drawRect: in the scroll view and draw everything within the window - this seems like it would be really slow. Sometimes drawRect is called with only a 1 pixel difference.
Same, but keep track of which ones I've already drawn
Draw them from the "outside" somehow, like from the scroll view delegate - I can't figure out how to use [#"mystring" drawInRect:] outside of drawRect: (context problems)
Is there something I haven't thought of? I know the scroll views were designed to be able to handle this kind of problem, but I'm not sure what the designed way is. Thanks!
The standard way to achieve this in an iPhone application is to create a normal UIScrollView that is the size you want it to be, and to populate it either directly with a CATiledLayer if you're feeling brave or with a custom UIView subclass that uses a CATiledLayer and implements - (void)drawLayer:(CALayer*)layer inContext:(CGContextRef)context.
CATiledLayer provides the same experience as Safari — it's good for views that are much larger than the screen and which are expensive to render, but which you don't want to ruin the fluidity of the user experience. It'll request tiles as and when it needs them on a background thread, then fade them in (according to a fade of any length, so you can cause them to appear instantly if you desire) when they're ready. If your program really can always keep up with the scrolling and you've requested an instant appearance then there'll be no evidence that there's an asynchronous step involved.
An example people tend to point to is this one, but if you're new to implementing your own UIView subclasses then it might be worth seeing e.g. this tutorial. Then look into the + layerClass property on UIView and the various properties of CATiledLayer (which I think you'll also possibly need to subclass since + fadeDuration is a class method).
I am new to iPhone development. I am parsing a xml and display the title, date, contents and image in the cell. Now the scrolling is not smooth, it is stuck.
How can I increase it? I have already applied lazy loading in another view, I am not able to apply in the new view. So how can I increase the scrolling performance? Can I check for any condition that if image is already loaded in the image view, so I can stop once again the loading of image view?
What I do to guarantee fast scrolling in a table is to subclass my own UITableViewCell where I implement all properties that I need.
Whenever that tablecell is initialized I draw the properties of the cell on the cell itself. So when you need an image on there, dont use an UIImageView, but just draw the image on the cell. Also all the text I need I just draw on there.
After a long stuggle finding out how to do all this, I also found a nice blog post about this.
http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/
First of all, check if you're not resizing the images - that takes a lot of computing power, and will slow down the table for sure.
Second of all, check for view hierarchy - complicated view hierarchy means bad performance. Rembemer to use as much opaque views as possible, and when you're using non-opaque views don't make the cells too complex(by complex Apple means three or more custom views). If the views are too complex - use drawRect method for custom drawing of the content.
There's a great example on how to achieve this provided by Apple called AdvancedTableViewCell (here's a link), and there's a great tutorial by Apple about table view cells (another link).
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