-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Italian [Risolto] Bottoni scrollabili in B4A ok ma non riesco in B4J
- Thread starter Gnappo jr
- Start date
- Similar Threads Similar Threads
Grazie Luca per i costruttivi contributi che stai fornendo, senza dubbio di utilità anche a chi farà ricerche sul tema nel tempo a seguire.
Farò domani tutte le prove suggeritemi.
Nel mio caso particolare una fonte di rallentamento è dovuta alla presenza di B4XPlusMinus che rimosso migliorano i tempi di risposta.
Quello che intendo come rallentamento è un lasso di tempo molto inquietante dal momento che premo il tasto click e il momento che appaiono le 20 righe della tabella!
Non è una seplice questione di performance ma il fatto di contare fino a 3 (o fino a 2) prima che appaia qualcosa!
Quindi volendo per studio, rifare in B4X un mio vecchio progetto B4A che presenta dei risultati in una tabellina scrollabile , mi trovo che, il vecchio con la scrollview i risultati sono fulminei, mentre il nuovo in B4X in android con la customscrollview ci mette così tanto per presentare solo 20 righe che è disarmante.
La soluzione è semplicissima: fare due cose distint, una per ogni piattaforma.
Ma siccome vogliamo tutti un gran bene a B4X, dobbiamo cercare il modo di renderlo almeno pari al vecchio no?
Ritengo l'argomento sensibile in quanto le app Android hanno la caratteristica di essere 'fulminee'
quindi sto c.. de problema lo vedo solo io ed un altro o ci sta per davvero?
Proprio per questo ho messo lo Sleep(0) dopo l'aggiunta di un nuovo panel (item), in modo che tu veda subito la creazione, anziché vederli comparire tutti e 20 solo al termine del caricamento.
Impostando la durata dell'animazione del layout clv_item su zero ms e lanciando l'app in modalità release, sul mio smartphone vecchiotto (originariamente Android 7 aggiornato a 8) il caricamento dei 20 item avviene in meno di un secondo (a occhio, non calcolato effettivamente).
Lo allego (non che il nome mi piaccia molto, veramente).
D
Deleted member 103
Guest
una discussione del 2018 che rigurada questo tema:
www.b4x.com
www.b4x.com
CustomListView running too slow
I have same problem again. my customlistview taking more than 4 min for nearly 1200 records of sqlite 7.12.00 7.16.00 my code is : cursor = Starter.year.ExecQuery("select * from GL where FBOOK='G001' order by FDESC") Dim...
www.b4x.com
CustomListView running too slow
I have same problem again. my customlistview taking more than 4 min for nearly 1200 records of sqlite 7.12.00 7.16.00 my code is : cursor = Starter.year.ExecQuery("select * from GL where FBOOK='G001' order by FDESC") Dim...
www.b4x.com
@Gnappos
Ho provato il tuo esempio e sul mio dispositivo gli elementi appaiono istantaneamente.
Aggiungere 20 elementi non può richiedere tempo (nel caso poi della semplicità dei tuoi).
Nel Layout principale tra le proprietà della XCLV metti a 0 anche Insert Animation.
Ma sono proprio dettagli.
Domanda:
i tuoi Test li fai in modalità Debug o Release?
Le prestazioni reali di una app vanno sempre verificate in Release.
Ho provato il tuo esempio e sul mio dispositivo gli elementi appaiono istantaneamente.
Aggiungere 20 elementi non può richiedere tempo (nel caso poi della semplicità dei tuoi).
Nel Layout principale tra le proprietà della XCLV metti a 0 anche Insert Animation.
Ma sono proprio dettagli.
Domanda:
i tuoi Test li fai in modalità Debug o Release?
Le prestazioni reali di una app vanno sempre verificate in Release.
Beh, là si fa l'errore di voler caricare 1200 elementi tutti insieme! Erel ha giustamente suggerito di usare il "lazy loading".
Cmq, non è proprio il tema in questione in questo thread, perché qui stiamo parlando della supposta maggior velocità di utilizzo di una ScrollView rispetto a una xCLV (sempre ricordando che ScrollView è solo per B4A-Android) mentre in quel thread tu affermi che sia più veloce creando l'item nel codice anziché caricarne un layout (c'è una tua routine di esempio).
Last edited:
Allego un progettino in cui uso la tua routine che crea l'item da codice e un'altra che lo carica da layout.
Lancialo in modalità Release; noterai che al primo caricamento dei 40 item, la tua routine risulta leggermente più lenta rispetto al caricamento del layout (ripetendo l'operazione i tempi sembrano uguali). Se non noterai differenza è perché il tuo smartphone è molto probabilmente più veloce del mio; in questo caso, raddoppia il numero di item da caricare oppure lancialo in modalità debug.
Nota anche quanto sia più semplice e breve la routine di creazione dell'item.
Last edited:
Come mai dal secondo caricamento in poi, gli item vengono tutti scombussolati e non nell'ordine del caricamento?
Per fare dei test su telefoni con prestazioni diverse, al posto dell'array di stringhe ho messo un ciclo For e la variabile del ciclo messa come nome item da caricare
Al primo caricamento va tutto come previsto, dal secondo in poi si spatacca tutto
Come se il CLV1.clear iniziale non venisse eseguito (ma invece viene eseguito correttamente, verificato)
B4X:
For count=1 To 1000
If Mode = "ByCode" Then
CLV1.Add(Add_row_Filippo(count, Width, Height), count)
Else
CLV1.Add(Add_row_Layout(count, Width, Height), count)
End If
Sleep(0)
NextProbabilmente perché si avvia un caricamento prima ancora che venga completato il precedente.
Essendoci uno Sleep servirebbe un Wait For, ma essendo solo un esempiuccio al volo non me ne sono preoccupato. Esempio, tra l'altro, che serviva solo a provare se veramente usare un layout anziché creare l'item nel codice sia più lento (e non sembra sia così), mentre il tema principale di questo thread è un altro.
Anche se ci fosse un minimo vantaggio nei tempi di caricamento creando l'item da codice, e non è così, quanto è più sintentica e pulita la routine che crea l'item caricando un layout! Siete d'accordo, spero; e immaginate se contenesse più di quelle tre View!
Last edited:
Aggiunto il Wait For e caricato 100 item come indicato da @amorosik (in un ciclo e con testo uguale all'indice di questo).
Si, ora e' chiaro e dimostrato
Non ho letto tutto il thread, ma mi sembra che vi siate appassionati 
Avete provato con un layout un po'complesso e, soprattutto, che contenga uno script iniziale? Per esempio qualcosa che carichi tre label/panel/imageview (insomma ciò che volete) sulla stessa riga ma che le ridimensioni e spazi in modo che abbiano le stesse dimensioni e una spaziatura uniforme (compresi i margini sx e dx)? E magari una seconda riga che dovrà posizionarsi 10dip sotto la prima (che abbiamo visto che cambia dimensione in funzione del device)?
Premetto che trovo molto comodo il LoadLayout (così come la PreferenceDIalog abbinata al FormsBuilder), ma troverei "più furbo" effettuare il load una sola volta (tanto poi si ripete identico), caricarne il risultato in una "cache" ed utilizzare quest'ultima per popolare la CLV. Tanto per evitare i continui accessi al file di layout (che essendo contenuto nel DirAssets in effetti risiede nel .jar)
Avete provato con un layout un po'complesso e, soprattutto, che contenga uno script iniziale? Per esempio qualcosa che carichi tre label/panel/imageview (insomma ciò che volete) sulla stessa riga ma che le ridimensioni e spazi in modo che abbiano le stesse dimensioni e una spaziatura uniforme (compresi i margini sx e dx)? E magari una seconda riga che dovrà posizionarsi 10dip sotto la prima (che abbiamo visto che cambia dimensione in funzione del device)?
Premetto che trovo molto comodo il LoadLayout (così come la PreferenceDIalog abbinata al FormsBuilder), ma troverei "più furbo" effettuare il load una sola volta (tanto poi si ripete identico), caricarne il risultato in una "cache" ed utilizzare quest'ultima per popolare la CLV. Tanto per evitare i continui accessi al file di layout (che essendo contenuto nel DirAssets in effetti risiede nel .jar)
Grazie veramente di cuore a tutti!
Ritengo che l'argomento sia stato trattato in modo esauriente ed è sufficente così.
Un ultima informazione, volendo ringraziare in forma tangibile, premendo su quei tastini con su scritto [Donate], quale cifra può essere adeguata per non essere interpretata come possibile offesa?
Ritengo che l'argomento sia stato trattato in modo esauriente ed è sufficente così.
Un ultima informazione, volendo ringraziare in forma tangibile, premendo su quei tastini con su scritto [Donate], quale cifra può essere adeguata per non essere interpretata come possibile offesa?
per me 1.000€ non mi offendo.
Si, scusa ho sbagliato valuta.
Per così poco (aiuto) non vale nemmeno la pena che sprechi un click
Sarebbe la stessa cosa, perché quel codice dello script o lo metti là o lo scrivi nel sorgente, deve comunque essere eseguito.
Eh sì, ma non si può; senza contare che all'interno della creazione di un item della xCLV normalmente riempi anche le View con dei valori ed è qui che queste vengono distinte dalle altre (degli altri item).
Ebbene si! Hai trovato la chiave del mistero! ?????
Finora non ho mai notato differenze tra DEBUG e RELEASE, figurati se per una manciata di righe di codice potevo supporre una così ABBISSALE DIFFERENZA di tempi di risposta tra debug e release!!! Invece con la xCLV la vedo in modo eclatante tant'è vero che avevo con grande rammarico deciso di non poterla usare.
E' bastato passare alla release come da Te suggerito e tutto funziona come atteso, cioè in modo istantaneo!
Questo spiega anche il fatto che una parte di noi vede il problema ed un altra no, hanno tutti ragione!
Accidenti che sgrugnata! (Damn what a blow to the face.)!
Per caricare molte righe, e' consigliabbole seguire le indicazioni lazy loading
In sostanza vengono caricate solamente le righe che 'vedi' a display
Tipo la 'paginazione' che si fa coi db, carichi 20 record, poi quando cambi schermata i sucessivi 20 e cosi via
Anche se hai 100K articoli, sempre 20 alla volta ne carichi, e' leggermente piu' complesso, ma fulminante come prestazioni
