I have a set of items with images, videos and .gif images that are displayed in a UIWebView that are being rendered dynamically when user scrolls to the bottom of the scree and reaches the end of the current UIScrollView offset. When downloading the items from the web I can display an activity indicator that makes user experience smooth and nice, but when I have all the data cached and retrieve it from cache I have a pretty annoying lag when all the items are being rendered at the same time (5 items per loading operation). My question is: Is it possible to somehow remove the lag from the UIScrollView when rendering items on it? And how can I display an activity indicator when rendering items on main thread? Specifically the lag happens when user scrolls to bottom, the scroll freezes, all items are rendered and scroll continues to go to bottom with the same force user has dragged it with.
P.S. I cannot use UITableView, so please do not suggest using it instead of scroll view.
You should consider using NINetworkImageView from the Nimbus project: https://github.com/jverkoey/nimbus
The reason it works well in your scenario is because it's manipulating the fetched image on a different thread. It does things like cropping and resizing and just gives you the end result on the main thread.
For a more complete sample, please see my answer here: https://stackoverflow.com/a/10361005/434841 for a similar question.
Related
We currently use react-base-table as our solution for an infinitely scrolling table component, but it runs into performance problems with a large number of columns because it does not virtualize horizontally. My understanding is that ag-grid does, so we are looking at it for primarily performance reasons.
Our app defaults to displaying data (log events) from bottom to top. The user is initially placed at the bottom of a potentially large virtual dataset (could be millions of events), and they scroll up to load and view more events (200 at a time).
After reading through ag-grid docs and searching here, I don't see anything about support for an upward direction for infinite scroll. Am I missing anything?
I've tried implementing it with the default row model, but am running into errors (eg "cannot draw while in the middle of drawing rows"). The 'onViewportChanged' event I'm using to trigger a fetch is called several times when rendering, and messes up our data model. Infinite scroll seems like the correct approach.
Yes, it is possible.
You will need to set serverSideInitialRowCount={1000} so the grid could adjust scroll size. And then in the onGridReady event call api.ensureIndexVisible(999).
The grid will request only the last data block, and will request other blocks as you scroll up.
So I am working working on something in unity (2d game). I have a list of button (UI) on my scene and I want to implement a scrolling mechanism. What is the best way to go about it? Currently , I can scroll through horizontally because I have added a "scroll rect" to the the canvas holding the buttons as I start the game. However when I try to scroll back (horizontally, it goes beyond the Buttons. Is there a way to make the scrolling continuous such that as I scroll, from the first UI element when I get to the last one and I keep scrolling, it continues with the first element. or what should I do. please let me Know If i should clarify.
In the Scroll rect you can set the movement type. I don't think the kind of "infinite scroll" you are asking for is available.
For your case, I think that the Use Elastic or Clamped mode to force the content to remain within the bounds of the Scroll Rect should do the work.
In the case of the infinite scroll specifically needed, you would need to ask for that explicitely and show your attempt for more specific help.
Im trying to implement a nice accordion effect on my app. My goal is to "open up" a cell when the user tap on it, diplaying additionnal content (such as text) as the cell height increase.
The perfect sample code for that is the TableView Animations & Gestures sample code provided by Apple. However I am experiencing a strange behavior, that ruins the whole effect.
It appears that depending on the order in which the tableview will display its cells (top --> Bottom or Bottom-->up) the cells textviews will overlap each other or not.
As its a bit difficult to explain with word so here is it with images.
Those screenshots were taken from the TVAnimationsGestures Sample Code, without any changes made to it. It comes from the first version of the sample code without storyboard:
Now the version with the storyboard, first behaved well, but after a while, and without me touching the code it started drawing this :
And I have the exact problem on my custom with my custom cells.
It took me a while to understand what I think the problem comes from. If cells are drawn from the Top cell to the bottom, there is no such problem. However if cells are drawn bottom to the top, they will stack in reverse and therefore overlap each other. I don't think it is possible to control this behavior.
What gave me the hint, is that when I scroll down, forcing the top cell to redraw, they actually redraw nicely, and the screen looks like this:
A Mixture of overlapping cells and "good" cells.
Again, this all comes directly from Apple sample code, without any changes.
Does anyone knows whats going on?
Thanks a lot for your help.
You can increase the cell height by pinching on the cell.
I'm trying to make a level-of-detail line chart, where the user can zoom in/out horizontally by using two fingers, and grow the contentSize attribute of the the UIScrollView field. They can also scroll horizontally to shift left or right and see more of the chart (check any stock on Google Finance charts to get an idea of what I'm talking about). Potentially, the scroll view could grow to up to 100x its original size, as the user is zooming in.
My questions are:
- Has anyone had any experience with UIScrollViews that have such large contentSize restrictions? Will it work?
- The view for the scroll view could potentially be really huge, since the user is zooming in. How is this handled in memory?
- Just a thought, but would it be possible to use UITableViewCells, oriented to scroll horizontally, to page in/out the data?
This is kind of an open ended question right now - I'm still brainstorming myself. If anyone has any ideas or has implemented such a thing before, please respond with your experience. Thanks!
This is quite an old topic, but still I want to share some my experiences.
Using such a large UIView (100x than its origin size) in UIScrollView could cause Memory Warning. You should avoid render the entire UIView at once.
A better way to implement this is to render the only area which you can see and the area just around it. So, UIViewScroll can scroll within this area smoothly. But what if user scrolled out of the area that has been rendered? Use delegate to get notified when user scroll out of the pre-rendered area and try to render the new area which is going to be showed.
The basic idea under this implementation is to use 9 UIViews (or more) to tile a bigger area, when user scrolled (or moved) from old position to new position. Just move some UIViews to new place to make sure that one of UIView is the main view which you can see mostly, and other 8 UIViews are just around it.
Hope it is useful.
I have something similar, although probably not to the size your talking about. The UIScrollView isn't a problem. The problem is that if you're drawing UIViews on it (rather than drawing lines yourself) UIViews that are well, well off the screen continue to exist in memory. If you're actually drawing the lines by creating your own UIView and responding to drawRect, it's fine.
Assuming that you're a reasonably experienced programmer, getting a big scroll view working that draws pars of the chart is only a days work, so my recommendation would be to create a prototype for it, and run the prototype under the object allocations tool and see if that indicates any problems.
Sorry for the vagueness of my answer; it's a brainstorming question
But still, this approach (in the example above) is not good enough in some cases. Cause we only rendered a limited area in the UIScrollView.
User can use different gestures in UIScrollView: drag or fling. With drag, the pre-rendered 8 small UIViews is enough for covering the scrolling area in most of the case. But with flinging, UIScrollView could scroll over a very large area when user made a quick movement, and this area is totally blank (cause we didn't render it) while scrolling. Even we can display the right content after the UIScrollView stops scrolling, the blank during scrolling isn't very UI friendly to user.
For some apps, this is Ok, for example Google map. Since the data couldn't be downloaded immediately. Waiting before downloading is reasonable.
But if the data is local, we should eliminate this blank area as possible as we can. So, pre-render the area that is going to be scrolled is crucial. Unlike UITableView, UIScrollView doesn't have the ability to tell us which cell is going to be displayed and which cell is going to be recycled. So, we have to do it ourselves. Method [UIScrollViewDelegate scrollViewWillEndDragging:withVelocity:targetContentOffset:] will be called when UIScrollView starts to decelerating (actually, scrollViewWillBeginDecelerating is the method been called before decelerating, but in this method we don't know the information about what content will be displayed or scrolled). So based on the UIScrollView.contentOffset.x and parameter targetContentOffset, we can know exactly where the UIScrollView starts and where the UIScrollView will stop, then pre-render this area to makes the scrolling more smoothly.
I have a bunch of small png images with about 45 x 45 pixels of size. not really big ones. there are about 40 of them right now.
I want that the user can select one of them as his avatar image. For this, I created an brand new view with an controller class. Now the problem is: How to display all those images to the user? There's no "big view". When the user touches one of them, it's going to be selected and the view switches back to the main view, where he's going to see his selected image. When he touches it, the image selection view will appear again.
So I thought about an table view, but it feels not right. The images have no title to be displayed, so it would be a big waste of screen space.
Any ideas? Should I programmatically generate a grid of UIImageView objects?
A grid is correct. Think iPhone Photos application. No need to make a completely new widget though, add multiple image views to table rows, segmenting them.
A grid seems like a good solution as it mirrors the wallpaper ui in settings so the user knows what to expect.
Another option in this case would be to use a UIPickerView. It takes up less screen space, and can be shown on the main screen (just pop up from the bottom, let them pick one, then disappear).