if (STRING.equals("") wird einfach nicht behandelt. Keine Fehler oder Errors

Hallo,

ich habe ein Problem mit einer if abfrage. Allerdings kann ich weder einen Fehler finden noch wird irgendetwas geloggt. Vielleicht ist es auch einfach schon zu früh.

Es geht im folgenden Code Ausschnitt:

String test = s.toString();

        if (test.equals("0"))
        {
            Log.d("Logincode:", "0");
            Constants.saveappdata("AUTOLOGIN", "0");
            Constants.Toast("Login fehlgeschlagen.");
        }

        if (test.equals("1"))
        {
            Log.d("Logincode:", "1");
            Constants.saveappdata("AUTOLOGIN", "0");
        }
        Log.i("Logincode:", s);

Hier noch das log dazu

02-17 03:56:34.708 5570-5570/XXXXXXXXXX I/Logincode:: 1

Dann habe ich das ganze mit == null bzw. != null getestet.

String test = s.toString();

        if (test == null)
        {
            Log.d("Logincode:", "0");
            Constants.saveappdata("AUTOLOGIN", "0");
            Constants.Toast("Login fehlgeschlagen.");
        }

        if (test != null)
        {
            Log.d("Logincode:", "1");
            Constants.saveappdata("AUTOLOGIN", "0");
        }
        Log.i("Logincode:", s);

Und das log dazu:

02-17 04:00:50.926 6962-6962/XXXXXXXXXX  D/Logincode:: 1
02-17 04:00:50.932 6962-6962/XXXXXXXXXX  I/Logincode:: 0

02-17 04:01:03.604 6962-6962/XXXXXXXXXX D/Logincode:: 1
02-17 04:01:03.612 6962-6962/XXXXXXXXXX  I/Logincode:: 1

Vielleicht weiss ja jemand von euch weiter.

Guten Morgen schonwieder g so schnell ist die Nacht vorbei. So es funktioniert und ein

test.trim().equals("0");

brachte dann den Erfolg. Ein "blödes" trim(). Da haben wir es ja "mal wieder. Wegen einem blöden "leerzeichen". Naja trim werde ich mir dann merken.

— geändert am 17.02.2018, 09:54:15

Das wird alles Serverseitig abgearbeitet und dann gibt's per HTTP als String 1 oder 0 zurück. Es muss es string sein da der string auch so zurück kommen kann

0&DATENRESPONSE&FOO&BAR&...

Für den ersten test habe ich erst nur 1 und 0 geschickt. Aber das muss noch erweitert werden mit

String [] tempvar = test.trim().split("&");

Und dann wird nicht nur der Code verarbeitet sondern eben noch mehr daher muss ich auf String zurückgreifen.

Ja, also, ähm, da hast du schon recht, "normalerweise" nutzt man hier strings wie status=0&foo=0&bar=0&..=..&..=..&..=..

Allerdings,

1. Baue ich das Protokoll Dokumentiert auf dem Server so dass auch andere DEVs es nachvollziehen können

2. Habe ich hier direkt alles mit theoretisch einer Zeile

   String[] data = s.trim().toString().split("&");

Wenn ich nun das Protokoll kenne (Dokumentation) habe ich in data[x]; immer die Daten die ich direkt brauche. Klar könnte ich auch immer die Zuweisung der Daten die als nächsten folgen mit &foo= mitsenden, müsste hier aber das Array nochmal mittels split() und Schleife durchlaufen damit ich wieder ein sortiertes Array nur mit den Daten habe die ich wirklich benötige.

— geändert am 17.02.2018, 10:55:18

Klar, da gebe ich euch natürlich vollkommen recht, jedoch, ich denke das ihr das nachvollziehen könnt, arbeiten wir in einem Team von 3 eingefleischten "alten Hasen". Wir haben bisher immer als Team sehr überzeugen können. Allerdings müssen wir auch viel Bitbanging betreiben und mikrocontroller Software mit php, c, python verbinden. Damit wir es einheitlich haben nutzen wir als "standart" eben das mikrocontroller standart Protokoll allerdings noch mit & dazwischen. Normalerweise sieht das Protokoll dann so aus das erst die Datenmenge und dann Datenmenge mal 8 bits kommt. Und dies haben wir halt komplett übernommen

[DATENMENGE] [DATEN_FÜR] [DATEN]

Nein. Serverseitig läuft auch hier unser eigener HTTP Server in python der nichts anderes kann ausser die Daten zu verarbeiten. Und der kennt eben nur unser Protokoll.

Ludy

Kurze Frage: Ist das nur für euch, oder soll das produktiv werden?

Also was heißt produktiv? Es soll Produktiv, allerdings für uns laufen, also nur Firmenintern, keine Vermarktung/Verbreitung etc.

Pascal P.

....
Allerdings scheint es mir dass dir unsere Ratschläge völlig egal sind.
....

Oh nein, keineswegs. Der Hinweis zu dem Callback war gut und eigentlich genau das was ich suchte. Ich wusste nur nicht genau wie es heißt. Ich lese mich derzeit darüber ein.