remove persistentHeader and persistentFooter

[torbenkeller]

The persistentHeader and persistentFooter fields are unnecessary.

• persistentFooter can be implemented around the ExpandableBottomSheet
• persistentHeader should be part of the expandableContent and then you set the persistentContentSize to the height of the header

[alestiago]

@torbenkeller what if the height of the header is unknown (or yet to be calculated)? How do we expect users of the API to deal with this?

[torbenkeller]

@alestiago I don't think the header height will ever be unknown. Either the user knows it directly because the header is a SizedBox, or he can calculate it by the insets and children of the header.

[alestiago]

@torbenkeller I don't think we should be forcing the user to pre-calculate the size of the header by looking at the insets and children of the header.

I think this because:

• Makes it more difficult to migrate from v1 to v2.
• Requires additional code from the user.
• This pre-calculation might not always be simple to obtain, (complex header, calculating text size, etc).

Can we avoid forcing the user to pre-calculate the size? What advantages are there if we don't pre-calculate the size for them? What disadvantages are there if we pre-calculate the size for them?

[torbenkeller]

@alestiago I think you are right. The header should stay and then I can update the docs and explain how to use it the best way. But the footer is totally unnecessary in my opinion, so I will remove it.

[alestiago]

That sounds great!

Indeed the footer seems unnecessary. I don't know if we can provide any feature that can make implementing the footer easier without constraining the developer.

A possible edge scenario I can think of is when an Android device has the navigation bar (the one with three icons) enabled and it is transparent. But don't know if this would be an issue; since it can be worked around with existing widgets.