Italian Resize delle form

[insoft]

Buongiorno sono nuovo del forum e mi sto cimentando con la prima applicazione android con B4A anche se fino ad ora ho sempre usato VBA Access o vb.net.

Mi sono trovato subito davanti a un problema (premesso che gli oggetti sono posizionati da codice usando dpi) e cioè che sviluppando l'applicazione su un tablet 7", poi caricandola su smartphone a 6" come l'Hiaer o su un Wiko da 5,2" cambia tutto e tutte le schermate sono da rifare.
A volte mi sono reso conto che cambia anche in funzione del font di default dello smartphone.
Non penso si debba fare una versione del codice per ogni dispositivo che si va ad usare, sicuramente sbaglio o trascuro qualcosa !!!

Da profano immaginavo venisse fatto il resize in automatico.
E' vero che costruendo il layout anziché da codice con l'editor di form integrato in B4A il resize invece avviene ??
O in caso contrario, immaginando sia un problema di molti, qualcuno sa darmi gentilmente un consiglio su come tentare di risolvere il problema.

Grazie a tutti.
Massimo

 

[LucaMs]

Ciao, Massimo.

Questo è IL problema delle app, direi, ovvero il principale.

Se quei fetenti di produttori concordassero un formato standard per i display, esattamente come accade per i TV il cui rapporto base/altezza è fisso a 16:9 (anzi, direi che dovrebbero proprio produrre dispositivi in questo formato!) il problema non esisterebbe.

Quindi, proprio per farti avere un'idea precisa del problema, prendi ad esempio i programmi tv di un tempo, che erano in formato 4:3; come riesci a vederli oggi su un TV (che appunto è 16:9)? O lo vedi in 4:3, con delle bande scure ai lati, oppure fai uno zoom perdendo parte dei lati dell'immagine. Il che significa che una soluzione perfetta non esiste.

E' vero che costruendo il layout anziché da codice con l'editor di form integrato in B4A il resize invece avviene ??

Sì e no; AutoscaleAll fa il ridimensionamento ma cercando un buon compromesso, in base al valore di ScaleRate, proprio perché non è possibile fare una sorta di zoom su schermi di proporzioni diverse. Se imposti questo ScaleRate a 1, avverà proprio il ridimensionamento al quale pensi (è come se tu da codice mettessi ogni valore in percentuale, anziché in dip) ma ovviamente le view non potranno stare nelle stesse posizioni e distanze relative originali "adattate".

Insomma, se ho un rettangolo, non posso metterci dentro un quadrato e pretendere che i bordi del quadrato tocchino i bordi del rettangolo senza che il quadrato... diventi un rettangolo

Detto che una soluzione ideale non esiste, per i motivi di cui sopra, secondo me conviene creare due variant, uno per landscape e uno per portrait, ancorare il più possibile le view ed usare gli script del Designer per aggiustare al meglio le cose.

 

[insoft]

Era più o meno come immaginavo, ci sarà da tribolare.

Comunque grazie 1000

Massimo

 

[sirjo66]

Direi che se posizioni gli oggetti tramite codice la soluzione migliore è farlo non con i dip ma con la percentuale, vedrai che automaticamente si ridimensionano

Ad esempio se dici ad un bottone di occupare il 20% della larghezza dello schermo lo farà sempre, credo che per te sia la soluzione migliore

Sergio

 

[LucaMs]

Ad esempio se dici ad un bottone di occupare il 20% della larghezza dello schermo lo farà sempre, credo che per te sia la soluzione migliore
Sergio

Si, ma che succede se invece di un tasto che di solito ha un'altezza relativamente bassa (ma cmq anche in questo caso) devi ridimensionare un pannello o un'immagine?

Quanto dovrebbe valere l'altezza di questo esempio sul rettangolo in basso? In percentuale anche quella? Se sì, dovrebbe essere il 44.44%y, ovvero circa 107 e quindi l'immagine diventerebbe 80 x 107, mentre in partenza era un quadrato (128x128)

Servirebbe una sottoscrizione, una petizione nei confronti dei produttori:
"Non rompete le balle, fate tutti i vostri dispositivi con formato 16:9"

 

[Gottrik]

Ringrazio LucaMs per aver dato dei "fetenti" ai produttori di Smart, Tablet ecc. , concordo totalmente !

