Because I am learning and this is my blog, I reserve the right to be wrong, very wrong, or just plain Wrong!  Consider this your one and only apology.  Sorry about that.

Getting familiar with Android terminology and structure…

A bit about their design philosophy.  The have two:  Connecting things.  No need to invent the wheel over and over. If you need an email app, don’t roll your own, just ask Android if there is a suitable app to handle it.  Customize it.  The user is not locked into a single way of getting a job done.   Is the default browser crappy?  Get a different one.  They also really like protecting data.  Each application runs in its own space. To gain access to other data,  permission must be granted.

Pick that app apart.

At any one time, applications typically either collect or present data.  A user can’t handle more than one screenfull at a time.   Applications that require more than one screen, must provide a method.

Applications may do more than one thing.

Activities represent a unit of work within an application – typically one screen full.   It may be data entry, it may be streaming netflix.

Services represent the background processing where the user’s active participation is not required.   When I turn on my gps,  that is a service.  So is streaming Pandora audio while I surf using the browser.

Broadcast Receivers will perform a task for you.  When I tap on an url link inside e-mail, it starts in Opera.  Email declares a need and Opera, being registered as a Broadcast Receiver for for web pages, performs the task.  Does that mean that all broadcast-receivers are content providers?  I think one is data the other is program.   Android describes the situation where an app needs a picture, spins the task off to the camera, and when done it returns to the app -photo in cache ready to go.  Powerful stuff.

Content providers  – handle the chore of managing common data.  When you start a new instant message,  the contact manger provides the default list of who you can talk to.

These four categories of components represent the core of Android structure.   But how do they talk?   Mostly through a message passing system known as an Intent.  The intent is the binding agent between application bits.  For example, once the contact is selected, the uri is returned to the originating app.

With broadcast recievers, you don’t know exactly where the application is going next, so it uses the ContentResolver to provide a way for apps to respond.

Each of these components has a variety of ways they are called, but all use intent as the conduit for communication between.