---
# System prepended metadata

title: <font size="7pt"><b>Application Components</b></font>
tags: [Developpement Mobile]

---

![](https://i.imgur.com/pW7K0Xp.png)
<font size="4pt"><sup>*Semestre automne 2021*</sup></font>
###### tags: `Developpement Mobile`

# <font size="7pt"><b>Application Components</b></font>
<font size="6pt"><b>Android</b></font>

---

[ToC]

## 0. Description

Application components are the essential building blocks of an Android application. These components are loosely coupled by the application manifest file *`"AndroidManifest.xml"`* that describes each component of the application and how they interact.

![](https://i.imgur.com/1TpKqWw.png)

## 1. Activities

An activity represents a single screen with a user interface. Class *Activity* performs actions on the screen.

If an application has more than one activity, then one of them should be marked as the activity that is presented when the application is launched.

- To create a subclass of **Activity** : 

```kotlin=
public class AnotherActivity extends Activity 
{

}
```

## 2. Services

A service is a component that runs in the background to perform long-running operations (playing music, fetching data, for example).

- To create a subclass of **Service** : 

```kotlin=
public class AnotherService extends Service 
{

}
```

## 3. Broadcast Receivers

Broadcast Receivers simply respond to broadcast messages from other applications or from the system.

Applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use.

- To create a subclass of **BroadcastReceiver**, each message is broadcaster as an **Intent** object. : 

```kotlin=
public class AnotherService extends BroadcastReceiver
{
    public void onReceive(context,intent){}
}
```

## 4. Content Providers

A content provider component supplies data from one application to others on request. Such requests are handled by the methods of the ContentResolver class. 

The data may be stored in the file system, the database or somewhere else entirely.

- A *content provider* is implemented as a subclass of **ContentProvider** class and must implement a standard set of APIs that enable other applications to perform transactions.
```kotlin=
public class MyContentProvider extends ContentProvider
{
public void onCreate(){}
}
```

## 5. Fragments

### 5.1 Description
A <a href="/reference/androidx/fragment/app/Fragment"><code>Fragment</code></a> represents a reusable portion of the application. A fragment defines and manages its own
layout, has its own lifecycle, and can handle its own input events. 

**Fragments** cannot live on their own--they must be <em>hosted</em> by an activity or another fragment. The fragment’s view hierarchy becomes part of, or <em>attaches to</em>, the *host’s view hierarchy*.

**Fragments** introduce *modularity* and *reusability* into the *activity’s UI* by allowing to divide the UI into discrete chunks. 

Activities are an ideal place to put global elements around your  user interface, such as a navigation drawer. Conversely, fragments are better suited to define and manage the UI of a single screen or portion of a screen.

Dividing the UI into *fragments* makes it easier to modify your activity appearance at runtime. 
While the activity is in the <code translate="no" dir="ltr">STARTED</code><a href="/guide/components/activities/activity-lifecycle">lifecycle state</a> or higher, fragments can be added, replaced, or removed. 
You can keep a record of these changes in a back stack that is managed by the activity, allowing the changes to be reversed.


## <font size="6pt"><b> 5.2 Simple "How to"</b></font>

### 5.2.1 Adding a user interface

To provide a layout for a fragment, one must implement the `onCreateView()` callback method, which the Android system calls when it's time for the fragment to draw its layout. The implementation of this method must return a **`View`** that is the root of your fragment's layout.

:::info
Note: If the fragment is a subclass of **`ListFragment`**, the default implementation returns a **`ListView`** from `onCreateView()`, so one doesn't need to implement it.
:::

To return a layout from `onCreateView()`, one can inflate it from a layout resource defined in XML. To do so, `onCreateView()` provides a **`LayoutInflater`** object.

```kotlin=
public static class ExampleFragment extends Fragment 
{
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) 
    {
        // Inflate the layout for this fragment
        return inflater.inflate(R.layout.example_fragment, container, false);
    }
}
```

The container parameter passed to `onCreateView()` is the parent **`ViewGroup`** (from the activity's layout) in which your fragment layout will be inserted. The `savedInstanceState` parameter is a `Bundle` that provides data about the previous instance of the fragment, if the fragment is being resumed (restoring state is discussed more in the section about handling the fragment fifecycle).

The `inflate()` method takes three arguments:

The resource ID of the layout you want to inflate. The **`ViewGroup`** to be the parent of the inflated layout. Passing the container is important in order for the system to apply layout parameters to the root view of the inflated layout, specified by the parent view in which it's going.

A boolean indicating whether the inflated layout should be attached to the ViewGroup (the second parameter) during inflation. (In this case, this is false because the system is already inserting the inflated layout into the container—passing true would create a redundant view group in the final layout.)

Now you've seen how to create a fragment that provides a layout. Next, you need to add the fragment to your activity.

## 6. Views



## 7. Layouts

## 8. Intents

## 9. Resources

## 10. Manifest





