Import externer Bibliothek (UpscaleDB)

Micka

Micka

Fortgeschrittenes Mitglied
1
Hallo,

ich möchte gerne innerhalb einer Android-App die UpscaledDB testen. Laut Entwickler soll diese unter Android nutzbar sein. Mein Verständnisproblem beschreibe ich im weiteren ausführlich, nur der Einfachheit halber hier einmal in der Kurzfassung. Der Entwickler schreibt folgendes:
Damit die jar-Datei korrekt geladen werden kann muss upscaledb-java.dll und upscaledb-2.2.0.dll im Pfad liegen.
Wie soll ich das verstehen? Müssen die DLL Dateien auch importiert werden? Wenn ja wie?

Ausführliche Beschreibung:
Ich habe mit dem Entwickler der UpscaleDB einige Emails geschrieben um zu erfahren ob und wie die Datenbank in einer Android-Anwendung eingebunden werden kann.

Zunächst schrieb er:
Es gibt eine Java-API die das JNI-Interface benutzt. Damit lässt sich upscaledb aus Java heraus nutzen.

Man muss also zuerst den Native Code für Android mit dem NDK compilieren (wie z.B. hier beschrieben:

Building existing autotools C/C++ projects on Android | DanielPocock.com)

und dann sollte man die JNI-Bibliothek nutzen können.


Einige Dependencies müssen nicht zwingend portiert werden: openssl, libuv, zlib und snappy sind optional. Falls man auf Verschlüsselung und (teilweise) Kompression verzichtet werden sie nicht benötigt.

Daraufhin habe ich mir ein Tutorial gesucht (Create Hello-JNI with Android Studio) und mich erstmal eingelesen wie die Geschichte mit dem JNI Interface funktioniert. Das ganze habe ich auch an einem neuen Projekt im Android Studio nachvollzogen. Soweit so gut, wie ich etwas C Code in meiner Android-App ausführe habe ich nun verstanden.

In einer weiteren Email des Entwicklers der UpscaleDB hies es:
als erstes musst Du upscaledb compilieren; entweder als statische Bibliothek (upscaledb.a) oder dynamische (upscaledb.so).

Danach musst Du das JNI-Projekt compilieren, wie es auch im Tutorial beschrieben ist. Das sollte eine dynamische Bibliothek erzeugen (upscaledb-java.so), die im Pfad installiert werden muss.

Hier ist das JNI-Projekt:

upscaledb/java/src at master · cruppstahl/upscaledb · GitHub (die Datei heißt upscaledb.cc).

Das JNI-Projekt muss entweder statisch gegen upscaledb linken, oder die dynamische upscaledb-Bibliothek muss im Pfad sein.
Danach kannst du die upscaledb-Java-Bibliothek benutzen:

upscaledb/java/java at master · cruppstahl/upscaledb · GitHub

Diese Java-Klassen laden die upscaledb-java.so-Datei und greifen darauf zu. Dann kann mit der Java-API upscaledb benutzt werden. Hier ist ein sample:

upscaledb/DatabaseTest.java at master · cruppstahl/upscaledb · GitHub

Ich habe mich bisher nicht wirklich mit C beschäftigt, das ganze zu kompilieren habe ich nicht verstanden. Eine Nachfrage zu weiteren Hinweisen diesbezüglich wurde ebenfalls beantwortet.
Unter Windows ist der kostenlose Compiler von Microsoft ganz gut (Visual Studio Express). Allerdings findest Du die für Windows compilierten Dateien auch auf der Webseite unter upscaledb.com/download. Da ist auch eine upscaledb-java.dll enthalten, sowie die jar-Datei mit den Java-Bibliotheken. Damit die jar-Datei korrekt geladen werden kann muss upscaledb-java.dll und upscaledb-2.2.0.dll im Pfad liegen.

