Il presente articolo è stato tradotto automaticamente.

Giochi

Gesture Magic

Marcus Perryman

Schermate touchable è sinonimo di Windows Mobile poiché le periferiche prima appare nel 2002, tuttavia, Windows Mobile 6.5 è la prima versione di richiedere qualsiasi forma di supporto di movimento che viene esposta per gli sviluppatori. Qual è un movimento e perché tutti impegno?

Le schermate tocco tradizionali trovate nei dispositivi Windows Mobile Professional forniscono una superficie di simulazione del mouse producendo pulsante del mouse a sinistra e spostamento del mouse messaggi tramite l'interfaccia del driver dello schermo. Questi messaggi vengono elaborati e consegnati come se lo schermo e stilo erano un mouse fisico e non esistono analogie definite: un mouse produce un flusso di coordinate della posizione in modo lineare e può essere utilizzato come un dispositivo di puntamento estremamente preciso, come uno stilo sullo schermo.

Esistono anche differenze. Ad esempio un mouse invia le informazioni sulla posizione indipendentemente dal pulsante informazioni ma touch screen sempre simula la pressione del pulsante sinistro e invia le informazioni sulla posizione solo se è presente un contatto con lo schermo. Questo paradigma può continuare fino a quando le somiglianze rimangono sicure. Tuttavia, con l'aumento dimensioni dello schermo su moderni telefoni, lo stilo più naturale e intuitivo diventa rapidamente dito indice dell'utente. Per i mercati consumer, affidamento su un fiddly semplice e rapido stilo perso è veloce intenzione di moda, sostituito con la domanda per un'interfaccia in grassetto e interattiva che shouts “ tocco me! ” per favorire una connessione emotional con un utente.

Dita e miniature presentano un diverso profilo in totale contrasto per la precisione di una punta dello stilo, vediamo analogie con interruzione di input del mouse verso il basso. I dati di input non sono più evidenziare accurate e spesso è più equivale a un'orbita lunare di una linea retta input lineare. E non solo i dati sono diversi, è previsto come risultato una risposta uniforme e animata, proporzionale la sequenza di input input. A questo punto è chiaro il paradigma di mouse non è più adatto e sia necessario un elemento diverso per la descrizione di questo tipo di input e comprendere come rispondere. Immettere i movimenti.

Non è soltanto su movimenti Touch

Prima di passare ai dettagli di movimenti tocco, let’s richiedere alcuni minuti per il passaggio e interazione utente su un livello più ampio sui movimenti in generale. Un movimento può significare grandi quantità di elementi diversi. Potrebbe essere un movimento del dito sullo schermo di un computer, ma shaking la testa è un movimento è sventola il braccio oppure shaking lancette con un utente. Il punto è che sarebbe shortsighted da prendere in considerazione solo l'input in una schermata come l'unica fonte di movimenti. Molti dispositivi dispongono oggi più sensori, tra cui tocco schermate, accelerometers, compasses, strumenti GPS e fotocamere. Un dispositivo, spegnerlo, trasformandolo in un cerchio o anche solo sorridente con la fotocamera potrebbe essere interpretata come i movimenti a cui deve rispondere il software, in cui è disponibile solo con i sensori shaking che sappiamo oggi.

Tenendo presente quanto appena detto, l'architettura in Windows Mobile 6.5 è stata progettata per separare il processo di origine e di riconoscimento del movimento di routing, consegna e risposta a tale movimento. Anche se può avere solo tocco movimento riconoscimento oggi, nuovo movimenti possono essere consegnati attraverso il sistema una volta il sensore e componenti di riconoscimento. Nuovi sensori e riconoscimento software può essere aggiunti da produttori di hardware e integrato in esistente gesture architettura recapito, vedere Nella figura 1. Verrà provengono nuovamente successiva per esaminare più da vicino movimento di destinazione e il recapito.

Figura 1 Architettura di movimento generale

Toccare riconoscimento

Nella figura 2 Mostra i nuovi componenti gesto rapido in Windows Mobile 6.5: Riconoscimento di movimento, movimento recapito, Physics Engine e automatica della finestra movimento (WAG). Abbiamo verrà Esaminiamo ciascuno, inizia con il riconoscimento del movimento.

