In the following code, the first console.log message prints pretty much instantly. Then everything just hangs (I'm initially assumed it was waiting for the body of the response to be returned). The Body of the response is only about 26K, the time waiting seems to be indefinite UNLESS, I shake the phone and interact with the debug menu. As soon as I interact with the debug menu, the promise resolves and everything moves along as expected. My interactions with the debug menu can be simple, like hide inspector, show inspector, just takes something to kick the promise resolution into gear and everything is fine.
fetch(SEARCH_URL, requestBody)
.then((response) => {console.log(response); return response.json();})
.then((responseData) => {
debugger
...
Note:
Disconnecting from the debugger and running the code does not exhibit the slowness (and not being connected to the debugger ignores the debugger statements)
And yes, I have rebooted the computer.
Might have found something in https://github.com/facebook/react-native/issues/6679
As you've found out yourself, this is a known bug that should be fixed in react-native v0.31
It is a known bug that parsing responses can lag badly when remote debugging is enabled. Disabling remote debugging should speed this up a lot.
You can read the issue for details and other workarounds.
What worked for me is moving the fetch calls inside the constructor of a react component. Otherwise they never resolve. Hope this helps
Related
I've a strange problem in app I'm currently coding.
Here is the story of the app :
I've used React Native's ScrollView as a horizontal slider,
I display maximum 5~6 slides so I don't need to use FlatList for this.
Slides are actually records coming from the database so actually they are some dynamic components
and slider works as expected.
In every slide, there are also are some option buttons (Touchables) to send data to the server.
When the user presses a button app is opening a modal window to confirm and then sending some data to server.
Until now all is okay.
The Problem :
But in some slides of the slider I'm having a strange problem :
"console.log" commands and also network commands to send data to server is not working.
On the screen, I see Buttons(Touchables) are working and also the modal I've coded is also appearing & disappearing according to the state variables. But somehow console.log commands and also network commands are not even executed. Since I can't log anything it's also hard to understand the problem.
Is there anyone had a similar problem ?
Thanks
I've finally solved this problem, wanted to share my experience here.
In the app I was making post requests to the backend with Axios,
but I wasn't interested in the result of this post requests,
they were just log records so the result of backend calls weren't important.
So I didn't use any "await" command or didn't code anything like Promise.then / catch,
just posted with Axios and scrolled to another slide in my app without waiting for the backend.
After the 8th Axios post, app started not to work.
It seems like working .. touchable effects , modals even navigation works
but nothing else was working. Event console.log commands weren't working.
It's an interesting behavior of React Native , but I've understood the situation after reading the blog below :
https://medium.com/#rotemmiz/react-native-internals-a-wider-picture-part-1-messagequeue-js-thread-7894a7cba868#
Basic reason was that in the backend (NodeJS) I didn't return any response,
there wasn't any command like res.send("success") .. so frontend React Native app was waiting for the response.. event if I didn't use any await or Promise it was still trying to get the response and after the 7-8 call it was blocking the main thread.
If there is a way to configure Axios not to wait for the backend to answer for the post request, please write here.
I'm having a really weird behaviour with my TWA. When I am launching the app, the address bar is not shown and the app is running in standalone mode as expected.
But when I am switching between Apps (putting the app in the background), and coming back to it, something weird happens: the page reloads, and the address bar is shown at the top of my app. I am not really sure to understand what's happening here. Even more strange, it looks like this weird behaviour is not happening all the time.
Does anybody here encountered similar issues ?
I checked my assetlinks file, it's accessible and valid, app bundle and so on, everything looks fine. The fact that the app is not showing the bar at launch also seems to confirm that the problem is not coming from the certificate or a configuration issue. What else could cause the problem ?
First launch (looking perfect):
Back from background:
We have seen this occasionally as well.
Which version of Chrome Custom Tabs are you using? Seems like most articles/tutorials use e446d08 which is quite outdated. Suggest trying a newer/latest version of it:
https://github.com/GoogleChrome/custom-tabs-client/commits/master
Their last commit comment suggests that they are still testing things:
There's definitely more we can test, but this is a start.
https://chromium.googlesource.com/custom-tabs-client/+/da65829d7d4b80c00809c6c4aa7f61f88fc7ca26
We have an API which randomly takes high content download time in chrome, It works fine always in firefox and takes an only few ms. The response size is 20kb uncompressed and 4kb compressed. The same request also works fine using curl.
Things that we have tried:
Disabling If-None-Match header to disable cache response from the browser.
Trying various compressions (gzip, deflate, br).
Disabling compression.
Disabling all chrome extensions.
The same request works fine sometimes on chrome but randomly returns very high content download time.
We are unable to understand the root cause of this issue. What are the other things we can try to minimize this time?
I made three requests here and the 3rd one took the most time (before the last spike). CPU does not seem to be maxing out for a longer period of time. Most of the time is idle time.
Also, When replaying the call using Replay XHR menu, the Content download period drops from 2s to 200 ms.
Are you by chance trying to implement infinite scrolling? If you are, try dragging the scroll bar instead of using the mouse wheel. For some reason, Chrome seems to struggle with mouse scroll events. If the scroll bar worked just fine, keep reading.
This post provides a detailed walkthrough of someone experiencing something similar - https://github.com/TryGhost/Ghost/issues/7934
I had attached a watcher on the scroll event which would trigger an AJAX request. I had throttled the request and could see that only 1 was being sent. I watched my dev server return the response within a few ms but there would be a 2 second delay in chrome. No render, no api calls, no and scripts executing. But the "Content Download" would take 3 seconds for 14kb. No other browser had this issue.
I stumbled upon suggestions that using requestAnimationFrame instead of setTimeout would solve the problem. That approach seems that approach works when the "Waiting" or green is significant, not so much for the "Content Download" or blue.
After hours of digging, I tried conditionally calling e.preventDefault() on the mousewheel event and to my amazement, it worked.
A few things to note:
1) I did not use the mousewheel event to make the api call. I used the scroll event along with throttling.
2) The mousewheel event is non-standard and should not be used. See https://developer.mozilla.org/en-US/docs/Web/Events/mousewheel
3) BUT in this case, you have to watch and handle the mousewheel event because of chrome. Other browsers ignore the event if they don't support it and I have yet to see it cause an issue in another browser.
4) You don't want to call preventDefault() every time because that disables scrolling with a mouse :) You only want to call it when deltaY is 1 if you are using vertical scroll. You can see from the attached image that deltaY is 1 when you basically can't scroll anymore. the mousewheel event is fired even though the page cannot scroll. As a side note, deltaX is -0 when you are scrolling vertically and deltaY is -0 when scrolling horizontally.
My solution:
window.addEventListener("mousewheel", (e) => {
if (e.deltaY === 1) {
e.preventDefault();
}
})
That has been the only solution that I've seen work and I haven't seen it mentioned or discussed elsewhere. I hope that helps.
console log of mousewheel event
I think you may be doing it wrong.™
Fundamentally, if this really only happens with Chrome, then perhaps the client-side code is to blame, of which you don't reveal any details.
Otherwise, you are trying to debug what you present as a backend condition (based on the choice on the nginx tag) with front-end tools:
Have you tried using tcpdump(8) to troubleshoot the issue? What packets gets exchanged and at what times?
Have you tried logging the times of the request being received and processed by nginx? E.g., $request_time?
Where is the server located? Perhaps you're experiencing packet loss, which may require timeouts and retransmission of some TCP packets, which invariably will introduce a random delay?
Finally, the last possibility is that the field doesn't mean what you think it does -- it sounds like it may take a hit from CPU load, as this is the result of the XMLHTTPRequest (XHR) processing -- perhaps you run some advertising with user tracking that randomly consumes a significant amount of CPU, slowing down your metrics?
I am new to Titanium Android App development and going through an unpleasant scenario of "Network goes off" during use of my app.
I tried reproducing it on my emulator, but going "Airplane mode" while app still working.
I tried below in app.js:
Ti.App.addEventListener('uncaughtException',function(){
alert("caught"); });
Ti.App.addEventListener('TiException',function(){
alert("caught:Ti"); });
So good thing is I am able to see "caught" but not before my app sees a red screen detailing and it breaks. see image:
App crash error
it would be very helpful if someone can help me out in identifying how to catch all those 'unplanned' exceptions and direct them as per some business logic so that user doesnot see those blasts.
Thanks in advance
The exception that you are seeing is related to LiveView. See the docs here: http://docs.appcelerator.com/platform/latest/#!/guide/LiveView which is totally unrelated to the code on the app.
If you are going to test offline mode in your app you need to run it without LiveView because it requires connectivity to work.
For reference:
The event that catches all the exceptions is uncaughtException
TiException is not a valid event so it will never be triggered.
When I build my app to my actual iPhone the debug area shows this:
[Allocator] Middle guard protection failed %d
[Allocator] Allocator invalid, falling back to malloc
It shows the 2nd line a total of 30 times. I have no idea what it means or how to fix it. It does not show this when I build to the simulator.
I am having issues with getting state preservation to work using storyboards and restoration ID's and I have a feeling this has something to do with a memory issue so it's dumping my memory and therefore I get no app restoration. Basically, when I go back to my app it shows me the last screen I was on for a second and then goes back to the root page.
Anyway, I'd like to fix this malloc stuff so I can at least rule it out the culprit, plus I don't want to have an issue with memory in general...
I've been googling this for a couple of weeks now too and can't find anything!
Looks like it's an issue with the Crashlytics framework. I have the same issue, and commenting this API call:
[Crashlytics startWithAPIKey:API_KEY];
removes that warning.
It does indeed seem to be an issue at Crashlytics. I know from other threads that they raised the "Allocator invalid..." issue in relation to another Middle error (not Middle guard protection failed %d), which later got marked as fixed.
I fixed this by deleting all the crashlytics stuff and using the new fabric/crashlytics framework. Problem solved.
(Interestingly, I had it only on an iPad, my iPhone 5C made no complaints at all.)