In option 2 you mention pages. Adding onto that, you could consider a ViewPager with a FragmentStatePagerAdapter. This would allow horizontal paging and would be able to handle large amounts of content well. As each fragment is paged off the screen, the fragment would be released. It would then restore the state of the fragment when it needs to get created again (assuming you implement the state save/restore properly). The fragments created by the FragmentStatePagerAdapter would need handling inside them for the zoom and scrolling you mentioned.
On Tuesday, September 3, 2013 3:27:17 AM UTC-5, NS wrote: > > Hello, > > I'm working on a document viewer which would display all the pages of the > document laid out vertically - allowing the user to scroll within the > document. If the user zooms in using pinch, the pages would zoom - now the > user would be able to scroll in all directions. > > I am considering a couple of options for the implementation: > > 1. Implement a custom View > - Handle scrolling in all directions by a) setting the scroll bounds > (override the computeHorizontal/VerticalScrollRange) and b) calling the > View's scrollBy(x, y) API to scroll in all directions. > - Handle drawing by overriding onDraw and drawing the page content in > this callback. > > The drawback is this approach doesn't take advantage of View Layout to > handle the pages - laid out vertically with some gaps between them. That > would be need to be handled manually by actually drawing gaps too along > with page content in the onDraw callback. > > > 2. Add Views to a multi-direction scrollable View > - Implement a custom View which allows multi-direction scrolling > (similar to ScrollView, but allows horizontal and diagonal scrolling too) > - Add children (representing pages) to this scrollable View. > - How should I manage the memory taken up by these Views? Since the > number of pages could potentially be very large and the size of each View > could be large (after zoom), the backing Bitmap memory could be extremely > large. > > > 3. Similar to 2, but doesn't use a drawable View for pages > - Use the multi-directional scrolling View as above. > - Instead of adding Views capable of drawing to this scrollable view, > use a non-drawing View like a RelativeLayout for each page instead. To each > Layout, add smaller Views (could be ImageViews). Handle these manually by > removing Views that are not visible. Since the backing Bitmaps would be > created for the smaller ImageViews, the memory requirements should be > manageable. > > > If folks have any suggestions/feedback regarding the approaches mentioned > above, or any other solutions, that would be very helpful. > > Thanks in advance. > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