Nella figura 2 Tocco movimento componenti

Il componente riconoscimento del movimento si connette direttamente all'input dal driver tocco esistente. Le informazioni di input fornite dal driver rimangano invariate in Windows Mobile 6.5 per mantenere bassi i costi di sviluppo OEM e per incoraggiare l'adozione.

Esistono cinque movimenti tocco riconosciuto in Windows Mobile 6.5 (seeFigure 3):

• Selezionare: tocco posizione rimanga entro un limite per lo spostamento (vale a dire il limite massimo consentito lo spostamento del dito) e tocco durata è inferiore al limite di tempo.
• Tenere premuto: tocco posizione rimane all'interno di una soglia più flessibile e supera il tempo limite di selezione.
• Doppia selezionare: due riconosciuto correttamente selezionare movimenti riconosciuti entro un limite di tempo e si verificano entro un periodo di tolleranza distanza.
• Dettaglio:lo spostamento del punto di tocco supera la soglia di Seleziona. Questo movimento è leggermente diverso ed è classificato come continuo quanto genera più eventi di movimento.
• Scorrimento: il movimento più complesso per riconoscere, poiché ha velocità, ad angolo deviazione e distanza soglie.

Nella figura 3 Cinque movimenti Core

Ci si potrebbe chiedere perché ci sono alcuni di questi movimenti poiché il comportamento del mouse viene visualizzata per acquisire le stesse informazioni sufficiente. Ad esempio, il movimento di selezionare sembra come facendo clic su un pulsante, e mano come uno spostamento del mouse. Esistono due motivi principali per cui tutte le cinque di questi movimenti sono importanti.

Coerenza: Fare clic con il mouse viene ricevuto come due messaggi verso il basso e backup del pulsante del mouse. Il comportamento esatto per il riconoscimento di un clic è specifico per il controllo viene riconosciuta. Ad esempio un controllo pulsante riconosce il mouse verso il basso e sposta il mouse fino come un clic quando entrambe le posizioni sono entro i limiti di finestre. Al contrario, il controllo ListView riconosce lo stesso evento, ma per ciascun elemento nel relativo elenco. L'azione di Seleziona viene riconosciuto in modo indipendente rispetto al controllo, utilizzando i parametri coerenti. Le soglie di distanza utilizzate per il riconoscimento di movimento sono abilitate per la risoluzione (o più precisamente, punti per pollice-riconoscono) e impostato per lavorare con una vasta gamma di profili finger (non vi è un intervallo di forme finger sorprendente). Pertanto, le distanze fisiche stesse vengono utilizzate su schermi di dimensioni diverse per garantire coerenza tra le periferiche.

Routing: Un dito non è una periferica di puntamento accurata, soprattutto quando l'utente è lo spostamento o esame, pertanto è essenziale che le applicazioni ingrandire l'area di destinazione touchable. Il componente di recapito movimento implementa alcune regole specifiche per agevolare questa operazione e aumentare il valore di questi movimenti semplici.

Routing

Le informazioni di movimento viene recapitate tramite il nuovo messaggio WM_GESTURE e come con tutti i messaggi di finestra sono presenti parametri associati, DWORD wParam e LONG lParam, che contengono i dettagli del messaggio. I parametri del messaggio WM_GESTURE contengono l'ID movimento come un wParam per indicare quale azione viene recapitata e un handle per le informazioni di movimento completo come un lParam. Un messaggio di mouse verrà sempre inviato per la finestra di primo livello nella posizione delle coordinate del mouse (sconto scenari cattura mouse), ma per i movimenti sono diverse le regole. I messaggi di azione sono diversi e vengono sempre inviati alla finestra di primo livello sotto il punto di contatto prima della sequenza che compongono la sequenza completa movimento. Questo subtlety non rende molto per movimenti selezionare, pausa e seleziona Double schermo piccolo solo spostamento tolleranze hanno un impatto. Tuttavia, il movimento di panoramica è piuttosto diverso. Quando si avvia la panoramica, tutti i messaggi di dettaglio vengono inviati alla finestra in cui la panoramica inizia, anche se il movimento di panoramica accetta il punto di contatto di fuori di tale finestra originale.

