Italian APPs che girano male con ANDROID 5.0

[juvanum]

Scusate ma è successo anche con le vostre Apps?

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...

Sapete qualcosa di più preciso?

 

[LucaMs]

Nessuna delle mie app ha problemi con Android 5.0... dato che non ho pubblicato app

(Scusa, se non metto qualche battutina scema non mi diverto).

Direi che potresti guardare questo thread.

 

[juvanum]

Nessuna delle mie app ha problemi con Android 5.0... dato che non ho pubblicato app

(Scusa, se non metto qualche battutina scema non mi diverto).

Direi che potresti guardare questo thread.

No problem: bisogna anche scherzare

Grazie per la segnalazione ma quel thread lo conoscevo già e purtroppo non ha risolto tutti i problemi

 

[Deleted member 103]

Ciao juvanum,

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.

 

[juvanum]

Ciao juvanum,

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 .

 

[Deleted member 103]

In tutta franchezza mi scoccia dover rimettere mano a un codice che davo per stabile da più di un anno .

Non sei il solo a scocciarti.
Io ho dovuto mettere le mani anche sulle iOS-App per il cambio di versione da 8 a 9.

 

[luciano deri]

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.

 

[juvanum]

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à..

 

[LucaMs]

Sicuri che i casi citati (msgbox-edittext_Enter... listview con edittext...) funzionino sulle versioni precedenti e non su Lollipop?

Potete pubblicare (postare ) un progettino d'esempio?

 

[luciano deri]

https://www.b4x.com/android/forum/threads/problem-with-doevents-on-android-4-4-2.56060/
ma il problema è conosciuto, anche se senza una soluzione degna.
vedi le risposte di erel
https://www.b4x.com/android/forum/threads/fatal-signal-7-sigbus-at-0x00000000-code-128.59885/
https://www.b4x.com/android/forum/threads/msgbox2-sometimes-my-application-crashes.56146/

E' un problema, per lo stesso motivo alcune volte le app vanno in crash durante il debug.

 

[LucaMs]

Beh, intanto QUEL problema quindi non sarebbe android 5.0 ma già dalla 4.4.2.

Io non credo affatto che DoEvents possa dare problemi, anzi. Purtroppo il codice è parziale. Provo a rileggere quel thread.

 

[LucaMs]

La routine non mi convince:

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?

 

[LucaMs]

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).

 

[LucaMs]

Allego una schifezza di progetto ma è giusto per dimostrarti che funziona (testato su un 4.4.2).

 

[LucaMs]

Bbbboni che ho scoperto una specie di bug.

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.

Progetto allegato.

 

[juvanum]

Beh, intanto QUEL problema quindi non sarebbe android 5.0 ma già dalla 4.4.2.

Google ha iniziato a installare ART dalla 4.4 di Android e la resa definitiva dalla 5.0

 

[LucaMs]

Google ha iniziato a installare ART dalla 4.4 di Android e la resa definitiva dalla 5.0

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.

 

[LucaMs]

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.

 

[luciano deri]

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.

https://www.b4x.com/android/forum/threads/problem-with-bluetooth-keyboard.44487/