search

Faltenreich / SkeletonLayout

Skeleton view pattern for Android
Apache License 2.0
505 stars 65 forks source link

Maintain visibility state #9

Open Faltenreich opened 5 years ago

Faltenreich commented 5 years ago

showOriginal() and showSkeleton() do not respect the original visibility of the masked views. The original visibility should be cached in order to return to the original state on calling showOriginal().

KennyGoers commented 5 years ago

I've made updates to the library to support this and am working on a callback to allow the user to have a say in which views are skeleton-ized. A few questions before I submit a pull request: 1) I think a view based on ConstraintLayout instead of or in addition to FrameLayout would be helpful in reducing the number of views in the view hierarchy. And another option to a callback architecture would be to add an attribute to child views to tag which views should be used for the skeleton. 2) I think a delay to showSkeleton() as a parameter would be a good addition for the cases when showOriginal() happens quickly (e.g., short delay due to cache hit as an example).

What are your thoughts?

Faltenreich commented 5 years ago

Hello @KennyGoers, thank you for your investment and the interesting feedback. I am not sure if I understand your suggestions correctly, so I will address both of them in the following:

  1. Which FrameLayout do you mean? If you mean the SkeletonLayout class, I am not sure about how replacing the FrameLayout with a ConstraintLayout would help. There is only one Bitmap drawn directly onto the canvas of the FrameLayout, representing the skeleton; no nested Views or ViewGroups.
  2. Could you provide an example of a scenario where a delay would improve the SkeletonLayout? I am currently unable to see a need for a delay on toggling the skeleton.
KennyGoers commented 5 years ago

Sorry for my late response.

  1. By deriving from ConstraintLayout (or others) there would not be a need for the extra layout, for example, I currently wrap a SkeletonLayout around a ConstrainLayout I'm trying to "skeletonize" if it was derived from ConstraintLayout directly I wouldn't have to have two layers. Understand?

  2. When I call skeleton view to show the skeleton and the call I make to fetch data returns immediately or quickly the skeleton flashes in quickly and returns to a data view. Since the transition is so quick it seems distracting more that useful, so a delay would leave the view blank if it was a very quick showSkeleton/showOriginal cycle.

Faltenreich commented 5 years ago
  1. This sounds like you are trying to inject Views directly and programmatically into the SkeletonLayout if I am not mistaken. Could you provide a simple layout hierarchy, so that I am fully able to understand your use case? I understand now what you mean and have to veto this suggestion. Changing from the most basic ViewGroup of them all - the FrameLayout - to the ConstraintLayout implies more dependencies, since not everyone is using a ConstraintLayout all the time.
  2. Good point! I will create a new issue for this new feature: https://github.com/Faltenreich/SkeletonLayout/issues/11. This feature seems like it could go hand in hand with https://github.com/Faltenreich/SkeletonLayout/issues/7.