Skeletonview: How to reload the original view controller / view ?

[ghost]

What did you do?

Experimented with the Pod's example, using all publicly-available functions {hideSkeleton(reloadDataAfter: true), hideSkeleton(), stopSkeletonAnimation(), plus setting isSkeletonable to false} inside of a DispatchQueue.main.asyncAfter call (time-delayed to show changes after a few seconds, to simulate a network-layer displaying the skeleton views first, then the original content).

The example's original storyboard was left untouched, as was viewDidLoad. ViewDidAppear had a call to view.showAnimatedSkeleton, which was also not altered.

What did you expect to happen?

Expected to see the original view controller layout after the end of the various skeleton-display-stop calls

What happened instead?

I eventually tweaked the example to focus on the avatar image only, and eventually got it to show an altered colour background (still in circular format). However I wasn't able to see the original content.

Alternatively I put the Dispatch call into a button press (button inserted on the bottom panel). Also experimented with reversing the order of calling isSkeletonable = false and hideSkeleton(), always putting self.view.layoutIfNeeded() last.

Steps to reproduce the behavior

In viewDidAppear, add a call to

DispatchQueue.main.asyncAfter(deadline: .now() + 4, execute: {
    self.turnOffAndReload()
})

the body of the turnOffAndReload() func :

func turnOffAndReload() {
    avatarImage.hideSkeleton()
    avatarImage.isSkeletonable = false

    self.view.layoutIfNeeded()
}

SkeletonView Environment

SkeletonView version: 1.2
Xcode version: 9.3
Swift version: 4.1

[jbweimar]

That is probably due to this code:

extension UITextView: PrepareForSkeleton {
    func prepareViewForSkeleton() {
        text = nil
        resignFirstResponder()
    }
}

extension UIImageView: PrepareForSkeleton {
    func prepareViewForSkeleton() {
        image = nil
    }
}

It doesn't save the state of the UI so you will have to reload it yourself. Presumably, in a real life scenario, this is not an issue as the hiding of the skeleton is the moment you are about to load new data.

[Juanpe]

Exactly, as @jbweimar says, in the real life scenario, when skeleton will hide, new content would appear. Anyway, I'm developing a new proposal for next version, to recover original state, when the content has not been modified

[jbweimar]

@Juanpe What is a use-case for recovering original state? I guess you could try to load an image, and then if it doesn't load you might want to show the old one again? But would you show the skeleton view in that case (loading when there's already content to show)? Because in that scenario you already have content on your screen. If data does fail to load, I would prefer to show a more general error screen.

[Juanpe]

Hi @jbweimar, you can check "viewstate" branch, I'm working on this approach :)

[jbweimar]

I checked it out. Seems like a good solution. Of course it would be nicer if you could have the data isolated per UIView type but at some point one has to look at the purpose of the project and not try to abstract too much :) Three more comments:

It would be nice to add a updateImage(_ image: UIImage) method on a UIImageView extension that removes the skeleton and updates the image with a fade out. I did this in my skeleton code, and it looks much better :)

Also, your use of isSkeletonable seems a bit strange. It appears as if the purpose of the way you implement the recursive search is to optimize searching (to cut branches early). But the user (programmer) has to pay for that by setting all the parent views to isSkeletonable as well. I do it the other way around. I cut off when "isSkeletonable" = true. Also, the number of views in most applications are quite limited so a full search is not a big deal. Even though I don't agree with your usage of isSkeletonable, you could improve it by setting isSkeletonable = true for all parent views when you set it on a child view. Sometimes you could have a UIStackView that contains a view that needs to be "skeletonable". This would force you to set an outlet for the UIStackView, or do some ugly casting.

I think your recursion function can be shortened by putting the leaf case in the beginning of the recursive function, and not passing it as a parameter.

But, I haven't given your code 100% focus so it might as well be wrong about all what I claim above. :) Again, thanks for the code, I learned a lot from it. Still relatively new to Swift as I've mostly been maintaining old Objective-C projects for clients.

Happy coding!

[Juanpe]

Hi @MassimoSavinoAtKater, latest version of SkeletonView recovery the view state. Could you check it in order to close this issue, please?
Thanks

[ghost]

Hi there, thanks for getting back to me. I haven't had the chance to look at this and likely won't be able for a while, but I don't want to hold things up for you. Closing out.