Android Components, Views, and Project Structure: Complete Guide (2026)
Last Updated: | Author: Deep Singh
Before you can build anything meaningful in Android, you need to understand the pieces you're working with. What is an Activity, exactly? How does a Service differ from a BroadcastReceiver? What's the difference between a View and a ViewGroup? Where does everything live in the project?
This guide answers those questions. It's a reference for the fundamental building blocks of every Android app — components, views, project structure, and the sizing units that make layouts work across the huge variety of Android devices.
Android Components
An Android component is one of the essential building blocks that make up an app. Each component has a distinct role — showing a screen, running in the background, receiving system broadcasts, or sharing data with other apps.
Components are loosely coupled, meaning they don't depend heavily on each other and can be triggered independently by the Android system. Every component is declared in the AndroidManifest.xml file. The manifest is responsible for telling the OS that these components exist, and the OS creates their instances and manages their lifecycle.
The Four Core Components
- Activity — Represents a single screen with a user interface. Think of it as "one screen" in your app. When you tap the app icon, the launcher opens an Activity.
- Service — Runs in the background without a UI. Used for long-running tasks like playing music, downloading a file, or syncing data.
- BroadcastReceiver — Listens for system-wide broadcast messages (like "battery low", "airplane mode enabled") and responds to them.
- ContentProvider — Manages and shares data between apps. For example, the Contacts app uses a ContentProvider so other apps can read contacts (with permission).
Supporting Components
- Intent — A message that lets one component request action from another. Also used to pass data between components. Explicit intents target a specific component; implicit intents describe an action and let the system find a matching component.
- Fragment — A reusable piece of UI that lives inside an Activity. An Activity can host multiple fragments, letting you build flexible layouts that work on both phones and tablets.
- Notification — A message displayed outside the app's UI, in the notification shade. Used to inform the user about events without interrupting them.
Modern note: In 2026, most new Android projects use Jetpack Compose instead of the traditional View system for UI. Compose replaces Activities-with-XML-layouts with @Composable functions. The four core components still exist and still matter — Compose only changes how the UI layer is written.
ViewGroups
A ViewGroup is an invisible container that organises other views. It's a subclass of View, which means a ViewGroup is itself a View — you can nest ViewGroups inside each other to build complex layouts.
- LinearLayout — Arranges children in a single row or column (horizontally or vertically).
- RelativeLayout — Positions children relative to each other or to the parent (e.g., "below this view", "aligned to the right of that view").
- FrameLayout — Stacks children on top of each other. Designed to hold a single child, but often used for overlapping elements like a floating button over a map.
- TableLayout — Arranges children in a table of rows and columns.
- TableRow — One row in a TableLayout. Its children are laid out horizontally.
- ListView — A vertically scrolling list. Simple but inefficient for large datasets.
- GridView — A two-dimensional grid of items.
- RecyclerView — The modern replacement for ListView and GridView. Efficient (recycles views), flexible (custom layouts), and the standard choice for lists in 2026. Use this instead of ListView.
- CardView — A Material Design container with rounded corners and shadow. Often used as a wrapper inside RecyclerView items.
- WebView — Displays web content (HTML, CSS, JavaScript) inside your app.
Note on ConstraintLayout: The modern recommendation for complex layouts is ConstraintLayout, which lets you position views with constraints relative to each other. It's more powerful than RelativeLayout and typically more efficient than nested LinearLayouts.
Views
View is the base class of everything you see on screen — both simple widgets and containers. Every other UI class extends from it. Here are the Views you'll use most often:
Display
- TextView — Displays read-only text. Think of it like JLabel in Swing.
- ImageView — Displays an image from a resource, file, or URL.
- WebView — Displays HTML, CSS, and JavaScript content.
- VideoView — Plays video files.
Input
- Button — A tappable button that triggers an action.
- ImageButton — A button with an image instead of text.
- EditText — A text input field where users can type.
- CheckBox — Allows zero, one, or multiple selections from a group.
- RadioButton — Allows exactly one selection from a group.
- Switch — A two-state toggle with a slider (ON/OFF).
- ToggleButton — A two-state button with a light indicator (ON/OFF).
- SeekBar — A draggable slider for selecting a value (like volume or brightness).
- RatingBar — A star-based rating widget.
- Spinner — A dropdown list for selecting one option.
Selection
- TimePicker — Selects a time.
- TimePickerDialog — Selects a time in a modal dialog.
- DatePicker — Selects a date.
- DatePickerDialog — Selects a date in a modal dialog.
Search
- AutoCompleteTextView — Shows suggestions as the user types.
- MultiAutoCompleteTextView — Shows multiple suggestions separated by a delimiter (like email recipients in Gmail).
- SearchView — A search box that filters a list or RecyclerView.
Layout Helpers
- Space — An empty spacer to create gaps between views.
- View — The base class. Often used directly as a divider line.
- ScrollView — Wraps content to make it vertically scrollable.
- HorizontalScrollView — Wraps content to make it horizontally scrollable.
Project Structure
Every Android project follows a standard layout. Understanding it saves you from hunting around when you need to add a resource or edit a manifest entry.
app/ — The Application Module
- manifest — Contains
AndroidManifest.xml. Declares components, permissions, and launcher activity. - java — Contains your source code — Activities, Fragments, ViewModels, business logic, validation, database access. In modern projects, this folder is often renamed to
kotlinwhen using Kotlin. - assets — Contains external files bundled with the app: JSON, XML, fonts, CSVs, HTML, CSS, JavaScript, and jQuery. These are read as a raw stream, not as Android resources.
- res — Contains Android resources: images, audio, icons, colors, strings, and layouts.
Inside res/
- drawable — Images and custom shape XML files.
- layout — XML layout files for each screen or reusable component.
- anim — Animation definition files.
- raw — Music and audio files.
- menu — Menu definition files.
- mipmap — Launcher icons and app icons.
- values — XML files for colors, strings, dimensions, styles, and themes.
Common files inside values/
- strings.xml — Text strings and string arrays, used for localisation.
- dimens.xml — Dimension values shared across layouts (margins, paddings, text sizes).
- colors.xml — Color definitions.
- themes.xml — Default and custom themes. (The original tutorial spelled this
theme.xml, but the standard filename isthemes.xml.)
Measuring Size in Android
Android supports many screen sizes and pixel densities. To make layouts that look right everywhere, you have to use the right units and constants.
Layout Constants
- match_parent — Resize this view to fill the parent's dimension.
- wrap_content — Resize this view to fit its content.
Size Units
- dp (or dip) — Density-Independent Pixel. This is the standard unit for margins, paddings, and view dimensions. On a 160 dpi screen, 1 dp = 1 px; on higher-density screens, dp scales up so that physical size stays consistent.
- sp — Scale-Independent Pixel. Used specifically for text sizes. It's like dp but also respects the user's system font-size preference. Always use sp for text.
- dpi — Dots Per Inch. A measure of screen density — how many pixels fit in a physical inch.
- px — Raw pixels. Avoid this unit in layouts — it doesn't scale across devices.
- in — Inches. Rarely used directly, since physical size is inconsistent across devices.
Screen Densities
Android groups screens into density buckets. Each bucket has a reference dpi value that determines how dp converts to px on that screen.
mdpi 160 dpi (baseline)
hdpi 240 dpi (1.5×)
xhdpi 320 dpi (2×)
xxhdpi 480 dpi (3×)
xxxhdpi 640 dpi (4×)
When you provide image resources at multiple densities (say, drawable-mdpi, drawable-hdpi, drawable-xhdpi), Android picks the one that best matches the device's screen. This is why you often see the same icon saved at five different sizes in a project.
DP to Pixel Conversion
The formula for converting dp to raw pixels at runtime is:
px = dp × (dpi / 160)
Android applies this formula automatically whenever you specify a dimension in dp. That's the entire point of using dp — you write the value once, and the system scales it correctly for every screen.
Example: A 60dp ImageView
<ImageView
android:layout_width="60dp"
android:layout_height="60dp"
android:src="@drawable/myimage" />
On different density screens, the physical size stays the same, but the raw pixel count changes:
mdpi (160 dpi): 60 × 160 / 160 = 60 px
hdpi (240 dpi): 60 × 240 / 160 = 90 px
xhdpi (320 dpi): 60 × 320 / 160 = 120 px
xxhdpi (480 dpi): 60 × 480 / 160 = 180 px
xxxhdpi (640 dpi): 60 × 640 / 160 = 240 px
Notice that the raw pixel count increases with the density, but the physical size — 60dp worth — stays the same. On a phone, that's roughly a third of an inch. On a tablet, still a third of an inch. That consistency is why dp exists.
The rule to remember: use dp for view dimensions, margins, and paddings. Use sp for text sizes.
No comments:
Post a Comment