Hi there!
I have read a lot of forums etc. about this topic and I have gained some knowlegde, but I still don't know weather it is at all possible.
Info
I'm using the Ionic Framework
Problem
I have an app which controls a IOT device using a network request (http/https).
Since the IOT device does not have functionality to automatically turn off after a specific time setting, I want the app to send this command after approx. 120 min. (2 hours).
So the user, when the app is opened, press a button to power down the device after 120 min. and then closes the app (kills completely, not in background).
Now I want the app to automatically send this power down command to the IOT device after 120 min.
I'm using Ionic Framework but can implement Native functionality and modules if it is possible this way.
What I think I know:
This should be possible on Android implementing a 'service' natively which I understand is a sort of deamon thread or resembles a Windows service. (exactly what I need).
iOS seems to be the problem, with a lot of restrictions on code execution after the app has been closed, or even stopped by the operating system. I've read on this thread (https://developer.apple.com/forums/thread/685525) that some cases are possible (music playing in background, fetching big files from the internet, etc.).
They also provide something they call PushKit https://developer.apple.com/documentation/pushkit. But that seems to only be able to notify the user, and auto power down is not smart if I have to send a request to the user that the 120 min. are up, now you can turn of your device yourself xD
Question
So my question is, will this be possible at all on either operating system (Android, iOS) or will I have to implement a server that will send the request to the IOT device instead?
TLDR
Is it at all possible to send a HTTP request after 120 min. on iOS and Android after the user has manually closed the app (killed the app)?
I have looked through a lot of forums and has not found a definitive answer to this question.
I expect that it will not be possible on iOS but only on Android.
Many threads on this topic is approx. 8-12 years old, so maybe some new possibilities has come to light?
Related
We have a device that need to be started at night, the device is started thanks to a bluetooth command sent by a mobile application. It's possible to send this command while the app is in the background and keep monitoring the device (i.e. receiving data), for example, for 30 minutes?
If it's possible what would be the ways to implement this feature in iOS and Android?
Update: Think about a sleep tracking device; the problem shouldn't be to scan all night because the user must connect the device before go to bed (and eventually try to automatically reconnect to a known device, without the need to scan). I'm asking if it's possible to stay connected and send/receive data while, for example, updating an internal database all night.
Several thing to take into account about Android BLE system development, read this for more information: https://blog.classycode.com/undocumented-android-7-ble-behavior-changes-d1a9bd87d983
BLE Scanning has an abuse prevention since Android 7. What does this means?
Prevention for an app stopping and starting BLE scans more than 5
times in a window of 30 seconds.
Long-running scans are converted into opportunistic scans. (30 minutes).
About the background process depends on what type of service you want. You can start a foreground service with a notification or you can start a Job which runs always in the background with no notification.
If you can be more precise on how the system is going to work I can give a more detailed explanation.
Edit: I've noticed that StackExchange has prefaced this question with Android but it applies for both iOS and Android.
We have a client side iOS/Android application that we expect to run (in remote Australia) with very limited internet connectivity. However, the application can expect to have very good connectivity to its local network, which is not on the net.
I've been looking into ways of waking a phone up with a notification of some sort whenever an event happens on the local server.
From what I've researched:
Web push is no good as even the newer VAPID based protocol still wants to route some data through the browser vendor's notifications server.
iOS Apple Notifications essentially have the same requirements as Web Push.
A background task which periodically polls the server/wakes up a Websockets connection can work, but could end up with pretty long delays between polls.
SMS is an option, as although 3G is limited, basic phone connectivity is sometimes available.
Are there any other ways of being able to wake up a locked mobile device with a server-sent event that I haven't listed? Given the operational situation having App Store compliance is not necessarily a requirement.
Cheers
After doing a fair bit of research, the answer (as of early 2018) is a pretty solid no, at least for a cross platform usecase.
iOS requires that an external notification that can wake the device come from a recognised internet-based source (APNS, and maybe in future the standardised VAPID based Push), from the mobile interface if available, or from the device itself which is limited by background execution restrictions.
I have a Freeswitch+FusionPBX server.
I have 2 numbers and devices
100#192.168.0.100 at Android (CsipSimple). The software has an option to stay running.
101#192.168.0.100 at iPhone (MitraPhone).
How it works
Since Android app is always running, I can always make a call from iPhone to Android.
Since the iPhone app is not running in the background, I can never call to iPhone except when MitraPhone is open.
Question
How to use SipPhones as expected at iPhone? So I can call to iPhone any time.
Suggestion
Since there should be some push to wakeup the iPhone app, maybe there is some SipPhone for both Android and iPhone, which can push each other on call?
AFAIK, there is no softphone that does what you want. But basic pieces are available.
For VoIP pushes, Apple released a specific API: https://developer.apple.com/documentation/pushkit
Apple also released CallKit to seamlessly integrate your VoIP service to general calling UI.
Someone tried to persuade freeswitch core developers to build the needed server-side module, with no luck:
https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-4347/FS-4347.html
These are what came up with a little bit of googleing.
We have an Android app with over a million active users. We recently started receiving feedbacks from users complaining that our app consumes huge amount of network data when in background (around 0.5-3 gigabytes in a week).
The app doesn't have any operations in the background except for the push notifications receiver which doesn't have any network calls. the data consumption on the background should be less than 10 megabytes for a week for sure.
Is there a code I can use to help me detect the cause for this data consumption when my app is in background?
Is there a way to limit data access from all SDKs when my app is in background?
In general, what's the best way to approach such a problem?
Thanks
Update:
In our case we found eventually that the source of the problem was from an SDK we integrated with the app.
If you have the same issue, I suggest you look closely at all your 3rd party code in the app, especially new libraries you added.
Second, check all the services that your app define in the manifest, look closely if any of those services can be the source for this problem.
Third, look for places in the app that use network operation with a re-try mechanism, there could be an infinite "while loop" trying to send some data to a server (maybe some sort of reporting or analytics).
You need to inspect the traffic coming over the wire from your devices. You will need one computer and your device connected to the same local network.
Set up a debugging proxy like Fiddler on a machine on your local network and note its IP address. This assumes your app communicates via HTTP.
Connect your test device(s) via WiFi to the same network as your debugging machine.
Configure your Android devices to use a proxy that points to your debugging machine.
Now you will be able to inspect all requests originating from the device(s). Presumably you will have to leave them running for some time to replicate the problem of some kind of periodic background service running and downloading data. However, I can tell you now that push notifications themselves are not causing 3GB of data on a single device.
You can write code for count the data usage as follows.
recived = TrafficStats.getUidRxBytes(uid);// uid is your appID
send = TrafficStats.getUidTxBytes(uid);
TrafficStats.getMobileRxBytes();
TrafficStats.getMobileTxBytes();
TrafficStats.getTotalRxBytes();
TrafficStats.getTotalTxBytes();
and there is good answer you can find here..
App data usage finding
I was thinking of using multiple Android devices (e.g. Nexus 7 tablets) to build a photo / video wall and I'm wondering a) whether it is possible and b) how to synchronize the display of all these devices. Google showed off its Chrome racer experiment so clearly it is possible to synchronize displays across many devices.
So here are my questions:
what technology should I use to synchronize the displays? Android? Chrome? Please point me to existing code if possible.
what's the minimum lag between devices that could be achieved in such a setup?
can video and sound playback also be started simultaneously on multiple devices (think video wall)?
what kind of architecture should be considered for such a project? Centralized server that sends out commands? Should devices talk to each other?
I'm very curious about suggestions!
EDIT:
blinkendroid is the only app I've found so far that might do the job. Pros? Cons? Alternatives?
Technically the screen isn't shared, the games state is shared and the phones all render the state as they understand it.
Just a bit of background about Chrome Racer. We have a case-study on here, but it doesn't fully cover the question you are asking.
The primary technology used for communication in Racer is WebSockets. WebSockets allow one client to push and receive messages from a server in near-realtime.
Racer starts a session for a game by giving it a unique ID and holds open a Web Socket to the user. Anyone who subsequently joins a game is told to use the Same ID and the server creates a Web Socket to them as well. Now the server knows all the participants.
When a game starts a message is broadcast to all the participants asking them get ready to start, during this phase the server is working out how long it takes to round trip messages to all the clients. It is doing this so that it can work out any latency between devices and thus attempt to compensate for the latency on the slower clients.
Now the server knows about the clients the game can start properly. As the users are playing their game their commands are being pushed to the server over the web socket. The server the relays this message out to all the connected clients (like a satellite does) and it does this same thing for every single user that is connected to the session. This is how the games state is shared.
As each client receives the commands that are broadcast to it from the server it updates its internal representation of the game and renders that to the screen.
And that is about it.
Actually, we wanted to use WebRTC Data Channel because it can reduce the number of hops that data has to make to reach the client. In our solution today a client pings the server and the server relays the message (2 hops), we can reduce the latency by half if we can send it directly to the other user (which is the goal of WebRTC). Unfortunately WebRTC was not ubiquitous enough to deploy this as a solution at the time.
Websockets means web. You don't need the web to sync multiple devices at the same physical place... For video/music syncing, native apps via local offline technologies like Bluetooth or WiFi sounds more reliable.