fix: activate iOS views synchronously

[tgjones]

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

This is either a bug fix or enhancement, depending on how you look at it. It applies the equivalent activation fix for UIView subclasses, that #1182 already did for UIViewController subclasses.

#1182 changed UIViewController subclasses to use ViewWillAppear instead of ViewDidAppear for activation, such that activation occurs before the view becomes visible.

This PR does the equivalent thing for UIView subclasses.

What is the current behavior? (You can also link to an open issue here)

UIView subclasses (correctly) override WillMoveToSuperview, which is called before the view becomes visible. However, within those overrides, they schedule an async callback on the UI thread like this:

public override void WillMoveToSuperview(UIView newsuper)
{
    base.WillMoveToSuperview(newsuper);
    RxApp.MainThreadScheduler.Schedule(() => (newsuper != null ? activated : deactivated).OnNext(Unit.Default));
}

Because Schedule schedules an async callback on the UI thread, the callback may (and in my testing, will) be called after the view becomes visible. This means that there's a visible flicker where you first see uninitialized views, and then they are populated with data.

What is the new behavior (if this is a feature change)?

The activation callbacks are now called synchronously from UIView subclasses, such that activation occurs before the view becomes visible. Instead of the code above, the WillMoveToSuperview overrides become simpler:

public override void WillMoveToSuperview(UIView newsuper)
{
    base.WillMoveToSuperview(newsuper);
    (newsuper != null ? activated : deactivated).OnNext(Unit.Default);
}

This matches the existing behaviour for ReactiveCollectionReusableView and ReactiveCollectionView, which already called the activation callback synchronously.

What might this PR break?

If anybody relies on the current behaviour of activation occurring after views become visible, this would be a breaking change. But that was almost certainly undesirable behaviour in the first place.

Please check if the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information:

[dnfclas]

@tgjones,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla2.dotnetfoundation.org.

It will cover your contributions to all .NET Foundation-managed open source projects.
Thanks,
.NET Foundation Pull Request Bot

[dnfclas]

@tgjones, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.

Thanks, .NET Foundation Pull Request Bot

[tgjones]

The AppVeyor build failure looks unrelated to my changes, but please let me know if I need to fix something.

[Qonstrukt]

I actually ran into this (again) today, so I'm all for it!

I've also noticed breaking of AutoLayout in cells because of the unnecessary scheduling.

[kentcb]

Great - thanks @tgjones! And yeah, the build error is definitely unrelated :/

[kentcb]

Build fixed in #1542, just waiting for merge before I can merge this.

[coveralls]

Changes Unknown when pulling 9196f30 on tgjones:cocoa-activation into ** on reactiveui:develop**.

[tgjones]

Great, thanks for merging!