Skip to main content

Come forzare la chiusura (shutdown) di una App iOS in Objective C

Durante lo sviluppo di una app iOS non è insolito che si presenti la necessità di effettuare la chiusura forzata – in inglese, lo shutdown – dell’applicazione: parliamo, per intenderci, del classico pulsante Exit, presente nella maggior parte delle App Android ma generalmente non utilizzato in ambiente iOS, dove si preferisce mandare la App in background e lasciare che sia poi il sistema a gestirne il carico a livello di risorse.

In effetti il sistema iOS non sembra prevedere una funzione che consenta di ottenere in modo programmatico quello che in termine tecnico è noto come graceful shutdown, ovvero una chiusura che non provochi – o rischi di provocare – un vero e proprio crash dell’applicazione: il modo preferibile per “chiudere” una App è simulare la pressione del tasto Home, che provoca per l’appunto l’invio della stessa in background.

Approfondisci

Come aggiornare il proprio CocoaPod e vivere felici

CocoaPod è un framework meraviglioso ma, diciamocelo pure, sul piano della documentazione fa acqua da tutte le parti, nonostante gli sviluppatori abbiano dedicato un intero sito web alla guida all’uso. Cos’è che non funziona esattamente? Il linguaggio utilizzato, la sintassi proprietaria estremamente contorta, gli strumenti di comando altamente user-unfriendly, l’incapacità di fornire degli esempi reali… un pò tutte queste cose insieme, unite alla intrinseca difficoltà che molti sviluppatori incontrano nel mettere d’accordo ben tre realtà: l’ambiente di sviluppo XCode, il repository GitHub e, per l’appunto, l’interfaccia di comandi pod . Non c’è niente di complicato, intendiamoci: il problema è che, almeno nel mio caso, si tende a dimenticarsi sistematicamente cosa bisogna fare.

Per risolvere questo problema ho provato a buttare giù un mini-elenco di cose da fare: di certo farà risparmiare qualche minuto a me, magari anche ad altri.

  • Accendete il Mac (o fate partire la vostra macchina virtuale).
  • Effettuate un Pull del vostro progetto dal repository GitHub o BitBucket sul vostro repository locale, giusto per assicurarvi di acquisire ogni possibile cambiamento effettuato direttamente dal web (merge di qualche pull request che avete accettato, etc.).
  • Aprite il progetto con XCode e modificate il codice sorgente sui vostri file locali, effettuando zero, uno o più Commit sul vostro repository locale a seconda di come siete abituati a lavorare.
  • Quando siete pronti, la prima cosa da fare è aprire il file .podspec ed aggiornarlo incrementando la versione della libreria modificando il valore numerico del parametro   s.version , ad esempio da 1.11 a 1.12.
  • Effettuate un test della vostra nuova build lanciando un prompt dei comandi, navigando fino alla cartella principale del vostro Pod e digitando: pod lib lint
  • Effettuate un ultimo Commit sul vostro repository locale includendo tutti gli ultimi cambiamenti, ivi incluso il cambio di versione effettuato nel file .podspec.
  • Al termine del Commit, assegnate al suddetto un Tag identico al numero di versione – lo stesso che avete specificato nel parametro   s.version  (1.12 nel nostro esempio).
  • Effettuate un Sync/Push sul vostro repository GitHub.
  • Lanciate nuovamente un prompt dei comandi, recatevi nella cartella principale del vostro Pod e digitate: pod trunk push NAME.podspec

Bingo.

Se solo potessi ricordarmi tutto questo per più di 3 ore…

imageNamed non valido (e altri problemi con i resource files) dopo la creazione di un CocoaPod

Qualche giorno fa ho scritto un articolo per illustrare l’integrazione della mia libreria DownPicker su CocoaPods. Come diretta conseguenza del refactoring effettuato per rendere il codice compatibile con i requirements del dependency manager più usato dagli sviluppatori XCode,  alcuni utilizzatori della libreria mi hanno immediatamente fatto notare che la nuova versione, se installata tramite CocoaPods, non visualizzava più le immagini integrate, nonostante fossero presenti nelle directory /Assets/ , quest’ultima regolarmente inclusa nelle wildcard presenti nel percorso indicato come resource_bundle nel file .podspec relativo al progetto.

Il problema era legato al fatto che il codice non conteneva alcun riferimento al bundle in questione, continuando a cercare l’immagine nella cartella principale del progetto: una pratica che funziona benissimo per un componente esterno inserito manualmente all’interno di un progetto XCode, ma sostanzialmente inadatta per un CocoaPod.

La soluzione è stata molto semplice, è bastato aggiungere un riferimento al bundle relativo al progetto sfruttando un overload aggiuntivo del metodo imageNamed:

Inutile dire che la medesima soluzione si adatta a qualsiasi altro tipo di asset o resource file non trovato. Nel caso in cui siate alle prese con un problema simile, adesso sapete come fare.

Felice sviluppo!

 

DownPicker: una DropDownList / ComboBox per iOS e XCode scritta in Objective-C

Quick links: Project Page – GitHub – Pod

Presto o tardi, sviluppando con XCode per iOS, ci si scontra con la necessità di avere a disposizione un controllo che renda l’utente in grado di selezionare una singola opzione da un elenco a scomparsa. Si tratta di un elemento comune a tutte le UI principali, il cui nome è di solito DropDownList, ComboBox o qualcosa di simile e rispecchia l’aspetto, le funzionalità e le caratteristiche tipiche dell’elemento   <select>  in HTML.

Ad oggi iOS non è provvisto di un elemento di questo tipo: la cosa più simile ad esso è il controllo UIPickerView, che però ha caratteristiche estetiche e funzionali tali da non renderlo sempre utilizzabile nel modo che vogliamo. Tanto per cominciare è molto ingombrante, particolarità che lo rende inadatto a molte schermate di impostazioni dove lo spazio a disposizione è solitamente poco; inoltre, a differenza della sua controparte HTML, il suo aspetto è molto diverso dalle caselle di testo, sbilanciando così l’equilibrio dell’interfaccia utente e costringendo lo sviluppatore a soluzioni non sempre ottimali.

UIPickerView in action: not always pretty.
Il controllo UIPicker in azione: non sempre entusiasmante.

Al contrario, spesso abbiamo bisogno di un controllo leggero e poco invasivo,  in grado di fornire all’utente le informazioni necessarie a interagire per scegliere una opzione senza dover sacrificare una porzione considerevole dello schermo.

Con questo obiettivo in mente ho realizzato DownPicker, un controllo per XCode scritto in Objective-C che emula le caratteristiche estetiche e funzionali di una qualsiasi DropDownList/ComboBox utilizzando nel contempo l’interfaccia nativa di iOS: prevede infatti una UITextField che ha il compito di comunicare all’utente la necessità di effettuare un TAP (e, dopo la selezione, mostrare il risultato selezionato) e un controllo di tipo UIPickerView per gestire la selezione.

Approfondisci

Objective C: allineare una UIView all’interno di una Parent View senza utilizzare la Storyboard

Ho già avuto modo di parlare in un articolo precedente di come a volte sia necessario eliminare da codice i vincoli impostati a livello di Storyboard. In molti casi, una volta rimossi quei vincoli, è necessario impostarne di nuovi: per farlo direttamente da codice possiamo utilizzare il metodo addConstraint, che ci consente di impostare dei vincoli tra il posizionamento di un qualsiasi oggetto e quello di qualsiasi altro oggetto presente nella View.

Nella maggior parte dei casi conviene prendere come riferimento la Parent View del nostro oggetto: vediamo alcuni esempi.

Approfondisci

Close