In our Android app, we are using saveEventually() and saveInBackground() of parse sdk (version 1.8.0).
It seems to work fine mostly but sometimes all calls to saveEventually and saveInBackground fail with the callback not getting called.
when this happens, we are still able to fetch data from Parse i.e. all read queries work.
We are using local storage. The updates start working again once we clear the app data.
What could be causing this?
It's because Parse.enableLocalDatabse() is on. I had this one before - it's hard to get to this point (it took me couple of days to figure it out). So get rid of this one in Your Application class and it should work.
Oh, and get latest version 1.10.3
Related
I Have implemented the node js rest API. That being use in my android app with the help of Retrofit. Now. If my app is in production and then somehow my main server will be crash. So, in that case I have a backup server that will work same as the main server do.
So, How can I set an alternate base URL in retrofit android? So, If the main URL does not work then call all API from that alternate URL. Is there any build-it functionality?
Or most welcome for suggestions, Any other alternative ways to implement this.
I have another suggestion for you.
A NodeJS server should not stop for no reason. Most of the time, it's because of a 500 Error that have not been catched and stop the server. So, at first, make sure that every js command that may cause error is inside try/catch block.
Then, I suggest using of PM2 package
This is the best option to run on a production server.
It has several advantages:
It's easy to setup and run.
PM2 will automatically restart your application if it crashes.
PM2 will keep a log of your unhandled exceptions - in this case, in a
file at /home/safeuser/.pm2/logs/app-err.log.
With one command, PM2 can ensure that any applications it manages
restart when the server reboots. Basically meaning your node
application will start as a service.
ref: https://pm2.keymetrics.io/docs/usage/quick-start/
I have built an application that calls a webservice in order to retrieve some information. This application is designed to work both on android and windows (using the firemonkey framework).
The object that calls the webservice has been built with a WSDL importer and works great when running the application on windows.
Nonetheless, when i try to use my application on an android device, i can only call the webservice two times. On the third time, the application freeze.
I have tried to do some debug and it appears that the application freezes when trying to call the web service :
genEtq := GetIGenerationEtiquettes(); // Converts a THttpRio as a IGenerationEtiquette object
soapattachmnt := genEtq.GetImageEtiquette(idEtiquette); // Calls web service -> freeze on third time
//
// Do something ...
//
The webservice is hosted on my computer so i'm sure there is no troubles on the service side. In addition, when i restart the application, i can still call the web service two times.
My application has the authorization to access to the internet on my android device so i'm running out of ideas on what's the problem.
Also i have tried to monitor the network (via wireshark) and i had been able to see the two first requests but not the third one.
Do you have any ideas on how to find the problem ?
Finally i have found the answer, my mistake was to call everytime the GetIGenerationEtiquettes() function instead of storing the resulting object.
Now i can call my webservice as often as i want.
Hope this answer will help someone.
It seems to work fine but after sometime all calls to saveEventually and saveInBackground are not saving data to parse (there is no callback and there is no error message as well). It seems it is silently discarded. When this happens, we are still able to fetch data from Parse i.e. all read queries work. We are using local storage. The updates start working again once we clear the app data. What could be causing this? How can we debug the requests that are silently discarded?
You are using a synchronous function saveInBackground. If you want to have callbacks, you need to call the asynchronous version saveInBackgroundWithBlock instead.
Please read the Parse documentation carefully before posting a question here.
Over the last couple days I have been programming an android app (With Android Studio), collecting JSON data to use through an externally provided API. However, I have found that, occasionally, my program refused to collect this information due to refusing to connect to the API service. This because I have found that (likely due to authentication) accessing the API can sometimes take time of up to 5 seconds to retrieve all data. While the app does seem to keep running trying to fetch the data, my logs state that connection is broken down after trying to connect for a few seconds.
As I have no control over the external provider and my app requires their service, I am forced to find a way to increase the timeout before the connection shuts down. I fail to find what may be used to do this or what could be used to circumvent this problem.
Any help would be appreciated.
As posted above, you declare the timeout you want to use as a parameter during the request. As I was using HttpGet, the method I had to use to include this parameter is described further here: Setting a timeout value when retrieving data via HttpGet object
My Android app uses the AWS Java SDK for uploading user photos to S3.
Whenever a user's phone's clock is 'skewed', this causes all transfers to fail. This is a well documented aspect of S3:
http://aws.amazon.com/articles/1109?_encoding=UTF8&jiveRedirect=1#04
It appears that the upstream S3 service reports this error quite clearly:
HTTP Status Code: 403 Forbidden
Error Code: RequestTimeToo-Skewed
Description: The difference between the request time and the server's
time is too large.
However when using the Java SDK, it seems as if the informative 403 code is lost ... and I have only an opaque "TransferState.Failed" to go by (which incidentally is the same error if internet connectivity is lost, if it times out, etc...).
As far as I can tell from the docs:
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/TransferProgress.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Transfer.TransferState.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Upload.html
There is no way to get the additional "RequestTimeToo-Skewed" metadata about a transfer failure.
Am I missing it? Is there any way to get additional error information when an S3 transfer fails using Amazon's Java SDK?
UPDATE #1:
A commenter kindly highlighted that I should clarity two points:
I am actually using the AWS SDK for Android (which seems very similar to the Java SDK, but is nonetheless distinct)
I am using the TransferManager class to perform my upload. Apparently, this is a high-level class that wraps the lower-level AmazonS3Client ... and this lower-level class should expose the error reporting I need, but I am still investigating the exact tradeoffs involved between TransferManager and AmazonS3Client. As far as I can tell, there is no way to get progress information via the (synchronous) AmazonS3Client.putObjectRequest which would be a blocker for me...
UPDATE #2:
My sincere thanks to Jason (of the AWS SDK team) for stopping by and helping me out here. The important information is, indeed, available as properties on an AmazonS3Exception if you use certain methods. The docs had originally confused me and I thought that a manual Thread.sleep() loop was required to poll status (and thus I could not leverage waitForCompletion or waitForException), but if you use ProgressListener on PutObjectRequest you can get full progress callbacks and the error-fidelity of AmazonS3Exception.
these two methods should help you out:
Transfer.waitForCompletion()
Transfer.waitForException()
If you detect that your transfer has failed based on a transfer progress event, you can simply call Transfer.waitForException() to be returned the exception that occurred. That exception will be an AmazonServiceException in this case, with all of the info that you need to see that the real problem was a clock skew issue.
Alternatively, the Transfer.waitForCompletion() method will unwrap the original exception from an ExecutionException and directly throw the original exception, just as if it'd all been happening on one thread. This might be a more convenient approach if you want to use a catch blocks to catch different types of errors cleanly and elegantly.
I disagree that the "catch Exception" block is "brutally broad". The point of that code is to catch any error that happens, mark the transfer as failed and rethrow the error so that the application code can know about it. If it were less broad, then that's exactly the case where exceptions could sneak through and transfer progress wouldn't be updated correctly and would be out of sync with reality.
Give those two methods and shot and let us know if that helps!
Well, I have debugged Amazon's SDK and I'm sorry to say that this information is being swallowed internally. Perhaps I will try to submit a patch.
Details: an AmazonS3Exception is being thrown internally which does in fact accurately report this exact error scenario, but a brutally broad try catch ( Exception e ) consumes it and washes away the specificity.
Here is the guilty try-catch:
https://github.com/aws/aws-sdk-java/blob/master/src/main/java/com/amazonaws/services/s3/transfer/internal/UploadMonitor.java#L145
Here is a screenshot showing that an AmazonS3Exception is correctly thrown with the right info...