Sviluppo di applicazioni mobili multipiattaforma [chiuso]


109

Vengono lanciate sempre più piattaforme mobili e gli sdk sono disponibili per gli sviluppatori. Sono disponibili varie piattaforme mobili: Android, iOS, Moblin, Windows mobile 7, RIM, symbian, bada, maemo ecc.

E la realizzazione di un'applicazione multipiattaforma è un problema per gli sviluppatori. Sto cercando cose comuni tra le piattaforme che aiuteranno gli sviluppatori che vogliono portare l'applicazione su tutte le piattaforme. Ad esempio quali sono le risoluzioni dello schermo diff, i metodi di input, il supporto open gl ecc. Per favore condividi i dettagli che conosci per qualsiasi piattaforma.

Oppure ci sono possibilità, scrivendo codice in html (tipo di oggetto) e caricandolo nell'applicazione nativa. Conosco l'androide, in cui possiamo aggiungere la visualizzazione Web all'applicazione chiamandosetContentView(view)

Si prega di condividere i dettagli della classe in cui possiamo aggiungere la visualizzazione html nell'applicazione nativa di diversi tipi di piattaforme che conosci.

Lo scopo di questo thread è condividere dettagli comuni tra gli sviluppatori. contrassegnare come wiki della comunità.

Strumenti e libreria multipiattaforma


1
Mentre ho trovato un thread interessante che è legato a questo, stackoverflow.com/questions/3326110/...
sohilv

un altro post bene su cross platform dev: stackoverflow.com/questions/51988/...
sohilv

1
Ha votato per chiuderlo come duplicato. Questo è troppo importante per essere suddiviso in due domande. stackoverflow.com/questions/51988/...
ripper234

1
Recentemente ho scritto
Anshu Dwibhashi

Risposte:


97

La mia risposta qui copre alcuni dei limiti tecnici degli strumenti cross-platfrom ma lasciatemi espandere un po ':

Penso che storicamente gli strumenti multipiattaforma siano sempre stati anche inutilizzabili perché tali strumenti hanno un focus filosofico sbagliato.

Tutti i punti di forza degli strumenti multipiattaforma sono i vantaggi che portano agli sviluppatori . Sono venduti con l'idea che consentono agli sviluppatori di scrivere una volta eseguito ovunque. Sono venduti con l'idea che consentono agli sviluppatori di espandere il loro mercato senza imparare nuove API. Sono venduti con l'idea che consentono agli sviluppatori di ridurre i costi e il time to market.

Ciò su cui NON vengono venduti gli strumenti cross-plaform è il vantaggio che portano agli utenti finali .

Il vantaggio per l'utente finale non è un punto di forza perché lo sviluppo multipiattaforma raramente è un vantaggio per l'utente finale. All'utente finale non interessa quanto lo sviluppatore abbia dovuto lavorare per portare il prodotto sul mercato. Né si preoccupano di quante piattaforme l'app può essere eseguita quando non usano ma una piattaforma. A loro interessa solo se l'app fa ciò di cui hanno bisogno sull'hardware su cui hanno bisogno per eseguirla. A meno che non abbiano una specifica esigenza di eseguire l'app su molte piattaforme diverse, il fatto che lo faccia non porta loro alcun valore.

Al contrario, gli inevitabili compromessi della creazione di un'API multipiattaforma significano che tutte le app create dall'API saranno al massimo di livello B su ogni piattaforma. Non saranno mai lo strumento migliore da utilizzare su ogni piattaforma.

Tutto ciò significa che nella maggior parte dei casi d'uso, gli strumenti multipiattaforma forniscono all'utente finale un prodotto inferiore rispetto a quelli realizzati con API specifiche della piattaforma. L'utente finale avrà sempre una scelta migliore.

Guadagni a lungo termine fornendo agli utenti finali gli strumenti più utili. Se non ti concentri filosoficamente sul rendere la vita dell'utente finale più facile e più produttiva, sei praticamente condannato fin dall'inizio. Gli utenti finali hanno molte scelte e se il tuo strumento non è tra i migliori, non ce la farai sul mercato.

Dovresti usare strumenti multipiattaforma solo se pensi che "gli utenti trarranno davvero vantaggio dall'esecuzione di questa app su molte piattaforme diverse". Se inizi a guardare gli strumenti multipiattaforma solo perché renderanno la tua vita (agli sviluppatori) più facile, allora li hai scelti per il motivo sbagliato e ti faranno più male di quanto non ti aiuteranno.


