Application Principles || Fundamentals || Android

 

Java is used to create Android apps. The code, data, and resource files are assembled into an APK using the Android SDK tools (Android package). The whole content of the software is often included in a single APK file.

Each programme is run on an own virtual machine (VM), allowing it to operate independently of other apps. The Android system is run under the principle of least privilege.. Each programme can only access the resources that are necessary for it to function. However, there are methods for an app to exchange data with other programmes. Apps may be able to exchange Linux user ids or request authorization before accessing contacts, the SD card, or other data.

App Elements

An Android app's building pieces are called app components. Each component in an Android app has a specified function, a unique life cycle (the process through which a component is generated and deleted), and a distinctive role. The four categories of app parts are as follows:

1. Activities: A single screen with a User Interface serves as an activity (UI). More than one activity can be present in an Android app. (For instance, an email app may offer a list of all emails, a view of each email's content, and a button to create a new email.) An app's activities come together to form a User eXperience (UX).

2. Services: A service operates in the background and completes lengthy tasks or works on behalf of another process that is located elsewhere. A service just operates in the background with the user's input; it does not offer any UI.

(For instance, a service may download data from the internet while the user is interacting with another App, or it might play music in the background while the user is using another App.)

3. Content providers are in charge of overseeing shared app data. Data may be saved in an app in four different ways: it can be written to a file and kept in the file system, added to or changed in a SQLite database, published online, or kept in any other persistent storage space the app can access. Other Apps can query or even edit the data using content providers. (For instance, the Android operating system has a content manager who controls the user's contact information, allowing any app with authorization to query the contacts.)

For improved data integrity, content providers can also be employed to preserve the app-specific private data.

4. Broadcast receivers: A broadcast receiver reacts to system-wide announcements (notifying other apps, for example, that some data has been downloaded to the device and is available for them to use, or that the screen has been turned off, the battery is low, etc.). It can also respond to announcements from apps. Although broadcast receivers lack user interfaces, they can warn users by displaying notifications in the status bar. Typically, broadcast receivers are utilised as a point of access to additional app elements, the majority of which are activities and services.

Any programme on the Android operating system can launch the component of another app, (for example, if you wish to There is an app that already performs things like make calls, send SMS, browse websites, and view photos, and your app can too. utilise it rather than creating a new activity for the same purpose).

There can only be one foreground process per app running at a time on an Android system, thus when the system begins a component, it also starts the app's process (if it isn't already running) and instantiates the classes required for that component. As a result, the component functions within the App to which it belongs. As a result, unlike programmes on other platforms, Android apps lack a main() function and do not have a single entry point.

An app cannot directly activate the components of another programme since the system runs each app in a distinct process, unlike the Android operating system. As a result, in order for one app to start a component in another app, the system has to receive a message from that app indicating its desire to start the component.

Context

Instances of the class android.content in context. The link to the Android system, which runs the application, is provided via context. To access the project's resources and the overall knowledge of the app's environment, an instance of Context is necessary.

Let's look at a simple illustration: Imagine that you are in a hotel and that you are craving food. You ask room service to deliver you items or clean up for you over the phone. Consider the hotel as an Android app, yourself as an activity, and the person providing room service as your context. This will provide you access to the hotel's resources, such as room service, meal options, etc.

Yet another instance, When you wish to order meals, you ask the wait staff member who is seated at your table at the restaurant where you are. Your order is then placed by the attendant, and your food is delivered to your table. Once more, in this illustration, the restaurant is an Android app, the tables or customers are app components, the food items are your app resources, and the attendant is your context, providing you access to the resources like food items.

Each of the aforementioned elements needs the context's instance to be activated. Not just the aforementioned resources, but practically every system resource is context-dependent. Examples include launching new activities or services, generating instances of system services, designing the user interface using views.