Chi sviluppa con Titanium sa che in questo mondo – che poi è solo un sottoinsieme del mondo Javascript – c’è chi utilizza la command line e l’editor/ide di preferenza, e chi preferisce rimanere al calduccio utilizzando tutti e solo gli strumenti messi a disposizione da dalla casa-madre Appcelerator, ovvero Appcelerator Studio.
Appcelerator Studio in se non sarebbe troppo male, il problema è che una versione modificata (e neanche troppo bene) di Eclipse si porta quindi dietro la sua estensibilità ma anche la sua pesantezza. In più a volte ti si blocca mentre stai facendo operazioni banali come aggiungendo stringhe al file strings.xml
costringendoti a buttare giù tutto e facendoti perdere del lavoro (le bestemmie che ho tirato giù a causa di questo problema sono veramente tante).
A volte succede anche che l’integrazione con gli stessi servizi di Appcelerator smettano di funzionare, ed è noto come la recente impossibilità di fare build su iOS abbia seminato il caos e costretto molti a un utilizzo più consapevole della CLI.
Sublime? No, Atom
Buona parte dei migliori sviluppatori che conosco, e che hanno a che fare con Titanium, si affidano a Sublime Text, un editor (termine riduttivo) veramente veloce e ben fatto. Per Sublime ci sono plugin di ogni genere, e Titanium non fa eccezione:
https://github.com/AoDev/ti-alloy-in-sublime-text-2
https://github.com/MattTuttle/sublime-ti-build
A me però non va di pagare per utilizzare un editor non open-source, e il simpatico messaggio che compare sempre più spesso con cui invitano ad acquistare una licenza mi da abbastanza fastidio.
Chi non usa Sublime ha due grosse alternative: Atom e Visual Studio Code. L’editor di Microsoft (ancora in preview) è molto bello e funziona bene specialmente con linguaggi della galassia Microsoft (vedi Typescript), ma per il resto forse gli è preferibile Atom, giunto da poco alla versione 1.0 e con una miriade di plugins che aumentano e migliorano giorno dopo giorno.
Configurare Atom con il minimo necessario per sviluppare con Titanium
Scelta fatta. Per programmare in Javascript potenzialmente basterebbe un blocco note, e per fare le build con Titanium c’è la CLI, però magari utilizzare qualche aiuto potrebbe non essere una cattiva idea.
Per avere un minimo di auto-completamento ho installato questo plugin che funziona bene:
https://atom.io/packages/titanium-alloy
che ha anche un’integrazione con hyperclick:
https://atom.io/packages/hyperclick
Auto-completamenti e auto-formattazioni non mi hanno mai fatto impazzire, ma un check statico del codice in tempo reale che segnali eventuali imprecisioni ma anche errori e pratiche di cattiva programmazione mi è sempre piaciuto averlo, e su Appcelerator Studio i linter latitano o funzionano male. Un linter è prezioso nel mondo javascript specialmente quando si lavora in squadra, perché sebbene in questi casi si tenda a scrivere in modo simile spesso non lo si fa abbastanza.
In Atom non solo si può installare ESLint, ma si può creare un file di configurazione del linter per ogni progetto.
https://atom.io/packages/linter
https://atom.io/packages/linter-eslint
{ "globals": { "Ti": false, "Titanium": false, "Alloy": false, "$": false, "_": false, "L": false, "arguments": false, "require": false, "module": false, "exports": true, "OS_ANDROID": false, "OS_IOS": false, "ENV_PRODUCTION": false, "ENV_DEV": false, "setInterval": false, "clearInterval": false, "setTimeout": false, "clearTimeout": false, "alert": false, "describe": false, "it": false, "beforeEach": false, "afterEach": false }, "rules": { "strict": [2, "never"], "new-cap": [2, {"capIsNewExceptions": ["L"]}], "no-trailing-spaces": [1, { "skipBlankLines": true }], "space-infix-ops": [1, {"int32Hint": false}], "comma-spacing": [1, {"before": false, "after": true}], "key-spacing": [1, {"beforeColon": false, "afterColon": true}], "semi-spacing": [1, {"before": false, "after": true}], "dot-notation": 1, "no-underscore-dangle": 1, "no-unused-vars": 1, "no-multi-spaces": 1, "quotes": [1, "double"], "eol-last": 0, "no-alert": 0 } }
In “globals” si elencano le variabili globali, specificando anche se possono essere assegnate oppure no.
In “rules” si specificano le regole di validazione, indicando se eventuali infrazioni vanno segnalate in rosso come errori (con il 2) o in giallo come warnings (con l’1). Lo 0 le disabilita.
Qui sono elencate tutte le regole di validazione di ESLint.
Altri plugins utili per Atom
Di estensioni ce ne sono una marea, e ognuno ha le sue esigenze, ma finora che mi sono piaciute ce ne sono due in particolare.
Un terminale integrato:
https://atom.io/packages/Termrk
E un project-manager che facilita il passaggio da un progetto all’altro:
https://atom.io/packages/project-manager
Titanium CLI
Come tutti sanno dalla CLI si può fare tutto quello che si fa con Appcelerator Studio. In teoria.
Una cosa che da quanto ne so funziona su Studio ma non sulla CLI è il LiveView, o almeno a me funziona solo su Studio, quando funziona.
Per fare le build io nella mia quasi totale incapacità di scrivere per bash mi sono creato questo script, semplice ma abbastanza efficace. Non è gestito il –liveview perché tanto non funziona.
# The platform: ios or android PLATFORM=$1 if [ "$PLATFORM" == "" ]; then PLATFORM="android" fi # The target: device, simulator (ios) or emulator (android) TARGET=$2 if [ "$TARGET" == "" ]; then TARGET="device" fi # Y for choosing destination, N for the default CHOICE=$3 if [ "$CHOICE" == "" ]; then CHOICE="N" fi if [ "$CHOICE" == "Y" ]; then appc ti build --platform $PLATFORM --log-level debug --target $TARGET --skip-js-minify --device-id else appc ti build --platform $PLATFORM --log-level debug --target $TARGET --skip-js-minify fi
Per fare i deploy (ipa e apk) invece mi sono fatto questo script, forse anche più brutto del precedente:
SRC_PROJECT_NAME="My Project" DEST_FILE_NAME="MyProject" OUTPUT_DIR=~/Documents/$DEST_FILE_NAME ANDROID_OUTPUT_DIR=build/android/bin IOS_DIST_NAME="My company" IOS_DIST_UUID="................" mkdir -p $OUTPUT_DIR appc ti build --platform ios --build-only --force --log-level info --device-family ipad --target dist-adhoc --distribution-name $IOS_DIST_NAME --pp-uuid $IOS_DIST_UUID --output-dir $OUTPUT_DIR mv $OUTPUT_DIR"/$SRC_PROJECT_NAME.ipa" $OUTPUT_DIR"/$DEST_FILE_NAME.ipa" appc ti build --platform android --build-only --force --log-level info cp $ANDROID_OUTPUT_DIR"/$SRC_PROJECT_NAME.apk" $OUTPUT_DIR"/$DEST_FILE_NAME.apk"
Conclusioni
Appcelerator sembra sulla via del tramonto, opinione diffusa anche nella community. L’aumento di stabilità su Android negli ultimi mesi/anni è evidente e le prestazioni non sono malaccio, ma l’esperienza di sviluppo è pessima rispetto ad altre piattaforme, e il quasi totale abbandono della “gratuità” di sei mesi fa le hanno fatto fare dei passi indietro tra le preferenze degli sviluppatori.
Forse si riprenderanno o forse no, resta il fatto che iniziare a utilizzare con profitto strumenti più generici e utilizzabili anche in altri ambiti può non essere una cattiva idea.
Magari dobbiamo continuare a usare l’SDK di Titanium sui nostri progetti, ma fortunatamente (ancora) nessuno ci obbliga a utilizzare tutti gli strumenti di sviluppo di Appcelerator.