52
Ben meno lavoro (non necessario) per gli sviluppatori significa cicli di aggiornamento più rapidi, nuove funzionalità più veloci, correzioni di bug più veloci e così via. Con la stessa manodopera si può ottenere di più. Lo considero un vantaggio per l'utente finale.
schoetbi

10
In teoria, uno sviluppo più rapido potrebbe essere migliore per l'utente finale, ma questo non è il fondamento filosofico della maggior parte delle API multipiattaforma. Ho visto molti tentativi di utilizzare tali strumenti in molti ambienti e l'attenzione è sempre rivolta a rendere la vita dello sviluppatore più facile a scapito della qualità del prodotto finale. Inoltre, la promessa di una soluzione più rapida ed economica raramente si esaurisce. Sembra sempre che ci sia uno spettacolo che si ferma da qualche parte che mangia la maggior parte del tempo risparmiato.
TechZen

5
Per portare a casa il mio punto, considera questo: esistono API multipiattaforma per molte classi diverse di hardware e sistema operativo. Quante app multipiattaforma usi personalmente regolarmente? Quante app multipiattaforma hai mai usato a cui pensavi bene? Le persone hanno spinto le API multipiattaforma da quando erano più di una piattaforma, ma non hanno mai avuto successo da nessuna parte. Non riescono perché non producono le app più utili per gli utenti finali.
TechZen

4
@TechZen - Sto usando StackOverflow ora sul mio browser web e non vedo alcun motivo per cercare un client nativo. Penso che generalizzi troppo le tue affermazioni.
Youval Bronicki

4
Sono abbastanza sconvolto dal fatto che questo tipo di dibattito filosofico soggettivo ottenga il segno corretto su un sito Web tecnico. Quel che è peggio, la tesi di questo post non è valida per la maggior parte dei principali software che utilizziamo oggi: i browser Web sono multipiattaforma; Photoshop, MS Office, Dropbox e altri prodotti sono multipiattaforma; basta aprire il menu Start o il Finder ed elencare i tipi specifici della piattaforma: è probabile che la maggior parte si riveli un piccolo software di utilità. La tua argomentazione sarebbe valida se credi che i telefoni cellulari siano radicalmente diversi (un assunto altamente valido), ma sembra che non ci siano argomenti per costruire quella base.
kizzx2

14

Esistono diversi approcci allo sviluppo multipiattaforma su dispositivi mobili. Ovviamente hanno tutti dei limiti. Nessuna soluzione riesce a sfruttare tutte le funzionalità del dispositivo come può fare un'applicazione nativa.

Riutilizzo del codice

Sebbene tutti i sistemi operativi mobili non utilizzino lo stesso linguaggio di sviluppo e API, a volte è possibile condividere alcune classi o codice di livello logico.

C ++ ad esempio può probabilmente essere riutilizzato per un'applicazione iOS , per un'app Android utilizzando NDK , per un'app Symbian poiché sono sviluppate in C ++, ecc.

