I have a node/express/socket.io app. When i run the app on android 4 and previous, it works just fine. However, with android 5.0+ and greater, every time my app loads and does its initial route (/), it sends the route function twice. The second time it executes, there is nothing in the request body, which is causing the app to error out.
app.post('/', someFunction);
Ive logged this function req.url and notice it is hitting someFunction twice for android 5.0+, but anything previous only hits it once and executes normally.
Does anyone have thoughts on to why this would be caused on new versions of android? and not others? Also to mention, this works just fine with iOS.
The problem was not related to sockets.io. It had to do with how the newer android OS web view handles some JS. In my EJS templates associated with that route, I have a
window.location.reload();
This works great with iOS and older android OS's, but the new versions didn't like it. I was able to switch to:
window.location.href = window.location.href;
And this seems to work just dandy.
Related
My ionic angularjs corodova app works great when receiving calls from the demo web page on chrome. When I try to initiate a call to the demo site or another device, whether using demo API key or real api key, i get
call_crossing_detected
What does this mean, and how do you fix it?
More details on symptoms. When this occurs, no video comes up and the initiating device shows the error and the call button remains. But the receiving device switches to the hangup button, which then works. And if you speak into either device the receiving device receives the audio, but nothing on the initiating device
"call_crossing_detected" reason appears on hangup event when a call is already established between the two users and you are trying to establish a new one.
So I think you may have an issue on the first call hangup.
I have resolved this issue. It was caused by apiRTC.init executing more than once.
My app works perfectly:
On browser, both locally and deployed
On emulator, using either the local or deployed server
On my device when using run android-device, using either the local or deployed server
But somehow, when I build it following these instructions, at the first server call, for example:
console.log("test1");
Meteor.call("someMethod", function (error, result) {
console.log("test2");
});
// yes I know how asynchronous calls work
console.log("test3");
Or:
console.log("test1");
Meteor.loginWithPassword("validUsername", "validPassword", function (error, result) {
// should print no matter if the credentials are good or bad anyway
console.log("test2");
});
console.log("test3");
"test2" does not get printed in the adb logcat, even though "test1" and "test3" do. There is a mapbox map that loads fine, so it's not an internet access issue. Also, startup works:
Meteor.startup(function () {
console.log("this gets printed in the adb console");
});
So it's not ALL Meteor methods. I used both my deployed and local server: there were no errors reported on the server log. I also tested hot-code push on my local server, it does reload the app on my phone! But only the first time I launch the app only after it's freshly installed. Still, there is at least some kind of connection between them.
I should also mention that I already built this app and it worked fine before, but I did not build it in a while and now it doesn't work anymore. I installed the package on two different devices and get the exact same issue.
Here is my package list if it can help, all on the latest version available:
meteor-platform
iron:router
sacha:spin
accounts-password
accounts-base
mdg:geolocation
mrt:flash-messages
mdg:camera
useraccounts:ratchet
fastclick
alanning:roles
tap:i18n
simple:imgur
Here are the client's logs when I launch it on my local server:
I/CordovaLog(18991): Changing log level to DEBUG(3)
I/CordovaLog(18991): Found start page location: index.html
D/CordovaLog(18991): file:///android_asset/www/meteor_cordova_loader.js: Line 12 : METEOR CORDOVA DEBUG (meteor_cordova_loader.js) Error reading version file Error: Failed to resolve entry: file:///data/data/com.idz9099616fhad1150nrz/files/meteor/version
D/CordovaLog(18991): file:///android_asset/www/meteor_cordova_loader.js: Line 12 : METEOR CORDOVA DEBUG (meteor_cordova_loader.js) Couldn't load from the manifest, falling back to the bundled assets.
D/CordovaLog(18991): file:///android_asset/www/meteor_cordova_loader.js: Line 12 : METEOR CORDOVA DEBUG (meteor_cordova_loader.js) Loading from url: http://meteor.local
D/CordovaLog(18991): http://meteor.local/d7372e9a56ce9d5ddfb0fea0d5e071cfd699fac8.js: Line 111 : show showSignInLink signIn
These are all before I hit "Sign In" on my app. That last statement is just a log print from the useraccounts:ratchet package that occurs everywhere. As soon as I hit "Sign in": blank page, and zero output on the logs. (that's due to the fact that I can never actually stop logging in, as we saw earlier) The above log remains as it is forever.
When using the app installed with run android-device, it's the same exact output, except that after I click, the next page shows up and everything works fine. (logging works, as everything else) As with the non-functionning app, no more log lines show up. (except when I start using the app as usual)
What really bugs me is that it works perfectly fine on my phone when I install the app using run android-device. Even when I stop the debug and use this build as a standalone app, it works flawlessly! But I cannot decently ask users to install my app using meteor run, can I?
From the information you've provided it looks like you have a race condition issue in your code. I'm not assured this is what it is, but the characteristic of the problem you're describing makes it quite likely.
On your local server it doesn't pop up because the connection is fairly instantaneous, but on a remote server it's more of an issue since the data may not yet be ready due to the higher latency.
Basically you have something like this in your code, or a variation in some way:
var doc = MyCollection.findOne();
return doc.name
The thing is MyCollection.findOne() is null (since the data has not yet loaded). This calls up a cannot read 'name' of undefined error (client side not server side) and this halts the execution of further code, which is why your screen is white and the subscriptions aren't run.
How to find where this is exactly. Try and get access to adb to view the client side logs on the device or view and login with xxx.meteor.com/your deployed server on your web browser and keep an eye on the JS console to find where it pops up. The key thing to reproduce the issue is a slower connection to the server than that available on your localhost
The fix is simply accounting for a lack of data, i.e return doc && doc.name instead of return doc.name or if(doc != null) return doc.name;
I have been using Google CloudPrint since December, and suddenly (sometimes, mostly when the networks is slow) when printing, it keeps printing.
I am using this configuration: Android Phone, my App creates a print job with ticket via Google CloudPrint, the android notification center displays the print job "Printing" (as in sending...), the Google CloudPrint receives the task, and prints it with the printer associated, then, normally, it removes the print job from the notification center. and thats all.
Now, it stays in the notification center... for ever, even if you cancel, it already sent a lot of print jobs (they are slow to appear on the GoogleCloud panel).
Is there a bug with Google CloudPrint or is a problem with my (probably outdated now) code?
I know is Beta, and that, but i neither find documentation, known bugs, or anything at all.
If you can guide me in solving this problem...
(This is the code i use to send the intent)
PrintHelper photoPrinter = new PrintHelper(Context);
photoPrinter.setScaleMode(PrintHelper.SCALE_MODE_FIT);
photoPrinter.printBitmap("print job", bitmap);
I had the same issue on a Samsung Galaxy Tab 4. I uninstalled Cloud Print and then reinstalled. Fixed the issue.
I am finding that about 1/5 of my tests are freezing, and after some searching for the problem I have narrowed it down to the line:
ParseInstallation.getCurrentInstallation().saveInBackground();
I am using Parse 1.5.1, and an Android 4.4.2 device. My application class looks like:
public class InitApplication extends Application {
#Override
public void onCreate() {
super.onCreate();
Parse.initialize(this, "my_App_ID", "my_Client_Key");
PushService.setDefaultPushCallback(this, MainActivity.class);
System.out.println("execution DOES reach here");
ParseInstallation.getCurrentInstallation().saveInBackground();
System.out.println("execution DOES NOT reach here");
}
}
The behaviour on my device is that I will first see a blank white screen for about 5 seconds, and then the screen goes black. I am not sure how long the screen stays black, as I usually force close. I've let it sit for about 10 minutes once with no change. I am unable to press the back button and any touch on the screen does nothing. I am forced to use my home button, then force the application to close. Upon reopening the application, it behaves and functions normally.
Further research led me to find this post: https://www.parse.com/questions/android-saveinbackground-lock-the-main-thread
But still, I have been unable to find a solution. One suggestion in the above post is to simply move the location of this code. I have tried this to some point after my main activity's onCreate() method (not to be confused with the application's onCreate() method). Behaviour appeared to be normal up until I got to the point where the getCurrentInstallation.saveInBackground() code is called, where my application froze and failed to respond until I forced it closed.
Are there any solutions to this problem?
I encountered the same problem as well using Parse SDK 1.5.1.
And I just downloaded the latest SDK 1.6.0 and problem solved.
Link to download the latest SDK.
You can track reported issue here:
Parse installation save causing app freeze
I already provided (confidentially) thread dump traces from my app. However at time of writing this post there is no useful feedback from Parse guys.
My humble opinion after looking into traces is a deadlock causing this issue after some trouble with server interaction. But it's just guessing.
Link updated
I do have the same issue and more.
The blank or black screen however happen not to all my test phones. It happens only to one of them (Android 2.3).
SaveEventually also does not work to the problematic phone above (all the other phones I have are working fine). It does not send data through successfully to the server. So I suspect that phone configuration of saving data on the phone itself before passing to the server when network is back on may be the issue.
I am using WL.BusyIndicator with an adaptor call in Worklight 6.0:
this.busyIndicator.show();
WL.Client.invokeProcedure(invocationData, {
onSuccess : function(response) {
this.busyIndicator.hide();
// do good stuff
}.bind(this),
onFailure : function(err) {
this.busyIndicator.hide();
WL.SimpleDialog.show("Adapter Error", JSON.stringify(err), [{text: "OK"}]);
}.bind(this)
});
This usually works, but on Android, when the adapter call fails (the worklight server is stopped) I will sometimes see the "Adapter Error" dialog, and when I dismiss it, the busyindicator is still there. At this point my app is dead, as there is nothing that I can do with the busyindicator running. (back button does not clear it)
There is nothing in the logcat other than the error message about the adapter call failing.
I've see this in the emulator on Android 4.1.2 and 4.2.2, and on a 4.1.2 phone. I wasn't able to reproduce it in the Android 2.2 emulator, but that runs so much more slowly, it may just be a timing window I can't hit there. I haven't seen the problem on iOS or in Chrome.
Has anyone else seen this?
We have encounter similar problems in 5.0x version. We ended up creating a Busy Indicator manager and implemented a time out that would eventually close the indicator. We then directed all calls through this manager.
I have something missing here...
Why are you using the BusyIndicator in the form of this.busyIndicator.show()?
Did you initialize your own busyIndicator? Try creating one of your own and then use it in the form of, for example: mybusy.show() and mybusy.hide().
I have seen this issue with 6.0 and 6.1. I did initialize in wlCommonInit. Since we were using jquery I decide to switch to the jquery loader and seems to work as I expected the busyIndicator would work. Only issue is you do lose the native loading but this was something I had to get passed.
$.mobile.loading( "show", {text: "foo",textVisible: true,theme: "z",html: ""});
$.mobile.loading( "hide");