Android development techniques move forward at a near frantic pace with so many different devices to work with and the use of a new language named Kotlin. With each change, the development environment becomes more functional and less error prone with increased reliability. Kotlin reduces the complexity of development, but the addition of platforms and app types increases it.
Android development you do today is different from the development you performed even six months ago. Android has become the platform of choice for so many tasks that, after you get up to speed, it will boggle your mind to see how many different ways you can employ it. No matter how you work with Android, this Cheat Sheet will help you perform tasks more effectively.
©senrakawa/Shutterstock.com
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.
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.
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.
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:
Class | Implementation | Descripton |
Navigation graph | XML file | Contains all the navigation information. This includes the destinations you define, along with all the paths that a user can take to reach those destinations. Accessed through the navGraph property of a NavHost or NavHostFragment . |
NavHost | Layout control | Displays all of the destinations defined in the navigation graph. It also contains a NavHost implementation that supports destination fragments, which are self-contained parts of an activity that have their own user interface that you might want to use as a destination in some cases. |
NavHostFragment | Layout control | Displays the particulars of a destination fragment. It’s similar to a NavHost but specific to fragments. |
NavController | Created object | Manages navigation within a NavHost or NavHostFragment . This is the app element that actually swaps app content as the user moves through the app. You provide the NavController with a path to take through the app (such as when you want the user to perform specific steps) or a destination to move directly from one place to another. |
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:
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.
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.
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:
Android provides you with a number of common layouts that will work with non-adapter widgets. Here are the layouts:
Dr. Barry Burd holds an M.S. in Computer Science from Rutgers University and a Ph.D. in Mathematics from the University of Illinois. Barry is also the author of Beginning Programming with Java For Dummies, Java for Android For Dummies, and Flutter For Dummies.
John Mueller has produced 114 books and more than 600 articles on topics ranging from functional programming techniques to working with Amazon Web Services (AWS). Luca Massaron, a Google Developer Expert (GDE). interprets big data and transforms it into smart data through simple and effective data mining and machine learning techniques.