Problem bei Nutzung einer App für Gingerbread auf ICS-System

[likedue]

Hey Leute,

ich habe mir am Wochenende ein Arnova Tablet mit 4.0.3 angeschafft.
Ich wollte hier gerne meine eigenen aufspielen, wie bei meinen anderen Geräten auch.

Die Apps als solchen sind alle auf die 2.3.3 platform ausgelegt.
Sollte doch eigentlich kein Problem sein?

Nun habe ich die erste App kompiliert und versucht zu testen.
Beim ersten Versuch muss ich jedoch schon feststellen, dass den Buttons falsche Funktionen zugewiesen wurden.
Ich habe an dem Source selber nichts geändert.

Ich habe bereits versucht das Projekt neu anzulegen und das Target auf ICS zu stellen.
Zudem habe ich dem alten Paket über die Properties beim Punkt Android auf 4.0 gesetzt und versucht es so zu lösen.

Leider jedoch alles ohne Erfolg.
Ich kann leider keine Logik hierhinter entdecken, die ich übergehen kann.

Ich hoffe, Ihr könnt mir weiterhelfen.

Gruß
Chris

 

[swordi]

ähm was heißt "buttons falsche funktionen zugewiesen" ?

ab (ich glaub) android 4 wurden positive und negativebutton vertauscht.

 

[likedue]

ich habe eine App deren Startactivity drei Buttons beinhaltet.
Und die funktionen hinter den Buttons sind nicht korrekt verknüpft.

Es sind die Button:

Start Info Beenden

die beim onClick:

Start Info Beenden
Info Beenden keine Fkt.

erhalten.

 

[swordi]

Mach mal ein Project -> Clean und exportier die App nochmal

 

[likedue]

Perfekt!

 

[likedue]

Hmm...Leider habe ich noch ein Problem.

Ich versuche in einer app eine Mysql-Datenbank anzusprechen.

Ich lege eine Information ab, hole sie bei Bedarf wieder und bestücke sie mit Inhalten.


Unter 2.3.3 funktioniert die App einwandfrei.
Unter 4.0.3 kann ich auch die erste Information ablegen, sie wieder abrufen aber dann nicht bestücken.

Ich bekomme folgende Exception:

01-15 10:56:35.402: E/AndroidRuntime(3496): FATAL EXCEPTION: main
01-15 10:56:35.402: E/AndroidRuntime(3496): android.os.NetworkOnMainThreadException
01-15 10:56:35.402: E/AndroidRuntime(3496): at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1099)
01-15 10:56:35.402: E/AndroidRuntime(3496): at libcore.io.BlockGuardOs.connect(BlockGuardOs.java:84)
01-15 10:56:35.402: E/AndroidRuntime(3496): at libcore.io.IoBridge.connectErrno(IoBridge.java:127)
01-15 10:56:35.402: E/AndroidRuntime(3496): at libcore.io.IoBridge.connect(IoBridge.java:112)
01-15 10:56:35.402: E/AndroidRuntime(3496): at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:192)
01-15 10:56:35.402: E/AndroidRuntime(3496): at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:459)
01-15 10:56:35.402: E/AndroidRuntime(3496): at java.net.Socket.connect(Socket.java:842)
01-15 10:56:35.402: E/AndroidRuntime(3496): at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:119)
01-15 10:56:35.402: E/AndroidRuntime(3496): at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:144)
01-15 10:56:35.402: E/AndroidRuntime(3496): at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:164)
01-15 10:56:35.402: E/AndroidRuntime(3496): at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:119)
01-15 10:56:35.402: E/AndroidRuntime(3496): at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:360)
01-15 10:56:35.402: E/AndroidRuntime(3496): at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)
01-15 10:56:35.402: E/AndroidRuntime(3496): at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)
01-15 10:56:35.402: E/AndroidRuntime(3496): at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:465)
01-15 10:56:35.402: E/AndroidRuntime(3496): at jaba.appcenter.wiegeapp.JSONParser.makeHttpRequest(JSONParser.java:63)
01-15 10:56:35.402: E/AndroidRuntime(3496): at jaba.appcenter.wiegeapp.NewMeasureActivity$GetProductDetails$1.run(NewMeasureActivity.java:126)
01-15 10:56:35.402: E/AndroidRuntime(3496): at android.os.Handler.handleCallback(Handler.java:605)
01-15 10:56:35.402: E/AndroidRuntime(3496): at android.os.Handler.dispatchMessage(Handler.java:92)
01-15 10:56:35.402: E/AndroidRuntime(3496): at android.os.Looper.loop(Looper.java:137)
01-15 10:56:35.402: E/AndroidRuntime(3496): at android.app.ActivityThread.main(ActivityThread.java:4424)
01-15 10:56:35.402: E/AndroidRuntime(3496): at java.lang.reflect.Method.invokeNative(Native Method)
01-15 10:56:35.402: E/AndroidRuntime(3496): at java.lang.reflect.Method.invoke(Method.java:511)
01-15 10:56:35.402: E/AndroidRuntime(3496): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
01-15 10:56:35.402: E/AndroidRuntime(3496): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
01-15 10:56:35.402: E/AndroidRuntime(3496): at dalvik.system.NativeStart.main(Native Method)

