Welcome to Part 3 of this review of the Pluralsight course Android Beginner Series: Understanding Android by John Sonmez.
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.
John explains each of the components in more detail.
This is just a single screen in an app, representing a single thing for the user to do.
Android Activities are connected by intents.
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.
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.
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:
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 run in background and have no UI. Once started they continue to run.
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.
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
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?
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.
John explains the navigation taken through an example email application. We might have different screens for:
The Task keeps track of all the activities that take us to the current activity that we are on.
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.
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.
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
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.
These are mini-views embedded in other apps. They’re most commonly used on the home screen.
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