Google presenta Android Things, il "nuovo" OS per IoT | Dev Preview

13 Dicembre 2016 83

Google ha appena annunciato una Developer Preview di Android Things, un rebrand di Project Brillo, il programma di sviluppo IoT basato su Android lanciato l'anno scorso. Un nuovo nome che ha molto più senso, in un ecosistema in cui figurano anche Android TV, Android Wear e Android Auto.

Android Things si configura come un pacchetto di risorse che permettono di iniziare subito a sviluppare il proprio device IoT. Ciò significa prendere il solito pacchetto di strumenti di sviluppo - Android Studio, l'SDK ufficiale e i Google Play Service e applicarli a device di classe IoT.

A livello hardware saranno supportate direttamente diverse development board, tra cui Raspberry Pi 3 (ecco spiegata la comparsa del device nei repo dell'AOSP), Intel Edison e NXP Pico. Una novità molto interessante è che Google pianifica di gestire in prima persona gli aggiornamenti software per i dispositivi, come viene con Android Wear.

Secondo l'annuncio ufficiale, nei prossimi mesi le future Dev Preview includeranno una struttura che permetterà agli sviluppatori di inviare ai dispositivi patch di sicurezza, aggiornamenti del sistema operativo e i propri aggiornamenti personalizzati.

Anche il protocollo di comunicazione dei device Weave riceve alcune novità: per cominciare è stato rilasciato un SDK pubblico, poi c'è una nuova console di gestione e l'integrazione con Google Assistant. Al momento l'SDK include schemi per lampadine smart, prese e interruttori smart e termostati. In futuro arriveranno molte nuove classi di device, oltre che l'integrazione di Nest Weave e Google Weave.

Maggiori dettagli per sviluppatori sono disponibili al nuovo sito di Android Things. Le Dev Preview per i tre device elencati sopra sono già disponibili al download.

Tanta memoria interna e ottimo hardware a prezzo conveniente? Honor View 10 Lite è in offerta oggi su a 244 euro.

83

Commenti

Regolamento Commentando dichiaro di aver letto il regolamento e di essere a conoscenza delle informazioni e norme che regolano le discussioni sul sito. Clicca per info.
Caricamento in corso. Per commentare attendere...
ale

Se qualcuno usa male le eccezioni, non è colpa sua... se un eccezione è prevista come checked, vuol dire che può verificarsi, e va gestita. Poi ci sono le eccezioni unckecked tipo OutOfBoundsException, ArgumentException, che puoi gestire opzionalmente. Esiste anche l'OutOfMemoryError, ma dubito che ti metta ogni volta che fai una new a controllare se hai memoria... anche perché, realisticamente, finirai mai la memoria ? Considerando che se mai usi lo swap insomma...penso non accada mai un eccezione del genere, e se proprio accade, penso che l'OS killerebbe lui prima la tua applicazione perché deve tenersi della memoria comunque per far funzionare il sistema...

Le parecchie classi (2 per leggere un file di testo, non 10 eh) per l'IO che non sono poi tanto un abuso, se capisci come funzionano, puoi benissimo pensarlo come un sistema "a scatole", o a livelli, hai un FilerRader, che ti mette a disposizione un accesso a basso livello, allora usi un BufferedReader che ti consente un accesso a più alto livello, e così via... il bello è che questo è un approccio modulare, perché il BufferedReader è lo stesso e funziona allo stesso modo che tu legga da un file, dalla console, da un socket di rete, insomma... riutilizzo di oggetti, uno dei pilastri della programmazione ad oggetti. Sebbene avessero potuto fare un BufferedFileReader, non lo hanno fatto, metti insieme due oggetti e lo hai.

Si ho capito cosa intendi per le chiamate con keyword arguments, sfortunatamente Java non le ha, anche se IntelliJ dall'ultima versione ti mostra lui il nome del parametro quando scrivi il codice. Però c'è anche da dire che un buon codice Java non dovrebbe avere metodi con più di 2/3 parametri, quindi non troppo necessario, servono più in python avendo una filosofia non strettamente OOP

Gabriele Di Bari

1- Partiamo dal fondo:
"La gestione esplicita delle eccezioni, è necessaria, per scrivere programmi sicuri"
Non è sempre necessaria, inoltre l'obbligo si traduce in java in parti di codice di questo tipo:
[like-Java]
{
qualcora
try{ qualcosa = roba insicura }catch(Exception e){ /* il nulla */ }
return qualcosa;
}
Con il risultato di avere codice brutto e comunque insicuro.
Sensa contare che ti affidi sempre al codice di terzi, se qualcuno non ha previsto un tipo di eccezione sono cazzi.

Ad esempio, una cosa che mi ha sempre stupito a suo tempo, è che in Java l'operatore "new" non lancia eccezioni (in C# può lanciare OutOfMemoryException, mentre C++ può lanciare bad_alloc).
Il che è moltro strano, ipotizza che stia scrivendo un'applicazione simile a photoshop, con il rischio che un allocazione fallisca perché troppo grossa, Java che fà?
Beh ad esempio su android la VM da:
"AndroidRuntime(17712): FATAL EXCEPTION: AsyncTask"
E addio Applicazione.

2- Java è il primo linguaggio che viene in mente quando si parla di abuso di OOP.
Potrei citare i casi in cui si può parlare espressamente di abuso, mi vengono in mente parecchie classi per I/O, ma basta averle usate per capirlo.

3- Le chiamate alla python, in Obj-C si intende che supportano i "keyword arguments" ovverro Persona(nome = "mario").
Ovviamente vi sono sintassi differenti.

ale

Beh simile a python non proprio, in python i metodi li chiami esattamente come in Java, o in C#, oggetto.metodo(), i parametri li puoi specificare con argomenti posizionali, o per nome, puoi avere anche argomenti opzionali, valori di default, insomma, molto fatto bene python.

Che il Java abusi dell'OOP non direi assolutamente, il Java è un linguaggio se mai dove l'OOP è l'unico paradigma possibile, una scelta sensata, sebbene tenda in certi casi a costringerti a scrivere più codice (ma tanto, ci sono gli IDE che bene o male mezzo codice te lo scrivono loro, tipo i vari metodi get/set) tende poi a semplificare molto il mantenimento del programma.

La gestione esplicita delle eccezioni, è necessaria, per scrivere programmi sicuri, come Java elimina un sacco di costrutti e pratiche pericolose, i puntatori, la possibilità di utilizzare variabili non inizializzate, l'overloading degli operatori, i goto, la possibilità di utilizzare codice non-OOP (ci sono i metodi static, ma vanno usati il meno possibile), insomma...

Gabriele Di Bari

allora la chiamata dei metodi in OBJ-C è simile a python, ovvero:
[oggetto metodo:param, field-name:param,..]
Per accedere ai field in OBJ-C(2) puoi usare la sintassi "puntata" come in C/C++/Java.
Ma in generale ti dico che per usarlo a livello produttivo (alla code monkey)
risulta essere molto pulito, non so' come spiegartelo, ma ho notato che il risultato è quello (forse perché non è necessario che nell'intestazione ci siano metodi privati? O forse perché lo stile di scrittura del codice è più forzato? Stile C per la parte imperativa?).
Java, invece, tra gestioni delle eccezioni esplicito ed obbligato ed sintassi prolissa e librerie standard con un palese abuso di OOP tende a far diventare il tutto poco leggibile.

