I was curious to know if it was possible to create a website with infinite scrolling that was literally infinite--that is, if the user were to theoretically scroll down forever, that content would continuously be displayed. This content would be a repeated image (an image that is shown and then repeated below itself indefinitely as the user scrolls).
Technically, no. Infinite is a powerful word. However, they could scroll until they crash the browser I suppose:
http://goo.gl/0ZIFlK
Related
I have implemented a client for a paginated REST service where I populate the whole table with empty entries and then load them in the background using pagination when the user starts scrolling the table.
This seems to work very well except for a little detail: I am calling reloadRowsAtIndexPaths: in the main UI thread (because UIKit requires so), and I feel the animation sometimes makes me lose input touches.
This is, the user starts scrolling through the list and items start to load. Sometimes a reload animation happens at the same time the user is just touching the screen again, and this touch is not recognized. The scrolling then doesn't continue and stops. It doesn't happen all the time, and I guess it is an infrequent user case (the user is expected to read each row of results before scrolling down) but it annoys me to no end.
I'm doing most of my animations with blocks and the flag UIViewAnimationOptionAllowUserInteraction is really helpful, so is there a block version of reloadRowsAtIndexPaths where the reload animation would not block the user interaction with the scrolling?
I think the solution you seek is to background-load your data in a thread (as you describe) and only call reloadRowsAtIndexPaths: once the data is received and ready to display. You should also probably redisplay the data NOT animated.
I don't think there's anything you can do to get around the missed touches with your current scheme. My suggestion is to "do what iOS wants" rather than "try to cajole iOS to do what you want." Yes, probably not the answer you wanted to hear, but I think that's just the way it works.
(Btw, you can always use bugreporter.apple.com to make an enhancement request! :)
I tried to implement the lazy loading solution for UIScrollView with paging enabled, as in the PageControl example from Apple. It seems to work fine, the only problem is that as the user scrolls past the 50% of the page, there is this short hitch as the content of the next page is loaded (obviously because loading the next ViewController takes some time and it seems to happen on the main thread).
Is there some way to make the scrolling seem more smooth that would work no matter how fast the user scrolls ?
You need to make sure that anything which takes time happens asynchronously. The techniques for this will vary based on what kind of content you're loading or what sort of drawing you're doing that causes the delays. Try to load images in the background, do custom drawing in the background, use operations or gcd to break up large tasks into smaller chunks that can happen concurrently, etc.
You should be lazy loading the surrounding pages so that they're already loaded when the user scrolls.
So if the user scrolls to page 2, load pages 1 and 3 (if they aren't already)
I'm using core-plot in my iPhone app to display datas in plots from NSMutableArrays.
I display 10 values on the screen and I allowed horizontal scroll only like that I can see all the values when I'm scrolling.
I've got something like 100-200 values in total to load.
I use differents tabBars to handle my differents needs.
Everything works fine, but when I launch my app on the iPhone I have some monstrous laggs when scrolling. Something like 2 seconds after the graph move (on the simulator there is no laggs).
I reload graph when I shake the iPhone.
I work on a 3GS, and there is no other app running in background.
Did someone had and resolved something like that?
Do you need more info?
UITable (and UIScrollView) has a bug in which it causes it to call layoutSubviews on its parent. Check to make sure this isn't causing your trouble. If it is, you may be able to solve it by wrapping the table in another UIView. I do this routinely to avoid this problem.
Another thing that can cause really slow scrolling is a lot of masks, transparencies, etc in your cells. For this, you might try setting the views to rasterize, which means they'll draw themselves once into a buffer, rather than draw themselves every time.
i am developing a book reader on ipad. i am using the swipe gesture to navigate to the next page. But my app is getting hanged on crashed when i try to navigate (swipe) at a fast pace. So, is there any way to restrict the number of continuous or consecutive swipes…???
Please help with me with your inputs. They will help me go a long way in my project. Thankyou
You could throttle the number of swipes you are handling by skipping say every third swipe or so). However, that would just add frustration for the user, as they'll be swiping and nothing would be happening. And if you actually go that route, at least add a wait cursor, so that the user is aware the app is busy.
However, you really should figure out why the app is crashing (or hanging - not clear from your question) and fix it. If the user wants to leaf quickly through the pages, you should let them.
Use a flag that keeps track of when you are paging. When you swipe, only trigger the paging mechanism if the flag is NO, and immediately set it to YES when paging. When your paging mechanism finishes, set it back to NO.
I have a horizontally scrolling UIScrollview with paging enabled. Each page represents a data feed. Each data feed consumes a fairly large amount of memory including text and images displayed in a UITableView. Since the user can have an unlimited amount of data feeds, I need to lazy load them to prevent maxing out my memory usage. My thought is to keep up to 5 data feeds in memory at any given point, and release anything outside of that range. My initial take is to keep the page in the viewport in memory, and the 2 pages to either side of it. This way when the user scrolls, the next sequential page will always be in memory and will display quickly.
Here is my problem:
We also need to support a scenario where a user can skip to a specific data feed, possibly 10 or more pages to the right or left, which throws my entire lazy loading scheme out the window.
Might there be a better strategy to support this scenario?
Yes, what you can do is create an outer scroll view, which houses individual cells akin to a tableview. In this respect, the cells have a content view which you can place your data, let's just assume you know how to do that since it seems you do.
Once you have this architecture in your mind, it becomes fairly clear: You can, knowing the width of your cells, and the size of the screen, some simple math can tell you how many you have on screen, and you can add one to the left or right so you're preloading some data for when the user scrolls.
This will say, give you the ability to have in memory, at most 5 feeds, if 3 are visible, at the start or end of the content view in the scrollview, 4 feeds, regardless of whether or not you have a billion feeds.
One critical part of this is cell reuse. You maintain a couple NSSets, one for recycled cells, and one for visible cells. Add items that have gone off screen to the recycled cells, dequeue items from recycled cells when setting up the cell, as to save additional memory allocations, which can be expensive. Just remember, using this strategy, you are still subjective to the same caveats as a UITableView with respect to cell reuse.
I'm plugging some software I wrote here, so forgive me for that, but I'm doing so as an example of what I'm talking about if you get stuck implementing what I discussed here, it's available here for your perusal.
One final note. To support skipping of cells, it's just simple math again to adjust the point in the scrollview you are at. The action for this can be done with a gesture, though now we're talking a pan gesture recognizer, with some specific properties that will be specific to your application, as an example. Or you can use buttons if you really must. Just ensure you know how to calculate your offsets to your cells, and scroll to that point. You'll be fine.
It's hard to give accurate advice with the information provided in the question. So I will just present a few thoughts I got when reading the question.
Does it take long to download a feed? Would it be possible to just download a few item (a screenful) to get the first few items showing right away? Perhaps lazy load the images if possible.
Have you considered caching the feed data on disk? That way you can present some data right away and then update the feed as new data gets downloaded.
Since each page is a feed view, would the user just scroll past a feed without looking at it? Do you really need to load 2 views on each side or can you get away with just 1 view on each side.
I don't think your lazy loading scheme stops working just because the user can skip directly to any page. You would have to start loading the data for that page when it is selected but by using a disk cache or downloading a small sample could make the app feel faster. I also think that using some kind of animation to animate to the selected page could buy you a little time.
Here is my problem: We also need to support a scenario where a user can skip to a specific data feed, possibly 10 or more pages to the right or left, which throws my entire lazy loading scheme out the window.
Then you need to fix your data structure. I wrote pretty much exactly this (a UITableView-like paging scroll view) and it works fine (there are some reloading quirks, but hey...).
Keep track of which pages you've loaded. I used a ring-buffer-alike modulo 8 and spent a while getting the code right; it's probably a lot easier to just use an NSDictionary with NSNumber keys and UIView values. This means when you change from page 1 to 10, you can still tell that the loaded views are for pages 1, 2, and 3, and drop them.
Load the required pages in -layoutSubviews. I would load 1 or 3; 5 is probably too many (but you need to load at least 2 if you're between pages).
Load 3 (one to either side) in -scrollViewDidScroll:. This is so that when you scroll from page 1 to 2, it doesn't try to load page 4 (which hasn't been loaded yet).
Load 5 (two to either side) in –scrollViewDidEndDragging:willDecelerate: if willDecelerate is NO, –scrollViewDidEndDecelerating:, –scrollViewDidScrollToTop:, and –scrollViewDidEndScrollingAnimation:. The idea is that the animation's over, so you can load the extra views without the user perceiving lag.
Possibly load 5 in –scrollViewWillBeginDragging:, to make sure that page 3 is loaded if you're currently on page 1.
I decided to do "two pages either side" because when you flick from page 1 to page 2, it often shows a pixel-wide sliver of page 3 when it bounces. This can be avoided with scroll view insets, but we didn't think of that at the time (oops). There's otherwise not that much of a reason to choose 5 over 3.
It's a bit of work to get right, but otherwise seems to work flawlessly.