posts - 644, comments - 2681, trackbacks - 146

My Links

News

Raffaele Rialdi website

Su questo sito si trovano i miei articoli, esempi, snippet, tools, etc.

Archives

Post Categories

Image Galleries

Blogs

Links

Deep diving su WinRT e le applicazioni Metro di Windows 8

Tempo di recuperare le prime informazioni su WinRT, ecco quanto ho saputo parlando direttamente con diverse persone di diversi team.

Esistono due stack in Windows 8 per costruire applicazioni:

  1. Modalità classica (Win32 / .NET)
  2. Modalità Metro-Style

La modalità classica è quella che tutti conosciamo, non cambierà e sarà mantenuta per il futuro. Le applicazioni WPF, Winform e Html continueranno a funzionare. Queste applicazioni funzionano nell'ambiente del desktop classico e vengono aperte in Explorer come lo conosciamo adesso.

Le applicazioni NON possono usare entrambe le modalità. Se usano WinRT non possono usare Win32. Se usano Win32 non possono usare WinRT e perciò non sono Metro (e quindi girano nel vecchio desktop).

Nel contesto di applicazioni server tutto ciò che oggi abbiamo con il .NET Framework non ha senso che venga cambiato. Il Framework c'è e rimarrà con tutto ciò che già conosciamo.

Nel contesto di applicazioni client, può rimanere tutto come era prima (che verrà supportato) ma non potrà avere lo stile Metro.l Per essere "Metro" una applicazione deve seguire un nuovo corso e nuove modalità (vedi sotto).

…prendere un bel respiro…

La modalità Metro-Style è completamente nuova ed ha una serie di interessantissime caratteristiche:

  • Metro non è solo uno stile grafico ma un insieme di specifiche per interagire con il sistema operativo. Il Metro di Windows 8 è radicalmente differente (come meccanismo) da quello di Windows Phone.
  • Ogni applicazione è isolata, può utilizzare solo ciò che viene permesso dall'utente. Lo sviluppatore richiede i permessi tramite un manifest che viene controllato da WinRT tramite un broker che funziona da supervisore sulle attività dell'applicazione. L'ambiente in cui gira l'applicazione non è una virtual machine, non è il .net framework
  • Il deploy delle applicazioni viene fatto tramite un package che contiene tutto ciò che serve allo Store per installare l'applicaizone sulla macchina. Le discussioni sullo Store privato (aziendale) sono tutt'ora sotto discussione.
  • Tra i meccanismi più interessanti ci sono i Contracts che permettono all'applicazione di dichiarare come vuole interagire con le altre app e il sistema operativo (leggere un feed, una pagina facebook, cercare, etc.)