Allo stesso modo Scroll movimento viene riconosciuto numero di pixel dalla posizione tocco punto originale. Ma ha senso di scorrimento dovrà essere instradato alla stessa finestra precedenti messaggi di dettaglio, come l'utente avviato la sequenza di input nel controllo originale e destinato a tale destinazione. Considerando che il movimento di panoramica è spesso associato con la modifica diretta, ovvero lo spostamento di contenuto sullo schermo come se fosse un pezzo di carta su un computer desktop, questo ciclo rende molto senso, perché il punto di controllo o dello schermo con il dito dal contatto iniziale dovrebbe rimanere sotto il dito come il contenuto viene spostato sullo schermo.

Routing dei messaggi non gestiti

Un altro aspetto insolito del routing dei messaggi di azione è ciò che accade ai messaggi di azione non gestita. Come tutti i messaggi non gestiti, essi finiscono DefWindowProc inviato per l'elaborazione predefinita. DefWindowProc riceve un messaggio di movimento, tenta di trovare l'elemento padre della finestra e inviare il messaggio a tale finestra. Questa operazione viene eseguita per ingrandire l'area touchable disponibile per l'utente.

Per illustrare, prendere in considerazione una finestra a scorrimento con un numero di figlio controlli etichetta. La finestra padre implementa Scroll e dettaglio movimento risposta logica per spostare i controlli etichetta figlio verso l'alto e verso il basso nell'area visibile. I controlli etichetta sono tuttavia non modificati e sapere nulla sull'azione supportano. Se l'utente per avviare un movimento, toccare in un controllo label anziché la finestra padre, aspettativa dell'utente è lo stesso, ovvero che il modulo verrà spostata in risposta all'input di movimento. Inoltrando messaggi di azione non gestita da un'etichetta alla finestra padre viene soddisfatta aspettativa dell'utente e si sposta il contenuto come se l'utente aveva toccati direttamente nel modulo. Questo comportamento è illustrato in Nella figura 4.

Nella figura 4 Routing dei messaggi

Per evidenziare c'è un piccolo trabocchetto: Non inviare mai i messaggi di azione dal padre finestra figlio o rischio richiamando un ciclo infinito e un overflow dello stack inevitabile arresto anomalo del sistema. È disponibile rilevamento alcuni ciclo base implementato in DefWindowProc per tentare di evitare questa situazione, ma potrebbe non rilevare tutte le occorrenze.

Messaggi di azione

Windows Mobile 6.5 riconosce i cinque movimenti, ma le applicazioni possono ricevere sette tipi di movimento. I tipi di movimento extra due sono BEGIN ed END inviati all'inizio e alla fine di una sequenza di movimento (tutti i tipi di movimento sono preceduti GID_ per indicare l'IDentifier di movimento, in modo che questi sono GID_BEGIN e GID_END). Ad esempio, se un movimento Seleziona viene riconosciuto, l'applicazione riceverà tre messaggi di azione: GID_BEGIN GID_SELECT e GID_END. Una sequenza di PAN termina con un movimento di scorrimento, l'applicazione riceverà GID_BEGIN, GID_PAN, GID_PAN …, GID_SCROLL e infine GID_END.

GID_BEGIN è utile in quanto contiene le coordinate dello schermo del punto di contatto originale. GID_END è utile in quanto indica quando l'input dell'utente è terminata e non verranno inviati alcun ulteriormente i movimenti della sequenza corrente.

Consente di introdurre il riconoscimento del movimento di base e il sistema di recapito in Windows Mobile 6.5, ho incluso un progetto di Visual Studio negli esempi di allegato denominati SimpleGestureCapture. In questo esempio visualizza una casella di riepilogo e viene aggiunta una nuova riga per ogni movimento messaggio ricevuto dalla finestra principale, incluse le informazioni di percorso per tutti i movimenti e l'angolo e la velocità di scorrimento dei movimenti. È necessario Visual Studio 2005 o Visual Studio 2008 e Windows Mobile 6 Professional SDK e installato Windows Mobile 6.5 Developer Toolkit. A questo esempio è possibile vedere come viene ricevuto il messaggio di azione e i dati estratti.

Effetti fisici

