Italian Chiusura Activity

Sberla

Active Member
Licensed User
Longtime User
Salve ragazzi, vorrei capire una cosa: Ma quando faccio Activity.Finish l'activity viene distrutta e quandi se la richiamo con StartActivity la ricrea chiamando l'evento create?

Ho messo nella Sub Activity_Create "If FirstTime=True Then" di crearmi tutti gli oggetti di quell'activity, altrimenti mi setta solo i valori degli oggetti creati.

L'ho fatto in questo modo per far andare l'app più veloce senza far creare ogni volta nel resume gli oggetti per poi popolarli.

Ho notato però che anche mettendo in Activity_Pause il metodo Activity.Finish, riaprendo quell'Activity non passa più nel If FirstTime=True.

Significa che il metodo .Finish non distrugge l'activity?
 

LucaMs

Expert
Licensed User
Longtime User
Quella che segue è una nota che avevo scritto dopo qualche test.

L'avevo scritta per me stesso, spero sia chiara e senza errori
----------------------------------------------------------------

Ciclo vita actiivties.

Se si esce da un'activity tramite il tasto back, l'activity va solo in pausa, per cui, richiamata nuovamente dall'activity "precedente", sarà subito eseguita la Resume, non la Create con first time = False.

Se invece si usa Activity.Finish e poi si richiama, sempre dalla "precedente", verrà avviata la Create con FirstTime = False! Ciò significa che FirstTime sarà True solo al "primo avvio" dell'App (da notare che l'app va chiusa per bene, altrimenti, al riavvio, non solo potrebbe non avviarsi per prima la Main, ma per tutte le Activity aperte nella "sessione precedente" FirstTime sarà False! Quindi, chiudere l'app con ExitApplication dopo aver fermato tutti gli eventuali servizi ed infine il servizio Starter).
 

udg