Also habe ich die Windows Dateien ebenfalls runtergeladen.
(upscaledb - embedded database technology -> Win32 compiled libraries ->http://files.upscaledb.com/dl/upscaledb-win32-2.2.0.zip)

Wie ich festgestellt habe enthält der Download jedoch keine fertige Jar-Bibliothek. Okay, das ist halb so wild. Lädt man sich von der Webseite das aktuelle Projekt (upscaledb - embedded database technology -> Sources -> http://files.upscaledb.com/dl/upscaledb-2.2.0.tar.gz) enthält dies ein Java Unterverzeichnis, Laut Entwickler der Datenbank kann dies über die win32.bat kompiliert werden um eine Jar-Datei zu erhalten. Dies klappt auch.

Nun habe ich also die benötigte jar Datei. die folgende Aussage verwirrt mich aber noch:
Damit die jar-Datei korrekt geladen werden kann muss upscaledb-java.dll und upscaledb-2.2.0.dll im Pfad liegen.

Ich weiß wie ich die Jar Datei in Android Studio in mein Projekt importiere. (Einfache file Dependency), aber wie importiere ich auch die DLL Dateien? Muss ich die überhaupt importieren oder reicht es die beiden DLL Dateien einfach in den "libs" Ordner zu kopieren wo sich auch die Jar Datei befindet?
 
Ich habe auch dem Entwickler noch einmal eine E-mail geschrieben um zu fragen ob die DLL zwingend notwendig ist. Seine Antwort lautet:
Hi,

um eine native DLL unter Java einsetzen zu können benötigst Du eine Zwischenschicht, die mit JNI (Java Native Interface) programmiert wird. Diese Zwischenschicht ist ebenfalls eine DLL (upscaledb-java.dll). Diese DLL wird dann von der JAR-Bibliothek mit Hilfe von JNI geladen, und "übersetzt" die Anfragen der Java-Bibliothek in Aufrufe an die ursprüngliche native DLL (upscaledb-2.2.0.dll). Du brauchst also die JAR-Datei und beide DLLs.


Unter Android ist das analog, außer dass die DLLs dort die Endung .so haben ("Shared Object" - ist die gängige Bezeichnung unter Linux). Wie man sie im Android Studio erstellt weiß ich nicht, aber dort musst Du den ganzen Prozess analog aufsetzen:

1. upscaledb compilieren (erzeugt eine .so-Datei) - native code!
2. upscaledb-java compilieren (erzeugt die upscaledb-java.so - auch native code!)
3. JAR-Datei compilieren

Wie ich das nun im Android Studio umsetze ist mir leider immernoch nicht klar.
 
Hallo Micka,

ich persönlich habe mich noch nicht mit dem Einbinden von DLL's unter AS beschäftigt ( wusste auch gar nicht das das geht :) )
Wozu ich aber meinen Senf geben kann, ist , dass ich beruflich aus der VS / DLL/ C Ecke komme.

Innerhalb einer DLL gibt es i.dR nur exportierte Funktionen , die virtuell aufgerufen werden , indem man vorher die Einsprungadresse der Funktion ermittelt.
Damit AS diese findet, gehe ich mal davon aus , das er diese auch im LIBS pfad plaziert haben möchte .
Er schreibt ja oben

Damit die jar-Datei korrekt geladen werden kann muss upscaledb-java.dll und upscaledb-2.2.0.dll im Pfad liegen.

Was sagt denn das Ganze , wenn du lediglich nach dem erstellen der JAR die DLL wirklich nur dahin kopierst.?
Von Assets schreibt er ja nichts

lg
Stefan
 
Ich werde das morgen mal testen.
 
Ich habe nun die Jar einfach mal normal über eine FileDependency dem Projekt hinzugefügt und die beiden DLL Dateien ebenfalls im "libs" Ordner abgelegt.
Die Hello World App lässt sich nicht starten


Code:
Information:Gradle tasks [:app:assembleDebug]
Observed package id 'add-ons;addon-google_apis-google-19' in inconsistent location 'F:\Android\sdk\add-ons\addon-google_apis-google-19-1' (Expected 'F:\Android\sdk\add-ons\addon-google_apis-google-19')
Observed package id 'system-images;android-23;google_apis;x86_64' in inconsistent location 'F:\Android\sdk\temp\SystemImagePackage.old01' (Expected 'F:\Android\sdk\system-images\android-23\google_apis\x86_64')
Already observed package id 'system-images;android-23;google_apis;x86_64' in 'F:\Android\sdk\system-images\android-23\google_apis\x86_64'. Skipping duplicate at 'F:\Android\sdk\temp\SystemImagePackage.old01'
:app:compileUpscaleDBTestArm64-v8aDebugSharedLibraryUpscaleDBTestArm64-v8aDebugSharedLibraryMainC UP-TO-DATE
:app:linkUpscaleDBTestArm64-v8aDebugSharedLibrary UP-TO-DATE
:app:UpscaleDBTestArm64-v8aDebugSharedLibrary UP-TO-DATE
:app:stripSymbolsArm64-v8aDebugSharedLibrary UP-TO-DATE
:app:ndkBuildArm64-v8aDebugSharedLibrary UP-TO-DATE
:app:ndkBuildArm64-v8aDebugStaticLibrary UP-TO-DATE
:app:compileUpscaleDBTestArmeabi-v7aDebugSharedLibraryUpscaleDBTestArmeabi-v7aDebugSharedLibraryMainC UP-TO-DATE
:app:linkUpscaleDBTestArmeabi-v7aDebugSharedLibrary UP-TO-DATE
:app:UpscaleDBTestArmeabi-v7aDebugSharedLibrary UP-TO-DATE
:app:stripSymbolsArmeabi-v7aDebugSharedLibrary UP-TO-DATE
:app:ndkBuildArmeabi-v7aDebugSharedLibrary UP-TO-DATE
:app:ndkBuildArmeabi-v7aDebugStaticLibrary UP-TO-DATE
:app:compileUpscaleDBTestArmeabiDebugSharedLibraryUpscaleDBTestArmeabiDebugSharedLibraryMainC UP-TO-DATE
:app:linkUpscaleDBTestArmeabiDebugSharedLibrary UP-TO-DATE
:app:UpscaleDBTestArmeabiDebugSharedLibrary UP-TO-DATE
:app:stripSymbolsArmeabiDebugSharedLibrary UP-TO-DATE
:app:ndkBuildArmeabiDebugSharedLibrary UP-TO-DATE
:app:ndkBuildArmeabiDebugStaticLibrary UP-TO-DATE
:app:compileUpscaleDBTestMips64DebugSharedLibraryUpscaleDBTestMips64DebugSharedLibraryMainC UP-TO-DATE
:app:linkUpscaleDBTestMips64DebugSharedLibrary UP-TO-DATE
:app:UpscaleDBTestMips64DebugSharedLibrary UP-TO-DATE
:app:stripSymbolsMips64DebugSharedLibrary UP-TO-DATE
:app:ndkBuildMips64DebugSharedLibrary UP-TO-DATE
:app:ndkBuildMips64DebugStaticLibrary UP-TO-DATE
:app:compileUpscaleDBTestMipsDebugSharedLibraryUpscaleDBTestMipsDebugSharedLibraryMainC UP-TO-DATE
:app:linkUpscaleDBTestMipsDebugSharedLibrary UP-TO-DATE
:app:UpscaleDBTestMipsDebugSharedLibrary UP-TO-DATE
:app:stripSymbolsMipsDebugSharedLibrary UP-TO-DATE
:app:ndkBuildMipsDebugSharedLibrary UP-TO-DATE
:app:ndkBuildMipsDebugStaticLibrary UP-TO-DATE
:app:compileUpscaleDBTestX86DebugSharedLibraryUpscaleDBTestX86DebugSharedLibraryMainC UP-TO-DATE
:app:linkUpscaleDBTestX86DebugSharedLibrary UP-TO-DATE
:app:UpscaleDBTestX86DebugSharedLibrary UP-TO-DATE
:app:stripSymbolsX86DebugSharedLibrary UP-TO-DATE
:app:ndkBuildX86DebugSharedLibrary UP-TO-DATE
:app:ndkBuildX86DebugStaticLibrary UP-TO-DATE
:app:compileUpscaleDBTestX86_64DebugSharedLibraryUpscaleDBTestX86_64DebugSharedLibraryMainC UP-TO-DATE
:app:linkUpscaleDBTestX86_64DebugSharedLibrary UP-TO-DATE
:app:UpscaleDBTestX86_64DebugSharedLibrary UP-TO-DATE
:app:stripSymbolsX86_64DebugSharedLibrary UP-TO-DATE
:app:ndkBuildX86_64DebugSharedLibrary UP-TO-DATE
:app:ndkBuildX86_64DebugStaticLibrary UP-TO-DATE
:app:androidDebug UP-TO-DATE
:app:preBuild UP-TO-DATE
:app:preDebugBuild UP-TO-DATE
:app:checkDebugManifest
:app:preReleaseBuild UP-TO-DATE
:app:prepareComAndroidSupportAnimatedVectorDrawable2420Library UP-TO-DATE
:app:prepareComAndroidSupportAppcompatV72420Library UP-TO-DATE
:app:prepareComAndroidSupportDesign2420Library UP-TO-DATE
:app:prepareComAndroidSupportRecyclerviewV72420Library UP-TO-DATE
:app:prepareComAndroidSupportSupportCompat2420Library UP-TO-DATE
:app:prepareComAndroidSupportSupportCoreUi2420Library UP-TO-DATE
:app:prepareComAndroidSupportSupportCoreUtils2420Library UP-TO-DATE
:app:prepareComAndroidSupportSupportFragment2420Library UP-TO-DATE
:app:prepareComAndroidSupportSupportMediaCompat2420Library UP-TO-DATE
:app:prepareComAndroidSupportSupportV42420Library UP-TO-DATE
:app:prepareComAndroidSupportSupportVectorDrawable2420Library UP-TO-DATE
:app:prepareDebugDependencies
:app:compileDebugAidl UP-TO-DATE
:app:compileDebugRenderscript UP-TO-DATE
:app:generateDebugBuildConfig UP-TO-DATE
:app:mergeDebugShaders UP-TO-DATE
:app:compileDebugShaders UP-TO-DATE
:app:generateDebugAssets UP-TO-DATE
:app:mergeDebugAssets UP-TO-DATE
:app:generateDebugResValues UP-TO-DATE
:app:generateDebugResources UP-TO-DATE
:app:mergeDebugResources UP-TO-DATE
:app:processDebugManifest UP-TO-DATE
:app:processDebugResources UP-TO-DATE
:app:generateDebugSources UP-TO-DATE
:app:incrementalDebugJavaCompilationSafeguard UP-TO-DATE
:app:compileDebugJavaWithJavac UP-TO-DATE
:app:compileDebugSources UP-TO-DATE
:app:prePackageMarkerForDebug
:app:transformClassesWithDexForDebug
To run dex in process, the Gradle daemon needs a larger heap.
It currently has approximately 910 MB.
For faster builds, increase the maximum heap size for the Gradle daemon to more than 2048 MB.
To do this set org.gradle.jvmargs=-Xmx2048M in the project gradle.properties.
For more information see https://docs.gradle.org/current/userguide/build_environment.html
Error:Error converting bytecode to dex:
Cause: Dex cannot parse version 52 byte code.
This is caused by library dependencies that have been compiled using Java 8 or above.
If you are using the 'java' gradle plugin in a library submodule add
targetCompatibility = '1.7'
sourceCompatibility = '1.7'
to that submodule's build.gradle file.
Error:1 error; aborting
:app:transformClassesWithDexForDebug FAILED
Error:Execution failed for task ':app:transformClassesWithDexForDebug'.
> com.android.build.api.transform.TransformException: java.lang.RuntimeException: com.android.ide.common.process.ProcessException: java.util.concurrent.ExecutionException: com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command 'C:\Program Files\Java\jdk1.8.0_40\bin\java.exe'' finished with non-zero exit value 1
Information:BUILD FAILED
Information:Total time: 34.145 secs
Information:3 errors
Information:0 warnings
Information:See complete output in console

Im GradleFile des App Modul's habe ich sourceCompatibility und targetCompatibility bereits hinzugefügt, bewirkt leider nichts.
Code:
apply plugin: 'com.android.model.application'

model {
    android {
        compileSdkVersion 23
        buildToolsVersion "23.0.3"

        defaultConfig {
            applicationId "com.example.michael.upscaledbtest"
            minSdkVersion.apiLevel 22
            targetSdkVersion.apiLevel 23
            versionCode 1
            versionName "1.0"
        }
        compileOptions.with {
            sourceCompatibility = JavaVersion.VERSION_1_7
            targetCompatibility = JavaVersion.VERSION_1_7
        }
        buildTypes {
            release {
                minifyEnabled false
                proguardFiles.add(file('proguard-android.txt'))
            }
        }
        // New code
        ndk {
            moduleName "UpscaleDBTest"
        }
// New code finished
    }
}
dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
    testCompile 'junit:junit:4.12'
    compile 'com.android.support:appcompat-v7:24.2.0'
    compile 'com.android.support:design:24.2.0'
    compile files('libs/upscaledb-2.2.0.jar')
}
 
Hi,

ich glaube diese Anleitung ist wichtig:
Unter Android ist das analog, außer dass die DLLs dort die Endung .so haben ("Shared Object" - ist die gängige Bezeichnung unter Linux). Wie man sie im Android Studio erstellt weiß ich nicht, aber dort musst Du den ganzen Prozess analog aufsetzen:

1. upscaledb compilieren (erzeugt eine .so-Datei) - native code!
2. upscaledb-java compilieren (erzeugt die upscaledb-java.so - auch native code!)
3. JAR-Datei compilieren

Du darfst also nicht die DLLs Kopieren, sondern die SO-Dateien, die du vorher selbst kompilierst.
 
okay, das stellt mich vor das Problem ich habe ein solches C Projekt noch nie kompiliert. Wie gehe ich da am besten vor. Zunächst installiere ich mir mal das Visual Studio nehme ich an.
Kardroid schrieb:
Hi,

ich glaube diese Anleitung ist wichtig:
Unter Android ist das analog, außer dass die DLLs dort die Endung .so haben ("Shared Object" - ist die gängige Bezeichnung unter Linux). Wie man sie im Android Studio erstellt weiß ich nicht, aber dort musst Du den ganzen Prozess analog aufsetzen:

1. upscaledb compilieren (erzeugt eine .so-Datei) - native code!
2. upscaledb-java compilieren (erzeugt die upscaledb-java.so - auch native code!)
3. JAR-Datei compilieren

Du darfst also nicht die DLLs Kopieren, sondern die SO-Dateien, die du vorher selbst kompilierst.

Ich hatte gehofft durch den Hinweis
Unter Windows ist der kostenlose Compiler von Microsoft ganz gut (Visual Studio Express). Allerdings findest Du die für Windows compilierten Dateien auch auf der Webseite unter upscaledb.com/download. Da ist auch eine upscaledb-java.dll enthalten, sowie die jar-Datei mit den Java-Bibliotheken. Damit die jar-Datei korrekt geladen werden kann muss upscaledb-java.dll und upscaledb-2.2.0.dll im Pfad liegen.
brauche ich nicht mehr das ganze Projekt zu compilieren da es ja scheinbar schon eine Windows geeignete Version gibt. Ich habe lediglich eine Bat Datei des Projekts ausgeführt um die JAR Datei zu erhalten.
 
Du darfst also nicht die DLLs Kopieren, sondern die SO-Dateien, die du vorher selbst kompilierst.

Da läuft was schief :)