La parte più interessante del movimento di supporto è che risposta naturale di verificarsi quando si modifica il contenuto dello schermo. La parte fondamentale di questa risposta è l'esperienza coerenza e prevedibile naturale tra il dispositivo. Per ottenere questa coerenza, è stato aggiunto un nuovo componente per il sistema operativo denominato motore di fisica. In questo modulo fornisce una suite di algoritmi elaborando numero che accettano inpue informazioni, ad esempio l'angolo e la velocità di un movimento di scorrimento e decay la velocità nel tempo utilizzando un coefficiente decelerazione specifico. Inoltre, il motore di fisica utilizzabile per applicare animazioni confine quando la velocità di input è sufficiente spostare il punto di animazione all'esterno di un rettangolo di delimitazione.

Per utilizzare il motore di fisica in Windows Mobile 6.5, una nuova istanza del motore di fisica deve prima essere creata e inizializzata. A intervalli di tempo regolari, viene eseguito il polling per recuperare il percorso di animazione corrente e l'applicazione chiamante ridisegna l'area client in modo appropriato. Il motore di fisica continuerà a decay la velocità dell'animazione finché non scende di sotto di un valore di soglia minima, quindi viene contrassegnata come completata e può essere rilasciato.

Come parte dei dati di inizializzazione, l'applicazione deve specificare il rettangolo di delimitazione dello spazio dati così come il rettangolo di visualizzazione per la visualizzazione dello spazio (vedere Nella figura 5). Se il rettangolo di visualizzazione viene spostato all'esterno del rettangolo di delimitazione, il motore di fisica utilizzerà l'animazione di confine selezionato (anche in questo caso, parte dei dati di inizializzazione) per portare il rettangolo di visualizzazione nuovamente all'interno. Inizializzazione Physics Engine è sufficientemente flessibile per consentire l'animazione in un solo asse o di animazione limiti diversi per ogni asse se necessario.

Nella figura 5 Come il motore di fisica Handles rettangolo e rettangoli Display

Per impostazione predefinita il motore di fisica decays la velocità in base a un delta del tempo impiegato dal punto di inizializzazione per il tempo di ciascuna chiamata di recupero del percorso. L'applicazione chiamante può eseguire l'override di questo metodo, specificando un valore “ tempo utente ” e il motore di fisica calcolare la posizione in quel momento. Ciò può essere utile per individuare la posizione sullo schermo in cui verrà completata un'animazione.

Un'altra configurazione Physics Engine interessante è che dimensioni articolo. Queste informazioni vengono utilizzate per imporre una griglia di posizioni di arresto valido tramite lo spazio dei dati, forzando il motore di fisica per consentire la posizione finale della posizione di visualizzazione terminare in uno di tali coordinate della griglia. Questo comportamento è utile quando un'applicazione viene visualizzato un elenco degli elementi sullo schermo e non si desidera un elemento parziale da visualizzare nella parte superiore dello schermo. Il comportamento funziona in uno o entrambi gli assi e verrà regolare decad animazione e interrompere gli algoritmi per estendere o contratto la durata dell'animazione in modo che colpisce i punti di interruzione necessari.

Uso combinato

Per un'applicazione per poter supportare completamente i movimenti tocco, è necessario essere migliorata per riconoscere i messaggi di azione appropriata e rispondere in modo appropriato. Se necessario, è necessario creare ed eseguire query su un'istanza Physics Engine per l'aggiornamento dello schermo. Inoltre, l'applicazione deve considerare che cosa dovrebbe accadere se una sequenza di animazione o movimento viene interrotta da ulteriore input dell'utente o altri eventi e assicurarsi che sia gestito in modo efficiente. Anche se tutto ciò è relativamente semplice ottenere, richiede una quantità ragionevole di codice standard che è necessario creare per ogni finestra che risponde ai movimenti. In modo che in Windows Mobile 6.5, una serie di operazioni è stata adottata per semplificare questa attività.

Innanzitutto, un numero di controlli incorporati è già stato aggiornato per supportare i movimenti, compresi i controlli LISTVIEW, LISTBOX, TREEVIEW e WEBVIEW (alcune modalità Don ’t supportano i movimenti). Se si sta già utilizzando uno qualsiasi di questi controlli, l'applicazione è già abilitata al movimento.

