Welcome to Part 3 of this review of the Pluralsight course Android Beginner Series: Understanding Android by John Sonmez.

John is the founder of Simple Programmer, and the author of the best selling book Soft Skills.

He also hosts the GetUp and CODE podcast, where he talks about fitness for programmers. John is a life coach for software developers, and helps software engineers, programmers and other technical professionals boost their careers and live a more fulfilled life. He empowers them to accomplish their goals by making the complex simple.

In this module we’re looking at what makes up an Android application, how apps work and what kinds of apps are supported by Android.

Anatomy of An Android App

What Is An App?

Apps are different In Android.

John explains that Android apps can share their functionality with other apps.

Apps are a loosely coupled collection of functionality.

There are many different types of apps, and later in this module John discusses the basic types that we can find.

An App is packaged as a .APK file and can contain the following elements:

• Manifest File (defines what an app can do and is composed of)
• Intents  (what your app knows how to do)
• Activities (usually individual screens)
• Services (functionality that can be run in the background)
• Resources (e.g. images and video)

Basic Kinds of Apps

John talks us through each of the basic kinds of apps.

Single Screen Apps

Usually have just one activity that makes up the app

Multiple Screen Apps

Most apps are multiple screen apps. They have multiple activities and are typically more complex than single screen apps.

John uses the example of an email app with one screen for the inbox and another for composing or reading individual emails.

No Screen Apps

Also known as headless apps, these have no activities.

They are either background services or components that can be used by other applications.

John uses the example of an app designed to play music in the background. It might have a minimal UI for configuring the app, but then it will run in the background.

App Components

John explains each of the components in more detail.

Activities

This is just a single screen in an app, representing a single thing for the user to do.

Android Activities are connected by intents.

Activity Lifecycle

To give us a better idea of how activities work John introduces each of the lifecycle stages.

Ignoring the loops, we have

Created->Started (visible)->Resumed (visible)->Paused (partially visible)->Stopped (hidden)->Destroyed

The Stopped state is what is moved to when the user opens up a different app.

The Android operating system will decide if it needs to free up resources, and if so it can destroy an activity.

The diagram in this clip shows that we might also move through states backwards, e.g. from Stopped to Started.

John recommends taking precautions to save data at a time to avoid it being lost.

Intents

John says Intents are one of the most misunderstood things about how Android works, however the basic idea is quite straightforward.

An Intent is a message that says what you want to do: we’re signifying an intended action to the Android operating system.

They can be used to connect different apps together. Intents can either be explicit or implicit.

Implicit Intents do not specify which service it wants to use, only the basic functionality that is required.

Intent Filters

We can define Intent filters in the manifest file for our application.

This lets the operating system know that certain parts of our application can fulfill certain requests
that our own app might make or other apps might make.

There a few different ways that an intent can be filtered:
By Action
By Category
By Data

Applications can have multiple intent filters.

John gives an example of taking a picture.
The Intent is “I want to take a picture” and the Intent Filter is “I can take pictures”
The Android operating system is able to match these up with each other to provide functionality from one app to another.

Services

Services run in background and have no UI. Once started they continue to run.

Content Providers

These components that give other components access to shared data.

John gives the example of the contacts content provider: this makes it easy to share this data with other apps.
As developers, we could for example use this content provider to send a text message to a specific contact.

Broadcast Receivers

These respond to a system event. John explains that Android sends system messages on certain events, giving a few examples:

– The screen gets turned off
– The battery is low
– Wireless network connection is lost

John recommends the Tasker App which allows us to setup kinds of automation for different things that happen on the device, using Broadcast Receivers

Android manifest

This file is required for all Android applications. It answers a list of important questions about what the application does.
Some examples of these questions about the app are:

What components are in it?
What permissions does it need?
What version of Android does it need?
What intents can it handle?

Navigation

Depending on which version of Android the user is running, navigation may work a little differently.

John explains the role of Tasks in navigation.
Tasks can serve as a unit that defines the navigation path we take through activities, however this is best explained with an example.

Email example

John explains the navigation taken through an example email application. We might have different screens for:

View Contacts
View Email
View Inbox

The Task keeps track of all the activities that take us to the current activity that we are on.

Navigation demo

John uses the emulator to show us the Android gallery app, which displays various images.
We see that we can go from here to our messaging application. At this point we have a task with several activities on it.

Killing Processes

Remember that John said earlier that processes can be destroyed by the Android operating system?
He gives some more information about this here. Android will assess things such as how recently and how frequently a process is used before choosing a victim.

Menus and Action Bars

Menus were used in early versions of Android but were replaced by Action Bars after Android 3.0.

Option Menus

John explains the following points here.

• Collection of menu items for an Activity
• Global actions
• Press menu button to display
• Android 2.3 or lower

Action Bars

The replace options menus as of Android 3.0.

John says it’s a simpler and more consistent way of doing navigation.

It usually takes up a dedicated portion of the app screen, typically at the top or bottom.

It combines the functionality of options menus and context menus. We can even have multiple action bars.

John shows an example from the built in messaging app.

Other Apps

Widgets

These are mini-views embedded in other apps. They’re most commonly used on the home screen.

Games

These usually don’t follow the UI guidelines. They’re usually a single activity.

John says some games are written in C++ and bypass the Dalvik VM for maximum performance.

Part 4 – Ways To Develop Android Apps is coming soon