This is in context of doing 10s of networks calls on multiple threads to retrieve small files (about 20K) over http.
In practice, is there any cost for making this call? Does it initiate a network operation or stay on the device? What percentage of the time is it actually wrong? Would it be actually faster to see if one of my http operations gets a sockettimeoutexception or a connectiontimeoutexception?
Based on that webpage, it calls isConnected() on a UI thread, just before explaining that "network operations can involve unpredictable delays" and should be done. Does that mean that isConnected() is a short and predictable delay, or should I not read that much into it?
In one of the battery life classes at I/O, they talked about how the 3G radio takes a bit to warm up, and that you might as well do a bunch of network traffic while it is warm (paraphrasing a bit). Does simply calling isConnected() warm up that radio?
This is checking static data in the ConnectivityService. It doesn't leave
the device, but it will leave your process. These calls don't do any
network activity and could be done on your UI thread.
Note that this check is not a promise that your request will complete - we
can lose contact at any time. Given that, it's probably worth calling once
before you start a complex/expensive sequence, but not really worth calling
throughout.
Calling isConnected does not warm up the radio - only network traffic will
do that.
On Mon, Jul 23, 2012 at 1:07 PM, Nathan <nathan.d.mel...@gmail.com> wrote:
> I wanted to ask a practical question about checking for network
> connection, which is probably a simple question. I am sure this is an easy
> question.
> This is in context of doing 10s of networks calls on multiple threads to
> retrieve small files (about 20K) over http.
> In practice, is there any cost for making this call? Does it initiate a
> network operation or stay on the device? What percentage of the time is it
> actually wrong? Would it be actually faster to see if one of my http
> operations gets a sockettimeoutexception or a connectiontimeoutexception?
> Based on that webpage, it calls isConnected() on a UI thread, just before
> explaining that "network operations can involve unpredictable delays" and
> should be done. Does that mean that isConnected() is a short and
> predictable delay, or should I not read that much into it?
> In one of the battery life classes at I/O, they talked about how the 3G
> radio takes a bit to warm up, and that you might as well do a bunch of
> network traffic while it is warm (paraphrasing a bit). Does simply calling
> isConnected() warm up that radio?
> Nathan
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
On Monday, July 23, 2012 1:41:08 PM UTC-7, Robert Greenwalt wrote:
> This is checking static data in the ConnectivityService. It doesn't leave > the device, but it will leave your process. These calls don't do any > network activity and could be done on your UI thread.
> Note that this check is not a promise that your request will complete - we > can lose contact at any time. Given that, it's probably worth calling once > before you start a complex/expensive sequence, but not really worth calling > throughout.
> Calling isConnected does not warm up the radio - only network traffic will > do that.
> R
> On Mon, Jul 23, 2012 at 1:07 PM, Nathan wrote:
>> I wanted to ask a practical question about checking for network >> connection, which is probably a simple question. I am sure this is an easy >> question.
>> This is in context of doing 10s of networks calls on multiple threads to >> retrieve small files (about 20K) over http.
>> In practice, is there any cost for making this call? Does it initiate a >> network operation or stay on the device? What percentage of the time is it >> actually wrong? Would it be actually faster to see if one of my http >> operations gets a sockettimeoutexception or a connectiontimeoutexception?
>> Based on that webpage, it calls isConnected() on a UI thread, just before >> explaining that "network operations can involve unpredictable delays" and >> should be done. Does that mean that isConnected() is a short and >> predictable delay, or should I not read that much into it?
>> In one of the battery life classes at I/O, they talked about how the 3G >> radio takes a bit to warm up, and that you might as well do a bunch of >> network traffic while it is warm (paraphrasing a bit). Does simply calling >> isConnected() warm up that radio?
It's also a good way to check if the user disabled network connectivity
(i.e. the "mobile data" toggle), and starting with Android 4.0, this is
also affected by the "allow apps to perform background sync" system setting.
> Since this message, I did look at the code for NetworkInfo.isconnected()
> and it is one line, doesn't look like it will block.
> However, I am less certain about ConnectivityManager.getActiveNetworkInfo*
> (**)* since it does call a system service.
> Nathan
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
If you ask for the active network and verify it's connected you should not
need to check other settings (mobile data togle, background-sync, etc).
They are all rolled in.
On Mon, Jul 23, 2012 at 2:44 PM, Kostya Vasilyev <kmans...@gmail.com> wrote:
> It's also a good way to check if the user disabled network connectivity
> (i.e. the "mobile data" toggle), and starting with Android 4.0, this is
> also affected by the "allow apps to perform background sync" system setting.
>> Since this message, I did look at the code for NetworkInfo.isconnected()
>> and it is one line, doesn't look like it will block.
>> However, I am less certain about ConnectivityManager.getActiveNetworkInfo
>> *(**)* since it does call a system service.
>> Nathan
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscribe@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
Yes, that was exactly my point. But the background sync is only rolled in
starting with Android 4.0, right?
24.07.2012 2:36 пользователь "Robert Greenwalt" <rgreenw...@google.com>
написал:
> If you ask for the active network and verify it's connected you should not
> need to check other settings (mobile data togle, background-sync, etc).
> They are all rolled in.
> On Mon, Jul 23, 2012 at 2:44 PM, Kostya Vasilyev <kmans...@gmail.com>wrote:
>> It's also a good way to check if the user disabled network connectivity
>> (i.e. the "mobile data" toggle), and starting with Android 4.0, this is
>> also affected by the "allow apps to perform background sync" system setting.
>>> Since this message, I did look at the code for NetworkInfo.isconnected()
>>> and it is one line, doesn't look like it will block.
>>> However, I am less certain about ConnectivityManager.
>>> getActiveNetworkInfo*(**)* since it does call a system service.
>>> Nathan
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Android Developers" group.
>>> To post to this group, send email to android-developers@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> android-developers+unsubscribe@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/android-developers?hl=en
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscribe@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
On Mon, Jul 23, 2012 at 4:24 PM, Kostya Vasilyev <kmans...@gmail.com> wrote:
> Yes, that was exactly my point. But the background sync is only rolled in
> starting with Android 4.0, right?
> 24.07.2012 2:36 пользователь "Robert Greenwalt" <rgreenw...@google.com>
> написал:
> If you ask for the active network and verify it's connected you should not
>> need to check other settings (mobile data togle, background-sync, etc).
>> They are all rolled in.
>> On Mon, Jul 23, 2012 at 2:44 PM, Kostya Vasilyev <kmans...@gmail.com>wrote:
>>> It's also a good way to check if the user disabled network connectivity
>>> (i.e. the "mobile data" toggle), and starting with Android 4.0, this is
>>> also affected by the "allow apps to perform background sync" system setting.
>>>> Since this message, I did look at the code for
>>>> NetworkInfo.isconnected() and it is one line, doesn't look like it will
>>>> block.
>>>> However, I am less certain about ConnectivityManager.
>>>> getActiveNetworkInfo*(**)* since it does call a system service.
>>>> Nathan
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Android Developers" group.
>>>> To post to this group, send email to
>>>> android-developers@googlegroups.com
>>>> To unsubscribe from this group, send email to
>>>> android-developers+unsubscribe@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/android-developers?hl=en
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Android Developers" group.
>>> To post to this group, send email to android-developers@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> android-developers+unsubscribe@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/android-developers?hl=en
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscribe@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
On Monday, July 23, 2012 2:44:51 PM UTC-7, Kostya Vasilyev wrote:
> It's also a good way to check if the user disabled network connectivity > (i.e. the "mobile data" toggle), and starting with Android 4.0, this is > also affected by the "allow apps to perform background sync" system setting.
> -- K
REALLY?
It was all good news and I was set to use it until now. But now I could be creating a support nightmare on 4.0.
That *would* make sense, if "background sync" were the only possible thing that an app would use the internet for. It *would* make sense if a user sees "no internet connection " in an app, and immediately thinks, "oh, that must be because I disabled background synching". Not likely. More likely, they'll forget they ever used that setting and we will exchange ten emails.
Maybe I misunderstand what "allow apps to perform background sync" is for. But I guarantee users will too.
In versions 4.0 and greater, if you app has background data turned off (by
the user) AND you are in the background and ask for the current active
network and check if it's connected, you will find it's not connected
(it'll be BLOCKED). In fact, if you try to access the network you will
fail.
If either your background data setting is off OR you are in the foreground
you will be told you are connected (provided a connection, of course).
Before 4.0 there wasn't strict data enforcement - the data background stuff
was a suggestion that was not enforced. Also the network status reported
was not app-specific.
I think that doing the calls you suggested should provide the correct
answer both pre-V4 and post-V4. Not doing the calls just means you may
fail after spending alot of time and energy setting up network comms.
If you want to put up a different notice if they are explicitly blocked by
a user policy, you can watch for NetworkInfo.DetailedState.BLOCKED.
Let me know if you still think this is a problem. We want to make APIs
that work for everybody.
On Mon, Jul 23, 2012 at 5:24 PM, Nathan <nathan.d.mel...@gmail.com> wrote:
> On Monday, July 23, 2012 2:44:51 PM UTC-7, Kostya Vasilyev wrote:
>> It's also a good way to check if the user disabled network connectivity
>> (i.e. the "mobile data" toggle), and starting with Android 4.0, this is
>> also affected by the "allow apps to perform background sync" system setting.
>> -- K
> REALLY?
> It was all good news and I was set to use it until now. But now I could be
> creating a support nightmare on 4.0.
> That *would* make sense, if "background sync" were the only possible thing
> that an app would use the internet for.
> It *would* make sense if a user sees "no internet connection " in an app,
> and immediately thinks, "oh, that must be because I disabled background
> synching". Not likely. More likely, they'll forget they ever used that
> setting and we will exchange ten emails.
> Maybe I misunderstand what "allow apps to perform background sync" is for.
> But I guarantee users will too.
> Nathan
> Nathan
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
On Monday, July 23, 2012 5:38:34 PM UTC-7, Robert Greenwalt wrote:
> In versions 4.0 and greater, if you app has background data turned off (by > the user) AND you are in the background and ask for the current active > network and check if it's connected, you will find it's not connected > (it'll be BLOCKED). In fact, if you try to access the network you will > fail.
> If either your background data setting is off OR you are in the foreground > you will be told you are connected (provided a connection, of course).
I'm guessing a service, even with a foreground notification, is going to be considered to be in the background, right?
It's possible that this has already gotten me a few support messages from people saying that a download isn't making progress. But there are so many user errors and server side errors that I'm not sure, even now, if this is one of the first questions I will ask.
On Galaxy Nexus, the phone wouldn't let me access this setting unless I set a data limit (assuming I found the right setting), gave me some warnings, and posted what I think is a persistent notification. This might be enough to make a user aware, but you never know since many users don't know how to find notifications (the secret pulldown).
In an activity, it does seem to make sense to note that data has been blocked. For a batch download service, it seems like it would make sense to check this at the very beginning and simply abort the operation, as this is unlikely to change, unlike connectivity.