Alcune soluzioni offrono anche la possibilità di scrivere l'app in una lingua diversa da quella normalmente utilizzata dal dispositivo. I più famosi (anzi l'unico che conosco) sono commerciali e basati sul progetto Mono (sviluppo C #):

Ma non sono sicuro che possiamo davvero chiamare questo sviluppo multipiattaforma poiché il riutilizzo del codice è limitato a seconda del dispositivo:

  • Windows Phone 7 non consentirà lo sviluppo di codice nativo (forse in ulteriori aggiornamenti)
  • AFAIK il progetto mono like non esiste per tutte le piattaforme (ancora?) Bada, webOS, maemo, ecc.

E anche la parte dell'interfaccia utente rimane specifica per ogni dispositivo.

sviluppo web

Una risposta normale quando si chiede informazioni sullo sviluppo multipiattaforma per cellulari è lo sviluppo web. Avremmo quindi bisogno di un wrapper, che utilizzerà il browser mobile, per farlo sembrare e comportarsi come un'applicazione nativa. È così che parte del framework multipiattaforma che vedremo più avanti nel lavoro.

L'ascesa dell'HTML5 porta allo sviluppo web funzionalità che potevano essere realizzate solo con un'applicazione nativa come geolocalizzazione, applicazione offline, archiviazione locale.

Possiamo trovare sempre più framework per sviluppare applicazioni web per cellulari con un aspetto nativo sfruttando i più recenti standard web HTML5, CSS3, Js:

Ma HTML5 è ancora molto giovane e l'implementazione può variare da un browser all'altro. La maggior parte dei browser mobili predefiniti utilizza il motore WebKit (l'eccezione principale è Windows mobile / telefono che utilizza Internet Explorer) e anche così non supportano necessariamente le stesse funzionalità . Il database locale è ancora scomodo con cui lavorare e non possiamo essere sicuri di come verrà implementato dai diversi browser. Inoltre, anche con HTML5, lo sviluppo web è ancora molto limitato rispetto a un'app nativa. Non puoi accedere a contatti, fotocamera, accelerometro, ecc.

Modifica: all'inizio di questo mese il W3C ha fornito alcuni avvertimenti sull'evoluzione di HTML5: articolo di ZDNet

Quindi si adatta solo a una categoria limitata di applicazioni.

Framework multipiattaforma

E poi abbiamo i framework di applicazioni mobili multipiattaforma. Con il quale presumibilmente puoi sviluppare una volta e distribuire su piattaforme diverse. Queste soluzioni di solito si concentrano su iOS e Android e si basano sul motore WebKit. Offrono una maggiore interazione con le funzionalità del telefono durante lo sviluppo con le tecnologie web. I più noti sono Nitobi PhoneGap, RhoMobile Rhodes, Appcelerator Titanium. Ma molti altri sono là fuori e non tutti usano la stessa tecnica come MoSync che traduce il tuo codice nel proprio linguaggio intermedio prima di compilarlo per la piattaforma desiderata.

[1] Ricorda che Apple ha una politica speciale sulle app scritte per la loro piattaforma. Non sembrano bloccare queste app in questa data, ma è un'informazione che dovrebbe essere presa in considerazione. Modifica: Apple ha cambiato questa politica dal 9 settembre.


6

Si ottengono elementi in comune quando si distribuisce come webapp (html5 come menzionato sopra) ma per le app native ricche le API sono completamente diverse per i vari smartphone.

HTML5 può migliorare un po 'le cose, ma per fare cose interessanti devi diventare nativo.

Esistono framework per smartphone "multipiattaforma" come Phonegap, ma ho sentito parlare per lo più cose negative sull'utilizzo di esso per un lavoro "reale". (molte spese generali ecc.)


5

Sì, html5 sta ottenendo un po 'di attenzione. Dovresti anche esaminare questo consorzio e questa piattaforma in arrivo nel quarto trimestre. Non sono sicuro del successo di quel progetto, poiché sembra un'enorme sfida, ma ecco i dettagli:

Sito web: http://www.wholesaleappcommunity.com/default.aspx

Notizie: http://news.google.de/news/search?aq=f&pz=1&cf=all&ned=us&hl=en&q=%22Wholesale+Applications+Community%22

WAC mira a pubblicare le sue specifiche iniziali e i componenti del suo SDK per gli sviluppatori a novembre. Questa specifica sarà basata sugli standard W3C e creerà una solida piattaforma per lo sviluppo di ricche applicazioni web mobili. WAC fornirà anche la retrocompatibilità per i dispositivi basati sulle attuali specifiche JIL e BONDI. ( http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=31021 )

.

È una coalizione internazionale di circa 25 società di telecomunicazioni che mira a creare una piattaforma aperta a tutti gli sviluppatori e che vende a tutti gli utenti di telefoni cellulari. ( http://www.downloadsquad.com/2010/02/15/atandt-wholesale-applications-community-is-a-platform-not-an-app/ )


1

Per quanto ne so, la maggior parte di questi dispositivi è in grado di eseguire questo:

Java ME - la piattaforma applicativa più diffusa per dispositivi mobili

Penso che questo possa servire sia da buon esempio che da cattivo esempio.


In realtà, non c'è java su iPhone e, per quanto ne so, java me non funziona su Android
Alaa Nassef

Lo sviluppo di Android è in gran parte Java. developer.android.com/reference/java/net/package-summary.html
Nick Garvey

Non conosco i dettagli, ma Avian JVM consente a java di funzionare su dispositivi iOS.
Quazi Irfan
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.