Per le applicazioni non utilizzano i controlli incorporate, vi è una nuova API semplifica notevolmente il lavoro necessario per attivare il supporto per movimento nella maggior parte degli scenari più comuni, chiamato WAG (finestra Auto movimento).

Finestra Auto movimento

La logica WAG è strettamente associata DefWindowProc() elaborazione per fornire una risposta azione predefinita disponibile per qualsiasi finestra. Quando abilitato, WAG verrà automaticamente rispondere GID_PAN e GID_SCROLL movimenti, creare una Physics Engine istanza e inviare i dati rilevanti posizionamento all'applicazione tramite messaggi di notifica. Movimento di scorrimento è in corso, fornendo le transizioni appropriate in e da uno stato di animazione o WAG implementa anche l'interruzione del movimento monitorando la coda di input quando una pan.

La configurazione predefinita per WAG è per ignorare i messaggi di azione, in modo che qualsiasi finestra che utilizza il comportamento WAG necessario attivarla prima. Per attivare il supporto di movimento, l'applicazione deve chiamare TKSetWindowAutoGesture per ogni finestra richiede il supporto e passare le impostazioni di configurazione necessarie. Come detto in precedenza, WAG è progettata per semplificare la maggior parte degli scenari più comuni per il movimento di supporto e affinché WAG unità della finestra, è necessario sia stato creato con lo stile WS_VSCROLL e/o VS_HSCROLL impostato in assi possono essere modificati mediante i movimenti tocco. Inoltre, l'applicazione è necessaria per gestire correttamente la barra di scorrimento, mantenendo l'intervallo min/max e dimensioni della pagina appropriata. Questa operazione è necessaria in modo che WAG possibile calcolare le dimensioni dell'area di dati che visualizza la finestra.

WAG dispone di numerose opzioni che vale la pena chiamata:

• WAG gestirà i movimenti GID_PAN e GID_SCROLL, ma uno può essere disattivato se necessario.
• Come il motore di fisica WAG supporta anche elemento di impostazione della larghezza e altezza. Queste informazioni vengono utilizzate non solo per impostare i punti di allineamento, ma anche per espandere i valori degli intervalli di scorrimento di un conteggio di elementi a un conteggio dei pixel. Ad esempio, se l'intervallo delle barre di scorrimento è da 0 a 9 per un elenco di 10 elementi e ogni elemento richiede 20 pixel in verticale per visualizzare il relativo contenuto, l'altezza dell'elemento deve essere impostato su 20. WAG verrà moltiplicare l'intervallo di scorrimento (10) per l'altezza in pixel (20) per identificare l'intervallo completo pixel di dati (200 pixel).
• WAG supporta una speciale modalità che determina lo spostamento finestra generando messaggi WM_xSCROLL all'applicazione invece di messaggi di animazione proprietario più comuni. Ciò risulta utile se si dispone di un'applicazione legacy e si desidera supporto gesto rapido con minimo assoluto assume il relativo codice. Questa modalità viene attivata impostando il valore nOwnerAnimateMessage fa parte dei dati di inizializzazione TKSetWindowAutoGesture() su 0 anziché WM_USER normale + valore x. Alcune funzionalità sono limitata in questa modalità, ad esempio alcun supporto per la manipolazione dei pixel per pixel, ovvero il controllo può essere gestito solo da un elemento. Inoltre, non è possibile passare di fuori dell'intervallo di scorrimento in questa modalità, in modo che i valori di extent vengono ignorati. Questa opzione non funziona anche per lo scorrimento in entrambi gli assi contemporaneamente perché deve essere spostate in modo indipendente ogni asse.
• Extent descrivono la distanza l'area di visualizzazione può essere trascinato oltre l'intervallo di dati e viene espresso come percentuale delle dimensioni di visualizzazione. Prestare attenzione quando si attivano gli extent, poiché ciò consente all'utente di trascinare la visualizzazione oltre i limiti di scorrimento e di esporre un'area dello schermo che molte applicazioni esistenti non sono in grado di gestire correttamente. Assicurarsi che l'applicazione è correttamente cancellazione dello schermo quando viene visualizzato lo spazio oltre la parte superiore o a sinistra dell'intervallo di dati.

