Microsoft, passi avanti per Project Islandwood
Il bridge per la conversione delle app iOS in app Windows 10 e Windows 10 Mobile è pronto ad arricchirsi con un nuovo web tool che semplificherà il lavoro degli sviluppatori.
di Salvatore Carrozzini pubblicata il 15 Gennaio 2016, alle 12:01 nel canale TelefoniaWindows PhoneiOSMicrosoft
Project Islandwood, nome in codice del bridge che consente di effettuare la conversione delle app iOS in app Windows 10 e Windows 10 Mobile, è considerato un'importante valvola di sfogo delle piattaforme della casa di Redmond, tenuto conto del fatto che ha le potenzialità per far crescere in maniera importante la quantità e la qualità delle app inserite nel Windows Store. Il progetto sta per entrare in una fase ancora più matura, consentendo, in concreto, agli sviluppatori iOS interessati di utilizzarlo in maniera efficace.
Il sito francese FraWin.com ha recentemente individuato un aggiornamento della pagina ufficiale dedicata al bridge che conferma il rilascio, nelle prossime settimane, di un web tool progettato per analizzare automaticamente le app iOS al fine di stabilire la compatibilità con il bridge iOS. Il tool è al momento in fase di test, ma gli sviluppatori interessati possono registrarsi sin da ora collegandosi al seguente indirizzo per essere tra i primi a provarlo. Microsoft, in questa fase, ha necessità di testare il tool e, per farlo, chiede ai developer iOS di inviare i file IPA.
Le finalità del nuovo web tool sono illustrate in maniera dettagliata dalla casa di Redmond:
Vogliamo rendere il più semplice possibile iniziare ad usare il bridge Windows per iOS. Nelle prossime settimane lanceremo un web tool che analizzerà automaticamente le vostre app per stabilire la compatibilità con il bridge e darvi i risultati corretti nel browser. Sarete in grado di stabilire esattamente quanto lavoro sarà necessario compiere per rendere disponibile la vostra app per Windows, insieme a suggerimenti, consigli e soluzioni per qualsiasi libreria che state utilizzando e non ancora supportata dal bridge.
Project Islandwood interessa marginalmente l'utenza consumer, quanto meno in maniera diretta, ma è facilmente intuibile l'impatto che potrà avere anche per gli utenti finali. Una delle critiche mosse in più occasioni al sistema operativo Windows 10 e Windows 10 Mobile riguarda, infatti, la qualità e la quantità delle app. Attingere all'esteso parco app dell'App Store rappresenta, indubbiamente, una strada utile per creare un'offerta ancor più ricca. Per completezza di informazione, si ricorda che il bridge di Microsoft permette di ottenere nuove app native Windows 10 e Windows 10 Mobile, non si tratta, in altri termini, di app eseguite in emulazione.
Project Islandwood è uno dei quattro bridge predisposti da Microsoft per epsandere i contenuti del Windows Store, gli altri tre coincidono con Project Westminster (conversione delle web app), Project Centennial (conversione di app .NET e Win32) e Project Astoria (coversione delle app Android). Dei quattro bridge solo Project Astoria è stato "messo in pausa", secondo recenti report.
15 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoChe dei quattro e' il piu' importante.
Il più importante è Islandwood perchè permette di creare app native.
Astoria è troppo pericoloso perchè necessita di un sottosistema Android e non produce app native, ma semplici conversioni.
Anche se in futuro funzionassero entrambi e si potesse partire da entrambi gli ecosistemi, sarebbe sempre auspicabile partire dalle app fatte per iOS.
Astoria è troppo pericoloso perchè necessita di un sottosistema Android e non produce app native, ma semplici conversioni.
Anche se in futuro funzionassero entrambi e si potesse partire da entrambi gli ecosistemi, sarebbe sempre auspicabile partire dalle app fatte per iOS.
esatto. speriamo di vederlo presto in opera e soprattutto di vederne i risultati.
Che le app arrivano convertendole da iOS o da Android a MS cosa cambia?
Da iOS è molto più facile perchè ha permessi è funzioni più simili a windows mobile.
Android invece ha funzioni che per windows non ci saranno mai (per esempio tutte le ui) altre che su quel sistema non hanno senso, inoltre ci sono grossi problemi di permessi che su android sono concessi e su windows no.
Probabilmente è anche per quello che da iOS converte l'app mentre da android la faceva girare in emulazione.
E poi ricordiamoci che Google ostacola in tutti i modi MS mentre Apple e MS sono come il gatto e la volte
concordo su tutto.
dal punto di vista della migrazione app, se accalappiano in modo efficace e veloce IOS, hanno già vinto.
paradossalmente non servirebbe nemmeno astoria (forse è pure per questo che l'hanno mollato).
Dissento
Astoria può dare vantaggi a breve termine, ma a lungo termine danneggia parecchio la piattaforma:
Gli sviluppatori Android che non vogliono portare le app su Windows avrebbero perdite dato che queste app arriverebbero comunque in modi illeciti, e non funzionando bene avrebbero un ritorno negativo sulla propria immagine
Gli sviluppatori Windows che negli ultimi 5 anni hanno investito in know how subirebbero la concorrenza di sviluppatori che possono fare l'app Android e Windows a costo minore
Danneggia gli utenti, perché le app Android girano peggio
Danneggia l'ecosistema perché in ottica multipiattaforma nessuno svilupperebbe per Windows, dato che puoi fare un'app che gira su entrambi
Danneggia Windows su desktop e tablet, le app Astoria girano solo su mobile, quelle Windows girerebbero anche su desktop e tablet
Islandwood è diverso: non consente né di eseguire app iOS né di portarle al 100%, bensì permette di scrivere app Windows usando codice pensato per iOS, addirittura puoi usare indistintamente all'interno della stessa app codice Objective-C/Cocoa e C++/XAML, o lavorare direttamente su Composition
Io credo che le app android richiedano troppi permessi e negarli ne pregiudica il funzionamento, accordarli pregiudica la sicurezza, permetterli in un ambiente emulato pregiudica le prestazioni e la stabilità.
probabilmente performance
OMFG! O_o
Ma quindi hanno "copiato" le API? Come hanno risolto? Cioé MS ha fatto un lavoro incredibile se funziona davvero...
Alla fine su iOS trovi sostanzialmente le stesse app su Android. Ciò che conta è portare le app su Windows Phone, e dunque basta un solo buon framework/tool allo scopo.
Ma quindi hanno "copiato" le API? Come hanno risolto? Cioé MS ha fatto un lavoro incredibile se funziona davvero...
allora, innanzitutto hanno aggiunto il supporto a Objective-C: non ho capito se tirando dentro clang o hanno semplicemente aggiunto un frontend per il compilatore di Visual C++, ma poco cambia
hanno inoltre aggiunto una projection di WinRT verso Objective-C: le projection sono il meccanismo che permette a WinRT di essere usato da linguaggi diversi... in questo modo si possono usare le API da Objective-C, ad esempio per mostrare una MessageDialog (i popup con i tasti Ok o Ok/Annulla per intenderci) puoi fare:
WUPMessageDialog *messageDialog = [WUPMessageDialog create];
[messageDialog showAsync:@"Hello!"]
WUP è un'abbreviazione di Windows.UI.Popups, il namespace dove si trova quella classe in C#e C++ (objective-c non ha i namespace)
hanno aggiunto anche una loro implementazione di Cocoa, Foundation e forse altre librerie iOS (quindi si, in un certo senso hanno copiato le API), quindi il codice scritto per iOS che usa quelle librerie funzionerà con poche modifiche o addirittura nessuna (ad esempio invece di usare una MessageDialog di windows potresti usare UIAlertView, che internamente userà MessageDialog probabilmente)
l'implementazione di Cocoa in particolare renderizza le interfacce direttamente sopra a Composition, che è il layer su cui si appoggia anche XAML (il sistema nativo per le interfacce nelle app Windows) e puoi anche mettere controlli insieme a controlli Cocoa, oltre a poter usare direttamente Composition (che serve per effetti grafici particolari o per avere prestazioni migliori/un minore consumo di risorse, un po' come CoreGraphics su iOS)
il tutto più o meno funziona, ovviamente ha ancora tanti bug e non tutte le API iOS sono state portate (inoltre è fermo a iOS 6 credo)
il progetto è open source su GitHub: https://github.com/Microsoft/WinObjC/
c'è anche un altro progetto simile di cui non ricordo il nome, gestito da Facebook e che è leggermente più avanti (l'app Facebook beta per 10 su PC è fatta con quello)
Android invece ha funzioni che per windows non ci saranno mai (per esempio tutte le ui) altre che su quel sistema non hanno senso, inoltre ci sono grossi problemi di permessi che su android sono concessi e su windows no.
Probabilmente è anche per quello che da iOS converte l'app mentre da android la faceva girare in emulazione.
Non credo che abbia a che fare con questo, credo che la scelta riguardi più come i program manager abbiano deciso di implementare i bridge per semplificare il loro lavoro.
Io credo che le app android richiedano troppi permessi e negarli ne pregiudica il funzionamento, accordarli pregiudica la sicurezza, permetterli in un ambiente emulato pregiudica le prestazioni e la stabilità.
Ufficialmente no perché non esiste nessuna dichiarazione che ufficializza che Microsoft abbia abbandonato Project Astoria.
L'univo commento ufficiale (almeno quello che conosco io) è la risposta di un portavoce di Microsoft ad una domanda esplicita di WindowsCentral.com su Project Astoria alla quale ha risposte che non sarebbe ancora pronto.
Ancora non ho avuto modo di guardare Islandwood quindi mi confermi che si tratta in pratica di una estensione delle language projections di WinRT che così ora oltre a supportare C#, C++ e Javascript supporta anche Objective-C.
Ora non so quanto hai giocato con Islandwood ma hanno anche mappato (almeno parzialmente) le API di iOS su quelle di Windows 10?
Su Project Astoria si hanno 0 informazioni tecniche, si è sempre parlato di un sottosistema Android ma non si è mai ben capito da cosa fosse costituito, anche per questo si tratterebbe di avere le language projections di WinRT per Java, (probabilmente) un mapper delle API che traducesse quelle di Android in quelle di Windows ed un JIT per compilare il bytecode Java o si trattava di un vero e proprio emulatore che porta con se il framework di Android (e magari vengono tradotte solo le chiamate ai servizi esterni)?
Perché non avrebbero usato approcci simili fra Objective-C e Java? Pensavano che sarebbe stato più semplice e veloce da rilasciare e rendere disponibile questa possibilità quanto prima agli sviluppatore? E se lo avessero usato un approccio simile all'Objective-C perché ci sarebbero questi presunti problemi prestazionali con le apps Android (tanto per dire W10 con il C# non sembra soffrire)? Microsoft non riesce a realizzare una VM Java decente o è che Java e le API di Android farebbero così schifo?
Ora non so quanto hai giocato con Islandwood ma hanno anche mappato (almeno parzialmente) le API di iOS su quelle di Windows 10?
si, sono delle projection come quelle per .NET, C++ e JavaScript tralaltro c'era anche un progetto per supportare C++ standard oltre a C++/CX, progetto adesso in mano a Microsoft stessa (http://moderncpp.com/)
non ci ho ancora fatto granché (ho provato ad installarlo un po' di tempo fa e guardato i sample e la documentazione, ma si, hanno mappato parte delle API di UIKit e Foundation... più tardi riprovo ad installarlo e faccio una prova
c'era un .wim con dentro l'intero filesystem di android e dei riferimenti ad hyper-v, ma non so se servivano solo per i loro test interni o effettivamente usavano in qualche modo hyper-v sul dispositivo
non c'era una vera e propria projection a quanto ho capito (dalla documentazione leaked), piuttosto credo ci fosse un "semplice" bridge basato su JNI e le app giravano su Dalvik, o almeno si identificava come esso (chissà come sarebbe andata usando qualcosa tipo IKVM + .NET Native?)
EDIT: ho ritrovato il link al cab che aggiungeva Astoria per la prima volta su W10M (quindi è una build molto vecchia): http://wp.ds.download.windowsupdate...189c48c46e9.cab
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".