Ma , a proposito di linguaggi di programmazione, chi sono quei "fetenti" che hanno eliminato le istruzioni Goto, Gosub ecc. perché le
ritenevano "poco eleganti" ...
Poco "eleganti" ? E chissenefrega ! Non le usino loro ... ma lascino ai molti imbranati come me la possibilità di utilizzare un vecchio
codice pieno di Goto ( verso l'alto e verso il basso ... ).
Usare Try, Catch ecc ? Ma fatemi il piacere ...

Scusate lo sfogo
Saluti

 

[LucaMs]

Beh, le motivazioni per eliminare quei comandi perlomeno c'erano, per fare tutti dispositivi con schermi differenti no.

E dico che le motivazioni "c'erano", perché alla fine anche usare i tanti eventi, ad iniziare dai timer ma non certo solo da questi, di salti in stile Goto se ne fanno pure troppi.


P.S. Anzi, pensandoci bene, i vari eventi sono pure peggio dei Goto; perlomeno questi li scrivevi tu e sapevi se e quando andavano in esecuzione mentre sugli eventi (tipo timer o httpjob, soprattutto) hai perfino meno controlllo.

Ma ho il sospetto che stiamo andando leggermente fuori tema

 

[Gottrik]

Si, sono andato fuori tema e mi scuso con tutti.
Sentendoti dare del "fetente" non ho resistito a sputare un rospo che mi stava in gola da tanti anni ...
Un'ultima osservazione ... se devo andare da Milano a Venezia posso prendere l'autostrada ( soluzione elegante , senza "spaghetti code" ... )
Però nessuno mi vieta di andare a Bassano del Grappa, poi a Rovigo, poi a Belluno e poi a Trieste ( soluzione per imbranati come me , e altri ... )
Forse una capatina anche a Mantova, non guasterebbe .
Il programma risulta contorto e poco elegante? E' vero, ma la ricaduta pratica si limita a qualche millisecondo di ritardo nel tempo di esecuzione ... chi
se ne accorge ? A me va bene cosi !

Passo e CHIUDO , chiedendovi ancora scusa.
Saluti

 

[LucaMs]

Non devi scusarti; e poi ho scritto "stiamo andando fuori tema". Inoltre, qui nel forum italiano scriviamo talmente poco che non è un problema.

Togliere il Goto, comunque, non è stato per motivi di eleganza, ma per rendere il codice meno "confuso", intricato, e quindi maggiormente "manutenibile".

 

[Gottrik]

E allora, visto che scriviamo poco, voglio chiarire :
Se si trattasse di scrivere un nuovo programma io sarei molto lieto di scriverlo come Dio comanda ... e ben vengano tutti i suggerimenti degli esperti.
Il guaio è che io sono molto interessato ad un codice scritto con il vecchio Basic.
Non mi è stato difficile convertirlo in Visual Basic e poi anche in Basic4ppc ( ringrazio Erel per avermi dato la possibilità di usarlo sui vecchi telefoni
con la "pennina" ).
Speravo di fare lo stesso con B4a ma purtroppo non posso usare Goto , Gosub ecc.
Se si trattasse solo di rimediare ai Goto che vanno "verso valle" ( se posso usare questa espressione ) potrei usare Try, Catch ecc. ma purtroppo ci sono
molti Goto "verso monte" e , come se non bastasse, sono spesso concatenati ... insomma non riesco a venirne fuori ... sono in un mare di nebbia come quello
della mia foto qui sopra a sinistra, devo rinunciare ... è un vero peccato perché il programma è molto valido ( serve per il calcolo balistico ).
Fosse solo un mare di nebbia, non avrei problemi perché ho una buona esperienza alpinistica ... temo invece di essere in mare di m***a !

 

[LucaMs]

Proprio quello è il punto; ti ritrovi in quel mare (se guardi bene riuscirai a vedere anche i miei capelli che spuntano in superficie ) proprio a causa dei Goto, che hanno intricato il flusso del tuo progetto.

Il Goto in sé non è dannoso; come un coltello può essere usato per tagliare il pane ma anche per uccidere, così era il Goto: se si fosse utilizzato poco, ad esempio al massimo un paio di volte in piccole routine, non sarebbe stato un problema ma, anzi, sarebbe stato utile. Proprio per il loro abuso da parte di molti programmatori in programmi non suddivisi in "piccole" parti è stato considerato dannoso.

Non conoscendo il tuo sw, l'unico consiglio che mi sento di darti è proprio quello di cercare di scomporlo in parti "di senso compiuto", che siano routine, funzioni o addirittura classi, se utile.

 

[udg]

@Gottrik Ciao, intervengo solo per una mia curiosità: nel calcolo balistico quali sono gli elementi di cui tieni conto? Immagino le forze di spinta e gravitazionale, ma non so se entra in gioco anche uno spin (non ne so nulla sull'argomento, ma credo che i proiettili vengano messi in rotazione sul loro asse longitudinale da scanalature nella canna per ottenere stabilità nel volo; è vero?) o altri elementi. Ragionando da profano assoluto potrei immaginare elementi come il vento, la densità dell'aria (o del fluido in cui si muove il proiettile), eventuali sollecitazioni sull'arma al momento dello sparo.
Ti ringrazio in anticipo per i chiarimenti.

udg

 

[LucaMs]

@Gottrik Ciao, intervengo solo per una mia curiosità: nel calcolo balistico quali sono gli elementi di cui tieni conto? Immagino le forze di spinta e gravitazionale, ma non so se entra in gioco anche uno spin (non ne so nulla sull'argomento, ma credo che i proiettili vengano messi in rotazione sul loro asse longitudinale da scanalature nella canna per ottenere stabilità nel volo; è vero?) o altri elementi. Ragionando da profano assoluto potrei immaginare elementi come il vento, la densità dell'aria (o del fluido in cui si muove il proiettile), eventuali sollecitazioni sull'arma al momento dello sparo.
Ti ringrazio in anticipo per i chiarimenti.

udg

Devi progettare un cannone con caratterstiche particolari?

 

[udg]

Devi progettare un cannone con caratterstiche particolari?

Non il genere di cannone che progetteresti tu..eheh

No, era davvero solo curiosità. Mi chiedevo quali fossero gli elementi di cui tengono conto nelle analisi balistiche.

 

[LucaMs]

@Gottrik Ciao, intervengo solo per una mia curiosità: nel calcolo balistico quali sono gli elementi di cui tieni conto? Immagino le forze di spinta e gravitazionale, ma non so se entra in gioco anche uno spin (non ne so nulla sull'argomento, ma credo che i proiettili vengano messi in rotazione sul loro asse longitudinale da scanalature nella canna per ottenere stabilità nel volo; è vero?) o altri elementi. Ragionando da profano assoluto potrei immaginare elementi come il vento, la densità dell'aria (o del fluido in cui si muove il proiettile), eventuali sollecitazioni sull'arma al momento dello sparo.
Ti ringrazio in anticipo per i chiarimenti.

udg

http://www.earmi.it/balistica/balest.htm

 

[udg]

Ohh, vedi che a cercare si trova sempre qualcosa di interessante? Invece dei soliti SELECT, view.witdh..etce tec un po' di fisica ed equazioni! Scrivendo il mio post pensavo proprio a quello, ma resta la curiosità di capire se nel programma da convertire di Gottrik c'è altro. Al peggio (se non è un segreto militare o d'ufficio) lo posta qui e ci divertiamo tutti insieme a convertirlo..con l'avvertenza che al quinto o sesto GOTO potremmo usare il proiettile contro di lui..eheh

 

[LucaMs]

Stai sprecando un talento... UDG!

Come se la Callas avesse usato la propria voce per vendere pesce al mercato!


Io farei ricerche su Google; questo è il primo sito (robetta) che ho trovato, ma ce ne saranno molti che potrebbero darti buoni consigli:

http://howwes.com/it/pages/820709

 

[Gottrik]

Per dare una mia risposta a "insoft" : io uso Autoscale e, anche se non risolvo completamente il problema, riesco a rimediare in parte agli inconvenienti causati dalle diverse caratteristiche degli schermi Android ( mando sempre qualche imprecazione ai produttori, purtroppo senza risultati, perché finora non è arrivato nessun "coccolone" ... ).

Per quanto riguarda la Balistica, LucaMs mi ha preceduto ... anch'io volevo consigliare a "udg" l'ottimo sito di Edoardo Mori.
Edoardo Mori è un magistrato molto bravo, ora in pensione, esperto di balistica ( teorica, pratica e forense ... ), uno che "non se la tira" e con le idee molto chiare.
Basterebbe leggere le critiche rivolte ai suoi ex-colleghi ... se fosse per me : "Edoardo for President ! ".

Per rispondere a "udg" :

La caduta 'verticale' e la deriva 'orizzontale' del proiettile dipendono dal 'tempo di volo' , cioè "per quanto tempo il proiettile rimane esposto alla forza di gravità ed alla spinta laterale del vento" ?

La deriva del vento si può calcolare, a patto di conoscerne esattamente la velocità ( costante ) e la direzione ( costante ).
Purtroppo ,in pratica, queste due grandezze non sono quasi mai costanti ...
Esiste anche la deriva orizzontale ( spin-drift ) causata dalla rotazione del proiettile sull'asse longitudinale ( effetto giroscopico stabilizzante ottenuto grazie alla rigatura della canna ).
La deriva "spin-drift" dipende quindi dal "passo di rigatura" e dalle caratteristiche del proiettile .

il "Tempo di volo" dipende dalla velocità iniziale del proiettile, dal "Coeff. Balistico" ( CB ) del proiettile, dalla densità dell'aria e ovviamente dalla distanza esistente tra l'arma ed il bersaglio.

Il CB ( che esprime la capacità di un proiettile di avanzare nell'aria ) dipende dal Cx ( coeff. aerodinamico ) e dalla Densità sezionale.

Il Cx è piuttosto difficile da rilevare perché dipende dal Numero di Mach, dal Numero di Reynolds, e dal 'Fattore di forma'(!).

Il Numero di Mach dipende dalla velocità del proiettile e dalla velocità del suono ( che a sua volta dipende dalla densità dell'aria ).

Il Numero di Reynolds dipende dal diametro del proiettile, dalla sua velocità, dalla densità dell'aria e dalla accelerazione di gravità ( spero di aver detto tutto ... boh ? )

Quanto sopra lascia intendere quanto siano importanti le condizioni ambientali sulla traiettoria dei proiettili ...

Il nocciolo del problema risiede quindi nel "Fattore di forma" che è rilevabile solo sperimentalmente e richiede accurati rilievi sperimentali su basi di misura a diverse distanze. Occorre anche tenere presente che la forma dei proiettili ha subito importanti modifiche nel corso degli anni, i proiettili moderni molto appuntiti e con la parte terminale "boat-tail" sono alquanto diversi dal "proiettile di riferimento" usato dai ricercatori della Krupp a fine '800 ... questo ha portato alla messa a punto di "curve di ritardazione" diverse da quelle usate nei decenni passati ( anche se poi la diversità si vede solo alle lunghissime distanze ).

Ma lasciamo perdere le lunghissime distanze perché altrimenti ci dobbiamo confrontare con il passaggio della velocità del proiettile da "supersonica" a " infrasonica" e qui le cose si complicano perché tutti i calcoli del CB possono risultare poco affidabili ( nella cosiddetta zona "transonica" ... )

La densità dell'aria dipende dalla sua temperatura, dalla sua umidità e dalla pressione atmosferica (assoluta )

In definitiva, l'osso duro sta nel "fattore di forma" ( tutte le altre grandezze sono misurabili ) e questo spiega perché importanti costruttori di proiettili ( vedi Sierra ) hanno ammesso di aver distribuito in passato valori dei CB non proprio affidabili ( chapeau alla Sierra ! ).

Negli ultimi anni i valori dei CB sono diventati come i consumi delle auto ... molti produttori "sparano" valori ottimistici che poi vengono disattesi nelle prove pratiche ...

Spero di aver detto almeno le cose più importanti, per me (che non sono uno specialista) non è facile riassumere in poche righe una materia così complessa e poi non dobbiamo togliere spazio alle domande relative alla programmazione Android, questo sito non è dedicato alla Balistica.

 

[LucaMs]

Molto interessante.

Manca un fattore, però: se fai in tempo a sparare prima che abbiano sparato a te

 

[Gottrik]

Nel mio ultimo scritto dico :

Il CB ( che esprime la capacità di un proiettile di avanzare nell'aria ) dipende dal Cx ( coeff. aerodinamico ) e dalla Densità sezionale.

Ho descritto come viene calcolato il Cx , ma ho dimenticato di dire come viene calcolata la Densità sezionale del proiettile:

La Densità Sezionale è definita da D = P / S dove P è il peso del proiettile ed S è la sua sezione (l'area frontale).

La Densità Sezionale D è una grandezza che rende l'idea di quanto un proiettile possa poi essere 'penetrante' ( nel bersaglio ... )

E' chiaro che una sfera di un kg lasciata cadere dall'altezza di un metro avrà una minore penetrazione nel terreno rispetto ad una barra di un kg avente una sezione frontale di pochi cm quadrati.

Ammesso però che la barra di un kg arrivi "di punta" ( ecco perché , al contrario della sfera che non ha bisogno della rigatura in canna, i proiettili cilindrici devono essere stabilizzati con una rotazione sull'asse longitudinale ... )

La barra , avendo una Densità Sezionale molto più grande, risulterà
sicuramente più 'penetrante' della sfera .

Saluti