Expert
Licensed User
Longtime User
La questione FirstTime dipende dal processo. Quando esegui per la prima volta (dall'accensione) il programma, questi attiva un processo in cui esegue Starter e l'activity Main (che risulta quidi avere FirstTime=True). Quando esci dall'app, finchè il processo non viene terminato da Android, se la rilanci avrai FirstTime=False.
Un modo per forzare la chiusura di un processo è quello di eliminare l'app dalla lista delle app recenti, ma ci sono vari post che suggeriscono come il comportamento di Android sia cambiato nel tempo passando da una versione all'altra.
Vale certamente l'indicazione di @LucaMs su ExitApplication, ma ricordando anche che Erel in genere ne sconsiglia l'uso se non in casi particolari.

Personalmente cerco di evitare del tutto di affidarmi allo stato di FirstTime..soprattutto ora che abbiamo il service Starter.
 

Star-Dust

Expert
Licensed User
Longtime User
Che serve il service Starter? Io lo tolgo sempre

Perché si sconsiglia ExitApplication?
 

udg

Expert
Licensed User
Longtime User
Ciao. Leggi qui.
In realtà è una vera manna dal cielo. Hai un servizio che viene attivato sempre e certamente per primo. Il posto ideale dove inizializzare componenti.
Ultimamente Erel lo ha indicato anche come luogo preferenziale per contenere le varie sub di interazione con un DB (personalmente preferisco l'approccio di Cableguy, ovvero di avere un modulo dedicato al DB).
Ad ogni modo, inizia a concentrare in Starter inizializzazioni come il formato di data e ora, le liste e qualche variabile globale..vedrai che man mano che lo utilizzi lo troverai sempre più comodo.
 

Star-Dust

Expert
Licensed User
Longtime User
Io per le iterazioni con un DB e le varie inizializzazioni creo una #Region che contiene tutto
 

udg

Expert
Licensed User
Longtime User
Dicevo di utilizzare Starter per chiamare la sub che inizializza l'accesso al DB o che esegue funzioni preliminari tipo una serie di ALTER TABLE per allineare il DB locale ad eventuali modifiche al codice o cose del genere. Il tutto senza doversi affidare al FirstTime di Main o all'intervento dell'utente tramite UI (es. un tasto).

Come dicevo, anche io preferisco avere il codice relativo al DB ben separato dal resto e le Region mi sono molto utili anche per distinguere ciò che agisce su una tabella da ciò che utilizzo per un'altra o altri contesti in cui un raggruppamento logico di funzioni mi facilita la manutenzione.
 
Last edited:

Star-Dust

Expert
Licensed User
Longtime User
Si avevo capito. Io fino ad oggi ho raggruppato tutto dentro una regione come nell'esempio sotto

B4X:
Sub Activity_Create(FirstTime As Boolean)
if FirstTime then
    VerificaSQL
    ImpostazioniIniziali

    End if
End Sub


#Region Inizializzazioni
  Sub VerificaSQL
   'Verifica Esistenza sql
   'Inizilizza DB
   ' ALTER Campi ecc..
  End Sub

   Sub ImpostazioniIniziali
   End Sub

   Sub LetturaDB(Tabella as String, Campo as Strimg, Filtro as String) as string

   End Sub

   Sub ScritturaDB(Tabella as String, Campo as Strimg, ID as String) as string

   End Sub
#End Region

Però voglio provare il ServiceStarter, vediamo ...

Solo che per chiamare una funzione o metodo non si dovrà poi chiamare ServiceStarter.FunzioneDB(parametri) ????
 

LucaMs

Expert
Licensed User
Longtime User
un servizio che viene attivato sempre e certamente per primo
finchè il processo non viene terminato da Android
ExitApplication, ma ricordando anche che Erel in genere ne sconsiglia l'uso
La prima affermazione è vera solo se è vera la seconda, ovvero se il processo NEL FRATTEMPO sia stato terminato "da Android"; e chi sa se e quando Android lo farà?
Io preferisco fare "all'antica", il mio sw, quindi su qualunque Sistema, lo chiude l'utente, non pincopallino; ecco perché non concordo con la terza affermazione.

Certo, se l'app è in background potrebbe capitare che Android chiuda il processo (e quindi lo Starter è utile) ma generalmente non dovrebbe farlo e comunque non mi pare una cosa "sana" lasciarlo aperto fino al momento random in cui sia il S.O. a chiuderlo.

Considera il caso, non penso raro, in cui un utente utilizzi la tua app, ad un certo punto, scontento del risultato ottenuto, voglia chiudere e ricominciare da zero: che fà? Preme Esc e poi attende speranzoso che Android elimini il processo per poi poter riavviare l'app senza conservare i valori delle variabili e quindi ripartendo dall'inizializzazione?
 
Last edited:

Star-Dust

Expert
Licensed User
Longtime User
Su questa cosa c'è molta confusione, spesso non si capisce quando Android andrà di nuovo su Activity_Create e quando su resume.

Ho un App, una delle mie prime, che a volte mettendola in background riparte dall'inizio altre volte da dove l'hai lasciata ....boh

P.S. Luca ma a quest'ora ancora qua?
 

Star-Dust

Expert
Licensed User
Longtime User
 

LucaMs

Expert
Licensed User
Longtime User
non si capisce quando Android andrà di nuovo su Activity_Create e quando su resume
La Create verrà avviata o soltanto la prima volta che l'Activity sarà utilizzata oppure se sia stata chiusa usando Activity.Finish.

All'epoca (in cui scrissi quella nota per me stesso, post #2) sviluppai questo progetto di prova, che ritengo utile per chiudere l'app.
Ha un inconveniente: una libreria usata dal progetto potrebbe mantenere avviato un proprio servizio. Chiesi ad Erel se ci sia un modo per verificare da codice ma, come sospettavo, non è possibile; è sufficiente però testare il progetto e verificare direttamente, nel dispositivo.

Allego il progetto.
 

Attachments

  • AppLife.zip
    10.8 KB · Views: 306

Star-Dust

Expert
Licensed User
Longtime User
In teoria è così .... In pratica , la mia App in StandBy c'è quando va in resume e quando riparte dal Create...

Me ne sono fatto una ragione
 

udg

Expert
Licensed User
Longtime User
Concordo con voi. Pensare al/alla garbage collection mi fa venire l'orticaria..
in altri ambienti hai funzioni per allocare e deallocare memoria esplicitamente. Se sai fare il tuo mestiere tutto fila liscio.
qui siamo alla "fai come vuoi ed incrocia le dita tanto poi ci pensano android e le quantità spropositate di ram dei device".
Sbattersi per rendere efficiente un programna? E perché mai? Meglio usare il tempo per cercare un font accativante, un tema "glamour" , una musichetta "figa". E qualche effetto di animazione no? Ma si, tutto fa brodo. Che vuoi che importi all'utonto dei leaks, del db disegnato a dovere e del codice che compila in kb invece di gb. Tanto dopo qualche settimana esce la nuova versione o passa ad un altro sw!

lavorare male ma lavorare in fretta..l'informatica degli anni 2000.
 

Star-Dust

Expert
Licensed User
Longtime User
Produciamo le App che la gente cerca.

Non ci possiamo permettere di sviluppare quello che è meglio o che piace a noi.

Altrimenti sarebbe una passione non un mestiere.

Per antonomasia il mestiere deve fare schifo
 
Reactions: udg

Star-Dust

Expert
Licensed User
Longtime User
PS le mie peggiori App sono le più scaricate
 

udg

Expert
Licensed User
Longtime User
le mie peggiori App sono le più scaricate

Direi che sia un trend assoluto e la tua osservazione lo conferma.
C'è roba davvero senza senso che ottiene milioni di download e successo tale da poter acquistare spazi pubblicitari televisivi, mentre oggetti ben più seri prendono polvere magari in un cellulare dimenticato e ormai sostituito da uno più recente o non vengono neanche trovati in fase di ricerca.

Sin dall'inizio io ho evitato il mercato e quindi il PlayStore. Per divertimento ho prodotto mini-app con lo scopo di imparare e testare nuove funzionalità, ma quelle vere sono state tutte a richiesta e distribuite direttamente. Fissate le specifiche, prodotta l'app e poi addio (a meno di manutenzione o sistemi basati su erogazione di servizi).
Non c'è da "fare i milioni" ma neanche da stare dietro ai capricci degli "scaricatori seriali" che, per di più, pretendono tutto gratis, subito e ognuno in base alle proprie preferenze!
 

Star-Dust

Expert
Licensed User
Longtime User
Io non ho molto da scegliere, distribuisco solo da Play Store.

A proposito, visto che le peggiori idee hanno il miglior successo, non avete qualche brutta idea? Ma di quelle orribili?

Grazie
 

udg

Expert
Licensed User
Longtime User
Pensa a qualcosa di veramente inutile e vedrai che avrà un gran successo. Negli U.S.A. funziona, in Italia credo molto meno..
 
Cookies are required to use this site. You must accept them to continue using the site. Learn more…