Is there a way to completely shutdown/kill an Expo app as soon as it gets exited by the user(To the background) so when he opens it the next time it opens from the start?
I know there is BackHandler.exitApp() but that just exits the app and doesn’t close it completely so that’s not what i need.
Related
I have created Mobile application in React native.
My problem is that whenever i open my app from launcher icon and minimize for sometime (eg: 10 minutes) then if i re-open my application from recent apps or else on clicking launcher icon again it should restart the application as it opening for the first time.
But doesn't matter how much time i minimize the application when i open it again it will open as a previous state.
How to solve this issue.
What Navigation module are you using? Depending on it, you need to call a method to init the app and that method must be called again when you switch back to the app.
Normally, application has their inherent state as snapshot when it go to background if the user do not close directly.
If you are testing on android, pressing backbutton on top of the navigation makes close the application. (you can control this if you want.)
In iOS, pressing home button always send the application into background instead of close.
I am not sure what OS you are using for development. But refer it.
I want to debug a today view extension (widget) in iOS 8, so I select the widget under "Scheme" in Xcode, and select my iPhone as the device and hit run. It says "running today-view on iPhone" and on the side bar on the left it says "Waiting to attach". It gets tuck at the "waiting to attach" phase forever and never shows me any debugging info on my iPhone. However this works fine if I select the simulator as my device. After a few seconds of "waiting to attach" in the simulator, the widget comes alive and debugging info is displayed.
Has anybody come across why an extension won't show debugging info on an iPhone but will in the simulator?
Do not stop & start the debugger while notification windows is open in the simulator. Close the notification window. Stop the debugger. Start it again. Debugging widget in iOS8 is very delicate. You need to do everything in a slow non-agressive way (for now).
Edit the extension scheme and make sure that under Run, the Executable option is set to Ask on Launch.
Run the extension scheme.
From the list, select the Today executable.
It should launch the Today app and your extension should be attached to the debugger now.
Close the notification window. It should start working.
I've been able to debug my Today view extensions in this way.
1) Make sure the notification center is dismissed.
2) Stop every process in Xcode with the stop button.
3) Run the extension scheme
4) Pull down the notification center and should hear the usual "app launched" sound from Xcode
5) Debugger will be attached automatically and you'll be able to debug the extension.
Let me know if this works for you.
This happened to me .... Looks like you were doing everything right .... try all the above.
The problem went away when I unplugged and re-plugged in my Phone.
Sometimes click on the widget will fire the running of extension.
Delete the app from your phone
Run the today widget scheme
It worked for me.
I am making a vim-style "window manager" that takes text input, much like Alfred or Spotlight in Mavericks (in a floating panel).
The problem I'm having is when I call activateWithOptions: on a running application it steals focus from my window. I was hoping the problem would be solved by simply bring my app to the foreground again, however it seems the activation is running on a separate thread, and I end up activating my app before the original app gets activated.
I have tried reactivating when I receive NSWorkspaceDidActivateApplicationNotification, but that doesn't work either.
Ideally I'd like to pause execution until the application is focused for multiple reasons, since that would be the window I manipulate further.
Does anyone have any suggestions?
I want to be able to restart the app when coming back from background. So if the user selects the app again it should start as if it were the first time it's open. I've been googling but couldn't find a way of doing this.
I was thinking in just add the main view of the app in applicationWillEnterForeground, but It would be great if I can deallocate resources.
You can't restart an app. What you can do is disable background support, so your app always completely terminates when closing.
"...you can explicitly opt out of the
background execution model by adding
the UIApplicationExitsOnSuspend key to
your application’s Info.plist file and
setting its value to YES."
Source: Opting Out of Background Execution.
VS2012's default C# "Metro style" project templates include code in App.xaml.cs (in the OnLaunched override) to restore the application state after a suspend-and-terminate. This code only runs when LaunchActivatedEventArgs.PreviousExecutionState is Terminated, i.e., "The app was terminated after being suspended."
How can I force my app to be suspended and terminated, so I can test this suspend/resume functionality in my app?
Things I've tried that don't work:
If I use the "close app" gesture (drag from the top of the screen to the bottom), then the next run's PreviousExecutionState is ClosedByUser.
If I kill the app -- either using Task Manager, or (if I was debugging) with the "stop" button on the VS toolbar -- then the next run's PreviousExecutionState is NotRunning. This is true even if Task Manager showed the app as "Suspended" before I ended task, so clearly it's more nuanced than the description of "terminated after being suspended".
You'd think I could just switch away from my app, and then open lots of other Metro-style apps until my app eventually gets kicked out. But even if I open every single Metro-style app that ships with the Windows 8 Release Preview, that's apparently not enough memory pressure to make Windows terminate my app. (I assume Windows would be less likely to terminate an app that was being debugged, so I launched my app from the Start screen -- no debugger -- before I tried this.)
It does appear that, if I switch away from my app and type into a StackOverflow window for several minutes, that my app will eventually get terminated, so perhaps there's a time-based component to it. But if I have to wait five or ten minutes every time for my app to terminate, that's a pretty slow testing cycle.
Given that this is something developers will have to test, you'd think there would be a nice, easy way for a dev to force an app to suspend-and-terminate. Is there some kind of stress-test app that comes with Visual Studio that will force enough memory pressure? Is there some menu item in Visual Studio that will force termination of my app? How are we supposed to test this?
In Visual Studio 2012, when you're debugging, there are "Suspend", "Resume" and "Suspend and Shutdown" buttons. By default, you should see the buttons while you are debugging your app. See this article for more info on debugging process lifecycle.
I had trouble finding the Suspend control because VS wasn't showing a second row of toolbars for me. As it turns out, this is on the "Debug Location" toolbar. Make sure you have this toolbar turned on and then you should be able to find the Suspend control (and it does work to solve the OP's problem).
If they don't show by default, go to TOOLS -> CUSTOMIZE, and under the Toolbars tab, check the box that says "Debug Location"
I was looking for VS 2013, just in case others came for the same reason.
Source:
http://blogs.msdn.com/b/visualstudio/archive/2012/08/23/new-visual-studio-2012-debugging-features-for-the-windows-8-app-lifecycle-model.aspx
a busy cat http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-92-metablogapi/2210.image_5F00_thumb_5F00_1FBA9C1E.png