Is Application.onFirstStart event fired on application upgrade? If not, is there any way to do something only once on upgrade or on the first start after upgarde?
onFirstStart will not run on update.
You can use onStart function, inside this function you can control application.version in order to understand if application is upgraded or not.
Related
I'm building my first CloudKit application, and am using CKFetchRecordZoneChangesOperation on startup to get any new records changed while the current device was offline.
I am also calling CKFetchRecordZoneChangesOperation when I receive a subscription notification of changes.
It is possible the subscription notification could come in before the startup call finishes. I am currently using a lock to prevent the 2nd call from starting until the recordZoneFetchCompletionBlock handler is called, signalling that the first one is done. This works, but it also smells a bit hacky.
In the context of an application that has been registered to run in the background with the location services, what event(s) will result in backgroundTimeRemaining being reset to its maximum value and will that reset extend the duration allowed for the completion of ongoing tasks?
Based on the experiments I ran on the simulator and hardware, and for the context I defined in the question, backgroundTimeRemaining is reset whenever an internal call from the location library is made to didUpdateLocations (or didUpdateToLocation for IOS<6).
This is what all approaches used to running continuously in background leverage in one way or another.
What are you trying to do exactly? It looks like you want to run continuously in the background.
Or maybe you just want to run a little bit of code when the location updates? Then don't "cheat the system" and run that code when your app is notified of a location change (and run it using beginBackgroundTaskWithExpirationHandler:).
I am working with a quartz implementation in a Java web app. We have implemented the TriggerListener class so when a trigger fires, it calls the vetoJobExecution(Trigger trigger, JobExecutionContext jobExecutionContext) method. We check a reference table to see if the job should run or not. All of this works fine.
The part that is broken is if the job should NOT run, so the vetoJobExecution method returns false. After that happens, the trigger will never fire again. This is the part I do not understand. It seems like the trigger should continue firing, and the vetoJobExecution method should keep being called to see if the job should run. This simply doesn't happen - once the job is vetoed, the trigger does not fire again and the vetoJobExecution method is never called.
We are using Quartz 1.5.2 (yeah it's old, I know).
What is the correct strategy for having a quartz job not run using the TriggerListener interface, yet still having the trigger fire next time?
Fixed by upgrading to version 1.7.3.
I am new to PhoneGap and I am trying to develop a small iPhone application based on PhoneGap. My question is, is there a way to cancel the execution of a method invoked by calling PhoneGap.exec() method. Something like PhoneGap.Cancel() or something..?
Thanks.
in exec only, you can send an action to cancel any action that you had previously initiated using exec.
I am trying to post some data before my application terminates. Iam doing this by genrateing sockets using CFStreamCreatePairWithSocketToCFHost and later on I have the callbacks for reading and writing.
But I am not able to post any data. It goes through all the functions but doesnot enter into callbacks. Does that make sense to anyone?. Is there anyway to get this working?
Thanks,
Sowri
Yes, after applicationWillTerminate is called, there are no more iterations of the run loop. Since CFSocket and CFStream both use the run loop to manage the sockets and to provide data via the callback, this will not work. Also, it's very important to note that the application may be restricted from doing certain things at this stage and that if your application does not terminate, the operating system will terminate the application. It may be a better idea to write a small log to a database and then post that information back the next time the application starts.
My gut feeling is that after the applicationWillTerminate method is done, it will just stop the whole app, without giving any other run loop the chance to execute, let alone do callbacks. So my guess is that calling asynchronous methods in the applicationWillTerminate won't even start. You're just too late at that point to start networking.
The applicationWillTerminate: callback is not the place to do any kind of critical operation because as the name implies, your application will terminate and it won't wait for your code to finish doing something.
What are you trying to post; if you explain why you want to do this we may be able to offer a better solution.