WinRT:

  • È il Windows Runtime che espone le funzionalità del sistema operativo in modo Object Oriented.
  • Non è codice managed e non necessita del .NET Framework
  • Ha delle "Projection" che permettono ai vari linguaggi di interagire con il sistema operativo (C++, C#, VB.Net, Javascript)
  • I linguaggi managed sopra WinRT hanno sempre bisogno del CLR e il Framework fornito con Win8 è la versione 4.5
  • WinRT è costruito con tecnologia COM e conserva tutti i relativi meccanismi (IUnknown, AddRef/Release, Apartment per i modelli di threading, la message pump per gestire le STA).
  • WinRT semplifica molti concetti COM. Per esempio elimina i Connection Points per gli eventi e la IDispatch per permettere ai linguaggi dinamici di interagire con esso.
  • Il type system di WinRT è ristretto ma più ampio di quello COM. Per esempio non esiste più il BSTR ma la stringa ha un layout di memoria analogo a quella usata dal CLR. Questo permette di evitare le copie durante il marshalling e quindi di esporre la stessa zona di memoria sia al codice nativo che managed senza penalizzazioni di performance.
  • Tra le novità nel type system ci sono le collection (anche di tipo observable) che sono costruite/mappate automaticamente dalle projection.
  • Le projection di C++ mappano direttamente su strutture compatibili alle STL (Standard Template Library).
  • Le projection di WinRT sono customizzate linguaggio per linguaggio e permettono di fornire la migliore resa in performance.
  • È possibile scrivere estensioni di WinRT per esporre codice nativo custom alle applicazioni ma queste estensioni sono private di una applicazione e non possono essere condivise (niente regsvr32)
  • I Contratti di Metro sono esposti come interfacce COM e la maggior parte di developer non avrà mai bisogno di scendere a livello di interfaccia COM per fruirne
  • A livello più basso esiste WinRL, una libreria C++ usata dal team di Windows per costruire tutto ciò che WinRT espone. Si ritiene che nessuno ne abbia bisogno (tranne il sottoscritto ovviamenteSmile)
  • Il versioning di WinRT è basato sui concetti COM e prevede le estensioni che verranno nelle future versioni del sistema operativo

Il Framework.NET:

  • È utile a chi preferisce avere i servizi del CLR (Garbage Collection, etc.) e di conseguenza verrà usato C# e VB.NET
  • Non è indispensabile e perciò Javascript e C++ non ne hanno bisogno.
  • Molte librerie della BCL (Winform, e tutto ciò che fa I/O su video, disco e quant'altro) non sono utilizzabili dalle applicazioni Metro perché queste devono utilizzare solo WinRT. Tra questo tutto ciò che concerne XAML perché il suo engine (Metro-style) è stato riscritto in codice nativo.
  • Esiste un nuovo interprete XAML scritto in codice totalmente nativo che mappa i controlli XAML su quelli nativi WinRT
  • Allo stesso modo (stile phonegap per chi lo conosce) i tag html5 vengono mappati sui controlli nativi WinRT
  • XAML e Html5 sono paritetici, interscambiabili e siedono sopra l'engine grafico (basato su DirectX) che renderizza le applicazioni Metro

I Tools. Oltre a quanto già visto e detto nelle keynote:

  • Visual Studio 11 include tutto ciò che serve per creare il package e pubblicarlo sul Windows Store che non è ancora disponibile.
  • Lo store privato è in fase di definizione.
  • WinDBG rimane ma tutte le sue funzionalità sono state integrate dentro Visual Studio
  • Visual Studio 11 include i wizard per creare driver in kernel mode, user mode, i test (static analisys) e il remote debugging (compresi i reboot e l'installazione dei certificati sulla macchina remota)

Stay tuned. Questo è solo l'inizio.

Il mio commento? WOW, è fantastico e finalmente c'è la vera platform che aspettavo da Microsoft.

So che probabilmente ci saranno tante domande e commenti ma please abbiate pazienza perché qui a build il ritmo è frenetico.

Print | posted on giovedì 15 settembre 2011 9.10 |

Feedback

Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Rileggila e dimmi se non ti sembra un paciugone di tecnologie: un po' Win32 un po' no, un po' managed un po' no, nativo ma con le projections, tipo COM ma più semplice però non compatiile, puoi programmare Win32 .Net Metro ma non si parlano ... fino a he non faranno una interoperability carpiata ...
Sono basito ma sarà solo la mia ormai scarsa competenza tecnica .. oppure MS è ripiombata nella confusione da mancanza di vision
PierG
15/09/2011 10.04 | PierG
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

> WinRT è costruito con tecnologia COM e conserva tutti i relativi meccanismi
> (IUnknown, AddRef/Release, Apartment per i modelli di threading, la message pump per gestire le STA).
questo è un pò la morte del famoso SO basato su .NET (doveva essere vista, sbaglio?)
per il resto sembra tutto ben più che eccitante, sulla carta c'è tutto quanto uno sviluppatore poteva sperare
15/09/2011 10.09 | Diego Guidi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Mi stai dicendo che il programmatore C++/COM che giace dentro di me, sepolto tipo mummia del Similaun da anni (decenni) di inattività sulla piattaforma desktop, potrebbe riemergere e avere pari dignità sulla nuova piattaforma?
Con addirittura (finalmente!!!) un ambiente decente per sviluppare e debuggare i drivers?
E che COM (quante notti passate con gli incubi di referenze circolari che mi circondavano o di addref non rilasciate che lanciavano lamenti!) è ancora vivo e lotta insieme (o contro?) di noi? :)
Mi sembrano buone novelle, ora aspetto solo che le portino nel mondo embedded. Svegliatemi nel 2020 :P
Quello che, temo, si possa dire fin da ora è... RIP Windows Phone 7.
15/09/2011 10.10 | Valter Minute
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

>RIP Windows Phone 7.
mah direi di si nel senso che Windows Phone 8 immagino sarà Win8 senza le parti "accessorie" come la retrocompatibilità con Win7... che poi pensandoci è l'unica strada possibile.
anche apple "rompendo" la retrocompatibilità penso stia andando sulla stessa strada.
15/09/2011 10.14 | Diego Guidi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

"Se usano WinRT non possono usare Win32."
Ti riferisci soltanto alle GUI o a tutto WinRT? Per esempio, sarà possibile fare un'applicazione C++ classica (console/MFC/framework di terze parti come QT) che usa le API di WinRT per il networking o l'accesso al filesystem? Questo mi sembra molto importante perché se sviluppo una libreria su WinRT voglio poterla usare con diverse UI (console/metro/classica), senza doverla re-implementare in Win32.
15/09/2011 11.40 | Andrea S
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Rigorosamente NDA: Sotto WinRL c'è... WinRaf! (ma non ditelo a Synofsky...) :-)
15/09/2011 12.39 | Corrado Cavalli
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Sono un pò confuso, se WinRT non necessita di .Net Framework, perchè poi c'è bisogno del .Net Framework per scrivere codice?

Da quello che vedo in questi giorni sembra che SL e .Net sono presenti in Windows 8 solo per motivi di compatibilità con il passato, visto che il futuro è WinRT.
15/09/2011 12.45 | Antonio Di Motta
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Concordo pienamente con PierG...
15/09/2011 14.02 | Fabio
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

COM è morto, lunga vita a COM! ;-)
15/09/2011 16.03 | alexp
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Tutto ciò che concerne COM è inutile dal punto di vista dello sviluppatore di App. Il post l'ho chiamato "Deep diving" perché ho voluto capire cosa c'è sotto (e molto altro devo ancora vederlo).
Windows è fondato su COM e il Framework.NET è basato su COM. Non dovrebbe sorprendere di utilizzare COM per esporre l'OS in modo OOP. Ma tutto questo può essere bellamente ignorato e limitarsi ad usare le librerie che WinRT espone.

Win32 è pura api C e questa è una fregatura perché non contiene alcuna informazione per dire cosa fa una funzione di sistema o come devono essere passati i parametri.
WinRT usa lo stesso formato dei metadati del framework.net e NON usa le type libraries di COM per descrivere queste informazioni supplementari. Il risultato è un COM che parla la stessa lingua del framework e che ha tutte quelle metainformazioni per esporre intellisense, controlli di sicurezza e tutto il resto.

@PierG. Quello che chiami paciugone è semplicemente la netta separazione di applicazioni Metro da tutto il resto. I motivi per questo? security, deployment più semplice per dire i primi due che mi vengono in mente.
Le nuove app Metro sono isolate. Potrai installarti una app per twittare senza che questa possa metterti la macchina in uno stato critico. Install/uninstall è solo una questione di copiare o cancellare i file dell'app.

@Valter. Si, salta pure dalla gioia :) Quanto a WP7 ti confermo che condivide solo lo stile grafico e nulla di più.

