6

What concepts in desktop application development (e.g. Java, WPF, Cocoa) are closest to Android's fundamental concepts like Activity, ActivityGroup, and Intent? (And what are the nuances to how they differ?)

3 Answers3

9

I'm not surprised that you asked this question. The Android programming paradigm is quite different from anything I've personally experienced and your first look at the API can be a bit daunting. I've never actually developed on any other mobile device, but I gather that Android has the most rigid architecture of any existing OS, and it feels like the result of many design meetings.

Some comparable patterns that I can think of off the top of my head:

  • An Activity is essentially equivalent to a window in a desktop system, but in many ways it can also be equivalent to an application as a whole. Though an Android app is usually composed of more than one Activity, each activity has its own well-defined lifecycle and methods for hibernating/restoring itself (e.g. the onSaveInstanceState() method). An Activity is definitely NOT equivalent to a process, however. If you really want to understand the quirks of the Android process lifecycle, read the Activity javadoc and check out this other SO question.
  • An ActivityGroup is really only used with android.widget.TabHost. You should treat an ActivityGroup as if it were a single Activity.
  • Someone above said Activity is a container, and it is, but it doesn't have children nor is it responsible for layout or drawing. I'd say a better analogy is "Activity : window :: ViewGroup : layout/container."
  • android.app.Service == daemon
  • As with most UI frameworks, all UI operations happen on a single thread (the "UI thread"), and there are utility methods that let you queue a certain chunk of code to be executed on the UI thread asynchronously. This is akin to WPF's DispatcherObject or SWT's Display.
  • Android extends the idea of user space vs. kernel space to the filesystem; not only can you not access the virtual memory of other applications, but your app also has its own section of the filesystem for which no other user or app has read/write permissions.
  • If you do want to provide other apps with access to your app's private data store, you do so using a ContentProvider. ContentProviders offer a query-based syntax and is much akin to any ODBC implementation you might find on a traditional OS.
  • The closest analogy for Intents that I can think of is actually AppleScript. Just as OS X apps expose certain methods to the scripting engine, Android apps can handle "intents," a high-level sort of IPC. The major difference here is that Apple-scriptable applications expose their script elements via a "scripting dictionary," whereas it is difficult to find out what intents an Android app can handle unless you can look at the AndroidManifest.xml for that app.

The Bottom Line: Android is really very different than anything else I've encountered and, for better or worse, there will be very many nuances about the platform that you will continue to discover over time. The best thing you can do is to start by reading the Developer Guide straight from top to bottom. I'm 7 months into being a full-time Android developer and I'm still learning new things every day. :-)

Community
  • 1
  • 1
Neil Traft
  • 18,367
  • 15
  • 63
  • 70
0
  • Events: Now there are two, Events and Intents. With intents anyone can subscribe to behaviors rather then registering.
  • Desktop widgets are same as android Widget (with many limitations)

Besides, take any library (not user interface jars) and it works with minimal changes unlike J2ME which is trimmed J2SE. Android's JVM is almost equivalent to core Java libraries. I tried Lucene and it worked on Android with very minimal hacks.

ankitjaininfo
  • 11,961
  • 7
  • 52
  • 75
0

You can't understand through desktop development as this is mobile.

  • Activity=Form/Container
  • ActivityGroup is used less frequently or not at all
  • Intents is a sort of API gateway to issue software operations, intentions that the system will handle it further (in the end it will end up handled by a code of an event)

Intent differs from Events in the way that events land on your method. Intents first goes deep in SDK and after it's handled (started, broadcast, notified) it will come back as an event so you can action on it.

Pentium10
  • 204,586
  • 122
  • 423
  • 502