LocationManager.NETWORK_PROVIDER is not triggering onLocationChanged in ICS - networking

Does anybody know what happened with event-listener for location changed for WI-FI provider. I saw a lot of questions about this but no proper answer.
I'm doing everything fine and it is working for older versions of android, but now I updated my SAMSUNG GALAXY TAB 10.1 to ICS and it is not working anymore. Maybe this is a SAMSUNG (or my mobile provider) bug when they implemented their UI into ICS...
I'm registering eventlistener like this (have in mind that it works good in prevous versions of android and I also enabled all location services in settings):
locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, loclistener);
//refresh time and distance are to 0 so it should trigger location change event
After this request I checked if network provider is enabled and it shows like it is.
Code:
if (locationManager.isProviderEnabled(LocationManager.NETWORK_PROVIDER)) {
Toast.makeText(this, "NETWORK PROVIDER enabled!", Toast.LENGTH_LONG).show();
}
If someone has an idea please help me...

This is known issue:
After device reboot the network location provider works fine but after some time it stops updating.
https://code.google.com/p/android/issues/detail?id=57707
Unfortunately without solution yet.

To track how often the network provider is updating, I modified the onLocationChanged() method to the following:
public void onLocationChanged(Location location) {
dummyText.setText(location.toString() + "\n" + "Elapsed Time (ms): " + (lastTime - location.getTime()));
lastTime = location.getTime();
}
And added:
long lastTime = 0;
...as a global variable.
This will print out the time between updates in milliseconds (after the first fix - first fix will just print the negative time value from the first Location).
I ran the above code on my Samsung Galaxy S3, and the network provider updates around every 20 seconds, so the code seems fine.
I also ran this on a Samsung Dart (from T-mobile, but not activated) on WiFi, and the network provider updates around every 45 seconds.
I also ran this on a Samsung Nexus S 4G (from Sprint, but not activated) on WiFi, and the network provider at first didn't update at all. Restarting the device seemed to fix the problem, and now its updating roughly every 20 seconds.
Based on your comments and my experience, it looks like this issue varies between OEMs and even between device models of the same OEM. It might be another quirk of the lack of the strict enforcement of LocationListener behavior prior to Android Jelly Bean 4.1. Strict enforcement of LocationListener behavior only recently started in Android Jelly Bean 4.1, which is mentioned in the Android developer docs here in under the first requestLocationUpdates method signature:
http://developer.android.com/reference/android/location/LocationManager.html
Prior to Jellybean, the minTime parameter was only a hint, and some location provider implementations ignored it. From Jellybean and onwards it is mandatory for Android compatible devices to observe both the minTime and minDistance parameters.
Also, from my experience, the refresh interval of the NETWORK_PROVIDER location updates on devices that do update is pretty fixed at around 20-30 seconds across many different devices. So, the minTime parameter you pass into the locationManager.requestLocationUpdates() method is likely to be ignored.
Having to reboot the device to get a network provider location is likely due to not getting a response from the Google server that provides this location info. Not sure why rebooting fixes it.

I had the same problem with the NETWORK_PROVIDER. The reason is that when you request for updates, the NETWORK_PROVIDER does not create a callback for the method onLocationChanged(). You also need to call getLastKnownLocation(NETWORK_PROVIDER) in order for it to start updating the location.
The weird thing is that for the GPS_PROVIDER this is not neccessary.
I hope this helps.

Ok. So now I got it working. It is really strange. I restarted all my devices and now it updates. I don't know what happened and I would really like to know what is the reason for this strange behavior. Thank you #barbeau for all your time and help.

Related

Missing videoTrack in a multitrack stream in Ant media server 2.4.1

We have a Multitrack web conference implementation using AMS 2.4.1 version. Its working great for our use case, except in one scenario. When there are N (< 3) number of users and they on there camera simultaneously, then few remote users are not rendered as we don't receive the video tracks for those users in newStreamAvailable. We only receive the audio track for those users. We are able to reproduce this quite frequently.
As a backup, I am trying to poll AMS using getTrackList with the main track Id to get all available streams, but I am not getting any message trackList
var jsCmd =
{
command : "getTrackList",
streamId : streamId, // this is roomId or main track id
token : token
}
Any insight would be helpful.
Thanks,
We were able to resolve the issue, posting here to help anyone who might be facing a similar issue.
With push notifications from the server, we might encounter issues when for some reason push operation doesn't succeed. In that case, it's better to have a backup plan to pull from the server and sync.
The Ant Media Server suggests pulling the server periodically for the room info. The server will respond with active streams and the application should synchronize.
For reference, please refer to following link https://resources.antmedia.io/docs/webrtc-websocket-messaging-reference

Multiple Realm clients showing new information but MongoDB showing old

