Notifications don't appear in apps built with JUCE

[tommaisey]

We're currently implementing Link in our app built with JUCE. Everything's looking good, but we're not seeing in-app notifications. I'm not sure where to start with finding out why.

It may be useful to refer to the JUCE code that wraps iOS native windows.

I should note that we work closely with the JUCE team closely, so we can expedite any changes required.

[Crandall1]

I was able to get the Link settings window to show using (more or less) the same code that JUCE uses to wrap the Bluetooth MIDI settings native window. However, I wasn't able to get the Link-provided in-app notifications to work, so if you solve this and want to share, I would love to see it.

[fgo-ableton]

The notifications are added as a subview to UIApplication.sharedApplication.delegate.window. Could you check if you have access to that from JUCE?

[leehu]

Hi. I'm going to start looking at Link in JUCE over the next couple of weeks - just wondering if you guys are going to be sharing/contributing your code in any way?

[jinkoandres]

@fgo-ableton we have the same issue, and we do have access to the Appdelegate's keyWindow and Window but Don't know how to verify that this UIView is being added. Where do you suggest we start looking?

[fgo-ableton]

@jinkoandres So I guess a subview that is added to is not visible on top of the JUCE window, right? Do you maybe have some code you could share, that shows how manage to show the LinkSettingsVC in an JUCE app?

[Crandall1]

That seems to be the case, best I tell. My feeling is that it is getting added underneath the main JUCE window, which is a subview of the main UIView itself.

Roli said this was on the table as something they were going to add (in lieu of the now nearly useless AudioBus) but that was months ago. I imagine that as soon as they need it, it'll get added quickly. That generally seems to be the case, although in general they're pretty good about feature additions.

[fgo-ableton]

I see... Is there some UIView in JUCE that allows drawing onto visibly? I could maybe add an option, to set a view to draw the notifications onto, as a temporary! workaround.

[fgo-ableton]

Please reopen the issue if it is still relevant.

[blursolo]

@fgo-ableton I don't use JUCE but have implement Ableton Link inside a framework which resides inside two AUv3 extensions ( effect and instrument ). The notifications don't show up there either.

First I wouldn't have access to UIApplication.sharedApplication.delegate.window because of the following error message: 'sharedApplication' is unavailable in application extensions for iOS: Use view controller based solutions where appropriate instead.

This can be fixed by turning Require Only App-Extensions-Safe API inside the frameworks build settings to No

So I ran a test like that:

if let window = UIApplication.shared.delegate?.window{ /* present some view controller.. */ }

It compiles but it doesn't show anything..

It would be great if you could add an option, to set a view to draw the notifications onto instead.

[fgo-ableton]

I am not sure if this is the proper way to do this. However, here's a proposal that could do the trick: LinkKit.zip

#include "detail/ABLNotificationView.h" and then set a custom function UIWindow*() that is used to acquire the window to draw the notifications on: [ABLNotificationView setGetKeyWindow: ${SOME_FUNCTION_RETURNING_A_UIWINDOW*}];

Let me know if that would work.

[blursolo]

Thank you @fgo-ableton for your reply. I tried again but I just can't access the main window inside the framework. It seems that Apple has disabled access to UIApplication.shared inside extensions completely. See https://stackoverflow.com/a/68496411/1084315

I guess it would be better if we could pass a UIViewController or a UIView to Ableton Link instead.

On that note maybe it could be done by passing a pointer / reference instead of a block or closure function to Ableton in order to make it a bit easier? I was having a bit of a hard time yesterday passing a UIWindow from Swift to Objective C setGetKeyWindow: UIWindow()() in that matter.

[fgo-ableton]

Hmm. Passing a pointer is kind of tricky too: This would require to set the view whenever a background window is available, set it to something else when the view changes, and reset it to nil when the app goes to background. That sounds like a scenario that could quite easily cause crashes. That plus the Swift/Objective C complication make me think that maybe the most solid route here is to use the C API from https://github.com/ableton/link/ and directly draw the notifications in Swift yourself?

[designerfuzzi]

I see nothing wrong with posting a NSNotification aka CFNotification that could be defined and as such registered to be Observed. After all NSNotifications is a String based mechanism for good reason, because it allows to hook up into NSNotifcationCenter by just knowing the string. When the post mechanism is done properly it can also be send on main thread, as normal send Notifications cause the observer to run linked functions in the thread they where send. Dispatch is the key.. Juce and NSNotifications are not friends, specially when it comes to midi device changes, that is because Juce is a wrapper after all which introduces its own notification mechanism for thread safety and stuff.. And therefor ignores that a lot basic system functions rely on NSNotifications. That doesnt hurt here, when someone can send a notification, it can be received in JUCE and does so as NotificationCenter is a Foundation toy it can run in any app no matter what. Also inside Apps that are not made with JUCE

But as fgo-ableton points out such Notification is actually not needed when you use the callbacks Link offers. I did just that to get rid of the annoying Notification view that was spitting in my event responder tree forcing users to touch the screen again. Was maybe a special case..

[blursolo]

@fgo-ableton I understand. I have replaced LinkKit with Link but now I can't access ABLLinkSettingsViewController because it's a LinkKit-only-thing, right?

Am I correct in assuming that the only callback I need in order to draw the notifications myself is: setNumPeersCallback() Could you make this one available in LinkKit as well? That would probably be the easiest and most flexible solution for everyone.

[fgo-ableton]

@rororomeda Thanks for the PR! I'm not so happy with adding the callback setter to the API and not showing the default notification based on that. This is a bit confusing. We did not add the numPeers property to the LinkKit API as it should not be needed for the general use case and I'd prefer to leave it this way. I pushed a different approach here: https://github.com/Ableton/LinkKit/tree/peers-notification There is now a NSNotification with the key ABLLink.NumberOfPeersChanged to observe the number of peers. When listening to the notification the user setting to enable/disable notifications should also be checked (see the example in the last commit). I also added a plist key ABLLinkSuppressNotifications to prevent LinkKit from showing the default notification.

[blursolo]

@fgo-ableton Thanks, that's cool with me. I built your branch and included it in my project. It works very well.

My last request would be to ask you for a new release with the new changes so I can submit my app to the App Store with the appropriate LinkKit licence : )

[fgo-ableton]

I just uploaded a new release: https://github.com/Ableton/LinkKit/releases/tag/LinkKit-3.1.10