Ho una classe thread in java e posso decidere che comportamente debba avere quel thread. Devo andare ad implementare io un sistema di ascoltatori o osservatori.
Un’opzione potrebbe essere andare a usare java.util.concurrent, per andare a capire come sono messi i threads.
In java abbiamo diversi metodi per andare a implementare il multithreading che sono più o meno complessi e che danno più o meno possibilità. I metodi visti ci danno interazioni sempre maggiori con i threads e task sottostanti. Pensiamo a swingworker è pensato per fare aggiornamenti dell’interfaccia grafica.
Problema: abbiamo due threads concorrenti che però accedono implementati come vediamo mi danno data race. Devo andare a sincronizzare il threads con la procedura synchronize, per evitare problematiche di data race ed accesso concorrente ai dati.
Che domanda ci poniamo prima di entrare in android? Abbiamo visto vari costrutti e classi, … questa roba c’è su android? Abbiamo thread, runnable, callable, future, timer task, future task, synchronized, locks & synchronized, ma non abbiamo SwingWorker, perché android ha il suo modo di disegnare elementi grafici sulla sua interfaccia.
Android mi consiglia di andare a usare corstrutti specifici di android, che al suo interno usa threads e tasks.
Consideriamo che ha senso parlare di threads non solo come UX, ma anche come esperienza d’uso.
Abbiamo il thread principale che ha in questo caso una serie di metodi.
E’ importante avere processi in background perché così rimane il sistema sempre operativo per l’utente.
Posso andare a configurare dei task che vengono eseguiti alla fine di un timer specifico e usiamo un handle per andare a comunicare con il main thread. Gli handler sono comodi per andare a creare un canale di comunicazione tra i vari task.
E’ interessante come possiamo andare a svegliare alcuni componenti solamente in caso di alcune condizioni che non derivano da eventi scatenati dall’utente, ma anche derivanti da altri fattori. Possiamo accorpare una serie di task per ottimizzare il consumo di batteria. Anche perché gestire i threads non è una cosa gratis, comunque consuma e io vorrei massimizzare la durata della batteria.
Ho una gestione dei job con classe e background:
Il problema principale è la gestione dei permessi. Il mio scheduler ha una serie di jobinfo che fanno partire le task a seconda di che cosa fa android manager. Il problema è che per esempio potrei non avere aggiornato correttamente i miei permessi. Discorso sempre legato ai concetti a runtime.
Da quando progetto il mio job e quando viene eseguito non è detto che io abbia ancora il permesso. E poi c’è anche una gestione dei permessi in background. Io in realtà devo fare un check e devo controllare che quei permessi ce li abbia e anche quando sto per lanciare l’effettivo task.