Vedi ad esempio una tipica libreria matematica, con uno stile simile alle api base del linguaggio:

[ObjC/C]
vec2 x = CreateVec2(2,1);
vec2 z = CreateVec2(3,1);
vec2 y = add(&z,add(&y,&CreateVec2(2,2)));
float ylen = length(y);

[gnu-c]
vec2 x = { .x = 2; .y=1; };
vec2 x = { .x = 3; .y=1; };
vec2 y = add(&z,add(&y,&CreateVec2(2,2)));
float ylen = length(y);

[Java]
Vec2 x = new Vec2(2,1); //heap
Vec2 z = new Vec2(3,1); //heap
Vec2 y = z.add(x.add(new Vec2(2,2)));
float ylen = ty.length();

[c#]
Vec2 x = new Vec2(2,1); //stack
Vec2 z = new Vec2(3,1); //stack
Vec2 y = z+x+(new Vec2(2,2));
float ylen = ty.length();

[C++]
vec2 x(2,1);
vec2 z(3,1);
vec2 y = z+x+vec2(2,2);
float ylen = length(y);

[C++14/modern]
vec2 x{2,1};
vec2 z{3,1};
auto y = z+x+{2,2};
auto ylen = length(y);

ale

Objective-C però è l'unico ancora vivo dei vecchi linguaggi OOP, ed ha alcune feature che per altro erano dettate da esigenze tecniche dell'epoca, all'epoca la potenza era poca, i compilatori erano poco evoluti, e comunque tutta la teoria dell'OOP doveva ancora svilupparsi...

La sintassi oltre ad essere brutta, è poco pratica, e si appunto presta poco ad una programmazione OOP moderna, nel senso che se utilizzi correttamente la OOP, ti può capitare frequentemente di scrivere cose come oggetto.medoto1().medoto2().medoto3(), utile per esempio nei costruttori, farlo in objective-C, cosa viene ? [[[[oggetto metodo1] metodo2] metodo3] ? mah a me sembra assurdo francamente... anche da un punto di vista di un editor che deve gestirti il codice, deve aggiungere una quadra davanti ?

Poi, ancora il fatto che non si siano superati i file header, per una classe devo definire un file di implementazione ed uno header, francamente un assurdità che non capisco, il fatto che non esistano delle vere e proprie interfacce come nel java, il fatto che fino a poco tempo fa addirittura mancava la garbage collection, il fatto che il programmatore ha a disposizione a costrutti pericolosi come i goto, il non aver superato i puntatori e l'assurda sintassi con -> per accedere ai campi, il fatto che si possano inserire delle funzioni non OOP in un programma OOP, generando quindi una tal confusione incredibile, insomma, definirlo un linguaggio buono per il 2016, no.

Swift al contrario è fatto molto bene, questo si

Gabriele Di Bari

Objective-C non è certo tra i linguaggi più vecchi nel panorama OOP, certo è nato prima di Java, ma non so dirti se questo è un male o un bene.
Comunque sia, Objective-C, quando si sviluppa un programma a scopo lavorativo con un design fatto,tende a farti scrivere codice pulito (solitamente in java accade l'opposto, per mia esperienza).
Ha una sintassi un po' tediosa, ma una volta "apprezzata" ci si può passare sopra.
Il build system e le librerie usano i framework di LLVM/CLANG che sono paragonabili alle librerie Java o ai moduli di Python e se hai provato Swift saprai come funzionano visto che in Obj-C si usano allo stesso modo.
Il fatto che ho le system call siano esposte è solo un bene, non è possibile che per eseguire una procedura di lettura debba passare per dei wrapper OOP che a loro volta chiamano dri wrapper non OOP che a loro volta chiamano le system call (Come succede in Java ad esempio).
Le system call sono le API dell'os, usarele direttamente o non usarle direttamente cambia poco o niente se non l'overhead delle chiamate.

ale

E allora il problema è da qualche altra parte... ma se vieni a dirmi che una banale applicazione client/server ti consuma tanta RAM e CPU, vuol dire che qualche problema c'è...

manu1234

Guarda sono due arraylist con 3 elementi (quando ho fatto i test) che non vengono mai toccato, solo letti. Ovviamente anche netbeans (altro accrocchio in java) ci mette del suo

ale

Ripeto, se il tuo codice consuma tante risorse per una cosa così banale, probabilmente c'è qualcosa che non va...

Anche con gli ArrayList bisogna stare attenti perché potrebbero essere poco efficienti, esempio banale, cancellare un elemento all'interno diverso dal primo o l'ultimo, ha complessità O(n) ovviamente dato che devi shiftare tutto l'array, quando si usa una struttura dato sono considerazioni fondamentali da fare (e che pochi fanno)

ale

Beh incubo non tanto, almeno, io l'assembly lo capisco e lo so anche scrivere, però, se devo scrivere un programma lo faccio in C#, Java, Python, Ruby, o un qualunque linguaggio di alto livello, perché non sono masochista...

ale

Swift è fatto bene infatti, anche se in un paio di punti secondo me è ancora incasinato, comunque...

Objective-C è un inferno, non solo per la sintassi, ma anche per il fatto che è uno dei primi linguaggi ad oggetti, e per questo molte feature dei linguaggi moderni non le ha... poi secondo me la critica maggiore, critica che faccio anche al C++, è che in questi linguaggi puoi tranquillamente mischiare codice object-oriented con codice imperativo, addirittura puoi benissimo scavalcare tutto e chiamare direttive a basso livello della vecchia libreria C, o chiamate del sistema operativo, il che secondo me porta a scrittura di programmi incomprensibili e ingestibili...

ale

Li però parliamo di cose specifiche, i microcontrollori ovvio che li programmi in C, anche perché non hai un sistema operativo o comunque qualcosa sotto su cui far girare qualcosa di alto livello, ti serve un linguaggio di basso livello che ti dia accesso diretto all'hardware...

Però per tutto il resto, al giorno d'oggi si usano linguaggi ad alto livello e via

Giova91

Se ne hai voglia a mi interesserebbe una piccola spiegazione e dei link dove approfondirla.
Grazir

manu1234

1 sono costretto ad usare netbeans per questo progetto, ho anche intellij ma mi tocca usare netbeans
2 programmo c# normalmente quindi java lo tratto come tratto il c# cioè come normalmente viene trattato java visto quanto sono simili (xaml a parte)
3 non uso ricorsione
4 uso solo 2 arraylist e nient'altro
5 sono una 10ina di metodi e 5 classi
6 rifatto in c# con grafica anche più pesante e qualcosa in più e prestazioni ottime con consumi di ram e cpu bassissimi

Lucian

"Brillo"

Bertone

Non discuto sulla qualità del codice di certi personaggi, ma trovami una sola azienda che sviluppa su microcontrollori (dove le risorse sono decisamente ristrette) in java anzichè C o Assembly direttamente...diciamo che non è pesante come molti lo spacciano ma non è che sia questo fiorellino, ha bisogno di ciccia sotto per girare :D

Antonio_lovy

Parole sante, da stampare e incorniciare

alex

Oddio assembly noooooo l'incubo degli informatici ahahah comunque sono d'accordo!

Sagitt

la jvm esiste su android solo per farlo girare anche sulle lavatrici con cpu di chissà quale genere.

Gabriele Di Bari

Minecraft vecchio, se non fosse per il grande quantitativo di mod, ms gli avrebbe già staccato la spina.

Gabriele Di Bari

1° C'è swift,
2° Obj-C una volta appreso, non è affatto male, il mio main language è il C++ quindi ad usarne dei subset ne sono abbituato [però il sistema a messaggi di Obj-c è una cosa che alla lunga si fà apprezza].

Andrej Peribar

Dicevo esattamente questo :)

Per altri sistemi intendevo no-linux

ale

Ma infatti... che poi tutti a criticare il Java, poi vorrei vederli a gestire un progetto di 100.000 righe di codice in C++ e vorrei vedere come non diventano matti... le prestazioni non sono tutto, anzi, spesso è meglio sacrificare le performance per la semplicità di sviluppo, la leggibilità e la mantenibilità del codice, altrimenti saremmo tutti a scrivere in assembly...

ale

Hai mai provato a creare un app per iOS ? Non credo, se no ringrazieresti l'esistenza di Java e di Android... penso che la piattaforma di sviluppo per iOS sia una delle peggiori al mondo, e ringrazia che ora sono pure passati a Swift, pensa prima che dovevi usare Objective-C, linguaggio obsoleto in una maniera assurda e con una sintassi che solo un pazzo poteva concepire

ale

Se non sai programmare, non prendertela con il linguaggio...

ale

Ti sbagli, il linguaggio è ovviamente Java, ma il runtime è diverso, Android ora usa ART, che usa la compilazione AOT (Ahead of Time) al contrario della compilazione JIT classica di Java (Just in Time), ossia invece di compilare il bytecode quando questo viene eseguito, il bytecode è compilato tutto in una volta al momento dell'installazione dell'app: per cui dopo in realtà non hai rallentamenti dati appunto dalla compilazione JIT classica.

Che poi che ci sia un bytecode centra gran poco, praticamente tutti i linguaggi moderni e compilatori moderni si basano su un bytecode, LLVM per esempio che è usato da Apple, e il bytecode o lo converti in codice nativo o lo interpreti JIT o usi un approccio ibrido come quello di Android che prende il meglio dei due alla fin fine con un overhead minimo

ale

Guarda che Android è passato dalla compilazione JIT alla compilazione AOT con ART da android 5.0, ossia le app vengono compilate dal bytecode al codice nativo al momento dell'installazione, quindi una volta sola sostanzialmente... il che rende la cosa praticamente uguale ad iOS.

Account creato pochi mesi fa

Perché non vai a giocare a palla nei pressi di qualche autostrada?

sherpya

se Wikipedia dice che su Android gira una virtual machine java è sbagliato, scusa se ti ho consigliato Wikipedia in tal caso, se vuoi continuare a rimanere nella tua ignoranza fai pure, la virtual machine di Android è totalmente differente da quella java, non da dimostrare niente a te, dovresti solo ringraziarmi

manu1234

Prima mi dici cerca su Wikipedia poi se ti riporto Wikipedia piangi. Bambino

manu1234

Il mio programma ne usa 2 per il client e 3 per il server, considerando che uno è dedicato alla jvm direi che li usa tranquillamente tutti e 4 i core

Keziolio

???

Linux è estremamente popolare in quell'ambito, ci sono diversi framework per fare distro linux embedded

giacomiX11

Accade perché usa un solo thread

Ottimo, allora so a chi rompere domani, heheheh
Al momento (come già intuivi) ho problemi con XZing, dopo averlo scaricato con nouget, non riesce a trovare le librerie/referenze.

alex

In realtà, come spiegato molto bene in un video di qualche tempo fa di di androidworld mi pare, con Art il gap prestazionale tra Java e C++ si è ridotto notevolmente. In ogni caso iOS non usa assolutamente una CPU definibile "un quarto" delle altre, anzi, gli ultimi prodotti montano una delle cpu più potenti in circolazione, idem lato GPU, e direi idem lato RAM, visto che ip7plus ha 3 Gb di RAM come la maggior parte dei telefono android odierni

sherpya

mi so scocciato a spiegarti credi quello che ti pare, perpetra ignoranza

manu1234

è sempre una virtual machine, solo diversa. cazz0 è java non ci vuole un genio. non è che perché l'hanno cambiata non ce ne sia più una

sherpya

android non ha una virtual machine java, fino al quattro ha dalvik dal 5 ha art non mi devo informare se vuoi ti mostro dove stanno i sorgenti

manu1234

io ho un i5 4460 e si, accade

manu1234

"Le applicazioni Android sono Java-based; in effetti le applicazioni scritte in codice nativo in C/C++ devono essere richiamate dal codice java, tutte le chiamate a sistema fatte in C (o C++) devono chiamare codice virtual machine Java di Android: infatti le API multimediali di SDL sotto Android richiamano metodi in Java; questo significa che il codice dell'applicazione C/C++ deve essere inserito all'interno di un progetto Java, il quale produce alla fine un pacchetto Android (APK)."

fonte Wikipedia. informati

Helix

Ogni tanto lo apro, e quando carica i chunck all'inizio è come fare un bel benchmark. È vero che il mio computer è un pò vecchio, ma potrebbe accadere lo stesso con uno xeon immagino xD

sherpya

ti sbagli vai su Wikipedia o dove ti pare e informati

manu1234

e si vede, oltre il 50% di utilizzo cpu e 2 gb di ram, senza mod

Helix

Certo che java è un bambino: è il motore di Minecraft xD

manu1234

"infatti basta guardare le performances di iOS che con UN QUARTO della RAM o CPU riesce tranquillamente a girare intorno a "Java" Android... " dopo java ha scritto android

manu1234

si invece

sherpya

se confronti java con ios sì

sherpya

no

manu1234

questo vale per qualsiasi altro linguaggio, è java ad essere un bambino speciale

HECTHOREX

Ovvio stiamo parlando della VM Java on top al Linux quindi un OS kernel NON NATO PER ESSERE REAL TIME e MAI veramente ottimizzato, con una obesa JVM che a sua volta ha strati e strati di obese funzioni e API spesso in completa sovrapposizione l una all altra....RIBADISCO...in iOS ALTAMENTE ottimizzato richiede UN QUARTO della CPU e RAM e SOPRATUTTO MOLTE MENO API calls per fare le stesse cose...!

Recensione Oppo RX17 Pro: ricarica lampo e super foto notturne

Honor Magic 2 (3.500mAh): live concluso alle 00:02

Recensione Meizu 16th: una piacevole sorpresa

Google Pixel 3: live batteria (2915 mAh) | Fine 18.55