Extremely weird bug we’ve been facing today.
We have an iOS app which has updated a document using Realm SDK and I know it has been pushed successfully because I checked the forCurrentlyOutstandingWork session to confirm a 100% upload and also opened up another device to validate if it got the new updated information and it has.
The problem is even though Realm clients across multiple devices are showing the new updated information, the MongoDB doesn’t show the new updated information. It did update after 15 mins automatically but this issue happened to us multiple times today.
Has anybody else faced this issue and found a solution to it ? Or should this never happen and we need to report a bug ?
TIA
Edit:
Realm sync write log -
Logs:
[
"Upload message contained 1 changeset(s)",
"Integrating upload required conflict resolution to be performed on 0 of the changesets",
"Latest server version is now 249"
]
Partition:
1
Write Summary:
{
"Image": {
"updated": [
"612ce539db1dbb2655f6c723"
]
}
}
This was an issue in MongoDB/Realm. I reached out to the support and they resolved it by pushing an update on the 9th of September 2021.
The replication to MongoDB is asynchronous due to the fact that conflict resolution must be performed against incoming writes from MongoDB clients (which sync does not control), to prevent the situation where a write made to MongoDB and a write made by a Realm client pass right by each other and leave the two states inconsistent. Ideally, these writes should happen within a few milliseconds but some latency can occasionally occur (especially around server restarts), but we closely monitor this and are always looking to optimize this.
Engineer on the Sync Team

"The Internet connection appears to be offline" when making URLSession requests on Apple Watch using LTE

Bug:
I'm consistently getting error code -1009 "The Internet connection appears to be offline." errors when making URLSession requests in an Apple Watch extension on an Apple Watch Series 3 when connected to the Internet only via LTE.
Steps to Reproduce:
Install the app.
Configure your device so that it's only on LTE.
Verify your connection to LTE using iMessages, e.g.
Launch the app.
Initialize a URLSession using the .default or .ephemeral session configuration.
Make a data task request for any known-good https URL.
Expected Behavior:
The request manages to reach the destination.
Observed Behavior:
The request fails immediately with error code -1009 "The Internet connection appears to be offline."
Code Sample:
let config = URLSessionConfiguration.ephemeral
let sesh = URLSession(configuration: config)
let url = URL(string: "https://google.com")!
sesh.dataTask(with: request) { (_, _, error) in
print(error)
}.resume()
NOPE: SEE UPDATE #3 BELOW: The crucial missing element: you must set the waitsForConnectivity flag on your session configuration to true.
let config = URLSessionConfiguration.ephemeral
config.waitsForConnectivity = true
let sesh = URLSession(configuration: config)
let url = URL(string: "https://google.com")!
sesh.dataTask(with: request) { (_, _, error) in
print(error)
}.resume()
If you do not set that flag, the requests fail immediately because LTE access isn't available instantly but only after the briefest of delays. Setting this flag to true makes the requests work. In my testing there even seems to be no appreciable difference in timing between enabling the waitsForConnectivity over LTE and making the same request without enabling waitsForConnectivity but conducted over WiFi, almost like the waiting period enabled by waitsForConnectivity in some scenarios is a next-turn-of-the-runloop kind of situation.
Update #1
I am unable to make any requests over LTE. When waitsForConnectivity is set to true, the requests just timeout according to the timeout properties of the session config. When waitsForConnectivity is false, the requests fail immediately. I'll update my question and answer when I have more information. I'm waiting on a response from an Apple TSI request which usually takes several days.
Update #2
Adding to the mystery, the same sample code runs fine over cellular on two other developers' hardware. I know that my hardware is good because Apple's apps fun fine over LTE on it (phone calls rolling down the highway with nothing but my watch in the car). So there's something really fishy going on. I've asked Apple DTS to look into this, and they can't reproduce the issue either. I'll be following up with them as soon as I can.
Update #3
Sometime in the intervening weeks after I last updated this post, cellular requests started working in my apps. I didn't change anything about my watch, no software updates, no resets, nothing. I didn't even recompile the code; the same build is still on my watch as previously. It just started working as expected, same as it did on other developers' devices.
The only thing strange I noticed is that I got three, back-to-back, identical SMS messages from AT&T notifying me that my Apple Watch is now linked to my iPhone number. Which is strange, because that linkage supposedly occurred the night I unboxed my phone, not two months later. I have no idea if this is related to my issue. All I know is that cellular requests are now working.
I had the same problem but was developing an App for the iPhone. This is what finally solved the problem. I set the configuration objects property:
config.allowsCellularAccess = true
This is very confusing, because the Apple documentation states that this property is set to true by default... but in my case it was not. Also, even though I am using "background tasks," and they are always meant to wait for connectivity, I also set waitsForConnectivity = true, too, just in case.
Just in case someone runs into this error but has everything set up correctly. I was running my project from xCode onto a real device but couldn't get past the internet connectivity issue.
In the code there was a check for __DEV__ to determine what API url to use.
I was building this for running not testing so i assumed it would make __DEV__ false. but it did not, so I had to change the code for that check and set it to a non-localized api url.
even if you are injecting your url, it might not grab the correct one based on if it thinks it is a DEV build or not.

