Or to ask the question in a different way: Can you run shiny apps in the background without the app being explicitly accessed by a browser.
My use case. I would like to refresh a data file stored on the hard disk every day. To do this, I can use invalidateLater(). However, do I explicitly need to have this app open in a browser window for it to work? Do I have to initialise the app by opening it in a browser window for it to work?
Related
I have implemented iOS/iPadOS 13 state restoration using NSUserActivity, mainly because my app supports multiple scenes.
The problem is that when I'm running the Simulator with two side-by-side scenes and force restart the app by rebuilding the activities are not saved and the UI is not properly restored on relaunch.
On the other hand if I first go back to the iPad home screen and then I force relaunch the app, the activities are properly restored.
Would this mean that a crash of my app would prevent saving these activities leading to an inconsistent UI state on relaunch?
And how could I periodically "force" saving activities (get stateRestorationActivity(for scene:) called)?
The problem is that when I'm running the Simulator with two side-by-side scenes and force restart the app by rebuilding the activities are not saved and the UI is not properly restored on relaunch.
What you're seeing when you "force restart the app by rebuilding" is the expected behavior. When you force restart like that, the app does not have a chance to save your NSUserActivities. Per Apple's state restoration tutorial:
If you want to test your app’s ability to restore its state, do not use the app switcher to kill the the app during debugging. Instead, use Xcode to kill the app, or kill the app programmatically. One technique is to suspend your app using the Home button, and then stop the debugger in Xcode. When you launch the app again using Xcode, UIKit initiates the state restoration process.
I understand that you weren't killing the app in the switcher, but any "forced" stop will disable state restoration (with a caveat). To test state restoration, instead use the technique suggested by Apple's tutorial above.
Would this mean that a crash of my app would prevent saving these activities leading to an inconsistent UI state on relaunch?
I think so. This is the caveat from earlier. While Apple says that killing the app (whether in the app switcher or from a crash or whatever) will disable state restoration, this is not necessarily true. You can see for yourself that Apple's own apps have odd state restoration inconsistencies when killed in the app switcher and re-opened (you may have to try it a few times to get inconsistent behavior). While I haven't tested this, I'd imagine that those same inconsistencies can occur from app crashes.
Simply question: Is it possible for a Shiny app to be launched in the same browser target window as the previous instance. It becomes quite annoying to have to close all test run windows after a while. I've tried to set a fixed port, but that didn't help.
I'm making a BB10 app with a headless component that's normally supposed to run nonstop, except when a certain field in its QSettings changes (to save battery power).
I tried looking everywhere for the documentation. But I still can't find out how to make a headless app terminate itself.
You can get notified every time your settings file change using QFileSystemWatcher and calling bb::Application::instance()->quit() when a certain QSettings value changes. Here's an example from BlackBerry that uses QFileSystemWatcher in headless to get notification whenever the QSettings file changes.
I prefer using invocation or my own headless communication mechanism though, you can see an exemple of how I usually deals with terminating the headless app here.
I'm testing alivePDF 0.1.5 and till now everything's been fine.
I'm super interested in the new function writeFlashHTMLText() cause it makes my life so much easier! xD
I'm now trying to display the generated pdf in a browser tab/window instead of just saving the file (using the filereference class' save function). I saw that there was a PDF.save() function that allowed that specifying the argument Download.INLINE.
However I don't want to use the save function of the pdf class cause I don't want to use a script.
Is there any other way to achieve what I want?
Thanks a lot for your answers.
Regards,
BS_C3
Because of the way Flash works security-wise you have two options:
Generate and save the PDF to the local machine - this can be done entirely client-side using FlashPlayer 10+ (see the FileReference class).
The user can then navigate to, and launch, the generated PDF file.
Save the PDF to a server and link to the PDF from your Flash application. This will let you open the PDF in the browser.
Obviously this requires a server of some sort.
Build your app as an AIR application - this will let you save the file and, as far as I'm aware, launch it from the local machine.
The current state of things: you cannot generate a PDF and open it in the browser completely client-side (i.e. FlashPlayer in a browser) unless you are using AIR.
Every time i compile or run, the flex builder opens a browser showing the output... is there anyway we can destory the older window when newer ones open... i mean a setting in flex.
no. but i think if your pressing debug test and that opens a new browser and starts debugging your app, when you hit stop on the debugging, the app will terminate and close the browser as well. this if the debugging app is the only tab you have opened in the browser. other than that, you can't really do anything about it.
If you have flex builder set up to build automatically then you just need to save the file that you have changed and then when flex have finished building (you can see the status down in the right corner of the screen) reload your browser.
That is pretty much the workflow i have when i develop in flex. This way i only get new browser windows opened when i debug.