How can you tell when a windows 8 Metro app gets put in the background? The suspended state doesn't activate. I have a break point on. It only hits if I close the app.
I am using a webcam and since no apps can run in the background I need to save my work when it's put in the background.
The windows phone it was application deactivated.
any help would be nice.
Apps do not normally get suspended when in the debugger. However, you can force a suspend when debugging by:
Enabling the Debug Location toolbar (red arrow in image below).
Then press the Suspend button (blue arrow).
The suspending event should fire when the application is no longer active, namely, when another application is brought to the front. Presuming you're using C#/XAML, the app.xaml.cs file already has the Suspending event wired up. In HTML5/JavaScript it's checkpoint and you'll see it in default.js.
Related
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've been using Wineskin for quite a while, and, as of late, I've been attempting to use Winemac.drv (or Mac Driver) from CodeWeavers more than X11. The main difference is that Winemac is fully programmed in Objective-C (including its Window system), while the X11 approach uses X11 dylibs and .nib files for windows.
Since Winemac's still in development, however, it lacks in some OS X functionality*. The feature in mind is bouncing on Dock. What's the problem with the bouncing? Well, it simply just doesn't bounce. More specifically at launch. The code somehow overrides the user's option for "Animating apps on launch", or does something that completely ignores the usual app launching animation.
I've still very little experience in Objective-C, so I might've missed some key documentation from Apple's Mac Documentation Library, but my question is:
Can apps usually override this option, or might this be the case just for Wine? If they can, how?
EDIT: I've stated incorrectly that the Mac Driver missed on functionality, when the reality is, as mentioned by Ken Thomases, that Wine processes start at background, so no icon is shown on the Dock at launch, and that means no animation.
I'm the developer of the Mac driver for Wine.
The issue is that all Wine processes start life as background processes with no presence on the Dock. Many Wine processes remain that way because they never present any windows.
When a Wine process does present a window for the first time, it transforms itself from a background process to a foreground process. At this time, it gains a presence on the Dock and in the Command-Tab application switcher and gets a main menu bar. It just so happens that the Dock does not bounce the icon of an app which transforms from a background process to a foreground process. Basically, the Dock is getting involved well after the process was launched and bouncing is for a process which is launching.
An application can make its Dock icon bounce by calling -[NSApplication requestUserAttention:]. However, this does nothing if the application is already active. Also, the bounce animation has a different quality. It's sharper and more urgent, rather than a relaxed bounce.
Basically, there's no way to achieve what you want for the general case. It may be possible to construct a script-based app bundle that configures the environment and then execs Wine. Since the app is bundled and describes itself in its Info.plist as a normal foreground app, it will get a Dock icon immediately and that icon should bounce. I'm not entirely sure how things will behave from there, in terms of the execed Wine taking over the Dock icon. Even if it works for the initial process, any Wine processes which are launched by the initial process will revert to behaving in the manner you're familiar with. (For example, many games have a patcher/launcher which launches a secondary process for the game itself. You might get the patcher/launcher icon to bounce, but that wouldn't help for the game process's icon.)
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.
I'm building a Windows Store app and it pops up toast notifications from time to time. I also have an animation that plays to show when something has updated. Both of these happen at the same time.
What I would like is to not show the toast when the app is running.
So, is there a nice easy way to determine this or do I have to manually track the state via the suspending/resuming events?
Edited info:
The solution has a background task project which goes off, gets the data, then decides if anything has changed that the user needs to know about.
If so, it creates a toast, updates the tile badge, and plays an animation to fade in the new data.
The issue is that I don't want to show the toast and update the tile badge if the user has the app full screen. Similarly, playing the animation isn't needed until the app is resumed (that's the easy part though).
I realize I could solve it by having one timer that works when the app is running, and a separate background task for when it's suspended but that seems like overkill in this case.
The simple answer here is that if your app is suspended, your code won't be running.
If you want to pop up toasts when your app is suspended, you'll either need to use the WPNS or a background task to track changes.
In most windows 8 apps when you tap anywhere inside the app you see a white-circle tap notification. For some reason, the notification doesn't occur in my app. How is the indication enabled or disabled?
i tried IsHitTestVisible , but don't see anything change in my grouped item page.
IsHitTestVisible has nothing to do with the white-gray tap short-animation, which is a shell feature. All apps are showing it when a touch event occurs in the context of the OS.
This question is kinda related to my lastest question so I will leave the answer here if someone tries to solve the same issue.
You can disable/enable the visual tap feedback with:
PointerVisualizationSettings.GetForCurrentView().IsContactFeedbackEnabled = false;
You can also remove it forever in your control panel.