How long does Firebase throttle you?

Even with debug enabled for RemoteConfig, I still managed to get the following:
Error fetching remote config values Optional(Error Domain=com.google.remoteconfig.ErrorDomain Code=8002 "(null)"
UserInfo={error_throttled_end_time_seconds=1483110267.054194})
Here is my debug code:
let debug = FIRRemoteConfigSettings(developerModeEnabled: true)
FIRRemoteConfig.remoteConfig().configSettings = debug!
Shouldn't the above prevent throttling?
How long will the throttle error remain in effect?
I've experienced the same error due to throttling. I was calling FIRRemoteConfig.remoteConfig().fetchWithExpirationDuration with an expiry that was less than 60 seconds.
To immediately get around this issue during testing, use an alternative device. The throttling occurs against a particular device. e.g. move from your simulator to a device.
The intention is not to have a single client flooding the server with fetch requests every second. Make sensible use of the caching it offers out of the box and fetch only when necessary.
When you receive this error, plug the value of error_throttled_end_time_seconds into an epoch converter (like this one at https://www.epochconverter.com) and it will tell you the time when throttling ends. I've tested this myself, and the throttling remains in effect for 1 hour from the first moment you are throttled. So either wait an hour or try some of the other recommendations given here.
UPDATE: Also, if you continue making config requests and receive the throttle error, the expire timeout does not increase (i.e. "you are not further penalized").
The quick and easy hack to get your app running is to delete the application and reinstall it. Firebase identifies your device as new device on reinstalling.
Hope it helps and save your time.

Game Center / GameKit resubmitting scores when network is available

I'm creating a game like application which supports Game Center. And I have a problem with reporting score to leaderboard when the player is authenticated to GC correctly but the network (wifi and cellular) is not available in the time when I want to report my score.
My app is for iOS 5.0 and greater and according to the documentation, it should resubmit the scores when network becomes available. Let me explain what i tried :
I opened my app and authenticate my GC account, turned the wifi off, reported score then opened wifi and waited 30 minutes. After that I checked leaderboard but there isnt any updated score on my leaderboard. (Maybe I am impatient and that is because of the undefined time / interval which apple decides to resubmit scores ?)
I opened my app and authentacate my GC account, terminated the app, turned the wifi off, opened my app again, it automatically authenticate's my GC account, I reported score then opened wifi and still no updated score on my leaderboards. (Maybe I am impatient and that is because of the undefined time / interval which apple decides to resubmit scores ?)
If this resubmit takes more then 30 minutes, I think it is so useless? Is there a way to overcome this? I mean if I save and send the scores later this would be bad too because GC will resubmit them later too? (It wont be so bad but still it would be unnecessary)
Is there any documentation about this resubmitting time ? I couldn't find any... I mean when will it resubmit? Do i need to keep my app and my wifi open until it resubmits?
Thank you for your answers ...
It doesn't matter whether wifi is on or off if you also have a cellular connection. The GC code will use whichever network access is available. If neither is available when you call 'reportScoreWithCompletionHandler:^(NSError *error)' it will report the score the next time the network becomes available.
You didn't say whether your code has ever worked. A common error is that the leaderboard identifier in your code doesn't exactly match the leaderboard ID in iTunesConnect. If they don't match the score will never be successfully reported but it won't tell you what the problem is.
Also note that the score should be a 64-bit value. Maybe you are reporting a 32-bit value.
Also be sure you aren't submitting the score before the local player is authenticated.
Are you checking the error code? If the 'error' you get back from 'reportScoreWithCompletionHandler:^(NSError *error)' is not NULL then something is wrong with your code. Its value may not be helpful (when it isn't NULL) but at least you know that something didn't work.
In my experience, in sandbox mode, the leaderboards usually update fairly quickly (less than a minute) but not instantly. But some days something is wrong with the server and the update takes hours or doesn't work at all. I've read that the production GC server is more reliable and updates faster than the sandbox server.
For what it may be worth here's the code I've been using to report scores. It seems to work:
-(void) submitScore:(int64_t)score category:(NSString *)leaderboardIdentifier {
if (!!! [GKLocalPlayer localPlayer].authenticated ) {
CCLOG(#"GKLocalPlayer is not authenticated");
return;
}
GKScore *gkScore = [[[GKScore alloc] initWithCategory:leaderboardIdentifier] autorelease];
gkScore.value = score;
[gkScore reportScoreWithCompletionHandler:^(NSError *error) {
[self setLastError:error];
}];
}

Resources