OK. Here is some additional details about this problem...
The problem is that when you make a jQuery ajax call in iOS, it seems to take forever to return with a 404. The timeout doesn't seem to take as long on Android.
The reason the timeout is the issue is because the ajax call has a success and fail callback, so it takes the length of the timeout to call the fail callback. If your code doesn't progress until either of these callbacks are called then it will appear as if your app has stalled.
I fixed the immediate problem but I still have this issue in other places where I have a loading spinner - so it's not so much of an issue there. However, is there a way to change this timeout value? And should I change it if I can?
I have a Phonegap app running on Android and IOS.
For some reason the initialization on IOS is very slow when WIFI is turned off. However, it acts normally if Airplane mode is turned on (in which case WIFI is off).
It always behaves the same at initialization on Android.
During initialization the app...
Get's the MACAddress using the phonegap plugin.
Get's the connection information using the phonegap plugin.
Does an ajax call using jQuery ajax, it does not wait for the data to return - however.
I've tried debugging the problem but it seems like the app is doing absolutely nothing while it hangs (it takes like a minute+ to initialize as opposed to the usual couple of seconds). There are no error messages or any significant syslog messages. It eventually starts and works normally.
I'm stuck on ideas as to what could be causing this, I know the code works correctly - at least on Android - because I followed it through and I also removed any unused plugins. I was hoping some of you might have some suggestions as to what you think may be the cause.
I'm sorry that I can't share the source because my boss would be upset with me if I did.
Related
I'm developing a react-native app, and we noticed something strange. When the app comes back from suspended state (it doesn't happen from normal background state I think), often, the fetch freezes afterwards.
To trigger it, put on battery saver (I think it will make the app go to suspended state a lot quicker), then put the app in the background, do some other stuff on your phone for a minute or 5-10, open the app again and use it.
In our case we navigated to an other screen which tried to fetch three lists of objects at the same time from the backend. In the backend, we noticed only one call coming through, and the Promise.all(...) on the three calls never gets resolved or catched. So there is no error either. Afterwards all calls work again and the problem seems to be gone. So it's a one time issue.
This never happens when not coming from suspended state.
This is extremely hard to debug, since when the app goes to suspended state, the debugger is disconnected.
We haven't tested this yet on Android, it could be that the problem exists there as well.
My gut feeling tells me, it has something to so with the internal networking of IOS or the fetch library of RN. (e.g. when reconnecting to wifi, coming from 4G or something)
Has someone experienced the same problem already or has more insights on why this is happening or how to solve this? (e.g. use a time-out and retry mechanism, which I would like to prevent, force a api call on state change to active - although react-native can't detect the suspended state)
Thanks in advance!
EDIT:
Forgot to add: we're using react-native 54, but are in the process of updating to 57. I'll report back if the issue is still happening on 57...
EDIT 2:
Atm, we solved it by doing to the calls after each other instead of the at the same time (so fetch().then(fetch().then(fetch())) which seems to resolve the issue. So yet again, doing the calls at the same time, never fails normally, only after a suspended state of the app.
I'm using the Wink API to control lights and thermostats etc. In the API you can subscribe to device topics to receive events such as when a light is turned on or off. This is handled through PubNub. I have this all working except that the events stop being sent if I leave the system overnight.
If I try to "manually" toggle a light by tapping the physical switch then normally an event is fired and received by my application via PubNub. Restarting my application and thus reconnecting to PubNub does NOT resolve the issue. The only way I've found to resolve the issue is to open the Wink app itself. Nothing else needs to be done but to open the Wink app. Then if I manually toggle the switch the event will show up and be received by my application. This solution works even if I don't restart my application.
There appears to be some sort of wake or keep-alive going on. Although I don't see anything in the Wink API docs that state such. There is also nothing sent from PubNub during this downtime. I have logging being sent out for the status(), message(), and presence() callbacks and nothing is logged from these overnight. Therefore taking all the above into account I believe the issue resides on the Wink side of things.
Unfortunately, Wink does not provide developer support. The Wink app is obviously doing something but because the transactions are encrypted it is unknown what it is doing. Also my test cycle is 8 hours long currently so it is difficult to debug this by trial and error. I'm working to see if this "timeout" is shorter than the overnight 8 hours I've experienced so far. i've also tried power cycling my Wink Hub yesterday but that did not resolve the issue.
Anyone else run into this issue? How do you keep subscriptions alive so that they are always sent?
I'm building an addon for firefox mobile (fennec).
Is it possible to detect if the browser is running in background or the screen is locked so that I can suspend some task that is running within my extension?
You can also listen for the "application-foreground" and "application-background" notifications. Firefox does this itself here:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#5445
I don't think that you can - Fennec itself doesn't seem to care whether the screen is on or off, at least I couldn't find any code checking that. Normally I would recommend js-ctypes to call the necessary OS functionality directly but it is of very limited use on Android. So I guess that the best thing you can do is using nsIIdleService to detect when the user has been inactive for a while.
I have an application that handles applicationWillResignActive and applicationDidBecomeActive notifications by doing stuff like pausing/unpausing BG music, etc.
I am experiencing a weird bug, in which in every 3-4 times becoming inactive and returning (e.g. locking/unlocking the device), the app seems to be completely stuck for a few minutes - meaning, I see the view I'm supposed to see, but I can't touch anything, and music isn't playing.
I debugged it, and it seems that the applicationDidBecomeActive notification is not getting called what so ever.
I looked at the log of my app and literally didn't see anything there for the entire time the app seemed stuck.
The only interesting thing is that in the device's console I could see this line appearing about 10 seconds after I unlock the device and noticing the stuck application.
Mar 20 11:51:13 unknown MobileStorageMounter[4882] <Notice>: (0x3f4d948c) idle_timer_callback: Exiting after idle timeout
Not sure if it's related.
Anyone had a similar problem?
It could be that a call to TestFlight is timing out, and prior to the timeout the app locks the main thread, which freezes the interface, until the request is processed or times out. This could happen if the request failed to complete before the system pushed the app into an inactive state, meaning that when it returns to an active state it would still be trying to listen for a response to the request that it will never receive, hence the timeout. The same can occur with Flurry Analytics (at least older versions of the SDK that I have used), and they happen to me as well when calling my own homemade API's and API responses are delayed by a second or two.
Turns out it was a bug in the TestFlight SDK, upgraded from 0.8.2 to 0.8.3 and problem was solved
I just found a very annoying thing about using websockets on iOS Safari (iOS 5.0.1). When sending two messages at very close interval (think 30 - 40ms, for example, sending a message at mousedown on a button and one on mouseup) the two messages arrive at 200 to 300ms of interval on the server.
This makes using WebSockets on iOS really painful for making a remote controller for example...
I'm affraid I know the answer, but is there anyway to make it work better ? It seems like it's a bug in the Websockets implementation of Safari but could it also be coming from the WiFi implementation (I hardly think so...) ?
I just found out some kind of workaround, and that the websockets implementation of Safari Mobile behaves even weirder than what I already found out.
While making some ping tests to validate my theory, I realised that I didn't have the problem anymore. Then I tested again with my original code and I had the same problem again.
Then I realised what changed in my code, compared to the ping test : the server never sends anything to the client. So, whenever my server receives a message from the iPhone, he sends a message back to it. That way, the latency disappears. It's really weird and there's probably something to be done to fix that issue, but in the meantime, this will do...