Hai i developed a application using broadcast receiver.I need to wake my Application always.so i used wakelock.here my code
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, "My Tag");
wl.acquire();
problem
1.If i wake up always my battery is getting drained.
2.if i cal w1.acquier() ,Is necessary to release the w1(ie w1.release)
I don't understand what is your 1st question.. I thought that is a fact if you want to keep waking up your application?
If keep your screen not dimming down is what you want to achieve, you could try this code:
//This is to keep the screen not dimming down.
Window.AddFlags(WindowManagerFlags.KeepScreenOn);
Wake lock keeps the cpu running on your application even when the screen is off so it will drain your battery hard. You want to call release on your wake lock when you no longer need the application to keep running in the background (example not waiting for any more callbacks).
Related
So, I'm developing an app that has a timer for about 5 minutes. During this time, the app should remain active. Accessing geolocation, counting steps, etc. The problem I'm facing is that the app falls asleep and the timer stops ticking.
I'm using react-native-background-timer for a timer. It shouldn't fall asleep, but it does. On both, android and ios. Actually it works perfectly fine when the app is in debug mode. But on release version without debug app simply falls asleep after about 3 minutes when the screen is turned off and timer stops ticking. It resumes when phone wakes up.
I can keep screen on all the time, with react-native-keep-awake, but I don't like this solution. Because my app also counts steps, and the phone should be ideally in the pocket. And with active screen, it will register accidental presses. Not good.
There should be a way. Phone calls can be really long with disabled screen and phone app doesn't sleep. I just don't know which direction to take. It's also hard to test, because with debug mode, app doesn't fall asleep at all. I need to run the release version and wait 3 minutes hoping the timer won't asleep.
Any ideas? Thanks.
Firstly, apologies for the slightly open ended questions but I can't find the info I'm looking for in other questions.
I'm trying to understand the lifecycle of a RN app on both iOS and Android. I understand the app bootstraps when you first start it and stays running while the phone is alive, but what happens when the user switches to a different app and comes back, or their screen times out then they switch it back on? It would be really annoying if the app restarted just because they briefly switched to check their email.
My specific use case (not particularly important to this generic question but included for context) is that I'm trying to build a game with socket.io connections and I'm wondering if I can hook into events to see if the app has been in the background or if I even need to. I have found a way of forcing a restart which may be necessary at some points, but I'd rather just try to reconnect things that have disconnected if I can find out when that happens.
Any push in the right direction would be appreciated.
The app doesn't restart when it goes in the background as you describe. The app keeps its state and the user sees the last screen they visited.
You should have a look at react native's AppState
https://facebook.github.io/react-native/docs/appstate
Using AppState you can addEventListeners that capture the change of the app's state like when going to background.
Of course there are also some problems here...
You can't capture the "kill "event. You can only detect if the app is sent to the background but unfortunately you can't detect when the user chooses to "kill" the app
You can't run any code while your app is in the background. This might be serious in your case but you should evaluate it. For example if you have a timer and you sent the app to the background then the timer stops.
I read in many places that if user swipes up and kills an app, that app will not be able to receive location updates. I get didEnterRegion and didExitRegion callbacks are received when my app is not killed and is in background. But if I swipe kill app, app doesn't get those callbacks. My question here is,
Is it that app will stop getting callbacks ever? i.e., even if the app is launched again and is in background it does not get the callbacks
I read about startMonitoringSignificantLocationChanges and background app refresh when used together, I can get callback even when app is killed by swipe. I tried this and could not get it working. Is this the expected behavior?
Will startMonitoringSignificantLocationChanges and background app refresh together when used, I get region entry/exit callbacks after rebooting device?
This is not expected behavior. You are supposed to get didEnterRegion and didExitRegion callbacks even after killing an app in the task switcher. If you are not seeing this, something may be wrong with your app or testing methodology. Posting code may be helpful.
A few caveats and tips:
Make sure your app has obtained backround permission with locationManager.requestAlwaysAuthorization(). Without it, it cannot detect at all in the background.
Detection in the killed state did not work on iOS 7.0.x. It started working as of 7.1+.
Make sure you wait long enough to get detections. In some app states, it can take up to 15 minutes.
Before killing your app in testing, check logs to ensure you know what CoreLocation thinks is your current region state. If you turn off a beacon then kill your app, CoreLocation may not have had time to realize the beacon disappeared, thinking it is still inside the region. If you then turn on the beacon, you will not get a new entry event because it thinks you are already inside.
I've been testing the new Motion Activity Manager APIs (CMMotionActivityManager). I want to create an app that can receive and process motion updates from startActivityUpdatesToQueue while the app is not running in the foreground. I correctly receive motion updates (stationary, walking, running, automotive, unknown) while the app is in the foreground but as soon as it goes into the background (and thus gets suspended), motion updates cease to be received by the app.
CMMotionActivityManager Class Reference:
"This method initiates the tracking of motion data asynchronously. Upon calling this method, the motion activity manager executes the handler block on the specified queue, reporting the current motion in effect for the device. After that, the motion activity manager executes the handler block only when the motion data changes.
The handler block is executed on a best effort basis and updates are not delivered while your app is suspended. If updates arrived while your app was suspended, the last update is delivered to your app when it resumes execution. To get all of the updates that occurred while your app was suspended, use the queryActivityStartingFromDate:toDate:toQueue:withHandler: method."
I want a way to keep my app running in the background and receive motion data (real-time). Right now the only way to keep the app running in the background is to use background services but "motion updates" is not in the list of allowed background services:
App Store Review Guidelines:
"2.5.4 Multitasking Apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc."
I don't want to have Location Updates (GPS) on all the time (to save battery). If I bank on continuous location updates but switch the GPS off, the app will get suspended.
Please let me know how to keep my app running in the background and receive motion activity updates.
There must be a way to do it: I tried the Strava app....even when the app is in the background, it swithes the GPS off when the user pauses running. When the user resumes running, it automatically turns the GPS on (all this while the app is in the background)...this probably means that the app is running in the background and actively receiving motion activity updates even while the GPS is off.
This is not a new issue. There has never been a Core Motion background usage setting. You are allowed to use Core Motion if your app is running in the background, but to make it run in the background you have to be doing something else (e.g. getting location updates at the time the user sends the app into the background, and you have the location background service listed in your Info.plist.
Note too that in iOS 7 if you have the right hardware you may be able to use deferred location updates to wake your app periodically in the background. Thus you save power but your app gets to run in the background now and then without an Info.plist background service listing.
I am bit confused about these two states. Following is my understanding;
when app is in background and if you have "Application does not run
in background" set to NO in App plist file then App continues running
in background. In suspend mode App stays in memory but does not
execute code! System doesn't notify App when it moves to Suspended
state and wipes out App from memory in low memory situation to create space for foreground Apps.
Is my understanding correct? If it is so then why don't I get my NSLog printed on console when App running in background and executing code? What actually happens to my TCP socket connection where I am continuously gets the data from server? Why do we need Suspended state as anyway System eventually wipes out App from memory in low memory situation. Is there any difference between App becoming active from suspended state or starting fresh?
You should look in the IOS App Programming Guide section "App States and Multitasking".
Find that by searching the Xcode documentation with the phrase "App States and Multitasking" and "Hits Must" item set to "Match Search Term". Another useful search phrase: "background execution".
The summary answer is that an application can continue "executing" in the background indefinitely for only a limited number of reasons:
in iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background,
such as a music player app
Apps that keep users informed of their
location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Aside from those specific operations, an app can ask to continue to execute for a very short time which the documentation covers in the section "Executing a Finite-Length Task in the Background". After a short time either your app tells the system it is done (and is then suspended) or it is forcibly terminated. Details in the doc.
Another useful bit of that document, with nice state diagrams, is the section "Managing App State Changes". That section talks about going into the background and returning to the foreground. It should answer your question about the difference between starting fresh versus starting from the suspended state. The short (not quite correct) answer is that if you start from the suspended state and you don't take any special actions when entering the background or (re)entering the foreground then you just continue more-or-less from where you were. Also, starting from the suspended state is faster. Read the doc since it says it much better than my paraphrase would.
App State
Not running: Your app is in this state before it starts up.
Active: Once your app is started, receiving events.
Inactive: When your app is running but something happens to interrupt it, like a phone call, it becomes inactive. Inactive means that the app is still running in the foreground but it’s not receiving events.
Backgrounded: In this state, your app is not in the foreground anymore but it is still able to run code.
Suspended: Your app enters this state when it’s no longer able to run code.
Background:
Executing code - Code is executed while the app is in a background state.
An app must go into a background state before it can go into a suspended state.
ie. Suppose you're on Facebook and you upload a video and you quickly switch to another app immediately after pressing the POST button. Although you switched to another app w/o terminating the app, the app can be configured to perform background processes to complete the upload.
An app that is in background does not necessarily mean it is suspended but an app that is suspended is in background.
An app can request to stay in background mode for extra time (for purposes of playing audio in the background or completing a network request, for example); afterward it will either go to suspended state or it will be forcibly terminated by the system.
Suspended:
Not executing code - Code is not executed while the app is in a suspended state.
An app that is in a suspended state is also in a background state.
The system moves apps to this state w/o notifying you beforehand.
An app in a suspended state is still in memory.
Some additional information that may help you on this topic:
UIApplication notifies the app of state transitions through methods in the AppDelegate.
Most state transitions are accompanies by these methods.
These methods are part of the UIApplicationDelegate protocol.
They provide you with a chance to respond to state changes.
The method below, for example, tells the delegate when the app is about to terminate. - It's only called if the app's in background before being terminated; not suspended.
func applicationWillTerminate(_ application: UIApplication) { ... }
In addition to Charlie Price's answer from 2013, iOS now also allows background for:
REMOTE NOTIFICATIONS that signal there is new content available for download. When a remote notification arrives, the system launches or resumes the app in the background and gives it a small amount of time to download the new content.
CORE BLUETOOTH to communicate with a bluetooth accessory while in background.
Click here for more details
UIApplication.shared.backgroundTimeRemaining tells you how many seconds is remaining until the system terminates the application. 3 minutes is the maximum time limit, but this time restarts each time the app is woken up in background mode.
You can prevent your app from ever entering a background or suspended state & instead immediately terminating by setting the UIApplicationExitsOnSuspend key to YES in the info.plist.
Additional links you may find useful:
https://developer.apple.com/library/archive/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
https://developer.apple.com/documentation/uikit/core_app/managing_your_app_s_life_cycle/preparing_your_app_to_run_in_the_background/about_the_background_execution_sequence
https://medium.com/#abhimuralidharan/finite-length-tasks-in-background-ios-swift-60f2db4fa01b
https://qph.fs.quoracdn.net/main-qimg-473264d5d9f0ec16d57b8dffcc9824d8