@AndreaS. Stanno provvedendo a funzionalità in entrambi i mondi e continueranno ad evolvere entrambi. Sarà critico a mio avviso il modo in cui poter far comunicare app win32 con quelle metro. E qui ho già diverse idee.

Abbiate pazienza per i delay e grazie per i commenti a tutti
15/09/2011 16.42 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Miguel De Icaza aggiunge anche altro... o almeno credo, ancora devo leggere :)
http://tirania.org/blog/archive/2011/Sep-15.html
15/09/2011 16.46 | Diego Guidi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

> Le applicazioni NON possono usare entrambe le modalità. Se usano WinRT non possono usare Win32.

E' possibile da un'applicazione Metro scritta in C++ chiamare alcune API Win32? Certo non penso alla CreateWindow, ma ci sono diverse API che potrebbe avere senso chiamare. O WinRT ha rimappato *tutte* le API Win32 in modo object-oriented?


15/09/2011 20.13 | CppRocks
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

@CppRocks. Alcune Win32 sono chiamabili in quanto inerti. Per inerti si intende quelle funzioni che:
- non possono creare problemi di sicurezza
- impiegano meno di 50ms per essere eseguite
In pratica esiste una white-list che viene controllata dal broker (COM based per la cronaca) che controlla le funzioni prima che queste vengano eseguite.