Oben wird erwähnt das er VS einsetzen soll und compilieren.

Unter Windows ist der kostenlose Compiler von Microsoft ganz gut (Visual Studio Express). Allerdings findest Du die für Windows compilierten Dateien auch auf der Webseite unter upscaledb.com/download. Da ist auch eine upscaledb-java.dll enthalten, sowie die jar-Datei mit den Java-Bibliotheken. Damit die jar-Datei korrekt geladen werden kann muss upscaledb-java.dll und upscaledb-2.2.0.dll im Pfad liegen.

Allerdings erstellt VisualStudio unter Win keine .so dateien :)
 
  • Danke
Reaktionen: Micka
swa00 schrieb:
Du darfst also nicht die DLLs Kopieren, sondern die SO-Dateien, die du vorher selbst kompilierst.

Da läuft was schief :)

Oben wird erwähnt das er VS einsetzen soll und compilieren.

Unter Windows ist der kostenlose Compiler von Microsoft ganz gut (Visual Studio Express). Allerdings findest Du die für Windows compilierten Dateien auch auf der Webseite unter upscaledb.com/download. Da ist auch eine upscaledb-java.dll enthalten, sowie die jar-Datei mit den Java-Bibliotheken. Damit die jar-Datei korrekt geladen werden kann muss upscaledb-java.dll und upscaledb-2.2.0.dll im Pfad liegen.

