Allow apps to provide customized ViewHolders #17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
svank
changed the title
|
nice work bro |
svank
force-pushed
the
custom-viewholders
branch
from
3a037ab
to
88b8569
Compare
The Overlay View feature is excellent for items like Share buttons which can remain in one place as the images scroll, but customizations cannot be added that scroll with the images being viewed. Additionally, the scrolling images themselves cannot be customized beyond what can be done in the ImageLoader and the background/padding/etc. options provided in StfalconImageViewer.Builder. To enable additional use cases, this commit allows applications to subclass the ViewHolders used internally, providing full control over the scrolling views. Subclasses are passed the PhotoView used in the default ViewHolder. Subclasses might simply adjust the style or layout parameters of the PhotoView. Subclasses might incorporate the PhotoView within a Layout and include other Views (e.g. a "New Image!" icon overlaid in the corner, or a caption). Subclasses might include other, alternative Views (e.g. a VideoView) and display one or the other depending on the item bound to the ViewHolder. Subclasses might ignore the PhotoView altogether and insert their own Views. This is achieved without affecting the existing use cases or requiring existing apps to modify their usage. A new constructor is added to StfalconImageViewer.Builder allowing applications a pass an additional argument, an implementation of ViewHolderLoader. This contains a single function, accepting a PhotoView and returning a subclass of DefaultViewHolder. When this new constructor is not used, a DefaultViewHolderLoader is used, which returns a DefaultViewHolder (which is the ViewHolder that was used before, extracted to its own file and enhanced for extensibility). Through a custom ViewHolderLoader and the DefaultViewHolder constructor and bind() methods overridden in the subclass, applications have complete control of the Views presented in the ViewPager. My use cases involves displaying both photos and videos taken with the camera function in my app, so my ViewHolderLoader creates a FrameLayout containing the default PhotoView and a VideoView, and my ViewHolder switches between these two views depending on the Uri it receives in bind(). To allow applications such as my own to play/pause videos as they come on or off the screen, I added two methods to DefaultViewHolder, onDialogClosed() and setIsVisible(), to allow videos to be paused when scrolled off-screen, resumed when scrolled on-screen, and stopped entirely when the dialog begins to close. A demo of custom ViewHolders will be posted at https://github.com/svank/Custom-ViewHolders-Demo
svank
force-pushed
the
custom-viewholders
branch
from
88b8569
to
dc46fa6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi! This is a great library you've made---and it's the only one I could find with this type of functionality, which surprised me.
I'm using StfalconImageViewer with the camera function in my app to let users view the images they've taken. I'm expanding to include video recording, so I'd like users to be able to view both photos and videos in the same pop-up viewer. After a few attempts, I made what I think are useful, generally-applicable changes to StfalconImageViewer to enable my use case and many others. These changes do not affect existing users of the library or significantly increase the library's scope, which I think makes them a candidate for merging.
In short, the image viewer currently uses a
ViewHolder, holding aPhotoView, along with theImagesPagerAdapterandMultiTouchViewPager. My changes add aViewHolderLoaderinterface and an optional additional argument to theBuilder, allowing apps to pass in aViewHolderLoader. This loader, or a default loader if none is passed, providesViewHolderstoImagesPagerAdapter. Apps that choose to implement aViewHolderLoadercan then have their implementation return a subclass of the defaultViewHolderwhich customizes the paging views as desired. A few additional details are described in the commit message.In my video use case, my custom
ViewHolderputs the usualPhotoViewin aFrameLayoutalong with aVideoView, and then inbind()it displays one view or the other as appropriate.Other use cases might want to customize each Pager page with additional views (e.g. a caption or a "new image!" icon) which scroll with the images---as opposed to placing that extra content in an overlay view, where the content would be statically positioned.
I created a repo demonstrating the use of these changes. It replicates my mixed photos/videos use case and shows how additional views (in the demo, a TextView) can add content alongside the image on each page.
This was my first time working with Kotlin, so I'm very open to suggested revisions.