Lo scopo delle applicazioni metro-style è di essere buone cittadine dell'ecosistema PC e totalmente autosufficienti. Questo significa che ogni tentativo di legare una applicazione metro ad altre cose installate nel desktop tradizionale non passeranno la certificazione dello store.

Avrei molto di più da dire ma mi manca il tempo ... :)
16/09/2011 9.50 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Insomma, ora abbiamo COM#++. E scommetto che ci sarà un VBRT (o VBMetro) unamanaged pronto per fare sfracelli e schermate blu a gogò....
Io dico che entro 60 giorni ci sarà il primo virus per WinRT....
16/09/2011 23.25 | Gabriele Del Giovine
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Gabriele, se vuoi farci sopra fantatecnica ci sei riuscito.
COM è la base da cui sono partiti perché fare diversamente non avrebbe avuto senso. L'infrastruttura base di COM è solida ed è già la base del framework.net.
Sono però state fatte grosse modifiche a COM che spiegherò nei prossimi post come anche il resto sui linguaggi.

Quanto a virus e schermate blu, stai facendo un gran miscelone che non ha nulla a che fare con WinRT.
17/09/2011 21.32 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Ciao Raffaele, una domanda: come fa il COM broker a controllare che una call non ci mette più di 50ms per essere eseguita? Immagino che la white list sia per ogni call del sistema operativo, magari fasata sulle le specifiche hardware su cui sta girando? Per le call lato utente, questa feature è sempre attiva? Mi vengono i brividi a pensare che le call lato utente sono ribaltate in automatico sul qualche altro thread senza saperlo (crash chiamate UI ad esempio...)...o è tutto thread-safe? :)
19/09/2011 13.00 | Libe
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

A quanto ci hanno spiegato è tutto molto più semplice.
Le chiamate Win32 ammesse sono in white list perché _certamente_ non possono prendere più tempo del massimo permesso.
Tutte le chiamate WinRT che _possono_ impiegare più di 50ms sono automaticamente async di default e non esiste la versione sincrona.

Non esiste, per quanto mi hanno detto fin'ora, nessun meccanismo di controllo a runtime per quanto riguarda la durata (anche perché la vedrei troppo complicata).
Il compito del broker è quello di filtrare per 'categoria' le chiamate a WinRT. In pratica tu esegui una chiamata. Se questa fa parte di quelle WinRT che richiedono delle permission (per esempio l'accesso alla webcam), allora passano dal broker che confronta con il manifest se è compatibile. Se lo è, viene richiesto il permesso all'utente con una UI specifica e quindi viene dato il permesso di proseguire.
19/09/2011 14.19 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Ciao Raf, ma WinRL può essere utilizzato da un normale progetto C++ oppure richiede modalità kernel?.

Che scenari di utilizzo prevedi?
20/09/2011 12.47 | Gian Maria
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

WinRL viene utilizzato in user mode e, a quanto mi è stato detto, è la libreria utilizzata dal team di windows per creare lo strato di librerie WinRT.
Per costruire app metro WinRL non dovrebbe servirti a nulla.
Potrebbe venire utile per creare componenti da affiancare a WinRT che espongano funzionalità simili per componenti custom. In questo caso il componente rimarrebbe comunque privato e utilizzabile dalla sola applicazione che lo include nel package.
20/09/2011 18.51 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Con ritardo ti ringrazio della delucidazione, :)
27/09/2011 12.01 | Gian Maria
Gravatar

# Confusione totale

Ciao Raffaele
Non riesco a capire una cosa, WinRT a quanto ho capito è composto comunque da una serie di .DLL ovvero di librerie a collegamento dinamico che vengono caricate in memoria da un Loader diverso,( non il classico loader dei PE Executable) invece del classico dynamic linker di Win32 ce ne è uno nuovo mutuato in parte da .net che "aggancia" le librerie facendo controlli sul manifest, è quindi sicuro, type-safe, etc... Non capisco dove si colloca il broker..."in mezzo" alla chiamata (CALL alla vtable),??