Allerdings erstellt VisualStudio unter Win keine .so dateien :)
das wäre mir garnicht aufgefallen weil ich keine Erfahrung mit Visual Studio und oder C habe. Vielen Dank, auch wenn mich das momentan noch nicht viel weiter bringt, immerhin ein weiterer Ansatz
 
Der Entwickler der Datenbank hats mir so beschrieben, deswegen hab ichs so versucht.
Du meinst den kompletten Java Ordner einfach importieren oder was genau?
 
Halb-Richtig,

der Java-Ordner beinhaltet mE alle erforderlichen Sources. (Habs natürlich nicht getestet)
Die musst du natürlich noch AS/Android-mäßig anpassen - das vorliegende Projekt sieht mir eher nach KDE/Linux aus . (make)
 
ich habe nicht vor nun alles von Hand anzupassen.
Momentan liegt mein Problem vorallem darin das Projekt der Datenbank unter Windows zu kompilieren um .SO Datei zu erhalten
 
Laut Entwickler der der Datenbank kann ich das C Projekt nicht einfach unter Ubuntu compilieren. Dies muss im Android Studio geschehen. Ich habe folgende Informationen zur Verwendung von Libraries gefunden,
allerdings beziehen diese sich auf Eclipse und ADT und nicht aufs Android Studio.
 
