Backendless general query

Hi guys, while I was testing my app It crashed cause I missed one check I thought I shouldn t do.

Server was offline, about 30 min ago (backendless console said so). Even if it was offline doSomething() was ran, and response was null (impossible cause I have a lot of stuff).

Should this work like this or is a bug? Will be changed? Now that I know I’ll test response anyway

     Backendless.Data.of("Place").getObjectCount(new AsyncCallback<Integer>() {
                    public void handleResponse(Integer response) {
                    public void handleFault(BackendlessFault fault) {

Hi, Fabio.
I’ve tried to reproduce the erroneous behaviour you’ve described in a two ways. With a broken network and with a broken server. An with both of them i receive an error (as expected).
It is possible that the server may work even if the console is down. Thus, your code could get an answer. But you shouldn’t receive null.
Could you, please, simulate network problem on your local machine and try to invoke the code to reproduce the problem again.
And clarify please, did you receive the ‘null’ only once, or you was able to repeat the behaviour.

Hi Oleg I’m “sure” about receiving null, It happened also the last time you guys updated backendless, but I didn’t care that much cause app was in the beginning. Nothing is sure of course, but I can exclude internet down cause I check it before starting a new download. I’ve debugged with android studio, null value come out. I don’t think is only with getObjectCount, had problem also with directory list of my file( don’t remember the right command now). If you can simulate the same thing that happened 2 days ago and interrupt the service(only with my project ofc) I’ll document with screenshots. I’ll take some more test now

ok I’ve made some tests. I was able to reproduce the response = null using a wrong application id, and also with a wrong api key. Wrong server url gave me error as it should be. I can’t tell for sure if it’s the same error that happened 2 days ago. You can try so I know I don’t have to solve mine bugs in my app ( they never end)


A few questions:

  1. What is your appId?
  2. Do you mind if I try executing code you’ve provided (getObjectCount API) on your environment to fasten the investigation process?
  3. Oleg asked you regarding the frequency of misbehavior. Are you constantly receiving null in response or it just happened a few times during server maintenance?
  4. What do you mean by wrong appId and secretKey? Taken from another app or just SMTH instead of an actual value?


Hi Anton,

  1. app id is : A9122928-8D86-B6AE-FF94-00AA23BEC700

  2. no problem, for sure you can, how? if need something else just ask.

  3. I started this query cause I had null as response, it was 2 or 3 days ago, don’t know if yours server were down or for maintenance, but when I tryied to login via browser in my console I got error message ( can’t remember the text). In that time, when I was calling getObjectCount I always got null as response (I’ve made a lot of tests, always got null). After a couple hours all was fine, and I haven’t edited my code ofc.

  1. appId is 12345 for example, I’ve used 1235 just to mess up. Oleg asked me to simulate problem in my pc, and the only things that gave me null as response was using wron appid or wrong secretkey. No internet was handled correctly in handleFault(). I’v never had problem in normal situation

My app crashed also 1 or 2 months ago, can’t remember if there was Backendless upgrade or something like this. Probably same issue, always triggered when calling getObjectCount and starting download from Backendless data ( so is one of these 2), but I had not debuged at the time.

I’ve called getObjectCount in a 30 min interval at least, it wasn’t just 5 min bad luck.
I’ve no problem about sending you my app for doing some tests, maybe I’m my code generate some fail in yours( impossible but who know)

Unfortunately I can’t reproduce the issue while everything is OK on server side. Please, if you’ll be facing similar behavior further - respond in the support topic right away so we could test and replicate the behavior in faulty conditions


Sure I will, thanks guys