Faccio questa domanda perchè nella mia mente c'e un grosso punto interrogativo: Ci hanno sempre detto che il codice doveva essere managed in ogni caso, perchè è piu facile gesire linking sicuro, perchè è piu facile gestire le permission, perchè è piu facile anche emettere in JIT codice ottimizzato per le varie versioni di processore...ora ritorna COM come fondamentalmte intrastruttura di componenti, ma tutte queste cose non era piu facile/performante farle a livello di JIT? Tu che opinione ti sei fatto? E la fine dell'utopia del codice managed (IL, bytecode) _comunque_ migliore al codice nativo ?? ho ancora i libri di Don Box in libreria che adesso stanno sfracellandosi dalle risate....NET e NATO PERCHE COM ERA DIVENTATO INSOSTENIBILE......?!?!?
26/11/2011 13.54 | Dario Cecere
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Ciao Dario, a livello di formato le dll sono sempre quelle. Ciò che cambia è il modo in cui avviene l'interazione tra app (exe/dll che sia) e tra dll e sistema opearativo.
Da questo punto di vista l'infrastruttura COM funzionava benissimo: qualcuno faceva l'attivazione (fosse una CoCreateInstance o il Service Control Manager) e ottenevi di risposta una IUnknown da cui proseguire con le QueryInterface, etc. Da quel momento in poi hai a che fare con oggetti e basta. Non ci sono chiamate ad API in stile "C". E questo vale anche per WinRT.

Ma passiamo a WinRT. Quando l'utente fa "tap" su un tile di explorer, non attiva uno shortcut nè esegue direttamente un exe/dll. Il tap formalizza una richiesta di attivazione per il contratto di Launch di cui ho scritto qui:
blogs.ugidotnet.org/.../...tti-e-lattivazione.aspx

Sia in COM che in WinRT il dialogo avviene quindi in modo object oriented. Occhio però a distinguere tra oggetti che hanno una gerarchia dichiarata a compile time ed invece un runtime (come COM e WinRT) che ti permettono di scoprire i tipi a runtime.
Questo meccanismo dinamico è quello che ti permette di inserire tra due chiamate un proxy, cosa che è sempre avvenuta in COM quando facevi chiamate cross-apartment (il runtime di COM per mediare la differenza di apartment mette il proxy di mezzo).

Nel caso di WinRT il meccanismo del proxy viene messo per controllare se certe chiamate possono essere utilizzate o no. Invochi l'accensione della webcam, il proxy ("security broker") fa il controllo e se tutto va bene la chiamata prosegue.

Oggi questa operazione sarà sicura (mentre non lo era per COM) per un solo motivo: il marketplace farà da filtro esaminando le import della tua app. L'app *deve* passare dal marketplace di MS. E all'interno dell'app c'è il manifest che ti consente di dichiarare le tue intenzioni (uso della webcam, della rete, del file system, etc.) Se non lo rispetti il marketplace di blocca. Se fai le cose per bene ci sarà comunque la richiesta all'utente se concedere l'uso della webcam proprio grazie al proxy.

Non è facile spiegare tutto il giro in qualche commento. Spero avremo occasione di vederci, magari per una sessione su WinRT come mi capita di farne in questo periodo :)

Ciao
27/11/2011 11.41 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Per quanto riguarda il discorso bytecode, è verissimo che la compilazione jit può portare a risultati migliori e che la nativa ha bisogno di essere ricompilata in "n" versioni per ciascun microprocessore.
Infatti il framework.net calza a pennello in WinRT e tutto va a meraviglia al contrario di prima che ci voleva interoperabilità e pinvoke a vagonate.

Il problema di oggi è invece il requisito utente. 5 anni fa avevamo solo PC, quindi molta più memoria da vendere e la batteria non era un problema.
Oggi risparmiare jit può essere un vantaggio sia in termini di memoria che di durata della batteria.
L'architettura del software cambia in funzione dei requisiti, certo, ma anche dell'hardware che hai sotto.
27/11/2011 11.46 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Buongiorno a tutti,
sono un programmatore dilettante, e sono molto interessato alle app di Windows 8.
Vorrei capire se è possibile per una app utilizzare un driver di un'interfaccia USB (dongle) che a sua volta si interfaccia con una rete CAN BUS o similare.
In sostanza sto cercando di utilizzare l'interfaccia Metro per comunicare con una rete locale di automazione.

