I would like to launch a particular viewmodel...similar to ShowViewModel()... when the application comes back from suspension.
For an Android's activity, it seems like the current activity can be pause and I would need to have the call in the OnResume of each activity in the application.
For iOS, particularly iOS 7, it seems that the application will be resumed after a suspension and the call must would be in the appdelegate's WillEnterForeground(). In this scenario, I am assuming that the last ViewModel/View is unknown.
How is the best way to handle this?
Thanks.
Related
I am implementing an app in Flutter, for which I need to schedule (audio) events in advance. Only after one event is completed I can schedule the next, since the duration of the event might not be known before. Each audio event is a notification sound for the user, thus scheduling and audio playback should both work while the app has no focus or the phone is locked.
I currently fail to implement these specifications and I guess I'm just not thinking the right way about it for the moment. Since I started to learn Flutter recently, there could also be just some simple misunderstandings from my part. Let me summarize what I know about background execution & native code in Flutter, please correct anything wrong with these statements:
When the App looses focus (or the phone gets locked) code execution stops.
However, inside the "primary" Dart-code, I can spawn an isolate which will run even with the phone locked or without focus on the app.
Different isolates share no memory whatsoever; they communicate via ports.
There a spawned isolate does not know anything about the flutter ecosystem, therefore it is not possible to use flutter plugins.
For the same reasons I cannot use MethodChannels as well to communicate with platform code from an isolate.
From this I conclude:
The event should be scheduled from a seperate Dart-isolate, so that locking the phone won't halt scheduling.
This isolate won't be able to play any audio file by itself, and won't be able to communicate with platform code.
Thus, it needs to communicate with the primary isolate, which can play audio. However, without the app open, the code won't respond.
Consequently, this approach cannot work?
Right now, I am stuck at this point and don't know how to continue. I guess one option could be to directly call java/swift code for the respective native platforms and handle scheduling and audio there. Yet, I hope that I just don't see a simpler option right now.
I have troubles using ExtendedExecutionSession in Windows 10 UAP.
First, it seems that ExtendedExecutionSession.RequestExtensionAsync only returns Allowed if it is called from the app Suspending event handler. If it is called outside this event handler the method returns Denied.
Second, most critical problem. My app executes downloads. If any download is in progress I request ExtendedExecutionSession to allow downloads to complete. What I found at least on Windows 10 mobile though is ExtendedExecutionSession is allowed in app on suspend but downloads seem to freeze. Nothing is downloaded while app is in background and when app is resumed downloads appear frozen with no data transferred.
Here is the MSDN guidance for Extended Execution: https://learn.microsoft.com/en-us/windows/uwp/launch-resume/run-minimized-with-extended-execution
SavingData is the only type of Extended Execution Reason that can be used in the Suspending state. Note that this is specifically for saving critical user data locally that will be lost once the process is removed from memory.
It sounds like you should use the Unspecified Extended Execution if you need to accomplish something when your app is running and in the foreground. It will be revoked if the user decides to close the app before the download operation completes. Like was previously suggested, a background transfer or use of the ApplicationTrigger or MaintenanceTrigger may be better options for these downloads if you want them to continue after your app has been closed.
Maybe it's a simple question, but I don't get it. When should I use concureency in my javafx project? Is it right that I should use for every task, which do some action in the background, the Concurrency API? So every action in my controller class, which has nothing to do with the UI should be executed in a single task?
I really don't get it how to use this right....
Whenever you have a task that may take sometime to get executed or there is a possibility of delayed response, you do not want your JavaFX Application thread to wait for it, because, as long as the JavaFX Application thread waits for the response, the UI becomes unresponsive.
A few examples where you may want to use a background thread is :
An I/O operation
A web service call
From the JavaFX documentation :
Implementing long-running tasks on the JavaFX Application thread inevitably makes an application UI unresponsive.
On the other hand, if you have minor calculations or some task which can be completed in a jiffy (I am not sure if this is the correct word, but I hope you can relate to what I want to say) and will not put the JavaFX Application thread on wait, you can execute them on the same thread.
I am new to mobile website development, and facing this issue where I want to refresh data on the website in every 30 sec which is invoked from the client side and server provides the data in response. Problem is when I close the browser or when the browser goes in background it stops working. Is there any thing we can do to make this thing possible?
Have a look at the Android Developers - Processes and Threads guide. You'll get a deeper introduction to how process life-cycles work and what the difference is between the states for background- and foreground processes.
You could embed your web app in a WebView. This way you could deal with the closing browser case: you could provide a means to "exit" the app that involves closing only your container activity. That way the timers you have registered in javascript will still be running in the 'WebViewCoreThread'. This is an undesirable behavior and a source of problems, but you can take advantage of it if you want (just make sure you don't run UI-related code there). I've never tested this in Kit Kat (which uses a different WebView based on Chrome) but works for previous versions, as I described here.
Now the user can always close any app. Even without user interaction, the OS can kill your app on low memory. So just give up on long-running apps that never end, because the OS is designed in such a way this is simply not possible.
You could go native and schedule Alarms using the AlarmManager.
Just checked this out on the Android KitKat WebView and as per Mister Smith's comments the javascript will continue executing in the background until the Activity is killed off:
Just tested with this running in a WebView:
http://jsbin.com/EwEjIyaY/3/edit
My gut instinct is that if the user has moved your application into the background, there seems little value in performing updates every 30 seconds, it makes more sense to just start updating again once the user opens the device up and cache what information you currently have available to you.
As far as Chrome for Android goes the same is happening, as Chrome falls into the background the javascript is still running.
If you are experiencing different behaviour then what exactly are you seeing and can you give us an example?
Just need to know what to handle for this situation:
Case(1) When user is not doing anything on the screen for a period of time
The system will suspend the app? Is this what causes suspension? This means nothing will be processed in the background?
How to handle this case that I want the process continues when app is left unattended (example : Using GPS )
----- Update
Need some confirmations for the following scenarios:
1) App is launched and user navigates from mainPage to other Page AND left the Tablet alone for a period of time and user did not interact with the Screen.
In this case, this will cause the Physical screen turn to black color screen. Is this means app Suspension or something else?
2) How Lock Screen or Screen Lock work or when it will happen. how different is screenLock from above question(1)? or they are the same thing?
Screen Lock will cause App Suspension?
3) When user presses the home button (Hardware button) on the tablet, this will cause App Suspension or termination?
4) In Windows Phone, there are these to detect and prevent Screen Lock and run the app :
a.The UserIdleDetectionMode property
b.The ApplicationIdleDetectionMode property
Can these be used in WinRT App? or how to handle this like WP in WinRT
If the app is the foreground app and the screen is active, it won't be suspended. Apps get suspended primarily for moving to the background. This wouldn't be just idle time, but could be if something like a lockscreen/screensaver comes on and the window is no longer active.
You could know this immediately by looking at Window.Activated events, but in this case a de-activated window (assuming it was the only and primary one for the app) would likely mean it went to he background and thus in queue for suspend.
And yes, once suspended, no code is running from the app -- if you wanted background code to run you'd need to use a background task (see MSDN samples for an example).