Allowing own View and own Adapters with RecyclerView

[soarcn]

Allowing own View and own Adapters with RecyclerView

[soarcn]

Thanks @pboos

Basiclly I agree most of your ideas of improving this library, and it would great if we could make more agreement before starting to code.

Replacing adapterview to recyclerview is something already in the PRs, but I don't see that much needs to transfer it to recyclerview. I understand recyclerview is a promising component that providing more flexibility, but bottomsheet is design to not too complex user cases, I don't think we could take many advantages from recyvlerview. And from cons side, it would introduce more dependency, and increase the size of this library.
But I am open to this, since I haven't use recyclerview in my project, and know limited knowhow about it. you could provide more evidences to prove the migration is meaningful and necessary.

Allowing custom adapter and supporting setting custom view is good to proceed, and alertdialog is a good model to refer to. But I do suggest that you could discuss the interface with me before the implementation.

Thanks again for your contribution.

[wangyeming]

I also agree with @pboos.For example, I want make my bottom sheets like this. Custom adapters are essential.

Additional, how can I set the item height ?
Thank you!@soarcn

[pboos]

@wangyeming that is actually not an overlay anymore but a Activity ;-). I looked at the source of the contacts app. There they have something called QuickContactActivity (if i remember correctly) where they handle this above. In the ChooserActivity which as well is a BottomSheet they do this as well. Sadly both of them depend on lollipop API and when removing them it does not correctly work on old phones.

@soarcn I think keeping it work with the same API might not be possible. Switching to DialogFragment will work without any API change. Just that the passed in argument for creating the BuilderInstance has to be either an FragmentActivity or Fragment to get the FragmentManager.
But passing in adapters will not work at all. The reason is that on screen orientation the fragment gets destroyed. Well we could set it to be retained (but i normally don't like that :D).
The other way would be to pass in an own Fragment that extends BottomSheetDialogFragment where one can do everything that is needed.

As well the other question. Should it work with the support fragments AND the native fragments? or is it okay to just work with the support fragments? Only support fragments for me would be okay, and I think most devs are using the support library anyway.

Let me know what you think.

[wangyeming]

@pboos I get it. Hope that Google can provide the official widget of Bottom Sheets.Thanks!

[soarcn]

@wangyeming Current item height is coming from google's official design, but you can change it, just override @style/BottomSheet.ListItem and @style/BottomSheet.GridItem

[wangyeming]

@soarcn Thank you!

[soarcn]

@pboos
Yes, I understand it is not possible to keep it same as current one, passing new more argument is fine to go. I could create a compact dialog version in a separate branch if needed, but let's keep the master branch as simple as possible.

Let's start with support fragment. I myself never use native one.

[pboos]

@soarcn I started some work on this. But it turned out to be way too much work to switch it over to DialogFragment. There are several problems:

• Drawables that get passed in
• Other things.

So basically for this to work the whole structure needs to change. So to have the rounded drawables you use, one would have to make his own version of the (BottomSheetDialogFragment). And I am pretty sure that will go too far for you. That is why I currently aborted the task.

[soarcn]

@pboos That's fine to go if you feel it is needed, and I could help to merge it if possible. Or you could start with creating a dummy class and discuss with me before moving forward,

[pboos]

At the time where I aborted my try, I already changed like half of the lines of the whole code. That seems almost too much work. I ended up going a separate approach. I now actually ended up using an activity. The same way that the ResolverActivity in Lollipop did it. I just had to change a few lines of code to make it compatible with Android 4.0 and up. Works fairly good. I will probably publish that part of my code on github as well. I don't want to compete with your BottomSheet library, but for my use case it seemed a better way to go and is more flexible for me. But it is more complicated than this library. So both have their strong points :). So when published I will link it here if you are okay with it.

[soarcn]

@pboos looking forward to your code, seems quite interesting.

I create this library for most of simple places as an out-of-box solution, but it definitely bring some limitation to adapt complex user cases.

The way create a bottomsheet with activity meaning user could not call up the actions with few lines instead of modifying many configurations(manifest.xml) and extending from a base activity, and dialog is much faster than activity.

[soarcn]

I just checked your bottomsheet library, which as you said have its strong points in some cases.

I will continue bettering my library to make it works for common cases as an out-of-box solution, and people could define their own bottomsheet layout with your library

[pboos]

So the bottomsheet library mentioned can be found here: https://github.com/tutti-ch/android-bottomsheet

I agree. Both libraries have their specialties. So both serve a purpose :).

[wangyeming]

@pboos Thank you very much!