I need to have a chrome app quit based on a js script, but after I've looked through Google's list of JS APIs for Chrome Apps, I'm not convinced there is a way sadly. I've tried having the program throw errors at itself, but chrome simply ignores them and moves on. By the way, this is for Chrome OS.
Perhaps the simplest hack to make a chrome app "quit" would be to set chrome.storage.local.set({dont_start:1}) and then chrome.runtime.reload() and make sure the onLaunched event listener, instead of doing the normal thing like opening an app window, instead checks first if dont_start is set, and deletes that key, and just does nothing (instead of launching the app). Then in about 30 seconds or so the event page will go inactive.
Related
I created a new macOS project in Xcode 11.4 where the language is Swift and user interface is SwiftUI. Without making any changes to the code in the project, the app will disappear from the dock by performing the following steps:
launch the Mac app by running the Xcode project
close the main window of the Mac app
select another running app such as Safari
the original Mac app disappears from the dock with no way to access it
This behavior does not happen if the window of the Mac app is open. I can select other running apps then go back to the original Mac app with no problems.
This behavior is known as Automatic Termination. I find it a misfeature, but Apple considers it a feature.
Your app may not have actually quit. It may just appear to have quit. "Launching" it again will just make it reappear in the Dock. It's also possible that some apps which look like they're still running have actually been terminated by the system. In theory, if you try to switch to them, they will be launched and told to restore their previous state to maintain the illusion that they were running all along. In practice, apps (even Apple's) rarely properly restore things to exactly how they were.
The process list in Activity Monitor is a true reflection for what is and is not actually running. Look there to determine if your app has really been terminated.
A developer is supposed to have to opt-in to Automatic Termination because it requires explicit coding of state restoration. However, Xcode's app project/target templates have it enabled by default. You can remove the NSSupportsAutomaticTermination key from your Info.plist to disable it.
Likewise, you'll presumably want to disable Sudden Termination, too, if you're not prepared to support it. You would remove the NSSupportsSuddenTermination key.
I try to implement facebook login whit app in my unity3d game for wp8.1. When debugging in Visual studio everything works fine. App launches from protocol and from onActivated event args i get facebook token. But when i launch game directly from the phone,without VS,sometimes it's not resuming after login, but just restarted. I try to debug OnActivated event in VS using Debug Location Toolbar, but when i choose resume event, onActivated event never fires.
Why it's never restart with visual studio and what can i do to clear this strange behaviour?
My problem described here
Fast App Resume crashing on WP8.1 when not attached to debugger
But the answer is only applyed to wp8
It seems like Windows just unloads application from memory. Anyway after last windows update it's happens much rarely
So once in a while, when Spotify updates their clients, Spotify will show a banner that says an update will be performed when restarted.
How does spotify make this work?
I'm assuming it must be something different, since most software needs you to redownload the binary´, and then perform a more or less assisted reinstall.
Example: When VLC has an update, it always tells you when you run VLC to watch something, but instead of just having a one-button "update and restart", it will download the installer and run the installer, but this is a lot more button presses than just doing what Spotify does.
Spotify downloads the installer and puts it somewhere in the AppData folder and relaunches itself. On launch, if an installer for a newer version is present it'll launch the installer in silent mode and exit. Once the installer has updated the client, it'll automatically relaunch the newer client.
This slightly odd sequence of events means that if the user ignores the banner and exits the client normally, it'll still get updated on next launch. I believe Google Chrome uses a similar mechanism.
I'm developing a phone gap app and using Safari's Web Inspector to debug it. The tool is very useful but there are a couple workflow inefficiencies that are costing me some time.
Every time I stop my PhoneGap app in xCode the Safari Web Inspector window automatically closes leaving me with the task of re-opening it every time I make a change and re-launch the app.
The only way I'm able to get a full read out in the console is by entering window.location.reload(). Again this adds a step to my work flow everytime I deploy a change in xCode.
Does anyone know how to set it up so that Safari Web Inspector stays open and the console automatically monitors the app?
To solve the reload issue, I add this in my head section when I'm debugging:
<script>
alert('connect your debugger, if you want')
</script>
The alert stops all execution, meaning that I can (manually, ugh) connect my debugger and not miss anything. Execution resumes when I hit okay on the alert window.
I'm having the same issues. I haven't solved them yet, and I'm running out of time, so I'll show you what I've got so far:
Create an ActionScript that opens the web inspector:
https://gist.github.com/amuino/5649177 This works!
Have Xcode launch it! I tried creating a shell script that, in turn, opens the action script, but to no avail. This is what I've got:
How to run a script after Xcode runs codesign on my iPhone app?
Actually I found a way around this issue. It's not super elegant but it works.
At the entry point of my app I added some delay with setTimeout, like this:
setTimeout(function () {
app.init();
}, 10000);
This will give you enough time (10 seconds) to reopen Safari Web Inspector and you will get full console read out.
It saved me a lot of headache.
The app responds to a custom URL, and correctly launches when in a suspended state. The question is, can I disable showing the Default.png when launched this way?
A use case for clarity:
app is started normally
a home button press puts app in standby
a url of the scheme the app recognizes is tapped in mobile safari
users sees Default.png before launch is complete.
As you probably know, when fast app switching activates usually the app is redisplayed with a screenshot of the last state rather than the Default.png. This is what I'd prefer happens when the URL launch takes place also.
It sounds like what is going on is that Fast App Switching is not actually working. So:
Make sure you are building the application for SDK for OS 4.0. If you don't, you app will not have fast app switching support.
See if fast app switching normally (otherwise) works with your application. I.E. when you just switch to safari, then re-launch your application, do you get the "default.png"?
Run the app under the debugger, but on your actual device. Make the problem happen, go into the Organizer, and look under device logs. This will show you if there was a low-memory issue which caused your application to be terminated, when Safari was launched, thus requiring it to be re-launched when the URL was selected.
I believe there were two mechanisms in place. In my app, I do not support "Launch with URL" - but what I do do is support the Application Delegate's call:
-(BOOL) application:(UIApplication *) application handleOpenURL:(NSURL *) url {
This may be the difference - this is the call which can be made to an application that is running to hand it a URL to process. If you are using the other technique, use this one instead. I use this, and do not see the "default.png" - i.e. do not evoke a "clean relaunch" when I get called.
Here's a possible workaround. This was causing me a headache with trying to seamlessly return from Facebook's single sign on process. I wanted the appearance of going back to my app's login area, instead of the appearance of restarting the app, even though I verified in every way possible that the app was indeed returning from fast app switching and not actually restarting.
While I couldn't find any way to force the app to display the previous state's screenshot, I did discover that the app will display Default-scheme.png (for example, Default-fb12345.png or Default-appname.png) when invoked with a url. So if your post-app switching screenshot is fairly predictable, grab a screenshot from iOS Simulator and copy it into your app. I would consider this an iOS bug. The app should always display the last screenshot when app switching, rather than Default-scheme.png simply because a url is involved.
Another possibility, which I didn't test, would be to symlink the bundle's Default-scheme.png (and Default-scheme#2x.png) to the snapshot file in the app home directory. This would be Library/Caches/Snapshots/[Bundle identifier]/UIApplicationAutomaticSnapshotDefault-Portrait#2x.jpg for most situations (unless it's landscape, or an iPad). If your app's state is unpredictable but the orientation is fixed, this could be a good option to try.
Make sure you've got the "Required Background Modes" key set in the Info.plist to the function that the app needs. If it's not listed, I just use "App Plays Audio" to keep it open.