| At line 1 added 72 lines |
| %%(display:none) |
| {{{ |
| WikiUp |
| }}} |
| /% |
| [{TableOfContents }]\\ |
| \\ |
| Ar.UP è un esempio di applicazione AR sviluppata in laboratorio che si interfaccia con il gestionale attraverso l'uso di £K48 (richieste REST).\\ |
| \\ |
| !! Overview\\ |
| \\ |
| App AR marker-based;\\ |
| Definiamo l'app marker based perché la sua interazione è basata sul riconoscimento di una immagine dallo streaming della camera, che permette di far "scattare" la magia AR.\\ |
| Una dettagliata spiegazione dei diversi tipi di AR comunemente in uso lo trovate ::DEC T(J1) P(URL) K(https://www.blippar.com/blog/2018/08/14/marker-based-markerless-or-location-based-ar-different-types-of-ar) D(qui)\\ |
| \\ |
| \\ |
| !! Stack tecnologico / Librerie\\ |
| \\ |
| React Native (RN) - scelta perchè permette di usare una sola codebase per le due principali piattaforme mobile, ma soprattutto per agganciare il discorso al secondo progetto che però affronteremo a tempo debito (ho in pratica sfruttato l'uso di RN per porre le basi, via fork, a quella che potrebbe essere la nuova app Sme.UP per fruire del gestionale su mobile).\\ |
| \\ |
| Su RN viene eseguito il codice nativo della piattaforma per le operazioni più avanzate, ma avendo un bridge che implementa in pieno JS in realtà ci sono anche soluzioni implementate 100% in JS. Per via della architettura di RN alcune operazioni in JS sono expensive e rallentano la UI (UI & JS vengono eseguiti sullo stesso thread, e sappiamo già che JS è single threaded, quindi è facile bloccarlo e causare i cosiddetti "FPS drops").\\ |
| \\ |
| Libererie RN (disponibili via npm, che è il package manager più usato per node e js):\\ |
| "react": "16.6.3" - segue le specifiche di react-native\\ |
| "react-native": "0.57.7" - l'ultima versione compatibile con react-viro\\ |
| "react-native-offline": "^4.2.0" - interceptor iOS e Android per individuare il cambio di rete (online, offline) https://github.com/rgommezz/react-native-offline\\ |
| "react-native-permissions": "^1.1.1" - permette di usare le API dei diversi sistemi operativi per individuare a runtime (ed in JS) i permessi concessi all'app, o richiederne di nuovi; in particolare su android una volta si usavano i file manifest, adesso è voluto che siano richiesti solo quando necessari e a runtime, spiegando bene all'utente a cosa ti servono (un po' come ha sempre fatto iOS).\\ |
| "react-native-vector-icons": "^6.3.0" - icon fonts vettoriali (fontawesome, etc)\\ |
| "react-navigation": "^3.1.2" - navigazione più comune in uso in RN, non è l'unica soluzione ma è quella mantenuta dalla community ufficiale\\ |
| "react-navigation-redux-helpers": "^2.0.9" - integrazione react-navigation e redux\\ |
| "react-native-gesture-handler": "^1.0.15" - dipendenza react-navigation, permette anche di individuare e gestire le touch gestures in modo semplice (in alternativa dovresti farlo con il panresponder\\ |
| "react-redux": "^6.0.0" - redux bindings per RN\\ |
| "redux": "^4.0.1" - redux\\ |
| "redux-actions": "^2.6.4" - permette di descrivere e creare azioni in redux come per flux, seguendo il pattern actions/reducers\\ |
| "redux-logger": "^3.0.6" - middleware per redux, per loggare le modifiche di stato\\ |
| "redux-thunk": "^2.3.0" - thunk per redux (le thunk sono funzioni che restituiscono una promise o una operazione pendente/deferred)\\ |
| Sfruttando il dinamismo di RN abbiamo usato:\\ |
| "react-viro": "^2.13.0" -\\ |
| che ci da un binding per ARKit e ARCore; avremmo potuto fare il modulo noi da zero, ma viste le risicate tempistiche e lo scopo dell'app ci siamo adattati.\\ |
| \\ |
| Viro supporta:\\ |
| AR: ARKit and ARCore\\ |
| VR: Cardboard (iOS and Android), Daydream and Gear VR\\ |
| \\ |
| I doc sono qui:\\ |
| [https://docs.viromedia.com/docs/]\\ |
| \\ |
| \\ |
| N.B. noi non siamo partiti dal loro esempio, ne usiamo il CLI che mettono a disposizione loro, perché limita l'app creata alla sola AR, mentre noi volevamo una base per farci sopra qualcosa in più usando quindi RN base;\\ |
| \\ |
| L'app AR.UP è sviluppata usando i Pods, quindi:\\ |
| \\ |
| - non si usa arup.xcodeproj\\ |
| - ma si usa arup.xcworkspace\\ |
| \\ |
| Questo è importante perché altrimenti non compila correttamente. Qui trovi di più sulla differenza tra i due progetti XCode:\\ |
| \\ |
| [https://stackoverflow.com/questions/21631313/xcode-project-vs-xcode-workspace-differences]\\ |
| \\ |
| Tra i documenti potrai annoverare sicuramente i componenti, ma il binding nativo che abbiamo fatto noi si discosta dalla documentazione: ho installato a mano i podfile e alcuni script per automatizzare processi e patch: purtroppo RN non è esente da bug\\ |
| \\ |
| [https://github.com/facebook/react-native/issues]\\ |
| \\ |
| \\ |
| Una cosa da tenere a mente, scegliendo tra nativo e RN: RN semplifica la vita usando componenti familiari ad uno sviluppatore che già conosce i pattern di programmazione reattiva ma aggiunge comunque un layer intermedio che può essere appunto sorgente di bug, oltre che di diverse limitazioni (è un tradeoff da valutare, ma oramai è così diffuso che rappresenta quasi uno standard di fatto). Per app canoniche dove esegui chiamate a API rest va benissimo essendo lo use case tipico in quei task è battle tested.\\ |
| \\ |
| N.B. ho in programma questo WE di fare cleanup perché ci sono cose che alla fine, per via delle scelte di progetto non abbiamo più usato, ma che ci servivano per il progetto che segue e sono state integrate;\\ |
| \\ |
| !! Risultato\\ |
| \\ |
| Se è stato eseguito tutto correttamente si ottiene una app eseguibile sui device nativi iOS e Android supportati (minSDK 26 android, iOS12+).\\ |
| N.B: i requisiti sono specificati non solo da React Native ma anche dalle librerie in uso, in particolare ARKit v2 richiede iOS 12.1\\ |
