Before iOS7 came, we noticed an issue:
Music remote-control from earbud or springboard can hijack our audio session even if we set the category to solo-ambient or another exclusive mode.
We thus tried a few things:
We tried to take ownership of the audio session back. But this requires that our audio code knows when to take it back and from whom. We thought we could let the app code become the first responder to remote-control events, do our stuff, and then pass the events on to the music app. However, we found that the events got detained by the first responder and there is no way to push it back to the chain of commands.
We tried to become first-resonder and block remote-control events all together when we are in solo-ambient. This worked fine with iOS6, still works with earbud control in iOS7, but fails with iOS7's control center. The control center seems to bypass the remote-control event handler remoteControlReceivedWithEvent completely, where we put our blocking code.
I read something elsewhere that:
You can't block the music app. your app can become one though (apple
won't like that) and then the control center would control yours.
But I found no documentation whatsoever about control center.
And as said above, control center does not enter the normal remote control hooks even if an app is the first responder.
Another quoteP
Remote Control Event handling is so your app can be controlled by
Control Center, the earbuds, etc... it is not so that your app can eat
said controls, preventing control of other apps from said sources. It
only worked in iOS6 because of a bug in iOS, now fixed in iOS7
Is it that what had were using was due this bug? I find it hard to believe because we got the solution on this list and the Xcode mailing list so I assume that was an accepted solution.
Now we really wonder if we are missing something from the very beginning:
Is solo-ambient really an exclusive mode for audio session or is it that music app is an exception to that exclusivity?
How can our app live in harmony with the remote-control, and control center?
Where can we find up-to-date documentation of remote-control and control center?
The remote control has been mysteriously fixed after clean building everything agains iOS7 SDK. Now app delegate can receive remote-control events from Control Center. However, the play/pause events are UIEventSubtypeRemoteControlPause and UIEventSubtypeRemoteControlPlay instead of the iOS6's UIEventSubtypeRemoteControlTogglePlayPause.
Related
Firstly, apologies for the slightly open ended questions but I can't find the info I'm looking for in other questions.
I'm trying to understand the lifecycle of a RN app on both iOS and Android. I understand the app bootstraps when you first start it and stays running while the phone is alive, but what happens when the user switches to a different app and comes back, or their screen times out then they switch it back on? It would be really annoying if the app restarted just because they briefly switched to check their email.
My specific use case (not particularly important to this generic question but included for context) is that I'm trying to build a game with socket.io connections and I'm wondering if I can hook into events to see if the app has been in the background or if I even need to. I have found a way of forcing a restart which may be necessary at some points, but I'd rather just try to reconnect things that have disconnected if I can find out when that happens.
Any push in the right direction would be appreciated.
The app doesn't restart when it goes in the background as you describe. The app keeps its state and the user sees the last screen they visited.
You should have a look at react native's AppState
https://facebook.github.io/react-native/docs/appstate
Using AppState you can addEventListeners that capture the change of the app's state like when going to background.
Of course there are also some problems here...
You can't capture the "kill "event. You can only detect if the app is sent to the background but unfortunately you can't detect when the user chooses to "kill" the app
You can't run any code while your app is in the background. This might be serious in your case but you should evaluate it. For example if you have a timer and you sent the app to the background then the timer stops.
I would like to build a helper app for gamers, and to build some extra functionality I would like to observe/time certain third party games behaviors, more specifically when the game actually launches the full screen process.
For example: my app is a system tray app, the game has a "launcher" app with lobby and menu screens. Once the game launches the extra process, usually OS X will switch resolutions (optionally) and my App would be notified somehow. Then I can start a timer. Once game match finishes, either the process is closed, or the game is not full screen anymore, my app gets a second notification and I can stop the timer.
Are there official Apple APIs that provide any way to observe/poll for the app going full screen and/or launch additional windows that I can reliably assume it's the actual game screen?
I doubt you're going to find a completely comprehensive solution. There are many ways for apps to achieve a full-screen experience and most don't provide a notification about that fact.
A full-screen app can modify the presentationOptions of NSApplication to hide the Dock and menu bar. Another app can use key-value observing to monitor its application object's currentSystemPresentationOptions property, which will reflect the current system status.
A full-screen app can capture the displays (although Apple discourages this technique). You can try to detect this by calling CGDisplayIsCaptured(), although it's been deprecated since 10.9 with no replacement. It may be possible that, if you register a callback with CGDisplayRegisterReconfigurationCallback(), you'll get called when something captures the display. However, capturing the display is sort of about preventing other processes from noticing such changes, so maybe not. In that case, you'd have to poll. You might also poll for the current display mode; changing the mode is the primary reason why a game would capture the display in the first place.
A full-screen game could also just create a borderless window the size of the screen and set its window level to be in front of the Dock and menu bar (and other apps' windows). There's not really a notification about this. You could detect it using the CGWindowList API, but you would have to poll. For example, you could call CGWindowListCopyWindowInfo(kCGWindowListOptionOnScreenOnly, kCGNullWindowID) and iterate through the dictionaries looking for one the size of the screen and at a window level above kCGStatusWindowLevel.
(You might be able to use the Accessibility API to get a notification when the frontmost window changes, so you'd only have to poll when that happens.)
You cannot observe a notification if there is none. So firstly you need to know if the app you want to observe is actually sending a notification that is observable. You cannot 'hook' into other apps without their planned consent.
I'm developing an app which uses ibeacon to determine if the user entered a specific region.
Now I'm using the CoreLocation framework to implement this geofencing-based feature.
I've read the document below.
https://developer.apple.com/library/mac/documentation/CoreLocation/Reference/CLLocationManager_Class/CLLocationManager/CLLocationManager.html
in which the Apple is saying that:
"In iOS, the regions you register with the location manager persist between launches of your application. If a region crossing occurs while your iOS app is not running, the system automatically wakes it up (or relaunches it) in the background so that it can process the event. When relaunched, all of the regions you configured previously are made available in the monitoredRegions property of any location manager objects you create. "
I discovered that it's true just before the ios 7.
From ios 7, An app will be waken-up from background but it will actually no longer could be re-launched from terminated-state (slided out from the task manager which displayed by double-clicking the home button).
If it's due to the Apple's policies, why does Apple not update the above official document?
So I'm thinking of an ios7's bug because the Reminder App (a built-in app) is also not relaunched in ios7 even though it's relaunched in ios6.
Is this issue due to Apple's policies? or an ios7's bugs?
It takes me more than 2 days to google for a solution.
Any ideas for this issue?
The documentation is simply out of date. This is intended behavior in iOS7. Apple produced a video explicitly discussing this change. The idea is that if the user explicitly terminates the app, the user does not want it running. See this thread.
Is this such a big deal? How often will users really do this? Remember, if users are annoyed by you app, they can always uninstall it, too. This was true in iOS6.
iOS 7.1 reversed this policy. That is even if the user kills your app the iOS still launches your app upon crossing the region.
I'm developing a Kiosk-Mode Application and I want to prevent the notification center gesture (swipe down from top). Since the Application isn't distributed using the AppStore private APIs are allowed.
I have skimmed through the UIKit class dump but did not find any hints on how to disable it (resp. don't know where to look, tried UIApplication and UIWindow).
Has anyone tried this yet and had success?
It may be a little tricky, cause you are trying to disable native iOS function like all-fingers swipe gesture on iPad and so on. Some people use this method to define different notification center swipe side:
statusBarHidden = YES
and then you can redefine side:
setStatusBarOrientation:UIInterfaceOrientationLandscapeLeft
as example.
I think you couldn't find any hacks to prevent iOS notification from showing at all. As last approach you can get some profit from dealing with jaiblroken features on unlocked devices...
I have an installation project in mind which involves a hacked iPad - I'd like to have a background process running recording all the touch events regardless of what app is running in the foreground, and send them out via OSC.
Note that this is using a jailbroken iPad with root access, and users will be alerted about not entering any sensitive data. But I'm not an iOS developer so I'm not sure if this is even possible. I'd appreciate any kind of input/suggestions.
[edit] Since someone questioned my motive behind this question, I'll try to explain a bit: to be specific, I'd like to build a mechanical system with Arduino that emulates the user's touch input on the iPad, but I do not want to limit them to using an app that does nothing else but recording touch events.
There are three options:
Use the IOHIDFamily subsystem to capture all the touch events. This will do most of the processing for you, the only thing you'll need to do is fetch the events using a HID client, get their types, and if they are touch events, get their position, radius and other things you need.
Use the MultitouchSupport framework. This way you will have to process the digitizer data frames manually which is tricky.
Use a MobileSubstrate hook to hook the already existing HID client inside SpringBoard.