Mobile: Nativo vs. web - Input per la discussione a livello di top management [chiuso]

Ovviamente (vedi sotto) le web app sono in qualche modo più facili da implementare e hai solo bisogno di un'implementazione per tutti i tipi di dispositivi, mentre la programmazione nativa richiede alcune modifiche per diverse plaform. Tuttavia, ci sono un paio di motivi per cui gli utenti potrebbero preferire un'applicazione nativa su uno web:

• L'applicazione nativa funziona dove la copertura è scarsa.
• Gli utenti potrebbero non volere l'applicazione online durante il roaming; i prezzi di roaming sono ancora assurdamente alti in gran parte del mondo.
• In alcune parti del mondo, l'accesso a Internet mobile non è ancora esattamente economico anche nella rete domestica, anche se sta migliorando rapidamente.
• Le applicazioni Web non possono essere mostrate nel menu delle applicazioni su Android e forse anche su altre piattaforme (è possibile un segnalibro sullo schermo di casa).
• Le applicazioni Web non possono essere eseguite in background fornendo ad es. notifiche o sveglia al timer.

Ci sono comunque molti problemi se vuoi avere un'applicazione nativa su varie piattaforme. Dalla mia esperienza di prima mano:

• Android è probabilmente il più utile da avere. Il core può essere implementato in C o C ++ e potremmo ottenere tutte le librerie necessarie per compilare lì, ma è necessaria una colla Java. Entrambi Qt e SDL può essere utilizzato per ridurre la quantità di codice specifico della piattaforma. Non supporta MIDP (Java ME), ma supporta Java, quindi è anche un'opzione Java core con Java ME e Android UI.
• iOS (iPhone) è programmato in Objective C, ma quasi tutti i C ++ li compila bene. Ci sono Qt e SDL porte che possono ridurre la quantità di codice specifico della piattaforma. Usiamo SDL lì e abbiamo dovuto aggirare alcuni bug presenti. Permane ancora un po 'di lavoro nel porting. Java è non supportato.
• Windows Phone 7. Dimentica questa piattaforma. Non è possibile ottenere il codice C o C ++, solo .NET e non è supportato da nessun'altra parte. Abbiamo persino provato a chiedere a Microsoft suggerimenti su come effettuare il porting su Windows Phone 7 (attualmente abbiamo l'applicazione in esecuzione su Windows Mobile), ma non ho avuto una risposta utile. Con la minima quota di mercato che questo ha attualmente, non me ne preoccuperei.
• Bada è programmato in C ++, ma la toolchain è un po 'instabile, l'API non è simile a nient'altro e stiamo davvero lottando per risolvere tutte le sue carenze. Esiste una porta Qt , ma non so quanto siano lontane; Non ho ancora sentito parlare della porta SDL. Abbiamo un cliente specifico interessato a questo, altrimenti non sono sicuro se valga la pena.
• Symbian S60. È ancora comune, ma non è chiaro quale futuro abbia. La strategia di Nokia non è al momento chiara. Vendono ancora telefoni con S60, ma ne vendono anche alcuni con MeeGo e hanno annunciato che inizieranno a utilizzare Windows Phone 7. È una delle ultime piattaforme che ancora supporta MIDP. È anche ufficialmente supportato da Qt (Nokia lo ha portato lì quando l'hanno acquistato).
• MIDP / Java ME. La maggior parte delle nuove piattaforme non lo supportano comunque, l'integrazione della piattaforma è minima (cioè non può essere eseguita su sfondo, fornire notifiche ecc.) E le opzioni dell'interfaccia utente sono abissali.

Abbiamo impiegato circa 6 mesi uomo per far funzionare la nostra applicazione su ogni nuova piattaforma. Certo, è un'applicazione piuttosto complessa, ma d'altra parte ha una GUI personalizzata, quindi abbiamo solo bisogno di visualizzare un framebuffer e non ripetere tutte le finestre di dialogo. Quindi non contare con meno di 3 mesi uomo per qualcosa di non banale. Potresti ottenere di seguito con Qt (non lo usiamo (facciamo la GUI personalizzata, quindi non c'è molto da fare) e abbiamo iniziato a usare SDL troppo tardi, quindi non lo usiamo su alcune piattaforme dove potremmo farlo) , ma alcune delle porte sono ancora beta e alcune non esistono ancora. Non mi aspetto che si possa risolvere il problema con i vari browser per dispositivi mobili.

Infine, molte piattaforme supportano lo sviluppo in Flash, ma non ne ho esperienza. Ho esperienza con Flash su alcuni dispositivi embedded personalizzati e non era troppo piacevole (ma aveva un driver di visualizzazione OpenGL personalizzato e avevano qualche problema nel porting del player, quindi abbiamo finito per fare un bel po 'di ottimizzazione delle prestazioni) . Potrebbe essere un'opzione per qualcosa di semplice però.

Alla fine, dovresti prima definire i tuoi requisiti, avere qualcuno che guardi le opzioni e fare delle stime (significa dedicare alcune settimane a questo!) e solo discuterne a livello di top management. Il top management non può prendere una decisione ragionevole senza numeri che siano almeno nella giusta area di gioco.

Dove Jan Hudec fornisce una panoramica piuttosto dettagliata / operativa sull'argomento, mi chiedo se questo è ciò che stai cercando al massimo livello di gestione, indipendentemente dai requisiti?

Forse altri fattori entrano in gioco, come il time to market (le app web dovrebbero essere molto più veloci rispetto allo sviluppo per un certo numero di piattaforme), il set di competenze richiesto (standard web tech vs java obiettivo c ecc.), costi di manutenzione e così via.

Stiamo adottando un approccio per app Web mobile e facendo uso di jquery-mobile.

Semplicemente dimezza lo sviluppo per noi in quanto non dovremo sviluppare separatamente le due piattaforme principali (Android e iOS). Ciò significa che non dobbiamo preoccuparci delle "stranezze del browser" mentre il team di jquery le gestisce.

Inoltre, siamo già esperti con javascript e jquery.

Potremmo anche creare un'app molto semplice per ogni piattaforma che apre semplicemente il sito web mobile.