Colpo di #genio estremamente radicale per risolvere un annoso #problema: il creare una data #webapp, che non abbia bisogno di grande interattibilità (vedi un social network, o un CMS), senza dover mantenere 2 #codebase separate e quindi impazzire, facendola funzionare sia con un #server che totalmente senza… ossia, come unire in una sintesi circa accettabile i due maggiori paradigmi del #frontend? 🤔️
Quello antico, delle prime #piattaforme#web, dove il server genera tutto l’HTML e il browser lo visualizza com’è, spesso con (quasi) zero #JavaScript (vedi la Spacc BBS). 📦️
Quello moderno, dove nel #backend si espongono API (spesso JSON REST), e il fronte viene sviluppato a parte come app che gira totalmente lato #client, con il #browser che richiede pezzetti di dati e fa i suoi iperprocessamenti. 💱️
Ormai quello antico non si usa quasi mai per #progetti nuovi, perché gli svantaggi sono pesanti appena si vuole andare un po’ più in là: per tappare i buchi nel progetto medio si finirebbe a dover scrivere talmente tanto #codice#ClientSide, che a questo punto era meglio fare tutto nel secondo modo, senza menzionare i modelli e le #API da esporre nel server che altrimenti non si sarebbero implementati. Però, le webapp antiche girano bene anche sul computer tascabile meno performante (average Ximi), sui browser vecchi, e spesso sono le uniche che vanno quando tutto il resto ti lascia a piedi. D’altro canto però, anche se in teoria quella #app potrebbe funzionare #offline, magari mostrando dati cachabili, se è sviluppata in modo attaccato al server ecco allora che non si può fare nulla: muore il server, muore tutto. 💣️
Quindi la mia #idea paxxerella, dato che devo fare banalmente una #applicazione come frontend per un altro servizio già esistente, ma voglio i vantaggi appena millantati: sviluppare con i paradigmi #ServerSide in un framework JS adatto, che giri sia in Node che nel browser. A quanto pare, qualcuno ci ha pensato prima, e qualcosa di già fatto ho trovato (Express+FrontExpress, Koa+Koa-Client, Rill)… ma è tutta roba ormai abbandonata, che o non funziona (ho provato) o ha altre #rogne. Te pareva che trovavo mai qualcosa di buono già pronto… Però, in un quarto d’ora ho tirato su uno #script scheletrino, giusto per poter partire per questa via. ☠️
Ora che mi sto ricordando, almeno quelli #pubblici sto potendo importarli nel mio #lettore di #feed, tramite #RSSHub, che mi genera i documenti #RSS per qualunque #canale. 💬
Però… la media di #interfaccia di un #aggregatore non è granché adatta a consumare #post di quel tipo, spesso tanti e corti. E allora toh, in qualche quarto d’ora ho creato dei #tweak per la mia #istanza#FreshRSS, che tagliano di molto i pezzi inutili della #UI quando navigo nella mia cartella fatta apposta (mentre per tutte le altre fonti non c’è alcuna #modifica). 🖌️
Pro: ora ho il #software che mi permette di fare quello che mi serviva, per cui non avevo trovato altre soluzioni già fatte che fossero funzionanti. In realtà, l’idea iniziale era di fare una #app specifica per questa #dimostrazione, ma strada facendo ho deciso che avrei reso questa più semplice e generica, potenzialmente utilizzabile anche per altri usi, e avrei implementato parte della mia logica sul mio #server con qualcosa di più rapido. Quello che è uscito fuori ora è una piccolissima app che esegue codice #JavaScript fornito dall’utente e permette a questo di interfacciarsi con API native. 3 API al momento, lmao. Non so se nel tempo la espanderò o no, ora mi serviva appena questa poca roba, e la #UX è #grezza grezza perché non ho tempo. Il codice è quì (ma non è bello): https://gitlab.com/octtspacc/DroidScriptin. ☕️
Contro: la programmazione Android in sé, che è sempre un leggero incubo. Tuttavia, l’unica alternativa teoricamente (chissà praticamente!) viabile sarebbe stata fare un’app per Symbian o J2ME, che certamente non avrebbe semplificato le cose. Vabbé, anche per questo ho alla fine realizzato questa parte del mio progetto demo nel modo in cui ho detto. La cosa più strana attuale del codice? (Content Warning: 🤓️) Il fatto che io debba tenere una classe dedicata funzionalmente vuota per dichiarare l’uso di un BroadcastReceiver all’OS, anche se io nella pratica quello lo uso nella MainActivity, e non nella classe che specifico nel manifest per quel permesso (perché non riesco a mettere MainActivity lì). Ah, però questo per quanto non abbia senso, funziona. La cosa veramente più strana, invece, lo è perché non funziona: su #Android4.4 (mio target) la UI è a posto, mentre su #Android13 (che monta il mio #smartphone principale) manca la barra dell’activity, e quindi non c’è manco modo di accedere al menu… vabbè, il #programma deve funzionare sul #telefono#vecchio, e lì appunto va. 🎈️
Il bug che ho descritto sopra, a confronto screenshot del mio telefono con quello dell'emulatore Android 4.4.(Ma come farà ad accadere questo #bug? 😩️)Nel mezzo: ne ho approfittato per provare #Kotlin un pochino, che avevo sempre snobbato, e adesso me ne pento… di non avergli dato una chance prima. È molto più piacevole di #Java da usare, secondo me, sintassi estremamente più pulita e concisa. Kotlin compila in #bytecode#dalvik e in generale targetta la #JVM direttamente, quindi le #API sono quasi identiche a Java, e avendo usato quello non bisogna imparare quasi nulla di nuovo; sintassi a parte appunto, che però si impara semplicemente scrivendo, è esotica ma assolutamente non esoterica. 🧶️
E giustamente vi chiedete, a che mi serviva esattamente? Se rientra nell’essere un sano #WeekendProject come ho programmato ieri, allora domani lo saprete… per ora non faccio spoiler, oltre a dire che il mio #MicroBlog potrebbe ottenere una funzione che solo #Twitter aveva e solo nei primissimi anni, e ora è un concetto estinto. Non vi dico che leggendo il #SourceCode potete intuire, ma mai dire mai… 👁️