Android Application Development For Dummies All-in-One Cheat Sheet

Most Android apps have a somewhat similar structure. You can depend on finding particular elements in every app, making it possible to reduce the development learning curve simply by knowing where to look and what to expect in each of the files. The following list doesn’t contain every file you find, but it does contain the common files found in most Android apps — the ones you use most often when starting.

• AndroidManifest.xml: Contains the essential configuration items used when installing the app on the host device. This is where you find:
  • A list of activities
  • Which activity is the first one to launch
  • Any theme used for the app as a whole
  • The app icon
  • The app display name
• MainActivity.kt: Contains the code used as a starting point for apps that you launch (as contrasted to those that act as service). The one function you always find in this file is onCreate(). However, you usually find many other additional functions used to make the app work.
• activity_main.xml: Provides the layout for the initial app display for apps that you launch (as contrasted to the interface drawn by the underlying operating system for some services, such as Android Auto). The default layout contains a TextView control with the words Hello World.
• strings.xml: Receives the string values used throughout the app for things like the app name, control text, and pointers to event handlers.
• build.gradle (Project: Name): Configures the project as a whole. This file contains essentials like:
  • The locations of repositories to use for libraries
  • Dependencies that the app has
  • The Kotlin version number
• build.gradle (Project: Name): Configures individual modules within the project. Each module has a separate file, but most projects begin with just one module. This file contains essentials like:
  • Any plugins needed by the module
  • Various SDK version numbers
  • The ID of the application associated with the module
  • All the implementation dependencies for the module

Whenever you compile your app, the compilation process eventually results in an Android Package (APK) file. This is the file that you upload to the device in order to install your app. Fortunately, you can easily see and analyze the .apk file by choosing Build→Analyze APK… from the Android Studio menu. What you see is a list of the .apk file contents, described in the following list.

• classes.dex: The compiled classes for the DEX version of your application code. This bytecode won’t match the Java bytecode. To see the difference for yourself, click the classes.dex entry to display the list of classes.

Initially, you see the Java bytecode for application code such as an event handler method. Right-click this same method for the DEX bytecode and choose Show Bytecode from the context menu. You see the DEX bytecode, which you can now compare to the Java bytecode if you want.

The differences are quite noticeable and should tell you that each virtual machine speaks its own language. For example, new #31 in Java bytecode translates to new-instance v0, Ljava/lang/StringBuilder in DEX.

• res: Uncompiled resources for your app, such as images.
• kotlin: Contains a list of Kotlin classes that aren’t compiled into the classes.dex file. Rather, they’re mapped to existing types on the target platform.
• resources.arsc: Contains the compiled resources for your app. When you choose this entry, you can see the list of resources and drill down into them to see specific entries.
• META-INF: Contains the manifest file, signature, and a list of resources in the .apk
• AndroidManifest.xml: Describes the name, version, and contents of the .apk file.

Each activity (full-screen user-interface element) or fragment (self-contained partial-screen user-interface element) in your app is a separate element. To move between them, the user clicks something or some piece of automation performs the move on the user’s behalf. The act of moving between activities or fragments is called navigation, and the navigation must work correctly. Every activity or fragment that a user can navigate to is a destination. Actions determine when and how the navigation occurs. The elements in the following table comprise essential navigation in Android:

A notification is a kind of highly formatted dialog box when displayed. There are differences, but if you start by viewing them as special dialogs boxes as a developer, it helps you understand some of the concepts behind them. The formatting consists of these items:

• Heading: The heading is a small strip at the top of the notification that acts as an identifier of notification intent and purpose. It contains these elements:
  • App icon: People readily identify apps they commonly use by the app icon. For example, most people can identify Twitter and Facebook solely by the icons their apps use.
  • App name: Some organizations create more than one app but use similar icons for each app. The app name identifies a particular app.
  • Header text (optional): A short piece of information to identify the sender when multiple people, organizations, devices, or other sources use the same app for notifications. For example, the header might contain the email address of the sender.
  • Timestamp: Even though this element doesn’t appear by default and Google claims that it’s optional, it really isn’t optional. The most annoying kind of notification is one that’s two weeks old and no longer important. Keep your users happy; include a timestamp.

Fortunately, you don’t have to rely on a timestamp alone. You have the ability to programmatically dismiss an outdated notification before the user sees it. This is especially important when dealing with notifications in the notification drawer.

• • Expand indicator: This is a little down-pointing arrow that tells the recipient that there is more information. Clicking the arrow expands the content to display the additional content (at which point, the down-pointing arrow becomes an up-pointing arrow so that the user can close the notification back up).

• Primary content: The primary content area contains the message you want to convey. It normally contains these elements:
  • Content header: The content header should appear in slightly larger and usually bolder text than the rest of the notification. It should provide an extremely brief bit of text that you use to convince the viewer to read more.

The header can also indicate multiple notifications from a single app. For example, when working with an email app, the content header can indicate the number of pending emails in the user’s Inbox.

• • Content text: This is the actual message. You should be brief enough to give the viewer an idea of why the notification is important without having to expand it. Of course, you can always provide an expand indicator if you need additional space for detailed content.

• Origin indicator: This is a relatively large icon that tells you about the message origin. Although you often see someone’s picture here, some notifications provide organization logos or other indicators of the notification source. If you see the face of a friend staring at you from a notification, you’re more likely to read it.
• Actions: You always need an action to get rid of the notification. Nothing is more annoying than to have a notification that hangs around like gum on your shoes. Other actions you might include are the ability to reply to the notification, open the app that generated the notification, call the person who sent the notification, or go to a website to obtain additional information. You don’t want to add a confusing array of actions that have nothing to do with the notification.

One important action is the hierarchy indicator. When an app sends multiple notifications, but these notifications represent a hierarchy, such as a message thread, the hierarchy indicator tells how many child notifications there are for the current notification so that the user can decide whether to drill down into the hierarchy to learn more.

You can also make one of the actions a short response from the user. The user can type text into the notification to provide a short answer to a question, such as yes or no to an invitation to dinner.

You control the appearance of the notification using one of the following templates, in most cases:

• Standard: This is the standard notification that contains just a short amount of information and one or two actions.
• Big text: You use this template when you have a lot of text to display. It looks similar to the standard template but allows room for a lot more information.
• Big picture: In addition to the icon, this template provides space for a picture of some type. You can use it for things like screen captures or to see a picture that someone sent you.
• Progress: Contains a progress bar that you can update to show the progress of something like a download.
• Media: Used to control media playing in the background. You see the standard VCR controls and possibly a picture of the album cover.
• Messaging: This template includes a picture of the person sending the message. The message could be a text, but there is a potential for other uses as well.
• Custom: If none of the templates in this list provides what you need, you can always try to create a custom template. This article describes how to create a custom template.

Android provides you with a number of common layouts that will work with non-adapter widgets. Here are the layouts:

• ContraintLayout: Places the controls relative to the parent and sometimes each other based on the limits of the current device. The controls appear in the same order and in about the same place within the limits of a constraint on each device that displays the user interface.
• LinearLayout: Creates a horizontal or vertical arrangement of controls with one control in each horizontal or vertical slot. The size of the largest control determines the size of the slot. This layout relies on scrollbars when the layout doesn’t fit on the user’s screen.
• FrameLayout: Defines an area onscreen to place a control, usually graphical, such as a picture.
• TableLayout: Relies on a tabular format similar to the tables used for web pages. Control size can vary to accommodate various device sizes. The overall layout remains the same.
• RelativeLayout (legacy): Makes it possible to position the controls relative to each other, which means that devices of different sizes will have the controls in the same order, but not necessarily in the same place.