2010-08-07 10 views

risposta

9

Non sono sorpreso che abbiate fatto questa domanda. Il paradigma di programmazione di Android è molto diverso da qualsiasi altra cosa abbia vissuto personalmente e il tuo primo sguardo all'API può essere un po 'scoraggiante. Non ho mai realmente sviluppato su nessun altro dispositivo mobile, ma ho capito che Android ha l'architettura più rigida di qualsiasi sistema operativo esistente, e sembra il risultato di molti incontri di design.

Alcuni modelli comparabili che mi viene in mente la parte superiore della mia testa:

  • Un Activity è sostanzialmente equivalente a una finestra in un sistema desktop, ma per molti versi può anche essere equivalente a un'applicazione nel complesso. Sebbene un'app per Android sia solitamente composta da più di uno Activity, ogni attività ha il proprio ciclo di vita ben definito e i metodi per ibernare/ripristinare se stesso (ad esempio il metodo onSaveInstanceState()). Un Activity non è assolutamente equivalente a un processo, tuttavia. Se vuoi veramente capire le peculiarità del ciclo di vita del processo Android, leggi l'attività javadoc e dai un'occhiata a this other SO question.
  • Un ActivityGroup viene utilizzato solo con android.widget.TabHost. È necessario trattare un ActivityGroup come se fosse un singolo Activity.
  • Qualcuno sopra detto Activity è un contenitore, e lo è, ma non ha figli né è responsabile per il layout o il disegno. Direi che un'analogia migliore è "Attività: window :: ViewGroup: layout/container".
  • android.app.Service == demone
  • Come con la maggior parte dei quadri di interfaccia utente, tutte le operazioni di UI avvengono su un singolo thread (il "filo UI"), e ci sono metodi di utilità che consentono di coda di un certo pezzo di codice da eseguire sul il thread dell'interfaccia utente in modo asincrono.Questo è simile a DispatcherObject di WPF o SWT Display.
  • Android estende l'idea dello spazio utente rispetto allo spazio del kernel al filesystem; non solo non puoi accedere alla memoria virtuale di altre applicazioni, ma la tua app ha anche una propria sezione del filesystem per cui nessun altro utente o app ha permessi di lettura/scrittura.
  • Se si desidera fornire ad altre app l'accesso all'archivio dati privato della propria app, è possibile utilizzare uno ContentProvider. ContentProviders offre una sintassi basata su query ed è molto simile a qualsiasi implementazione ODBC che potresti trovare su un sistema operativo tradizionale.
  • L'analogia più vicina a Intents che posso pensare è in realtà AppleScript. Proprio come le app di OS X espongono determinati metodi al motore di scripting, le app Android possono gestire "intenti", una sorta di IPC di alto livello. La principale differenza qui è che le applicazioni con script di Apple espongono i loro elementi di script tramite un "dizionario di scripting", mentre è difficile scoprire quali intenzioni un'app Android può gestire a meno che non si possa guardare allo AndroidManifest.xml per quell'app.

The Bottom Line: Android è davvero molto diverso da qualsiasi altra cosa che abbia incontrato e, bene o male, ci saranno molte sfumature sulla piattaforma che si continuerà a scoprire nel corso del tempo. La cosa migliore che puoi fare è iniziare leggendo la Guida per gli sviluppatori direttamente dall'alto in basso. Ho 7 mesi per diventare uno sviluppatore Android a tempo pieno e sto ancora imparando cose nuove ogni giorno. :-)

0
  • Eventi: Ora ci sono due, Eventi e Intenti. Con intenti chiunque può sottoscrivere comportamenti piuttosto che registrarsi.
  • widgets desktop sono stessi Android (con molte limitazioni)

Inoltre, prendere qualsiasi libreria (non vasetti interfaccia utente) e funziona con modifiche minime a differenza J2ME che viene tagliato J2SE. La JVM di Android è quasi equivalente alle librerie Java core. Ho provato Lucene e ha funzionato su Android con hack minime.

0

Non è possibile comprendere lo sviluppo del desktop in quanto è mobile.

  • Attività = Forma/contenitore
  • ActivityGroup viene utilizzato meno frequentemente o per niente
  • Intents è una sorta di gateway API di emettere operazioni software, intenzioni che il sistema gestirà ulteriormente (alla fine finirà gestito da un codice di un evento)

L'intento differisce dagli eventi nel modo in cui gli eventi atterrano sul tuo metodo. Intenti prima entra in profondità nell'SDK e dopo che è stato gestito (avviato, trasmesso, notificato) tornerà come evento in modo da poter agire su di esso.

Problemi correlati