tl;dr How to find out from a server if Android device is online or not at any given time?
I have an app which needs an Internet connection at all times to make reservations. User can also make reservations independently, from a website.
However, if Internet connection on Android device is gone (edge case) - I would still like that device continues operate offline (and making reservations locally, offline) while website will stop accepting reservations - because Android device is no longer connected to an Internet and there could happen all kinds of sync errors.
In other words, Android device offline reservations have advantage over a website reservations.
So after Internet connection is retrieved on a device, website will continue operate properly.
Suggested solution
I thought about some solution which could include sending a push from a server to device and waiting for a response (HTTP call to some endpoint) in some reasonable time-period. If response doesn't come back - device is offline, otherwise it's online. Any other, more robust, suggestions?
There is nothing to do but use some Agent runs on Android and notifies the server that its on.
Other way, more complicated is to use "Push notification" (Meteor technology server side, for example).
Something about server side cron-job:
Stand alone process that run over all clients in data base, lets say every 1 day, and compares for each client last "im alive" meassage (request) with current time.
If difference equals lets say 1 week, sets client status to "Zombie".
Related
I am working on an Ionic 2 application. My use case is quite simple, I display a page, and I use the angular2's Http service to retrieve a string on a remote API, and I display this string on my page. Every seconds, I did the same "GET" request, and I display this string.
If I start my application with WiFi activated and connected to a network, every things works fine. Then when I disable WiFi, I except my HTTP Packets to be sent through mobile network, but my HTTP request never get out of my phone (I check in my backends logs, and I can't see any trace of them).
Of course, this problem doesn't occurs with my development phone (on Android 5.x), but only on my customer's phone (on Android 4.4)... I guess that the old android version can't switch the network interface of an already opened TCP connection.
Does some one have already experienced this kind of problem ? And is there some solutions I can develop in my app ?
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'm trying to figure out what the solution is to having multiple android devices on one network share data.
Assuming all of them are running the same app, and a user "registers", I'd like to figure out (without any user input) what other devices on the network are available to be talked to and then to send them this registration data, so that when the user goes to the next device, their info is already there.
I'm able to ping the 255 connected devices in the x.x.x.0-255 range to see which respond, but am not clear on how I can write an app resident server (using the term loosely) that I could then send the data to.
I can't be the first person to need to solve this problem, but am unable to find anything useful on this front.
One caveat is that this is for devices that have no 3G (or other means) of getting to the internet, and the wifi network they're on won't have access to the internet either, so the solution has to be 100% internal network and can't include any additional devices (like a box running apache that all the device can use as a server).
TIA
but am not clear on how I can write an app resident server (using the term loosely) that I could then send the data to.
Create a Service that has code that opens a ServerSocket and listens on incoming requests, such as an HTTP server.
On the whole, this is dangerous, but for constrained circumstances -- such as your "100% internal network" -- it should be safe.
I'm having a difficult time figuring out where to start looking for a solution to a problem, I was hoping someone could give me some guidance, here's what I'm trying to do:
1) I want to be able to have multiple devices communicate and update data to each other over wifi and/or wired connection
2) I want to be able to limit logins, user 1 can only log into one device at a time. EG if user one is logged into device 1, if they attempt to log into device 2 the login fails. What is a good way to keep track of this?
3) If user 1 updates a piece of data on device 1, user 2 currently logged into device 2 should be able to see that update, as should user 3 on device 3, ad infinitum.
4) One thing that I also have to figure out is how to allow each device to function if the network goes down independently, then updates each device as the network is restored. Data integrity has to be maintained in some way. The only way I'm familiar with is a Master/Slave architecture where each 'slave' device sends their updates to the 'master' device and that dictates which one is committed based on the time of the transaction.
I've considered implementing something like a Token Ring, where each device on the network that is running my application broadcasts a signal that it's available and sequentially passes a token that either updates data, or says who is logged in at that terminal. My worries about this is it won't scale well with too many terminals. I'm also not sure of how to broadcast an application recognization so that each application on the network can recognize others that need to be updated as anything changes. I have little experience setting up communication between devices and I just need a place to start.
I would suggest a web server to control the broadcasting of data and tracking the devices. This way any code changes wouldn't require a update on the 'master' device. Each device would broadcast any updates to the server (which would then push this update out to all the other devices) as well as continuous server polling to track the user on the device and it's connectivity.
Android has the Gmail push features, which means the new message arrives in the mailbox without checking or refreshing the mailbox.
As I understand, the sync processes are like these:
1) User turns on the sync
2) There will be a alert msg and the sync flag in the Gmail DB of this device will be True
3) When a new email reach the Gmail Server, it will check if the device sync value, if it's True then send the email
OK, here, I don't quite understand how exactly does it work,
For a WiFi and cell signal connection, does the phone has a TCP socket open keep listening to the Gmail Server, or when a new email arrives the Server and it sends a SMS alert to the phone, and the phone will open the data channel to fetch the email? Do the two ways of connections have different approaches?
And second question is which method is the priority one?
Say when you are in the middle of receiving data(emails), and suddenly the phone connect to a wireless network, will the data socket be closed and then reopened for the WiFi one? What's the behavior for the case when carrier's data channel and WiFi flips?
I have also downloaded the source code, anyone knows which part should I be looking into in order to solves my questions? I found a folder called "email" inside the folder "package", should I be looking at its code?
I know I asked quite some questions here, I'd appreciate if you know the answer for any of them, thanks very much!
This technically is not part of Android, but rather Google's proprietary application suite that runs on Android. It also is not really implemented in Gmail -- the google apps collectively have a push data connection with google's servers (built on the gtalk data protocol, but mostly there for historical reasons) which they share. When new mail is available, the push connection is used to send a "tickle" to the device to say that something has changed in mail, and on the device this is then dispatched to the gmail app which opens a new socket connection with its server to synchronize the local state with whatever changes have happened. This same mechanism is used for contacts and calendar sync, as well as things like instigating downloads from market.
The way this works is an implementation detail, but currently it is done by keeping an open socket connection. On a network that can't do voice and data, the connection is dropped when a voice call takes place. When switching between wifi and cell, the connection is dropped and restarted.
Note that doing push notifications this way is quite resource intensive on the device, which is why this has been carefully designed to allow one such instance to support all Google services.