Develop Reference

Failed to publish the request over MQTT - Flutter - Parse Server

I have a sample app that uses Parse Server. I've been testing my app on both emulator and physical devices and I noticed that the response time is much slower on the physical device.
This one is from the emulator.
and this is one is from the physical device:
I've been scratching my head regarding this one. I've also posted it on the parse community platform and followed the advice there to manually monitor the server for every change I've made until I reach my prior server configuration. I overhauled the server from scratch. Do some load testing -> Deployed the server on a replica set -> load testing. Now, I'm in the process of doing some basic queries. I used ADB logcat to see what's happening on both device and saw these errors on the physical device and not on the emulator:
E[N rtchannel]_rt_mqtt_publish_callback(356)=>Failed to publish the request over MQTT. token:be925eea-407c-417d-96c9-3af5a7e83e48, category:mcd-sync-data-task-category, requestId:54138, error:Error Domain=mqtt Code=3008
E[S sync]_createResponseError(166)=>Network Response be925eea-407c-417d-96c9-3af5a7e83e48 contains sync error Error Domain=mqtt Code=3008 - Underlying error (null): Error Domain=mqtt Code=3008
This one also shows before pulling the payload.
W[S sync-state-machine]MCDSyncStateMachineScheduleDelayedRetry(173)=>skipping the new retry with longer delay
W[S sync]_scheduleNextCursorRetry(326)=>skipping delayed retry due to state machine state decision
The number of times these errors pop up is related to the number of queries executed. I did not put any configurations on the server which use MQTT. Any help is much appreciated.

Error codes in Nearby Connections 2.0

I've been experimenting with the new Android Nearby Connections v2.0 API. Most of my devices can now talk to each other most of the time, but I also get a lot of error codes back when trying to connect. Checking status.getStatusCode() inside my program, I can see the following return codes:
STATUS_ALREADY_CONNECTED_TO_ENDPOINT (8003)
STATUS_BLUETOOTH_ERROR (8007)
STATUS_ENDPOINT_IO_ERROR (8012)
STATUS_ERROR (13)
I'm having a hard time making sense of these. The first error code seems self-explanatory, except that I see it in cases when I haven't hit the onConnectionResult callback with a "SUCCESS" return code on either side of the alleged connection. My current code is full of trace statements, and I'd see logging entries if those callbacks had been reached. So maybe the devices are connected at some lower level, but if so, the higher-level code doesn't always hear about it.
I'm guessing that STATUS_BLUETOOTH_ERROR indicates a Bluetooth error on the side that logs it, while STATUS_ENDPOINT_IO_ERROR indicates an error (probably involving Bluetooth) on the other end? Is it possible to get any more details?
The STATUS_ERROR (13) status that I see once in a while sounds like the sort of error code a programmer would use for those "WTF, we should never get here" moments, but without access to the source code, I can only guess.
Note that I see these errors between devices that talk to each other beautifully at other times, using the same code. Sometimes if the code retries enough times, it eventually gets a stable connection. Sometimes it connects and gets instantly disconnected from the other end. Sometimes I just get an endless stream of repeated error messages (STATUS_BLUETOOTH_ERROR and/or STATUS_ENDPOINT_IO_ERROR).
I'm using Nearby Connections with the connection strategy P2P_CLUSTER. These problems seem to happen most often when both sides do both advertising and discovery. However, I wrote two smaller programs that specialize in either advertising or discovery, and they sometimes get these errors too (but less often).
In the trace messages, I've also noticed lots of warning messages from Nearby Connections that look like this:
09-04 22:54:40.070 3866-3924/? W/NearbyConnections: Cannot deserialize BluetoothDeviceName: expecting min 16 raw bytes, got 6
I'm guessing that this is because Nearby Connections uses its own short tokens (like ZGbx) instead of the device Bluetooth name? I'm not at all sure about that, though. And anyway, if these are Nearby Connections' own special tokens, then why would it be issuing warning messages about it?