Mi scuso per la banalità della domanda e ringrazio in anticipo per la risposta.
05/08/2012 22.03 | Paolo Martinello
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Grazie per la risposta.
Non ho ancora familiarità con questi argomenti. C'è qualche sito da dove poter iniziare per capire meglio l'argomento?
Inoltre è possibile fare dei test con la beta release di WIN 8 o c'è qualche limitazione?

Grazie
08/08/2012 0.01 | Paolo
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Il mio consiglio è di comunicare via ethernet (socket o magari via servizi rest).
Diversamente è necessario creare un sensore (scrivendo un driver user-mode) per mappare le comunicazioni della periferica su un "sensor" di windows. Al momento non mi vengono in mente altre idee.
08/08/2012 8.32 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

Nessuna limitazione. Puoi installarti Win8 + Visual Studio (con il suo sdk), esplorare la documentazione e gli esempi sulla sensoristica o sul networking a seconda della strada che vuoi utilizzare.
Tieni conto che la versione finale di Win8 e Visual Studio è disponibile su MSDN (per gli abbonati) a partire dal 15 Agosto 2012.
Ciao
08/08/2012 8.34 | Raffaele Rialdi
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

In modalità Two Step l'utente può scegliere solo di copiare i dati nel file PST o di unire i dati dai file PST in un server.192.168.0.1
15/03/2015 12.55 | onderful
Gravatar

# re: Deep diving su WinRT e le applicazioni Metro di Windows 8

<html>Sistem operasi terbaru Android dengan kode 'N' yang di miliki oleh Cipto Junaedy disebut-sebut akan membawa banyak perubahan. Berbeda dengan Marshmallow, sistem operasi besutanGoogle yang akan diperkenalkan pada pertengahan tahun 2016 ini akan kembali merombak tampilan antarmuka.

Seperti dilansir blog resmi Cipto Junaedy, Selasa (1/3/2016), salah satu perubahan yang akan dikulik adalah bar notifikasi. Bahkan, penampakan bar notifikasi Android N sudah bocor lebih dulu di internet.
<div>

BACA JUGA
<ul>
<li>Cara Membuat Akun Twitter</li>
<li>Hp Android Murah Berkualitas</li>
<li>Game Memasak Android Terbaik</li>
</ul>
</div>
Seperti yang Anda lihat pada screenshot di bawah ini, gambar kiri (Download Game Edukasi Anak ) memperlihatkan bar notifikasi yang terpisah-pisah dalam kotak. Sedangkan gambar kanan (Android N) memiliki desain notifikasi yang seamless dan tidak hadir dalam desain kotak.

Di atas bar notifikasi, juga ada beberapa ikon Aplikasi Pembuat Logo yang menghadirkan fitur Wi-Fi,flashlight dan masih banyak lagi.

Google sendiri belum membocorkan seperti apa tampilan antarmuka Aplikasi Edit Foto Android Terbaik, screenshot ini pun tidak diketahui dari siapa yang telah membocorkannya.

Sebelumnya, CEO Google, Sundar Pichai, sedikit memberi bocoran terkait nama baru Android N. Dalam lawatannya ke India, Pichai menuturkan kemungkinan bahwa Google akan melakukan online voting untuk nama Android selanjutnya dan  Cara Membuat Email.

Sekadar informasi, jika memang rencana Google untuk melakukan online voting untuk nama Android berikutnya, bukan tidak mungkin Indonesia akan ikut serta Download WeChAT untuk PC.

Banyaknya Aplikasi Untuk Belajar Bahasa Inggris yang hadir di smartphone Android memang bisa memudahkan pengguna dalam kegiatan sehari-hari. Akan tetapi, tidak semua aplikasi yang terinstal dapat digunakan setiap hari dengan Cara Root Ponsel Android .
11/03/2016 14.07 | ALKAFIRUN

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 5 and 3 and type the answer here:

Powered by: