Microsoft, passi avanti per Project Islandwood

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 pubblicata il , alle 12:01 nel canale Telefonia
Windows 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 - info
s0nnyd3marco15 Gennaio 2016, 12:06 #1
Dei quattro bridge solo Project Astoria è stato "messo in pausa", secondo recenti report.


Che dei quattro e' il piu' importante.
Marok15 Gennaio 2016, 12:28 #2
Originariamente inviato da: s0nnyd3marco
Che 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.
devilred15 Gennaio 2016, 12:47 #3
Originariamente inviato da: Marok
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.


esatto. speriamo di vederlo presto in opera e soprattutto di vederne i risultati.
igiolo15 Gennaio 2016, 13:14 #4
Originariamente inviato da: Bivvoz
E perchè?
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).
Unrealizer15 Gennaio 2016, 14:50 #5
Originariamente inviato da: s0nnyd3marco
Che dei quattro e' il piu' importante.


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

Originariamente inviato da: Bivvoz
Perchè hanno mollato astoria probabilmente non lo sapremo mai con certezza, ufficialmente per motivi di sicurezza.
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
Pino9015 Gennaio 2016, 15:51 #6
Originariamente inviato da: Unrealizer
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


OMFG! O_o

Ma quindi hanno "copiato" le API? Come hanno risolto? Cioé MS ha fatto un lavoro incredibile se funziona davvero...
cdimauro15 Gennaio 2016, 16:29 #7
Ed è la soluzione migliore. Project Astoria non doveva nemmeno nascere: tante risorse buttate via.

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.
Unrealizer15 Gennaio 2016, 17:02 #8
Originariamente inviato da: Pino90
OMFG! O_o

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)
damxxx15 Gennaio 2016, 17:16 #9
Originariamente inviato da: Bivvoz
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.

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.

Originariamente inviato da: Bivvoz
Perchè hanno mollato astoria probabilmente non lo sapremo mai con certezza, ufficialmente per motivi di sicurezza.
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.


Originariamente inviato da: Unrealizer
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


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?
Unrealizer18 Gennaio 2016, 10:43 #10
Originariamente inviato da: damxxx
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?


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

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


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

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)?


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".

La discussione è consultabile anche qui, sul forum.
 
^