UIScrollView insertSubview:atIndex: problem

  • Hi All,

    I'm trying to add an a View at the start of a Scroll View but it
    always seem to add to the end, not the start. The code I have is:

    [theScroll insertSubview:myImageView atIndex:0];

    In order to have the image added at the start of the Scroll View, but
    it acts exactly the same as if I'd have done:

    [theScroll addSubView:myImageView];

    Any ideas?

    Thanks in Advance
    Dave
  • On Jul 30, 2012, at 11:20 AM, Dave <dave...> wrote:

    > I'm trying to add an a View at the start of a Scroll View but it always seem to add to the end, not the start. The code I have is:
    >
    > [theScroll insertSubview:myImageView atIndex:0];
    >
    > In order to have the image added at the start of the Scroll View, but it acts exactly the same as if I'd have done:
    >
    > [theScroll addSubView:myImageView];
    >
    > Any ideas?

    You are going to have to define what you mean by start & end, as it is not clear in context.

    If you mean a visual location, then neither of these methods are going to do what you want. You would put something visually at the start/end of the view by setting its location (via frame.origin or center) not via the add subview method you use.

    If you mean a layering order, then the insertSubview:atIndex: method may attempt to do what you want, but given that a scroll view has other implicit subviews you would need to be more careful if you need an exact location. It may make more sense to use an intermediate subview that you place content into and which is a child of the scroll view in that case.
    --
    David Duncan
  • On 30 Jul 2012, at 19:40, David Duncan wrote:
    >
    > You are going to have to define what you mean by start & end, as it
    > is not clear in context.
    >
    > If you mean a visual location, then neither of these methods are
    > going to do what you want. You would put something visually at the
    > start/end of the view by setting its location (via frame.origin or
    > center) not via the add subview method you use.
    >
    > If you mean a layering order, then the insertSubview:atIndex:
    > method may attempt to do what you want, but given that a scroll
    > view has other implicit subviews you would need to be more careful
    > if you need an exact location. It may make more sense to use an
    > intermediate subview that you place content into and which is a
    > child of the scroll view in that case.
    > --
    > David Duncan
    >

    Hi David,

    It's probably easier if I try to describe what I am trying to do!

    Basically I have process that generates UIImage's and each of these
    images needs to be presented in a Scroll View. However there can be a
    large number of images generated and each image is pretty big too, so
    obviously, it can't hold them all in RAM. My idea is to keep a number
    of images (say 5) cached and as the user scrolls, generate the next
    or previous image and discard the old one.

    In this document:

    http://developer.apple.com/library/ios/DOCUMENTATION/WindowsViews/
    Conceptual/UIScrollView_pg/UIScrollView_pg.pdf

    I found the following:

    Configuring Subviews of a Paging Scroll View

    The subviews of a paging scroll view can be configured in one of two
    ways. If the content is small, you could
    draw the entire contents at once, in a single view that is the size
    of the scroll view’s contentSize. While this
    is the easiest to implement, it is not efficient when dealing with
    large content areas, or page content that takes
    time to draw.

    When your application needs to display a large number of pages or
    drawing the page content can take some
    time, your application should use multiple views to display the
    content, one view for each page. This is more
    complicated, but can greatly increase performance and allows your
    application to support much larger display
    sets. The PageControl example uses this multiple view technique. By
    examining the sample code, you can see
    exactly how this technique can be implemented.

    Supporting a large number of pages in a paging scroll view can be
    accomplished using only three view instances,
    each the size of the device screen: one view displays current page,
    another displays the previous page, and
    third displays the next page. The views are reused as the user
    scrolls through the pages.
    When the scroll view controller is initialized, all three views are
    created and initialized. Typically the views are
    a custom subclass of UIView, although an application could use
    instances of UIImageView if appropriate. The
    views are then positioned relative to each so that when the user
    scrolls, the next or previous page is always in
    place and the content is ready for display. The controller is
    responsible for keeping track of which page is the
    current page.

    To determine when the pages need to be reconfigured because the user
    is scrolling the content, the scroll
    view requires a delegate that implements the scrollViewDidScroll:
    method. The implementation of this
    method should track the contentOffset of the scroll view, and when it
    passes the mid point of the current
    view’s width, the views should be reconfigured, moving the view that
    is no longer visible on the screen to the
    position that represents the next and previous page (depending on the
    direction the user scrolled). The delegate
    should then inform the view that it should draw the content
    appropriate for the new location it the represents.

    By using this technique, you can display a large amount of content
    using a minimum of resources.

    If drawing the page content is time consuming, your application could
    add additional views to the view pool,
    positioning those as pages on either side of the next and previous
    pages as scrolling occurs, and then draw
    the page content of those additional pages when the current content
    scrolls.

    --------------------------------------------------

    The above is basically what I'd like to do, hold a number of pages/
    images "around" the current page and when the user Scrolls left or
    right replace the appropriate pages/images with newly rendered versions.

    I reckon that holding to 2 or 3 pages/images to the left and right of
    the current image should be enough to allow the user to scroll and
    not know the pages are being generated on the fly.

    I've looked for the Sample Code mention is the above document, but I
    can't find it anywhere, I found a sample project on the Apple
    Developer Site but it doesn't seem to the the one they are talking
    about.

    Any ideas or sample code on how to do this gratefully appreciated!

    Thanks in Advance
    Dave
  • On Jul 31, 2012, at 3:52 AM, Dave <dave...> wrote:

    > The above is basically what I'd like to do, hold a number of pages/images "around" the current page and when the user Scrolls left or right replace the appropriate pages/images with newly rendered versions.

    So it sounds like you want the views to be visually in a particular position, and you should thus ensure that each view has the correct frame.origin or center to place them that way.
    --
    David Duncan
  • On Jul 31, 2012, at 03:52 , Dave <dave...> wrote:

    > Basically I have process that generates UIImage's and each of these images needs to be presented in a Scroll View. However there can be a large number of images generated and each image is pretty big too, so obviously, it can't hold them all in RAM. My idea is to keep a number of images (say 5) cached and as the user scrolls, generate the next or previous image and discard the old one.

    Remember that scrolling can accelerate if the user keeps swiping, which means that scrolling doesn't necessarily display *every* view of the sequence.

    If the time it takes to create the view is short (less than the display refresh time), then there's no point in caching "nearby" images at all, at least from a scrolling point of view. You can simply recreate images as they are needed.

    If -- the more likely scenario -- it takes longer to create the images, then caching the images isn't really going to solve the performance problem either, because that would require the cache to correctly predict what images are *going to* be needed, and have enough advance warning to be able to load up the cache *before* the images are needed. Your intended caching mechanism will fail in the case where the failure is probably most noticeable to the user -- the fast, continuous scrolling I already mentioned.

    For those reasons, I'd suggest you'd be better off creating the images on demand, in a background thread, and drawing them when they become available. (You can create a low-resolution version or a partial representation of the data to display immediately, if that can be done fast enough.)

    Such an approach, combined with the 3-views scrolling technique (to keep the memory usage down), should give you a good solution.

    IDK either where sample code disappears these days, but watch the 2011 WWDC session video on using scroll views. It walks through the process of configuring such a view (it's fairly simple, and you can pretty much write your own code while watching). If you want to see how iOS 6 will simplify things a bit more, watch the beginning of the 2012 session on the same subject. I'd also highly recommend the 2012 WWDC session on concurrent user interfaces -- why, when and how you might move drawing to the background.
previous month july 2012 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today