Moin Micka,

den link den ich dir oben geschickt habe - und das habe ich ja schon dazu geschrieben :
- Sein Projekt ist ein Linux Projekt (make)

Wenn du .so (binary-Library) haben möchtest , dann ist die Aussage richtig , dass du Linux verwenden musst.
Es gibt eine Vielzahl von C-Compilern, die frei zu haben sind.


Es verwirt ein wenig :

WAS WIRD BENÖTIGT ?

Reicht der Java Code , der in seinem Projekt ist ?
Ist der Core doch nur in C ? braucht man die complierte .so oder kann man NDK verwenden ??
Das mit Visual-Studio ist erst mal eindeutig falsch (DLL)

P.S kann es sein , dass er keine richtige Lust hat und dich/uns mit den unterschiedlichen Aussagen
schlichtweg nur verwirrt ? :)


lg
Stefan
 
Zuletzt bearbeitet:
Hy,
Ich habe den Versuch diese Datenbank zu benutzen mittlerweile aufgegeben. Scheinbar weiß der Entwickler ja selbst nicht wie es funktionieren soll. Mir fehlt die Zeit diese jetzt noch ins Projekt einzubauen.
 
Micka schrieb:
Hy,
Ich habe den Versuch diese Datenbank zu benutzen mittlerweile aufgegeben. Scheinbar weiß der Entwickler ja selbst nicht wie es funktionieren soll. Mir fehlt die Zeit diese jetzt noch ins Projekt einzubauen.

