Newsgroup: it.comp.lang.delphi
Titolo: XE7 - Android terminale (Huawey Y6) non visto

eseguito Android Tools ed installati
 
Android Tools
 
Android SDK Tools aggiornato rel. 24.0.2
Android SDK Platform tools   rel. 20
Andoid SDK Build Tools rel. 19
 
Android 4.4 (API 19)
SDK Platform rev3
 
Extras
Android Support Library rel.19
 
Avviando XE7 (progetto LocationDemo)
 
Delphi
Target Platform
-- Android SDK 22.3.32bit
--- Target
---- non compare alcun device (anche eseguendo Refresh)
 
Il Device monta Android 5.1, le Library ferme a 4.4 ammesso che c'entri.
 
Il Terminale Huawey G510 (rotto) viene invece individuato, ma per farlo 
vedere a Delphi avevo installato Huawey_Android_Usb Driver_v1.0
 
Sia G510 che Y6 che scheda SD vengono visti da Win10 senza installare 
driver.
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

abilitato usb debug e impostato accetta da sorgenti sconosciute?
 
 

>
si' fatto (abilitato Debug Usb .... era un'opzione nascosta, accessibile 
con vari tap, da impostgaione info telefono, numero serie)
 
Il Device viene regolarmente visto come SLC-L21
 
ho dovuto aggiungere System.Android.Sensors alle uses, segnalato 
mancante, ed il path
 
{path aggiunto}
C:\Users\Public\Documents\Embarcadero\Studio\15.0\PlatformSDKs\android-ndk-r9c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin\arm-linux-androideabi-ld.exe: 
error: cannot find -ldl
 
esegue il Link ed alla fine
 
[DCC Fatal Error] F2588 Linker error code: 1 ($00000001)
 
che potrebbe essere legato a quello che non trova nonostante il path


Guarda...io sono impazzito perchè il path agli eseguibili era troppo 
lungo....
Sew hai modo, sposta/copia la toolchain in c: e rifai i collegamenti 
nelle opzioni...io ho risolto così
 
'73 MB339
 
 


spostato toolchains su c:
su Tool/Option/Library selezionato Android e aggiunto
c:\toolchains
 
cerca sempre nel path
C:\Users\Public\Documents\Embarcadero\... toolchains
 
bisognerebbe modificare i path di ricerca predefiniti impostati  in fase 
di installazione
 
il file arm-linux-androideabi-ld.exe esiste, non e' chiaro invece cosa 
non trova "error: cannot find -ldl" un file o un parametro; non credo 
sia il "vecchio" problema dei 256 caratteri.
 

Mi permetto un suggerimento.
Se devi sviluppare per Android molla delphi.
 
Spostarsi su Android Studio e usare un dialetto JAVA è dura.
Lo sto facendo io stesso, e contemporaneamente mi sto muovendo verso java.
Quindi, so bene di cosa parlo.
 
Ma, secondo me, nel ns lavoro è SCONTATO il dover imparare cose nuove.
 
Pragmaticamente parlando, non hai ancora iniziato e sei già nei casini.
Non so da quanto ti stai sbattendo su questa cosa, ma ti suggerisco di fermarti un attimo, rilassarti e porti una semplice domanda:
 
Quanto vale la pena impazzire su questa cosa spendendoci del TEMPO che potrebbe invece essere piu' proficuamente utilizzato per studiare e imparare a sviluppare NATIVAMENTE su android usando lo strumento STANDARD per tale piattaforma?
 
A.
 
 
 

>
giusta considerazione.
 
 
 
 


Ciao Alberto,
uno fa presto a dire java, ma java come, in che contesto, con quale ide...
mi interessano le tue esperienze
 
 

 ma java come, in che contesto, con quale ide...
 
Il contesto è ovviamente (ma non per tutti) JEE versione 7.
Lo so che non è l'ultimissima ma onestamente me ne frego.
 
Al momento sto usando Netbeans 8.0.2 e tomcat 8.
Sia chiaro: ho fatto ben poco, visto che intanto devo pur lavorare e sono abbastaza preso. (aggiungo che è un periodo particolarmente positivo).
Giusto una webapp che tramite semplici servlet permette una gestione CRUD
tramite jdbc su un db MySql, senza usare alcun DAO.
 
Al momento sta cosa lo invoco da una applicazione XE7 usando TIdHttp.
Next, ci saranno le chiamate da una app android sviluppata OVVIAMENTE con Android Studio.
 
Ho provato a usare jersey ma ho avuto problemi, ma ci sta visto che sono all'inizio, quindi per adesso ho lasciato perdere.
 
Gli step successivi saranno in ordine sparso:
 
1) mettere in piedi un sistema di autenticazione/token etc evitando l'uso della basic authentication
 
2) scegliere un framework per la persistenza (iBatis, Hibernate o non so che altro). 
 
3) attivare HTTPS su tomcat, e qua per ora userò un certificato autogenerato
 
4) scegliere un framework Jax-rs e passare da richieste HTTP *semplici" a RESTful
 
 
Ammetto che così a "istinto" sono portato a sceglierei framework di Apache.
Ma qua dovrò ragionare anche in funzione della rivendibiltà.
 
 
A.

 problemi simili con Android), cosa succedera' provando cose piu' serie.
 
Esattamente! 
 
A.

 
Errata corrige:
 
aggiungo che NON è un periodo particolarmente positivo
 
A.

 Il contesto è ovviamente (ma non per tutti) JEE versione 7.
 
Huh?! Cosa c'entra JEE con Android?

 Si assume che tu stia lavorando con Java 7 o 8.
 
la presunzione è la madre di tutte le cazzate, ma questo tu lo sai bene, 
sei un esperto ...idiota
 
-- 
Ripristinare il trattato di Vienna è imperativo!
W IL LOMBARDO-VENETO.
W LA LIBERTA'.
ONORE E GLORIA A S.M. CARLO D'ASBURGO-LORENA!!!

 Quasi sempre e` irrilevante. Si assume che tu stia lavorando con Java 7 o 8.
 
Mica tanto irrilevante, a meno che non vuoi sentirti rispondere "ho scritto una
lambda ma non funziona. Uso Java7"
 
Enrico

 lambda ma non funziona. Uso Java7"
 
Non hai capito il punto: ormai, o si usa Java 7 o si usa Java 8, quindi avere informazioni precise su quale versione di Java si sta usando, per risolvere un problema legato ad Android, e` irrilevante.