I have a timer running in my app. When the app goes in background I realized I need to removeFilePresenter because otherwise the process is killed and when I am back in foreground my table cannot reload data.
How can I do that and reload my graph database as soon as the app comes back to foreground?
Thanks!
You can reload your data in the viewDidLoad, or viewDidAppear lifecycle calls in any view controller. Even with many instances of Graph, it will always reference a single instance under the hood, so you don't have to worry about duplication or poorly managed resources.
Related
I have an app that uses sharing of CoreData in iCloud when activated by the user. Upon activation, the app needs to be restarted because most of the sharing code is done in AppDelegate. What is the accepted way of not only notifying the user to restart the app, but making sure the app is truly restarted and not just put in the background?
There is no accepted way, because this is a sign of a badly designed app. Apps are not allowed to simply exit (Apple will reject the app for this). Asking the user to force-quit your app is like hanging a big, flashing "crap" sign on the app.
The fact that code is in the app delegate is no excuse. First, you can (and should) move that code out of the app delegate. Second, even if it's in the app delegate, any object can be disposed of and re-created. That includes the entire Core Data stack. Reinitializing Core Data and your UI is a big step but it's possible. If you need to reinitialize things, then do it.
I've got an App with Extended Execution.
When I close the App, it runs perfectly fine in the background.
But when it is in "background" I need to do some things differently than when the App is visible.
Since I'm extending the Execution session on startup, the OnSuspending Event is never called. Is there any way to check if the App is currently active?
Thank you!
If you must start the extended execution process when the app is running you could possibly use navigation (or resize?) events that will tell you when you lose (and possibly regain) UI?
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?
I'm debugging a Core Data issue in my app (running on iOS 5), where the changes to existing managed objects are not being persisted between app sessions. If I use [UIManagedDocumentContext save], nothing happens, and my changes are lost next time I restart the app. If I use [UIManagedDocument saveToURL], however, the changes do get saved. The Apple docs are unclear as to which is the right way of persisting the updates. Can someone explain the difference between the two, and when to use each method?
I'm currently working on a solution that has two projects, a console and a form application. The console application is the main entry point to my application, and from the console the user would run the form application.
The problem is, when the user boots the form application the rest of the business logic (from the console app) won't run until the form is closed. My first thought was to use a background worker for the form, but the business logic in the form project already uses a background worker (and I only have two CPUs...). Perhaps this could be my ignorance for multithreading, but is there a way to do this?
Any thoughts are much appreciated!
Cheers
Well, this is pretty unusual. In general, it doesn't make a lot of sense to provide the user with a nice GUI and still leave a console window up and interactive.
But yes, calling Application.Run() or Form.ShowDialog() is going to block the thread. It has to, the message loop needs to be running to keep the GUI alive. If you do this, be sure to put the [STAThread] attribute on the Main() method.
The only other decent alternative is to start a thread. This isn't a problem, a UI thread doesn't burn any CPU cycles. Code only ever runs when the user does something, it's otherwise idle 99% of the time. Be sure to call the thread's SetApartmentState() method before you start it, STA is required.