[Disclaimer: I work on Nearby Connections] I can try and help out.
STATUS_ALREADY_CONNECTED_TO_ENDPOINT: This occurs if you call 'requestConnection' while you have any pending (onConnectionInitiated) or established (onConnectionResult) connections to the given endpoint. Move your log statements earlier, to onConnectionInitiated, and you should see why we throw this error.
STATUS_BLUETOOTH_ERROR: Something went wrong with Bluetooth. The phone is probably in a bad state. This (hopefully) shouldn't happen too often. But if you really want a fix, stop advertising & discovery before reattempting requestConnection. Nearby Connections will toggle Bluetooth when it detects this error, but only if nothing else is going on.
STATUS_ENDPOINT_IO_ERROR: We lost connection to the other device. This can happen for a variety of reasons (they could have walked too far away, Bluetooth was flaky, the device stopped responding, etc). If you're discovering while you have connections, avoid that. Discovery can be hard on the phone and reduces bandwidth at best, causes dropped connections at worst.
STATUS_ERROR: Something went wrong that didn't fit well in the other error codes. It's a catch-all. This is most-often returned in onConnectionResult(FAILED), to notify you that something went wrong in between onConnectionInitiated and waiting for both sides to accept the connection.
We've also lowered the log severity of "Cannot deserialize BluetoothDeviceName" in an upcoming release, since it's not really a warning. It's like you said; expected behavior when we see non-Nearby Connections devices while discovering.
If you continue to see problems, let us know what devices you're using and we'll be sure to add them to our test suite.

I just want to add that it may be necessary to have a short client name string when calling the API.
E.g., Nearby.Connections.requestConnection(googleApiClient, shortNameHere,....)
I had been generating my own client name with UUID.randomUUID().toString() and that seemed to cause the STATUS_BLUETOOTH_ERROR.
All I did was change the code sample to use a UUID name and to use P2P_CLUSTER and I got that error.
This was the solution for me regarding the STATUS_BLUETOOTH_ERROR.

WebViewClient returning "Couldn't establish a secure connection." upon recreating the fragment

