Вопрос

I have a requirement in my application wherein my app should always be connected to the internet(2G/3G only).To achieve this one can create a service which keeps checking if the device is connected to the internet or not.If not, then we can programmatically connect to the internet(This being because my app will work in an environment with very less user interaction,so most things should happen automatically). The 'service' approach is fine but consumes considerable battery due to the constant polling,which I want to avoid.

I recently read about a broadcast called -CONNECTIVITY_ACTION, which the system generates.As per the doc Changes to a device's connectivity can be very frequent—this broadcast is triggered every time you move between mobile data and Wi-Fi. .

In my requirement the device will ONLY be connected to 2G/3G and never to the wifi.So is there a broadcast from the system using which I can get to know the changes in connectivity(ON/OFF) to the 2G/3G alone? Because as per the above quote what I infer is that CONNECTIVITY_ACTION would be fired only when the state changes from mobile data(2g/3g) to wifi. Is it so?(Please correct me if I am wrong).

Also,please enlighten me with the most efficient approach that I should use to check that my device is connected to the internet(2g/3g) constantly(other than a service based approach),so that I can then take action to connect to the internet automatically? Thanks in advance !

Это было полезно?

Решение

The mentioned broadcast is sent when disconnected completely. It's even mentioned in the docs

For a disconnect event, the boolean extra EXTRA_NO_CONNECTIVITY is set to true if there are no connected networks at all.

Just listen to CONNECTIVITY_ACTION and do whatever is needed to reconnect your device.

Complete doc: https://developer.android.com/reference/android/net/ConnectivityManager.html#CONNECTIVITY_ACTION

Другие советы

The 'service' approach is fine but consumes considerable battery due to the constant polling,which I want to avoid.

Nope, the service approach does not. Infact you need to have your listeners in a service to do all this in the backend.

Connectivity listeners for wifi and data are the only way to do it. If you dont use wifi, testing will be a nightmare (imagine testing on a 2g network). Data listener you need to test when on highway's and bad network scenarios. Listeners behave badly, sending multiple events sometimes, and sometimes no event at all. So test this really well with wifi before you test with data. Since with data you need to get out of the office and test on real roads and undergrounds, in lift and in special modes like AIRPLANE mode. Think about this feature carefully is it worth the effort ? There are too many scenarios (real world) that can fail. The impact is huge, if it misbehaves battery, functionality and your connection server can get too many connect requests sending it into a DOS attack :).

Think about automatic connection carefully.

When I had this case, I changed the UX / UI a bit to connect when needed, adding 2 seconds to the performance of the app instead.

Edit : Testing nightmare

Yeah, coding is one part of the problem, testing can be a nightmare. Imagine getting 10 bugs a week only on this connectivity problem. Imagine a DOS attack on the server, and u wont know until you reproduce it. Servers DONT log socket connections (with time stamps). Imagine a whole 3 day effort on fixing a DOS attack caused by your own app from one customer, who was in the lift. :) I faced this shit recently. Samsung has made it impossible to do somethings in Android due to their poor customization of the framework.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top