Ecco gli strumenti messi a disposizione da Huawei per gli sviluppatori italiani

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/telefo...ani_86033.html

Entriamo maggiormente nel dettaglio dei contenuti del primo Huawei Developer Day italiano e vediamo quali strumenti vengono messi a disposizione degli sviluppatori. Sono un mattone fondamentale dello sforzo profuso da Huawei i programmi di training e supporto dedicati, come Huawei Codelabs

Click sul link per visualizzare la notizia.

[Sandro kensan]

Però nel precedente articolo c'era un commento molto interessante di un developer che voleva informarsi sulla fattibilità della portabilità della app della propria azienda dal mondo google al mondo huawei. Aveva partecipato alla conferenza proprio per scoprire se era fattibile il porting e ha fatto domande precise durante una conferenza in cui c'erano sviluppatori Huawei.

Il problema non era quello di fare una app ex novo con le chiamate ai servizi Huawei invece che a quelli google, sarebbe stata una cosa lunga ma semplice. Invece si voleva fare il porting, quindi quel che serviva era una modifica veloce dell'App dell'azienda dello sviluppatore e quindi una serie di wrapper tra i google services e gli huawei services. In pratica un wrapper per ogni chiamata con la manutenzione del wrapper fatta da Huawei in modo che l'esoso compito non ricadesse sull'azienda.

Bene, i programmatori Huawei sono coscienti del problema ma i vertici non stanno andando in questa direzione. Quindi la domanda è:

" svilupperanno e manuteneranno i wrapper tra i due mondi?"

[phmk]

Ma non l'ha fatto... peccato ..

[Unrealizer]

Originariamente inviato da Sandro kensan

Però nel precedente articolo c'era un commento molto interessante di un developer che voleva informarsi sulla fattibilità della portabilità della app della propria azienda dal mondo google al mondo huawei. Aveva partecipato alla conferenza proprio per scoprire se era fattibile il porting e ha fatto domande precise durante una conferenza in cui c'erano sviluppatori Huawei.

Il problema non era quello di fare una app ex novo con le chiamate ai servizi Huawei invece che a quelli google, sarebbe stata una cosa lunga ma semplice. Invece si voleva fare il porting, quindi quel che serviva era una modifica veloce dell'App dell'azienda dello sviluppatore e quindi una serie di wrapper tra i google services e gli huawei services. In pratica un wrapper per ogni chiamata con la manutenzione del wrapper fatta da Huawei in modo che l'esoso compito non ricadesse sull'azienda.

Bene, i programmatori Huawei sono coscienti del problema ma i vertici non stanno andando in questa direzione. Quindi la domanda è:

" svilupperanno e manuteneranno i wrapper tra i due mondi?"

Una piccola precisazione: il mio commento non riguardava questo, anzi questo è facile ed è giusto che venga gestito dagli sviluppatori delle app, e non è molto diverso da ciò che bisogna fare se si vuole supportare Amazon Fire o qualche distribuzione alternativa (tipo il progetto Astoria di Windows 10 Mobile, se fosse andato in porto o i defunti Nokia X), il problema è un altro.

Al momento se vuoi fare un'app Android hai fondamentalmente davanti due strade*: o fai un'app nativa in Java e/o Kotlin, o usi uno dei vari framework che ti permettono di riutilizzare una percentuale variabile di codice tra più piattaforme. I più famosi sono Xamarin (acquisita da Microsoft qualche anno fa), React Native (di Facebook), Flutter (di Google) e Cordova (Apache). Non ti saprei dire una percentuale, ma molte app ormai vengono scritte con una di queste tecnologie piuttosto che con l'SDK nativo.

Nel caso delle app Java/Kotlin è facile usare HMS: aggiungi il repository Maven, aggiungi una riga alla lista delle dipendenze e magicamente la libreria HMS è pronta e utilizzabile. Due minuti in totale e sei pronto.

Nel caso delle altre app, questi framework hanno bisogno di un po' di codice "collante" per poter utilizzare librerie native, che va scritto e soprattutto mantenuto, per poter gestire il passaggio tra il mondo Java in cui HMS vive e il mondo C#/JavaScript/Dart in cui gran parte dell'app vive.

Questo collante non è di per se difficile da scrivere, ma più è vasta la libreria che vuoi wrappare e più lungo/tedioso diventa il lavoro. Poi bisogna anche testarla e mantenerla aggiornata con le nuove release delle piattaforme.

Ora, nemmeno per GMS (e molte librerie famose) esistono wrapper ufficiali gestiti direttamente dagli autori delle librerie, ad esempio qui trovi il wrapper GMS per Xamarin, che appunto è mantenuto da Xamarin stessa (così come per AndroidX o molte altre librerie).

HMS però è un player piccolo rispetto a GMS, ci sono un miliardo di app per GMS (e/o distribuite su Play Store) contro un numero non pubblico ma sicuramente più piccolo di app per HMS/distribuite su AppGallery.

Pubblicare dei wrapper, anche di una sola parte di HMS, sui vari package manager (e open source su GitHub ovviamente) cambierebbe tantissimo le cose, attirerebbe anche molti sviluppatori per contribuire ai wrapper.

*: la stessa cosa vale per iOS, ovviamente con Objective-C e Swift al posto di Java e Kotlin

Originariamente inviato da phmk

Ma non l'ha fatto... peccato ..

L'ha fatto, ma non è bastato (a compensare il resto)

[Sandro kensan]

@unrealizer
Grazie della precisazione