Our application has tabs and one of the fragments can contain a webviewclient. Users are now reporting an issue where the webviewclient is unable to load the page. We've confirmed that the server is up and running, we've also identified that the issue happens in v4.3 and all earlier versions. We have also confirmed that it works fine in v5.0; right now we've not been able to test whether it works in 4.4 or not (I guess that information only helps if someone knows of a change that occurred in 4.4 and newer that would cause something to fail in all earlier versions).
So the actual problem is we create the webviewclient and load it into the fragment, the web page (Connected to via HTTPS) loads perfectly everytime in this scenario for all versions. For v5.0 we can then click a different tab and come back to the tab with the webviewclient; we can see the fragment being created and everything works as expected, the web page loads as expected. But for v4.3 and earlier we see the fragment being created, but the webviewclient fires onReceivedError with an -11 error code (couldn't establish a secure connection). Looking further in the debug log we get a handshake error, here is the log for the call. Interestingly the website we are connecting to can accept TLS1.2; we can see that when we go to the URL using Firefox and use dev tools, etc. so that error is pretty interesting too.
04-24 14:38:52.415: W/chromium(15434): external/chromium/net/http/http_stream_factory_impl_job.cc:865: [0424/143852:WARNING:http_stream_factory_impl_job.cc(865)] Falling back to SSLv3 because host is TLS intolerant:
04-24 14:38:52.446: V/chromium(15434): external/chromium/net/socket/ssl_client_socket_openssl.cc:310: [0424/143852:INFO:ssl_client_socket_openssl.cc(310)] ssl_ctx_ is used
04-24 14:38:52.469: E/chromium(15434): external/chromium/net/socket/ssl_client_socket_openssl.cc:899: [0424/143852:ERROR:ssl_client_socket_openssl.cc(899)] handshake failed; returned 0, SSL error code 5, net_error -107
04-24 14:38:52.469: V/chromium(15434): external/chromium/net/socket/ssl_client_socket_openssl.cc:508: [0424/143852:INFO:ssl_client_socket_openssl.cc(508)] ~SSLClientSocketOpenSSL()
04-24 14:38:52.469: I/GATE(15434): <GATE-M>DEV_ACTION_ERROR</GATE-M>
04-24 14:38:52.477: V/webkit(15434): reportError errorCode(-11) desc(Couldn't establish a secure connection.)
04-24 14:38:52.532: I/GATE(15434): <GATE-M>DEV_ACTION_COMPLETED</GATE-M>
Digging around it looks like we might need to override the SSLProtocolFactory; but that seemed to be for self signed certificates, etc. We are connecting to a well know 3rd party and there doesn't appear to be anything wrong with their certificate. As always with these things, it probably feels like something we're missing for earlier versions of Android; or a work around for something that has been fixed in newer versions but not really sure where to look next.

This appears to be a bug in Android v4.3 and earlier, which now Google are not maintaining will not be patched. The website we are connecting to is running TLS but has recently switched off SSLv3. It's a payment provider and PCI compliance is forcing providers to disable both SSLv3 and earlier versions of TLS in the coming year to stay compliant. We've also identified that whilst Chrome on that version of Android is able to communicate with the site properly, the native Android browser can not (So duplicates what we see in WebViewClient). Frustratingly this means there does not appear to be a secure solution to this problem. It might be possible to override the SSLProviderFactory but this looks like it is a sledgehammer to crack a nut, opening up other potential security issues.
UPDATE: In the end this was resolved by the 3rd party we were connecting too. There was nothing we could do in the Android side of things, but I think it was a bios update that sorted something on the server which meant it started communicating in a way that Android could handle (we couldn't get much detail from the 3rd party as to what they did).

Cordova 3.5.0 return 0 sometimes ,for navigator.connection.type

i am trying to develop a cordova(3.5.0) project in android platform and in that i have to check network connection availability before each API call. for that i am using 'navigator.connection.type',and some times it return 0. why this is happening? plz help me for solving this trouble

Without some more details I can only guess.. There are some conditions which may cause this.
navigator.connection.type = 0 -> connection type unknown.
So you may have a connection, you may not it simply hasn't been determined yet, or because of privileges the device isn't saying.
Are you calling this check too early? ie before deviceready
In our app we do not check the connection each time but we handle it this way:
by making the API request anyway, knowing that its possible to fail, we set a timeout and error handling. If it fails by error or timeout we check connection type and then ping the server with a simple "hello" "acknowledge" request. Its a super small request that we figure will work or if it timeouts again the connection must be so poor it might as well be disconnected.
This is because there are really two types of connection you need to check. Many miss this!
And also because its navigator totally lies some times... :/
Just because wifi is on and connected and navigator tells you this, it doesn't mean you will have a connection to the outside world. You need to check the network hardware (which is all navigator will tell you) but you must also check network connectivity, if this is something you are sensitive about.

Can't get SipDemo to register

I am developing an application that will make SIP calls using the SIP APIs. I want to use the SipDemo code as my starting point, but when I run SipDemo on my devices (Nexus or Galaxy Tab) I always get "Registration failed. Please check settings." I am using the same username/password/server information that works successfully in Sipdroid.
I inserted log messages in setRegistrationListener to follow what's happening, and I will see onRegistrationDone fire, but then it seems to register again, because it will then see Registration failed with the error message "registration timed out" followed by registration failed with the error message "cannot initiate a new transaction to execute".
I've been beating my head about this for a few days, and I've got a deadline rapidly approaching. Any help on this issue would be greatly appreciated, or if you could point me to some other examples/tutorials of how to use the SIP APIs.

I fixed it! The demo wants to use UDP by default, but I was able to make it connect by hardcoding the protocol to TCP. I have a netgear modem from charter cable, and I have seen several reports of it blocking access. I assume the two are related, but for now I'm just happy to have it work so I can continue my development.
Thanks for the help!

Check the logcat, it should have more information about what failed. Also if you have control over the server, check the server logs as well.

Seems like you are not alone http://code.google.com/p/sipdroid/issues/detail?id=60.
I would suggest that you try what people tried there: i.e.
Try another router.
Change port in code. Read the link for more details.