Android_Project Structure
Let's go over the Android project structure, we'll start with how the Android Studio is setting up the project structure to give us a clean overview of the important files within our projects.
As already mentioned, Android Studio will set the Android Project View as the default view when you initially create a project. This view shows a flattened version of your project's structure that provides quick access to the key source files of Android projects and helps you work with the new Gradle-based build system. The Android project view:
- Groups the build files for all modules at the top level of the project hierarchy.
- Shows the most important source directories at the top level of the module hierarchy.
- Groups all the manifest files for each module.
- Shows resource files from all Gradle source sets.
- Groups resource files for different locales, orientations, and screen types in a single group per resource type.
If the Android Project View is not enabled by default in your Android Studio, you can enable it by clicking Project and selecting Android, as shown in the image below.
The Android project view shows all the build files at the top level of the project hierarchy under Gradle Scripts. Each project module appears as a folder at the top level of the project hierarchy and contains these three elements at the top level:
-
java/- Source files for the module. -
manifests/- Manifest files for the module. -
res/- Resource files for the module.
Below you can see the difference in normal Project View (left), and the Android Project View (right). Note that Android Project View doesn't represent the structure of the project on disk itself.
App components are the essential building blocks of an Android app. Each component is a different point through which the system can enter your app. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your app's overall behavior.
There are four different types of app components. Each type serves a distinct purpose and has a distinct lifecycle that defines how the component is created and destroyed.
Here are the four types of app components:
- Activities - An activity represents a single screen with a user interface. The activities work together to form a cohesive user experience in an app, however each one is independent of the others. As such, a different app can start any one of these activities, if your app allows it.
- Services - A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface.
- Content Providers - A content provider manages a shared set of app data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your app can access. Through the content provider, other apps can query or even modify the data, if the content provider allows it. Content providers are also useful for reading and writing data that is private to your app and not shared.
- Broadcast Receivers - A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the system — for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Apps can also initiate broadcasts. Although broadcast receivers don't display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. Broadcast receivers are designed to do a minimal amount of work, and delegate to other components when an event occurs.
A unique aspect of the Android system design is that any app can start another app’s component.
Before the Android system can start an app component, the system must know that the component exists by reading the app's AndroidManifest.xml file (the "manifest" file). Your app must declare all its components in this file, which must be at the root of the app project directory.
The manifest does a number of things in addition to declaring the app's components, such as:
- Identify any user permissions the app requires, such as Internet access or read-access to the user's contacts.
- Declare the minimum API Level required by the app, based on which APIs the app uses.
- Declare hardware and software features used or required by the app, such as a camera, bluetooth services, or a multitouch screen.
- API libraries the app needs to be linked against (other than the Android framework APIs), such as the Google Maps library.
- And more
When you are declaring components in your AndroidManifest.xml, an important thing that you can do is declare the component's capabilities, so that the system knows what the component can do. To do this you can optionally include intent filters that declare the capabilities of the activity so it can respond to intents from other apps. You can declare an intent filter for your component by adding an <intent-filter> element as a child of the component's declaration element.
For example, if you've built an email app with an activity for composing a new email, you can declare an intent filter to respond to "send" intents (in order to send a new email) like this:
<manifest ... >
...
<application ... >
<activity android:name="com.example.project.ComposeEmailActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<data android:type="*/*" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
</application>
</manifest>Then, if another app creates an intent with the ACTION_SEND action and passes it to startActivity(), the system may start your activity so the user can draft and send an email.
For more about creating intent filters, see the Intents and Intent Filters document.
An Android app is composed of more than just code—it requires resources that are separate from the source code, such as images, audio files, and anything relating to the visual presentation of the app. For example, you should define animations, menus, styles, colors, and the layout of activity user interfaces with XML files. Using app resources makes it easy to update various characteristics of your app without modifying code and—by providing sets of alternative resources—enables you to optimize your app for a variety of device configurations (such as different languages and screen sizes).
For every resource that you include in your Android project, the SDK build tools define a unique integer ID, which you can use to reference the resource from your app code or from other resources defined in XML. For example, if your app contains an image file named logo.png (saved in the res/drawable/ directory), the SDK tools generate a resource ID named R.drawable.logo, which you can use to reference the image and insert it in your user interface.
Android supports many different qualifiers for your alternative resources. The qualifier is a short string that you include in the name of your resource directories in order to define the device configuration for which those resources should be used (screen orientation, screen density, etc.).
There's another big part of Android Project, and that is Gradle , or Gradle Scripts, but we are going to cover this in another page.
Comparing Ionic and Android project structures, although I know I just scratched the surface, but the Ionic project structure looks much more intuitive to me and I started adding content to the Ionic app in no time. Comparing it to Android where I'm not really sure where or how to start just yet.