My React Native (Android) application sends requests to the server when some events are triggered. But when I lock phone screen and in a few minutes event is triggered, app try to send request, but it fails. I tried fetch (error Network request failed) and XMLHttpRequest.
On some devices it works fine and I can't understand it depends on Android version or on device model.
Why does it happen and why on some (not all) devices? How can I fix it? Thanks!
Hello issue not because of react-native development but as per android guideline,
Whenever device in Doze mode you can not access network or network resource directly for that you need to start some foreground service in your application or we can say foreground service, Actually, I don't know much about how to create and start foreground service in react-native, But maybe this word help you, Here also official document regarding doze mode
https://developer.android.com/training/monitoring-device-state/doze-standby
Related
I have developed a hybrid app running on Android, that successfully monitors the users location and displays it to the user as a moving icon on a map. This part of the app is all written in javascript and works inside a webview. The webview also communicates with my remote server to share the user's location with other users of the same app.
Up until Android Nougat this all works even when the app is backgrounded for several days. When the user returns to the app they can see where they have been with timestamps at each point. And all the other app users can see where everyone is, even if they are no actively using the app.
From Android Oreo onwards, I had to move the location tracking to a background service to get it to continue in the background and I have tested this to be still working fine even with the app in the background for a long period. Returning to the app, the user can still see where they have been. However the remote communications to the server, on Android Oreo and later, cease after approximately 2 minutes in the background.
Please could someone explain why this is, and what I could (if anything) do about it?
What is the restriction that I am running into and where is it documented on Android developer? I have set the app as not to be limited in settings/network/data saver and this makes no difference.
Would it make a difference if I replaced the webview XMLHttpRequest with similar code in background service, using volley or something similar?
All help very much appreciated.
Although I have not discovered what restriction I am running foul of, I have found that by moving the http request from the web view to the background service using volley, the server continues to be updated whether or not the application is in the foreground.
Only tested so far on Android 8,9 and 10 in the emulator. Testing soon on a real device
I have developed a react-native app for Android to receive real time food orders (like Uber Eats, Postmates, etc.). The app is running in a Lenovo tablet that is constantly charging. I use a GraphQL subscription to detect new orders and Firebase Cloud Notifications to check the network status of the tablet.
The problem is that right now the system eventually kills the app after some days with no interaction. I would like to know the best approach to prevent the systems kills the app and being able to run it 24/7 in this case scenario.
Thanks!
You should write a service for your app, which starts the app when it gets killed.Never ending service has a good tutorial on how to do this.
I am using service for sending current location of device to server continuously in background, but service is also getting killed when I swipe out the application on some phones. It's working if I remove restriction of running background services from Phone settings to the app. I will be thankful, If someone provide solution of removing this restriction programatically.
Every Phone manufacturer has it's own settings for background processing apps. As there are many android device manufacturers it will be difficult to check for every device group. I'm facing the same issue for my app. It will be better if you ask to check is there any setting regarding background services in their device.
I am running a background service which checks for some updates from the server every 2 hours in my android app and it works fine so long as the device is the not in the locked state. But once I lock my phone and unlock again I see my device displaying the message that my app has crashed. What could be the real reason behind it. Does it need some permissions to be declared. Could anyone suggest me as to why this is happening.
It can be happening from several causes. But I gonna give my guess: are you taking in consideration the case that your app fails to reach the server? What I mean is that I'm guessing that when you lock your phone, or close it in some way, it can be closing your connection and your app can be crashing because it fetchs the server without connection. Its only a very broad guess...
I'm building a webapp for Android smartphones that runs with the OS internet browser. the main interface is to input data. the data is added to a queue (android 1.5: gears, android 2.x: html5). Each 5 minutes (using setTimeout), the script looks if an internet connection is active, and if so, sends all the queue to the server.
If the phone is plugged on the wall and the webpage is ontop, the timeout works. if the browser is minimized or another application runs on top of it, the timeout doesn't work. if the phone is in sleep mode it doesn't work either.
Can only native apps runs in background?
can only native apps runs in
background?
Certainly, I would not expect the browser to be waking up the device, for your sleep mode scenario. Apparently, based on your symptoms, they pause all Javascript threads when the browser itself is paused. That is not terribly shocking, given the battery problems that leaving those scripts running might cause.
You could also base it on system time, rather than just setTimeout. That way it would at least run when they returned focus to the browser.