In genere un'applicazione configurerà WAG con nOwnerAnimateMessage come valore dell'intervallo WM_USER per WM_APP. WAG utilizzerà questo valore per il messaggio inviato all'applicazione ogni volta che l'applicazione necessita di ridisegnare l'area di visualizzazione. Il primo messaggio in una sequenza di animazione verrà preceduto da un messaggio di stato per indicare che il controllo ora risponde all'input di movimento. WAG aggrega GID_PAN movimento messaggi automaticamente e invia solo un messaggio di animazione all'applicazione con una frequenza massima di 24 ore al secondo (regolamentati utilizzando la durata timer GESTURE_ANIMATION_FRAME_DELAY_MS trovata in gesturephysics.h da Windows Mobile 6.5 Developer Toolkit). Lo stesso vale per le animazioni di scorrimento, in cui WAG utilizza il timer stesso per interrogare il motore di fisica un massimo di 24 ore al secondo.

L'opzione messaggio di stato per WAG risulta particolarmente utile se il controllo supporta lo stato attivo o modifica visiva senza l'interazione dell'utente, ad esempio tramite gli aggiornamenti asincroni. I messaggi di stato indicano il controllo quando l'utente interagisce attraverso l'interfaccia tocco. Deve essere utilizzati come trigger per interrompere gli aggiornamenti che potrebbero modificare gli aspetti visivi di controllo o il relativo contenuto o richiedere inutilmente le risorse dall'animazione della schermata. Produce un effetto di animazione a schermo intero può essere intensivo di risorse, pertanto è importante interrompere qualsiasi elaborazione in background non necessari e concentrare le risorse necessarie per fornire risposte tempestive e uniformi all'utente. Al termine dell'interazione tocco, utilizzare il messaggio di stato per attivare un aggiornamento dei dati e un aggiornamento, se necessario.

Per ulteriori informazioni sull'API WAG, vedere la documentazione MSDN per Windows Mobile 6.5 (MSDN.Microsoft.com/library/ee220917).

Trucchi e suggerimenti

Utilizzo il movimento di API per accettare ed elaborare le informazioni di movimento è abbastanza semplice. Tuttavia, può essere un po' più difficile produrre animazione uniforme in risposta ai movimenti. Di seguito sono riportati alcuni suggerimenti utili.

Tempo primo frame è di fondamentale importanza. È sorprendente come riservate occhio umano può essere alla latenza di interfaccia utente. Ad esempio, un ritardo di più di 100 ms tra un touch screen e una risposta grafica può causare una sensazione di sluggishness, anche se l'applicazione mantiene un costante 24 fotogrammi al secondo (fps). Attività che è veloce, in teoria sotto 50ms primo frame di risposta. Vale la pena notare che il sovraccarico del riconoscimento del movimento e recapito di movimento sono state attentamente ottimizzate, determinando solo 1ms o 2ms da tocco all'applicazione.

È preferibile una frequenza fotogrammi coerente. Nel testing, gli utenti preferito una frequenza fotogrammi leggermente più lenta ma più coerente su una velocità più veloce ma più variabile. Queste informazioni ci applicato creando un timer per regolare la frequenza di aggiornamento per la cornice e il timer per garantire alcune tempo della CPU disponibile in ogni frame per gestire altre attività di ottimizzazione.

Rimuovere un inutile sovraccarico durante l'animazione. È ovvio il minore lavoro disponibili per ogni frame, che possono essere disegnati ulteriori frame al secondo. Tuttavia, talvolta è più difficile identificare esattamente quali lavoro può essere tralasciato. Durante la modifica del tocco e soprattutto durante le animazioni di scorrimento, l'utente è meno interesse in modo dettagliato e più interessati a indicatori ampia. Ad esempio, durante lo scorrimento di un elenco dei messaggi di posta elettronica, l'utente potrebbe essere meno interessati a un'anteprima di ogni messaggio ma maggiore interesse nella relativa posizione nell'elenco e il titolo. Pertanto, potrebbe essere possibile interrompere l'aggiornamento o recuperando il testo di anteprima per consentire più tempo per l'animazione uniforme.

