iOS Multitasking

See also: juce_ios_UIViewComponentPeer.mm - #4 by peteatjuce

Unfortunately I only have newer iOS devices here for testing. On an iPhone SE 2 and a recent iPad the screen rotation seems to work correctly in the DemoRunner.

My best guess for the broken commit would be this:

Is there any chance you could try reverting just this commit (i.e. git checkout develop; git revert 04f2ca61) and check whether that resolves the issue for you?

Hi @reuk,

Thanks for the suggestion! I’ll try to do that today or tomorrow. Either way, I’ll report back to you as soon as I’ve tried it!

Pete

Hi @reuk

That seems to work but if you were to revert, I would strongly suggest you use the following chunk of code (which I use in my own patched-up implementation, and have used ever since I implemented my own split-screen implementation).

- (void) viewWillTransitionToSize: (CGSize) size withTransitionCoordinator: (id<UIViewControllerTransitionCoordinator>) coordinator
{
    [super viewWillTransitionToSize: size withTransitionCoordinator: coordinator];
    [coordinator animateAlongsideTransition: nil completion: ^void (id<UIViewControllerTransitionCoordinatorContext>)
    {
        sendScreenBoundsUpdate (self);
    }];
}

Hoping that helps!

Pete

Thanks for trying that out. Are you saying that when the commit is reverted, but the implementation of viewWillTransitionToSize is implemented as above, iOS rotation works consistently for you?

Hi @reuk

Yes, exactly as you described :slight_smile:

Let me know if I can be of any additional help!

Pete

NB I’m just now re-checking that Split-Screen works on iPad… if you don’t hear back from me, it is working fine…

Thanks for replying. Unfortunately I’m a bit confused - if I revert the patch but leave viewWillTransitionToSize as it is above, the effect of the patch is just to add in the AsyncBoundsUpdater class, and to add it as a data member of JuceUIViewController. However, the triggerAsyncUpdate function is never called on this object.

Are you sure the body of the animation callback is correct above? Should that be calling triggerAsyncUpdate on the bounds updater, instead of calling sendScreenBoundsUpdate directly?

Certainly works for me.

Yeah - good point, you’re right - it means that AsyncBoundsUpdater isn’t called.

Works perfectly!

If you DM me (or mail me at intermorphic.com) to give me your mail address, I’ll mail you the exact version of the code I’m using.

It contains my tvOS patches, and a few other patches (all clearly commented/marked!) - nothing major.

Best wishes,

Pete

Just use pete@ …

FWIW, we’ll now test out this version internally, and report back if we see any problems. HTH! Pete

This is what I’m finding confusing. If the AsyncBoundsUpdater is never actually used, why would adding it back in have any effect? I think there must be something else going on here.

Could you tell me which devices + OS combinations have been causing problems for you?

Hi @reuk,

Well, the reverted version works as you say. I’ve just now rechecked for you as requested.

I’ve made the change below, but at this point in time it doesn’t seem to make any difference which of the versions below I use (though I’ll stick to my modified version).

So, it seems to work (reverted) with or without AsyncBoundsUpdater - but the version with coordinator animateAlongsideTransition (which doesn’t use AsyncBoundsUpdater ) is the one that looks most “iOS safe” to me, so I’ll stick with that approach in my own builds for now…!

My change: from this:

    // On some devices the screen-size isn't yet updated at this point, so also trigger another
    // async update to double-check..
    if (boundsUpdater != nullptr)
        boundsUpdater->triggerAsyncUpdate();

To this:

    [coordinator animateAlongsideTransition: nil completion: ^void (id<UIViewControllerTransitionCoordinatorContext>)
    {
        sendScreenBoundsUpdate (self);
    }];

Best wishes,

Pete

Sorry, I don’t understand how making the changes you describe could have any effect on the behaviour of rotations on iOS. If you’re testing with your custom fork, it’s possible that other changes on your branch are interacting with this change.

It would be most helpful if you could check the behaviour of the current JUCE develop branch (ideally in a JUCE example like the DemoRunner), with and without commit 04f2ca61 reverted. Testing the develop branch is the only way we can be sure that the fix will work for all JUCE users.

Please could you also tell us which devices and OS combinations are causing issues for you? Ideally I’d like to try reproducing the issue for myself, but I can’t do that unless I know which configurations cause issues.