In Windows 10 potranno girare le app Android e iOS rielaborate

Microsoft rilascia a sorpresa due SDK per il porting di app Android e iOS in ambiente Windows 10, accorciando di molto l''integrazione delle app nel proprio store rispetto a quanto accade oggi.
di Alessandro Bordin pubblicata il 29 Aprile 2015, alle 22:59 nel canale Sistemi OperativiMicrosoft
35 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoNo, la situazione è completamente diversa...
Microsoft ti fornisce un SDK per "rielaborare" le applicazioni Android e iOs e farle girare dentro Windows 10, sta allo sviluppatore dell'app decidere se implementare la sua applicazione o meno. Non centra nulla ne Apple ne Google, anche perchè quelle applicazioni non sono le loro...
Solo in questo modo si puo avere una vera concorrenza.
E' vero che le app sul Lumia sono brutte, ma non vuol dire niente, perche quando il telefono si diffondera' un pochino di piu le faranno.
Alcune sono gia buone, a mia madre gli ho presouna app per youtube che e' fatta bene per esempio.
Facebook e' veramente brutta, ma non e' giusto risolvere il problema copiando l'app di Iphone!
Dovrebbero fare una app fatta bene ricopiando lo stile di windows!
E non e' una questione di risorse, Facebook e' valutata miliardi di dollari e non hanno i soldi per mettersi a farla a modo?
Si tratta di pazientare.
Secondo me questo metodo / approccio e' sbagliato
Facebook in effetti è un pò scandalosa come società sul discorso app... ma del resto su Android esce una versione nuova al giorno. Mettono una novità e ne rovinano un'altra. Almeno fino a due mesi fa era così. Ora si è stabilizzato e l'app è molto buona
Però loro che hanno i soldi non dovrebbero avere di questi problemi
Microsoft ti fornisce un SDK per "rielaborare" le applicazioni Android e iOs e farle girare dentro Windows 10, sta allo sviluppatore dell'app decidere se implementare la sua applicazione o meno. Non centra nulla ne Apple ne Google, anche perchè quelle applicazioni non sono le loro...
Nel caso delle app per Android letteralmente si prende un .apk già compilato per Android
e lo si reimpacchetta dentro un .appx di Windows.
Questo perche nel S.O. hanno implementato un sottosistema Android quasi completo, con redirezione delle chiamate Linux al kernel Windows 10 e rimappatura delle Google API su servizi Microsoft (es: se l'.apk chiama una delle API di Google Maps, viene ridirezionata su uno stub che le converte per Bing Maps).
Naturalmente non tutto funziona perfettamente quindi in molti casi bisogna mettere mano ai sorgenti e ricompilare per ottenere un apk più "Windows Friendly".
Poi hanno fatto un implementazione parziale di ADB (Android Debug Bridge, usato per il debugging e come shell remota per altre operazioni di contorno).
Il problema è che è tutto "parziale": il target di riferimento è Android 4.4 KitKat ma come già scritto "non funziona proprio tutto" e pure le funzioni di debug "non sono proprio la stessa cosa" (implementazione parziale di ADB, come detto prima).
Nel caso di iOS hanno inserito un sottosistema che implementa [U]una parte[/U] delle API iOS
più precisamente "le più usate" (secondo Microsoft) ed Objective C è supportato direttamente da Visual Studio (cosa relativamente facile visto che per supportare Objective C basta un compilatore C ed un preprocessore ad hoc).
Anche qui i problemi sorgono sulle "parti mancanti" se vengono usate dalle app.
e lo si reimpacchetta dentro un .appx di Windows.
Questo perche nel S.O. hanno implementato un sottosistema Android quasi completo, con redirezione delle chiamate Linux al kernel Windows 10 e rimappatura delle Google API su servizi Microsoft (es: se l'.apk chiama una delle API di Google Maps, viene ridirezionata su uno stub che le converte per Bing Maps).
Naturalmente non tutto funziona perfettamente quindi in molti casi bisogna mettere mano ai sorgenti e ricompilare per ottenere un apk più "Windows Friendly".
Poi hanno fatto un implementazione parziale di ADB (Android Debug Bridge, usato per il debugging e come shell remota per altre operazioni di contorno).
Il problema è che è tutto "parziale": il target di riferimento è Android 4.4 KitKat ma come già scritto "non funziona proprio tutto" e pure le funzioni di debug "non sono proprio la stessa cosa" (implementazione parziale di ADB, come detto prima).
Nel caso di iOS hanno inserito un sottosistema che implementa [U]una parte[/U] delle API iOS
più precisamente "le più usate" (secondo Microsoft) ed Objective C è supportato direttamente da Visual Studio (cosa relativamente facile visto che per supportare Objective C basta un compilatore C ed un preprocessore ad hoc).
Anche qui i problemi sorgono sulle "parti mancanti" se vengono usate dalle app.
Ad esempio, gli sviluppatori di Facebook faranno prima a continuare lo sviluppo della loro mezza app di wp attuale o a metter mano a quella di Android o iOS partendo da QUELLA base li seppur necessitante di lavoro per l' adattamento di buon livello?
Inoltre nel sito che si chiama tipo apkmirror si vede che escono le app tutti i giorni.
Come è immaginabile che si prenda un apk e si lavori su quello?
La sensazione è che venga un casino totale, ai bug della versione Android ci aggiungeranno i bug della versione convertita.
Non è meglio che uno su Windows faccia la sua app usando Windows senza andare a fare casino?
Teoricamente credo che nel momento in cui lo sviluppatore di una determinata app fa la prima conversione FATTA BENE, a quel punto fare le altre per le versioni successive dovrebbe e più semplice... o magari è più facile apportare la modifica direttamente alla versione precedente già convertita per wp. o più semplicemente su WP verranno aggiornate una volta ogni tre mesi
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".