{"id":1583,"date":"2016-10-02T06:52:23","date_gmt":"2016-10-02T10:52:23","guid":{"rendered":"https:\/\/cindypotvin.com\/?p=1583"},"modified":"2017-02-18T16:39:20","modified_gmt":"2017-02-18T21:39:20","slug":"how-to-get-started-with-android-development-basic-structure","status":"publish","type":"post","link":"https:\/\/cindypotvin.com\/how-to-get-started-with-android-development-basic-structure\/","title":{"rendered":"How to get started with Android development – Basic structure"},"content":{"rendered":"
In a previous article<\/a>, I wrote about how you can launch your first Android application from the samples provided with Android Studio. Now that you’ve had a chance to poke around a few samples, I’m going to tell you a bit about the basic structure of an Android application.<\/p>\n A good place to start understanding an application is the manifest. The AndroidManifest.xml<\/em> file links all the parts of an Android application together, including:<\/p>\n The Java code of your application lives in the java<\/em> folder. The first class you’ll create is a Activity<\/em> class, which is the main building block of all Android applications. An activity is a full screen window in which all your code will run. Each activity has it own life cycle which starts when it’s first launched and last until it is finally destroyed. <\/p>\n The user navigates between different activities in your application: the back button of the device closes the current activity by default and goes back to the previous one. If the user closes the first activity of your application, he’ll go back to the application that was previously open, if any. You can also launch other applications (with their own activities) using intents. You can use this to request an application that can send an email or play music, and the installed applications that can manage this will be displayed to the user.<\/p>\n The activity life cycle can be affected by events outside your control: for example, if a phone call comes in, your current activity (so your application) will be paused. Each activity has a layout associated with it that describes how controls that are displayed, and the activities are declared in the AndroidManifest.xml<\/em> file.<\/p>\n Unfortunately, the fact that the activity is bound pretty strongly to the navigation AND to the user interface\/layout makes it hard to separate the business logic and the display logic properly. You can create a usable Android application with only a .java<\/em> file with an Activity<\/em> class, but eventually you’ll want to move on to a better architecture. There are some patterns out there that can help you do this, but for your first application you should stick with this and avoid introducing additional complexity.<\/p>\n Resources are everything that your application needs that is not Java code, such as layouts, strings, images and other constants. The Android API uses XML for most resources. The res<\/em> folder contains all the resources of your application, such as:<\/p>\n\n
Activities and the java folder<\/h3>\n
Resources<\/h3>\n
\n