Utilizzo razionale dei buffer fuori schermo. Doppio buffer può essere un modo eccellente di migliorare le prestazioni di disegno e la riduzione frammentato disegno dello schermo. Tuttavia, deve essere applicata con attenzione, come un buffer fuori schermo si rivela costoso sotto le risorse. Assicurarsi che il buffer viene mantenuto per più breve tempo possibile e viene mantenuto una dimensione minima. Utilizzando l'API ScrollWindowEx spesso possibile ottenere lo stesso risultato senza il sovraccarico della memoria di un buffer fuori schermo.

Misurare la prima volta e quindi applicare i miglioramenti appropriati. È prassi di analisi delle prestazioni standard per garantire che sta correzione qualcosa che viene effettivamente interrotta. Pertanto, prima di modificare qualsiasi codice, assicurarsi che capire dove sono i costi nel ciclo animazione misurando i primi e quindi applicare le attività per le aree che consente di ottenere i vantaggi più significativi per l'applicazione.

Operazione IT gestite

Il codice delle applicazioni che utilizzano i controlli comuni (ad esempio, LISTBOX, LISTVIEW, della visualizzazione Web e TREEVIEW) potranno beneficiare automaticamente il supporto di movimento tocco aggiunto questi controlli senza apportare modifiche al codice gestito. Per le applicazioni che dispongono di controlli personalizzati, dovrà essere modificato in modo da rendere il codice di controllo utilizzo dei movimenti tramite l'API esposte in Windows Mobile 6.5 Developer Toolkit. Il toolkit contiene le intestazioni di c ++ e gli esempi e mirate a sviluppatori di codice nativo. Tuttavia, le API sono progettate per essere facile da utilizzare tramite un semplice interoperabilità dal codice gestito.

La parte dell'implementazione del supporto movimento complessa è in corso in grado di ricevere i messaggi di animazione WAG e il nuovo messaggio WM_GESTURE perché a differenza dei desktop, compact framework non espone il gestore WndProc. Richiede la tecnica comune di sub-classing finestra per visualizzare prima di tutti i messaggi inviati ad esso ed escludere quelli che necessari per raggiungere questi messaggi. Questa operazione può essere eseguita mediante una DLL di supporto nativo o semplicemente chiamare direttamente all'API native. Nell'esempio di codice disponibile con l'articolo sul sito MSDN online, ho incluso alcuni esempi che mostrano come questo potrebbe raggiungere, insieme con tre progetti che mostra i movimenti tocco, il motore di fisica e WAG tutti in uso con codice gestito. Sono inoltre disponibili diverse soluzioni disponibili nella comunità.

Operazioni successive

Per iniziare a utilizzare i movimenti di Windows Mobile 6.5, assicurarsi di scaricare il Kit di sviluppo da Microsoft.com/downloads/details.aspx?FamilyID=20686a1d-97a8-4f80-bc6a-ae010e085a6e. Include gli emulatori ed esempi per esplorare molte le possibilità. Inoltre, è disponibile all'indirizzo documentazione di MSDN per questa API nativaMSDN.Microsoft.com/library/ee220920. Se sta cercando soluzioni di codice gestito, dare un'occhiata al codice di esempio associato a questo articolo nella pagina MSDN o blog ’ Maarten Struys (dotnetfordevices.com/forum.HTML?monthidx=8&yearidx=2009) o il blog di Marco Yakhnin (blogs.msdn.com/priozersk/Archive/2009/08/28/Managed-wrapper-of-the-Gesture-APIs.aspx).

Sono inoltre più di mia ramblings sui movimenti tocco sul mio blog:

• Let’s Talk About Touch (parte 1): blogs.msdn.com/marcpe/Archive/2009/06/29/Let-s-Talk-About-Touch-part1.aspx
• Let’s Talk About Touch (parte 2): blogs.msdn.com/marcpe/Archive/2009/06/29/Let-s-Talk-About-Touch-part2.aspx

Marcus Perryman ha lavorato per oltre 10 anni in vari ruoli tecnici, tra cui lo sviluppatore consulente e sviluppatore evangelist presso Microsoft. Attualmente, Perryman funziona come un progettazione software engineer nel gruppo di prodotti Windows Mobile, progettazione e sviluppo di prossima generazione di sistemi operativi mobile.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Tim Benton, John Lawrence, David Goon, Stewart Tootill e Marcin Stankiewicz