Vielen Dank für eure Hilfe

 

[swordi]

schreib mal
"NetworkOnMainThreadException" bei google rein und du wirst dazu viele einträge finden

auch hier im forum wurde das problem in den letzten wochen ungefähr 100 mal durchgekaut.

 

[likedue]

Asche auf mein Haupt.

Entschuldigt bitte.
Ich bin noch neu in der Materie.
Ich konnte mein Problem simpel mit diesem Zweizeiler in der onCreate fixen:

StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder()
.permitAll().build();
StrictMode.setThreadPolicy(policy);

Vielen Dank an Swordi für den Hinweis.
Manchmal ist es schwierig einen Fehler zu sehen, wenn man nicht weiß was das Problem verursacht.

Es ist echt angenehm hier immer zeitnah Lösungen angeboten zu bekommen.

Gruß
Chris

 

[killphil75]

Das ist zwar die Lösung bzw. funktioniert es so. Besser wäre es aber wenn du deine Netzwerkaktivitäten in einen eigenen Thread auslagerst.
zb. mit Hilfe von AsyncTask - das wäre dann die saubere ICS gewünschte Lösung.

 

[likedue]

Okay.
Was würde es ändern oder wo sind die konkreten Vorteile?

Also für meine kleine App, die ich hier laufen lasse und für die ich damals auch gefühlte 2 Jahrzehnte brauchte um sie ans laufen zu bekommen wird das wohl reichen.
Ich denke, wenn ich mal eine neue vom Stapel lasse, könnte ich darauf eingehen.

Es sei denn....es gibt plausible Gründe, warum ich das so nicht machen sollte.

Ich hab wohl verstanden, dass wenn ich es so löse die App hängen bleibt, wenn die DB nicht ansprechbar ist.
Nur sehe ich hier keinen Nachteil.
Für meinen Nutzen empfinde ich es als sinnvoller dass ich keinerlei Eingaben machen kann, wenn etwas nicht läuft, als stetig Phantomentries zu gestalten, die den Empfänger nicht erreichen.

 

[killphil75]

Okay.
Was würde es ändern oder wo sind die konkreten Vorteile?

Ich hab wohl verstanden, dass wenn ich es so löse die App hängen bleibt, wenn die DB nicht ansprechbar ist.

Ja das ist das Problem, Netzwerkabfragen im Mainthread (ui-Thread) führen zum Einfrieren der App - Android löst dann nach einigen Sekunden einen ANR (Application Not Responding) Error aus und die App kann abschmieren... im schlimmsten Fall auch noch andere Sachen.

Es geht einfach darum, das man in Android bestrebt sein sollte die UI immer responsive zu halten, sprich Eingaben werden wahrgenommen bzw. verarbeitet... deswegen langwierige Prozesse (berechnungen ect. immer in einen eigenen Thread auslagern)

Wenn dein User warten soll bis das abgeschlossen ist, ist das auch kein Problem.

-> Progressdialog anzeigen
-> Netzwerkaktivitäten ausführen
-> Progressdialog schliessen
-> Datensätze verarbeiten
-> fertig

Wie gesagt ganz einfach per AsyncTask zu lösen.