Anatomy of the Android app
Regardless of your previous programming experience, whether it’s Windows, MacOS, Linux, or iOS-based, Android Development is great for anything you encounter. So, the purpose of this chapter is to understand the high-level concepts behind the construction of Android apps. By doing so, we will explore in detail both the various components used to create applications and the mechanisms that allow them to work together
1. Android activities
Familiarity with object-oriented programming languages such as Java, Kotlin, C ++ or C # becomes familiar with the concept of encapsulating elements of application functionality, then instantiating them into objects and manipulating them to create applications. Since Android apps are written in Java and Kotlin, it’s still very much. However, Android also elevates the concept of reusable components. One or more parts of the Android app are called operations. An activity is a single, standalone module of application functionality that is usually directly related to a single user interface screen and its associated functionality. An appointment application, for example, may be an activity screen that displays appointments for the current day. The app can also use another functionality
Contains a screen where the user can register new appointments. Activities are in the form of fully recyclable and interchangeable building blocks that can be shared between different applications. Existing email application, for example, is a special activity for sending and sending email messages. The developer can write an application to send an email message. Instead of developing email creation functionality specifically for the new app, the developer can only use the functionality from the existing email application. Functions are created as a subcategory of the Android Activity class and must be implemented in order to be completely independent of other activities within the app. In other words, calling a shared functionality is not reliable.
A known point in the program flow (since other applications may use the functionality in an unexpected way) and an activity does not directly call methods or access the instance data of another activity. Instead, this is accomplished using a content and content provider. By default, an activity does not result in the functionality it executes. If this functionality is required, the activity should be started separately as a by-product of the parent activity.
2. Android Fragment
An activity, as described above, usually refers to a single user interface screen in the app. The alternative is to build functionality using a single user interface layout and associated function class file. A good option, however, is to split the activity into different classes. Each of these terms is called chunk, each of which is part of the user interface layout and matching class file (declared as one).
A subclass of the Android fragment class). In this scenario, an activity becomes just one or more pieces of embedded container. Android Apps Anatomy In fact, fragments provide an effective alternative to displaying each user interface screen through a different functionality. Instead, an app may have the same functionality switching between different components, each representing a different app screen.
3. Objectives of Android
The intent is that one activity can launch another and run the flow through the activities that make up the application. The purpose is to have a description of the operation to be performed and, optionally, the data to be executed.
Intentions can be clarified, in which they are requested to initiate a particular activity, which is used by referring to the activity by class name, or to perform that type of work or to perform a specific task. Should be processed. . In the case of implicit motives, Intent chooses Android functionality to enable a runtime that closely matches the specified criteria, using a procedure called Intent Resolution.
4. The purpose of transmission
Another type of intent, the Broadcast Intent, is a system wide interest sent to all applications that record “interest” transmission lever. The Android system, for example, sends broadcast intents to indicate a complete change of the system, a connection to an external power source to the device, or a change in device status such as turning the screen on or off. . The transmission intent may be generic (asynchronous) which directs all interested broadcasters to send more or less time to the receiver at the same time as it is processed. It can then be canceled or sent to the next transmission receiver.
5. Broadcast Receiver
Broadcast receivers are mechanisms by which applications respond to broadcast intentions. The broadcast receiver must be registered by an application and configured with an intent filter to indicate the types of transmission that are of interest. When the matching intent is transmitted, the receiver will be invoiced by the Android runtime, even if the application that registered the receiver is currently running.
The receiver has 5 seconds to complete any task required before returning (such as launching a service, updating data, or giving a notification to a user). Broadcast receivers work in the background and have no user interface.
6. Android Services
Android services are processes running in the background and have no user interface. They can be started and subsequently managed from operations, broadcast receivers or other services. Android services are ideal for situations where the app needs to continue working, but the user interface does not need to be visible to the user. Even if the service does not have a user interface, they can notify the user of events (short notification messages that appear on the screen without interrupting the functionality that is currently visible) and can also issue intentions. Android runtime is compared to many other processes and can only be removed by the system as a last resort to free up resources. In the event that a service needs to kill a runtime, it will be restarted as soon as sufficient resources are available. Declaring that a service needs to be run on the front can reduce the risk of cancellation. This is accomplished by calling StartForground (). This is only recommended for situations where the cancellation may harm the user experience (for example, if the user is transmitting through the audio service).
Example situations where a service is a viable solution, as mentioned earlier, are streaming. Anatomy of an Android application of audio when the application is not active or the stock market tracking application should proceed.
The user must be notified when the share hits the specified price.
7. Content Provider
Content providers implement a mechanism for sharing data between applications. Any application can provide other applications with access to its underlying data through content provider implementations, including the ability to add, delete, and query data (subject to permissions). Access to the data is provided by the Universal Resource Identifier (URI) defined by the content provider. The data can be shared as a file or as a whole SQLite database. Native Android apps have many standard content providers that allow apps to access data, such as contacts and media files. Content providers currently available on Android systems use content resolver.
8. Application Manifest
Glue Application Manifest File that pulls together various elements that contain the application. Within this XML based file, the application describes the operations, services, broadcast receivers, data providers, and permissions that make up the complete application.
9. Application Resources
In addition to the dex files that contain the manifest file and the byte code, the Android application packages typically contain a collection of resource files. These files contain resources such as strings, images, fonts, and colors, which appear in the user interface with an XML representation of the user interface layout. By default, these files are stored in the / res subdirectory of the application project’s hierarchy.
10. Application context
When the application is compiled, a class called R that contains instructions for the application resources is created. The application manifest file and these resources are collectively known as application references. This instruction introduced by the Android context class can be used in application code to gain access to application resources at runtime. In addition, a wide range of methods are known in terms of application
Collect information at runtime and make changes to the application’s environment.