Sorry dass ich mich hier einmische. Aber ich denke du hast da ein kleines Missverständnis was Java und Android betrifft. Du fragst den Entwickler der upscaledDB wie diese in "Java" zu nutzen ist und bekommst da auch Antwort. Versuchst es aber dann in Android zu integrieren. Android ist aber nicht vollständig kompatibel mit Java weil Android eine "spezielle" java run-time hat und nur die wichtigsten Klassen enthalten sind.
Meines Erachtens ist es nicht sinnvoll Android anders zu benutzen als es von Google vorgesehen ist.

Warum baust du dir nicht einfach einen kleinen WebServer denn du als Wrapper verwendest?

Android Gerät -> webserver -> upscaledDB

Grüßse
 
Nonsens schrieb:
Micka schrieb:
Hy,
Ich habe den Versuch diese Datenbank zu benutzen mittlerweile aufgegeben. Scheinbar weiß der Entwickler ja selbst nicht wie es funktionieren soll. Mir fehlt die Zeit diese jetzt noch ins Projekt einzubauen.

Sorry dass ich mich hier einmische. Aber ich denke du hast da ein kleines Missverständnis was Java und Android betrifft. Du fragst den Entwickler der upscaledDB wie diese in "Java" zu nutzen ist und bekommst da auch Antwort. Versuchst es aber dann in Android zu integrieren. Android ist aber nicht vollständig kompatibel mit Java weil Android eine "spezielle" java run-time hat und nur die wichtigsten Klassen enthalten sind.
Meines Erachtens ist es nicht sinnvoll Android anders zu benutzen als es von Google vorgesehen ist.

