Ovvero in passato ho realizzato varie Apps che giravano tutte bene ma quando sono iniziate le installazioni sugli ultimi Android (5.0 e successive) comincio a ricevere segnalazioni di malfunzionamenti.
Avete registrato qualcosa di simile anche voi?
Su internet qualcosa ho trovato: Google ha sostituito la macchina DALVIK con un'altra...
anche io ho riscontrato i stessi problemi.
Ti consiglio di procurarti un dispositivo con android 5+ e ricompilare le tue app - solo così puoi vedere dove si trova il problema.
anche io ho riscontrato i stessi problemi.
Ti consiglio di procurarti un dispositivo con android 5+ e ricompilare le tue app - solo così puoi vedere dove si trova il problema.
Ciao Filippo,
l'ho fatto: sto utilizzando un P8 LITE di Huawei (android 5.0)
Speravo che qualcuno avesse già trovato il classico uovo di colombo per risolvere gli inconvenienti... Ormai è assodato che la "colpa" è della sostituzione di DALVIK con ART.
Mi stupisco un pò che sul forum siano poche le segnalazioni di qualche incompatibilità nel porting delle apps da DALVIK ad ART.
In tutta franchezza mi scoccia dover rimettere mano a un codice che davo per stabile da più di un anno .
Ho riscontrato diversi casi si blocco, le problematiche maggiori sono in eventi che coinvolgo il layout. Ad esempio un msgbox nell'edittext_EnterPressed, uppure doeventS per disegnare una listview in un EditText_FocusChanged. Ho risolto con CallSubDelayed (anche per chiamare la msgbox). In effetti è una gran noia.
Ho riscontrato diversi casi si blocco, le problematiche maggiori sono in eventi che coinvolgo il layout. Ad esempio un msgbox nell'edittext_EnterPressed, uppure doeventS per disegnare una listview in un EditText_FocusChanged. Ho risolto con CallSubDelayed (anche per chiamare la msgbox). In effetti è una gran noia.
Grazie Luciano.
Speravo che a livello di forum venisse realizzata una lista delle funzioni e/o contesti dove il porting dà maggiori problemi... cosi almeno uno va a colpo sicuro e rimuove la maggior parte delle incompatibilità..
sub ShowListDim PH As Int : PH = 5%Y
ScrollView1.Panel.RemoveAllViews
strquery = ("SELECT ..."'") dbCursor = Main.dbSql.ExecQuery(strquery)For i = 0To dbCursor.RowCount - 1DoEvents
dbCursor.position = i
panel1.Initialize("PRow")
ScrollView1.Panel.AddView(ps, 0, i * PH, 100%x, PH)
panel1.LoadLayout("LayRow")
....
Next
ScrollView1.Panel.Height = dbCursor.RowCount * PH
dbCursor.Closeend sub
Tu aggiungi al pannello interno alla scrollview la view chiamata ps che non si sa cosa sia e dove sia.
Forse volevi aggiungere panel1, nel quale carichi il layout LayRow?
Scusa, eh, ma per tagliare la testa al solito povero toro...
prova a creare e caricare una scrollview nello stesso modo (sempre su un 4.4.2) senza caricare dati da db (magari senza caricare layout, ma creandolo al volo per ogni pannello interno, almeno all'inizio).
Secondo me non avrai errori (con o senza DoEvents).
Ho voluto modificare il progetto allegato al post precedente per fare in modo che il numero di Item fosse variabile.
Volendo aggiungere 1000 item e volendo vedere se la visualizzazione avvenisse durante la creazione degli item, aggiungendo un DoEvents...
sorpresina: crea solo 10 item "per colpa del DoEvents".
Questo significa, secondo me, che durante la creazione degli item, il doevents fa sì che il controllo del flusso passi alla resume dopo il caricamento di soli 10 item.
Secondo me non ha senso ed è una specie di bug.
Ho provato il progetto allegato al post #15 su un emulatore con Android 4.3.1 (API 18 - 4.4.2 = API 19) ed il difetto rimane; ho aggiunto un log per il contatore del ciclo e uno nella Resume: la scrollview viene visualizzata quasi subito, il log scorre nella finestra dei log poi compare, giustamente, il log della Resume ma la scrollview sembra contenere solo 11 item (o forse il suo pannello interno non viene ridimensionato - per sapere questo, basterebbe "allungarlo" durante il caricamento - farollo ).
Questo per dire che lo strano comportamento (direi "sbagliato" comportamento) avviene anche con versioni precedenti la 4.4.
Provato ad incrementare l'altezza del pannello interno della scrollview all'interno del ciclo, anziché ridimensionarla al termine di esso; risultato: con 300 item Android va in crash e si riavvia (nell'emulatore con Android 4.3.1).
Su un dispositivo reale con 4.4.2, tutto ok, con 300-400 item, sia con che senza DoEvents.
L'esempio faceva un po' cagare, comunque scava scava il problema lo hai trovato. Può darsi che non sia direttamente il DoEvents a scatenarlo, fatto sta che senza il problema non mi si verifica più. La cosa brutta è non vedere la creazione di ogni singola riga , la app sembra bloccata fino a che non ha disegnato tutte le righe. Ho omesso di dirvi una particolarità: il problema si manifesta maggiormente con un inbut da scanner in emulazione tastiera. In pratica inserivo la stringa in una edit text (chiave di inner join), nell'eterpressed c'era un if al contatore del cursor se > 0 chiamava la sub per disegnare la lista dei dettagli altrimenti msgbox per comunicare che non ci sono dettagli. Se la digitazione e la pressione dell'enter era mooolto veloce talvolta, in entrambi i casi, schiantava. Con lo scanner, che passa l'enter come carattere finale dell'input, schiantava sempre. In un primo momento ho risolto togliendo il DoEvents ma restava il problema del msgbox (il crash avveniva dopo la visualizzazione del messaggio), con callsubdelay ho risolo entrambi i casi.