Why does my WinJS app hit breakpoints I set in onactivated and oncheckpoint even after I comment out the call to app.start at the bottom of default.js? I thought a call to start was required to queue up these events.
Related
We have an electron app that we're setting up to launch from protocol links following the structure described here: https://github.com/oikonomopo/electron-deep-linking-mac-win (found from Open app and pass parameters with deep linking using Electron (macOS))
Once the app is installed, we either open the app from finder/launchpad or can invoke the app from a browser using myapp://someparams.
If I invoke myapp://someparams when the app is closed, the app opens and the main process fires the open-url event for mac as expected and I can grab the parameters from the url. If the app was initially opened via this method, re-invoking the myapp://someparams continues to focus the app and fire open-url as expected.
However, if the app was initially opened from the finder, launchpad, or command line, invoking myapp://someparams causes the second-instance event to fire instead and I haven't been able to find a way to get the url that was used to invoke the app. Windows works as expected since the second parameter to the second-instance event contains the protocol as a parameter but that isn't the case with mac.
So the question is - is there a way to grab the protocol/url from the second-instance event on mac? Or is there another way around this?
I did see this snippet from the docs: https://electronjs.org/docs/api/app#apprequestsingleinstancelock
On macOS, the system enforces single instance automatically when users try to open a second instance of your app in Finder, and the open-file and open-url events will be emitted for that. However when users start your app in command line, the system's single instance mechanism will be bypassed, and you have to use this method to ensure single instance.
You should set LSMultipleInstancesProhibited to true in info.plist.
If you are using electron builder, you can set 'LSMultipleInstancesProhibited: true' at mac.extendInfo
For example
mac: {
...
extendInfo: {
LSMultipleInstancesProhibited: true,
}
}
Ok, this is what I know so far about the Windows Phone 7.1 application life-cyle, but I still have a few questions.
Application Launching
- Called on application start-up, then proceeds to initializes App and then MainPage.
Applicaiton Deactivated
- Called when app becomes dormant (running but user is not using it). This calls the OnNavigatedFrom method of the current page before moving to the ApplicationDeactivated method in the App class. Once the application is Dormant it might become Tombstoned if the operating system needs more memory.
Application Activated
- Called when app comes out of Dormant or Tombstoned state, you can call IsApplicationInstancePreserved to figure out which (true means Dormant, therefore the state was preserved). Once this is called it moves to OnNavigatedTo.
Applicaiton Closing
- Called when user navigates backwards past the first page and the app exits. The OnNavigatedFrom method (on the first page) would be called as well.
So my questions mostly pertain to what is being initialized when the ApplicationActivated method is called.
-If the application was NOT Tombstoned is there anything you need to do to initialize the application or does the operating system restore everything back to the way is was? Is the constructor even called for the page that it is navigating to or was everything just frozen?
-If the application WAS Tombstoned do the page constructors get called? (I'm assuming so since nothing was saved). If the page constructors are called is there a difference between navigating to this page for the first time and coming back from a Tombstoned state?
These are all things that you can test yourself. Under the properties of an the application project you can enable tombstoning when you navigate away from the application. This setting is under the Debug tab.
Correct me if I'm wrong but here are the answers to the questions I posed.
-When the application gets activated and it hasn't been tombstoned then only the OnNavigatingTo method of the last page gets called (no page constructors). I don't believe there is anything you need to do in this case since the application state has been saved.
-When the application gets tombstoned you need to save any page data that you might need to reload since everything on the page is lost and when it becomes activated again the page constructor IS called before the OnNavigatedTo method.
Hope this helps anyone in the future with similar questions....
is there any way to handle the Windows button keypress within the *.Xaml.cs especially when the app is busy getting a request processed using an Asynchronous BeginGetResponse. is there a override handler like OnBackKeyPress?
What's the appropriate way to handle this use case? i'm already handling Application_Activated and deactivated in the App.Xaml.cs file for tombstoning.
You can't stop this from happening. When this happens the current page will get its OnNavigatedFrom override called so you could clean up your page and save state from this method.
Bear in mind that it won't be possible to tell whether this is due to the hardware Start key or if the user just navigated away by say pressing the Back key or tapping a button.
Update:
If you're trying to avoid a crash due to Fast App Switching interrupting your networking call you should rather handle this when you return to the application. Your WebRequest will be cancelled and you should handle this case as shown in this MSDN blog post.
I have an app that subscribes to a specific kind of notifications from the default NSNotificationCenter.
On OSX Lion, it works fine, except that when the app loses the focus (another app becomes active), it stops receiving the events. When the app gains the focus, it starts receiving events again.
The app did not have this behavior on previous versions of OSX, it always received notifications, even when it was out of focus.
What can I do to change this behavior?
Thanks!
Nathan
I know its a bit late to answer this, still for my records and if some one still searching.
My OS X Menu bar app had the same problem. I wanted the app to observe all states.
Reason:
When the app looses focus,the observer is suspended.
ie. When the application becomes in-active it calls the method
-(void)applicationDidResignActive:(NSNotification *)notification
and by default the NSDistributedNotificationCenter object gets suspended.
Solution:
I created an object for NSDistributedNotificationCenter
NSDistributedNotificationCenter *center=[NSDistributedNotificationCenter defaultCenter];
and then when the app looses focus its call the applicationDidResignActive method and inside
that the NSDistributedNotificationCenter object is made to regain from suspended state by sending NO to setSuspended method.
-(void)applicationDidResignActive:(NSNotification *)notification
{
[center setSuspended:NO];
}
and then app starts observing even when it looses focus.
According to NSDistributionNotificationCenter reference
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSDistributedNotificationCenter_Class/Reference/Reference.html#//apple_ref/doc/uid/20000396-BCICEHHB
The NSApplication class automatically suspends distributed notification delivery when the application is not active. Applications based on the Application Kit framework should let AppKit manage the suspension of notification delivery. Foundation-only programs may have occasional need to use this method.
You can either
set the observer's behavior when suspended to NSNotificationSuspensionBehaviorDeliverImmediately using
- (void)addObserver:(id)notificationObserver selector:(SEL)notificationSelector name:(NSString *)notificationName object:(NSString *)notificationSender suspensionBehavior:(NSNotificationSuspensionBehavior)suspendedDeliveryBehavior
or set deliverImmediately to YES when posting
- (void)postNotificationName:(NSString *)notificationName object:(NSString *)notificationSender userInfo:(NSDictionary *)userInfo deliverImmediately:(BOOL)deliverImmediately
to send notifications immediately under suspended state.
And make sure you're not periodically killing distnoted.
I forgot I had an old launch agent script to killall distnoted to avoid memory leaks.
It looks like the default behavior when adding an observer to a NSDistributedNotificationsCenter has changed to NSNotificationSuspensionBehaviorCoalesce, that does not deliver notifications when the app is inactive.
Described here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSDistributedNotificationCenter_Class/Reference/Reference.html#//apple_ref/doc/uid/20000396-5567
I have a Mac OS X application that is also a protocol handler (just as, for example, Safari is a protocol handler for the HTTP and HTTPS protocols). So when a user clicks a link of the form myscheme://some-kind-of-info in any application at all, my application launches to handle the link.
Now I need to be able to determine if the application was launched by such a link click, or if it was launched by any other method. In other words, it was launched by any method besides a link click. (In those cases, I want the app to stay open, but if it was launched by a link it should quit and ignore the link. This way it only operates when already running.)
Is there some way within the app at startup to introspect and find out that it was launched by a standard method rather than by an AppleScript GetURL event? I'd like to find out through a documented method, rather than - for example - just have my app only open these links after it's been running for a half a second.
You can register a handler for each of the possible Apple Events you'll get on launch, and make note of which one you receive first.
If the application is launched without documents, you'll get kAEOpenApplication.
If it's launched with documents, you'll get kAEOpenDocuments (or
kAEPrintDocuments).
If it's launched with a URL, then (obviously) you'll get kAEGetURL.
There's also kAEOpenContents, but I wasn't able to trigger it easily in my test app; it's probably worth supporting no matter what.
How Cocoa Applications Handle Apple Events documents all of this stuff.
There is one error in there, though; it says that AppleScript's "launch" will send kAEOpenApplication. It won't, it'll send ascr/noop (kASAppleScriptSuite/kASLaunchEvent, defined in ASRegistry.h). I couldn't get the usual Cocoa event handler mechanism to trap this event, so you may need to do some more digging there.
One way you can check if the event is sent at launch is to register the event handlers in your application delegate's applicationWillFinishLaunching: method; they should deliver by the time applicationDidFinishLaunching: is invoked. With that method, you could potentially only check for kAEGetURL.