Warum baust du dir nicht einfach einen kleinen WebServer denn du als Wrapper verwendest?

Android Gerät -> webserver -> upscaledDB

Grüßse


Hy,

bei meinem Projekt geht es darum lokal unter Android verwendbare Datenbanken zu evaluieren, daher kommt die Webserver Lösung nicht in Frage.
Wenn du dir den ersten Post nochmal genau durchliesst wirst du feststellen das ich den Entwickler gefragt habe wie das ganze in Android funktionieren soll, ich habe nicht explizit nach Java gefragt. Das die Verwendung über die Java Schnittstelle funktioniert ist wohl so. Keine Ahnung, ich habe es wie gesagt nicht umsetzen können.

Grüße
 
@Micka

Du hast zwar schon innerlich damit abgeschlossen , aber es gibt doch den reinen C-Code.
Warum machst du dir dann nicht ein NDK Projekt ??
 
Genau das hatte ich ja vor. Ich wollte ursprünglich so wie der Entwickler es beschrieben hat den C-Code mittels JNI in meine App einbinden. Dabei kam es dann zu den Problemen mit den nicht compilierten .SO librarys. Laut Entwickler muss ich diese selbst compilieren wovon ich ehrlich gesagt keine Ahnung habe.

Nun da das Projekt schon ziemlich fortgeschritten ist fehlt die Zeit es dort noch zu integrieren. Aber Du kannst dich gerne an einer Beispiel App versuchen und mit mitteilen obs geklappt hat. Interessieren würde es mich durchaus obs klappt. Evtl kann dies dann im Folgeprojekt eingearbeitet werden.
Schöne Grüße
 

Ähnliche Themen

D
  • Data2006
Antworten
14
Aufrufe
486
jogimuc
J
M
Antworten
4
Aufrufe
1.171
swa00
swa00
5
Antworten
0
Aufrufe
1.144
586920
5
Zurück
Oben Unten