Problem mit JDBC MYSQL Treiber

I

ImAAndroid

Neues Mitglied
0
Hi,
Folgendes Problem: (Benutze MYSQL JDBC Treiber)

Meine App speichert Daten in einer SQL Liste auf einem Server (über Internet). Der Codeausschnitt lautet etwa so (alles FETT geschriebene natürlich geändert):



public class SQLAccess
{

public void register() throws Exception {

Class.forName("com.mysql.jdbc.Driver");
connect = DriverManager.getConnection("jdbc:mysql://MEINEIP:3306/Liste?"+ "user=Blub&password=Bla");

...mehr Code
}




Bei Android 2.2.1 läuft auch alles super. Nun habe ich zum Test ein Smartphone mit Android 4.0.3 und die App stürzt ständig an der Stelle connect=.... ab! Hab bissle im Internet gesucht und ne Stelle gefunden wo es heißt ab Android 4.0 lassen sich Internet-Verbindungen nicht mehr in der Main UI einsetzen, diese müssten in einem "Background" Thread geführt werden. Liegt es wirklich daran? Und wenn ja, wie kann ich das bewerkstelligen?

Grüße!




FehlerLog:


05-30 15:11:57.679: D/dalvikvm(2876): DexOpt: unable to opt direct call 0x205d at 0x14 in Lcom/mysql/jdbc/ConnectionPropertiesImpl$ConnectionProperty;.storeTo
05-30 15:11:57.779: I/dalvikvm(2876): Could not find method java.lang.management.ManagementFactory.getThreadMXBean, referenced from method com.mysql.jdbc.MysqlIO.appendDeadlockStatusInformation

05-30 15:11:57.779: W/dalvikvm(2876): VFY: unable to resolve static method 7645: Ljava/lang/management/ManagementFactory;.getThreadMXBean ()Ljava/lang/management/ThreadMXBean;

05-30 15:11:57.779: D/dalvikvm(2876): VFY: replacing opcode 0x71 at 0x0079

05-30 15:11:57.849: D/AndroidRuntime(2876): Shutting down VM
05-30 15:11:57.849: W/dalvikvm(2876): threadid=1: thread exiting with uncaught exception (group=0x40aa8228)
05-30 15:11:57.849: E/AndroidRuntime(2876): FATAL EXCEPTION: main
 
Wenn du eine TCP/TP Verbindung im Hauptthread aufzubauen versuchst, wird das in der Meldung (im Stacktrace) explizit gesagt. Der Stacktrace müsste auf den LogCat-Schnipsel, den du gepostet hast, folgen.
 
Das witzige ist wenn ich beim Manifest Target SDK Version rauslösche funktioniert alles wunderbar, allerdings sieht das Design dann bei einem Android 4.0.3 System genau so aus wie beim 2.2..

Tu ich bei Target SDK Verison 15 rein, so siehts vom Design her besser aus (Ansichtssache), aber stürzt dann eben an der oben genannten Stelle ab!

Weiß einer einen Reim darauf? Die App wurde mit SDK 2.2 erstellt.
 
Klick mal Hier :glare:

2.250.000 Ergebnisse :thumbsup: gidf.de !

Evtl. überlegst du ja mal das nächste mal bevor du eine Antwort abgibst ;)
 
Zuletzt bearbeitet:
Man sollte übrigens über Android keine direkte Verbindung zu einer Datenbank aufbauen. Der richtige Weg wäre ein WebService, den du ansprichst und dort dann die DB-Zugriffe abgehandelt werden.
 
ApeDick schrieb:
Man sollte übrigens über Android keine direkte Verbindung zu einer Datenbank aufbauen. Der richtige Weg wäre ein WebService, den du ansprichst und dort dann die DB-Zugriffe abgehandelt werden.


Das ist ja auch richtig, leider ist das keine Antwort auf meine Frage. Es gibt viele verschiedene Wege etwas zu programmieren.
 
ImAAndroid schrieb:
Das ist ja auch richtig, leider ist das keine Antwort auf meine Frage. Es gibt viele verschiedene Wege etwas zu programmieren.

Klar gibt es verschiedene Wege. Aber leider auch sehr viele falsche. Wenn du deine App irgendwann mal im Market oder auf anderen Wegen veröffentlichen möchtest, hast du auf jeden Fall schon mal eine Sicherheitslücke. Zumal man mit relativ wenig Aufwand den User und das Passwort für die DB rausbekommt.
 
ApeDick schrieb:
Klar gibt es verschiedene Wege. Aber leider auch sehr viele falsche. Wenn du deine App irgendwann mal im Market oder auf anderen Wegen veröffentlichen möchtest, hast du auf jeden Fall schon mal eine Sicherheitslücke. Zumal man mit relativ wenig Aufwand den User und das Passwort für die DB rausbekommt.


Ich hab nicht gesagt, dass ich die App auf irgend eine Weise veröffentlichen möchte. Das das PW im Android Code drinn steht und es besser über einen einfachen Skript am Server laufen sollte ist mir bewusst, aber danke für deine Aufmerksamkeit. :winki: Ich habe trotzdem immernoch keine plausible Antwort auf mein Problem bekommen
 
Zuletzt bearbeitet von einem Moderator:
Pack den mysql Kram in einen Thread und werd glücklich.

Übrigens - deine Lösung direkt auf die Datenbank zuzugreifen

ist garnicht so dumm.

1.) brauchst Du beim Servercrash nur einen mysql restaurieren :thumbup:

2.) hast Du durch Protokoll-Komprimierung und SSL eine sichere Verbindung

3.) hast Du keine Scripte deren Sicherheit Du im Zweifelsfall nachweisen musst

4.) praktisch keine Kosten um XML oder JSON oder ... zu parsen

Es ist zu empfehlen, den Timeout des Servers sinnvoll zu setzen, bei mir
180 Sekunden - da man mit Verbindungsabbrüchen bei Mobilfunk rechnen
muss.

Meine Erfahrungen aus dem kommerziellen Bereich, allerdings eigenen Implementierung
des Protokolls, sind durchweg positiv und absolut praxistauglich !

Das Passwort kannst Du auch als Hash speichern - weiss nicht ob JDBC hier das auch
akzeptiert !

Finde es Blödsinn zu sagen, ein Webservice ist sicher weil das Passwort auf dem Server liegt.
Spätetens, wenn Du verschiedene Accounts über die App ansprechen willst - kommst Du
nicht umher Login-Daten zu senden.
 
Zuletzt bearbeitet:

Ähnliche Themen

S
Antworten
4
Aufrufe
990
Sempervivum
S
B
Antworten
0
Aufrufe
685
basementmedia
B
B
Antworten
4
Aufrufe
470
bb321
B
Zurück
Oben Unten