You need all four user interface orientations enabled, in order for multitasking to work. It looks like you’ve only enabled the landscape orientations, so you should enable the portrait orientations too.
I’ve been using the develop branch. Multitasking definitely works in the DemoRunner on that branch.
I do not intend to use the multitasking, My app only supports landscape.
I am addressing a potential regression when the multitasking support has been provided within juce cmake.
The issue is when multitasking is disabled because UIRequiresFullScreen is never (beeing true or false) set in the plist.
Thanks, I understand the issue now. I’ll get that patched on develop.
Hi @reuk
I’m sorry to report I’ve (just) now come across a problem with this change.
The issue is that orientation changes work fine on iOS Simulators, but we’ve found they’ve stopped responding to orientation changes with physical devices. It looks like some sort of timing related issue in the Juce code. Maybe there is a recent iOS change that has aggravated this?
Anyhow, I’ve this morning had to revert back to my own split screen handling code, where orientation changes are all picked up fine (and split-screen still works, of course).
juce_ios_WIndowing.mm
juce_ios_UIViewComponentPeer.mm
If you’d like my copy of the code, just send me a mail, I’d be happy to give it to you of course!
Best wishes,
Pete
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?
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.
Hi @reuk sorry it has taken a while to get back, but have been incredibly busy preparing the update to Wotja. Been down all sorts of technical rabbit holes! Anyhow, that is now off for review by the various app stores.
I’ve back-merged the latest develop branch tip d4e802016 (11/03/2021) and the “juce standard” rotation is now working 100% fine on my oldest test device.
Tim is going to dig-out an older device still from the mothballs for testing, but so far so good.
Thanks as always,
Pete