Creating a New Project

Most of the time, you will be doing Android development on an existing project, such as one created by somebody else on your development team.

But, on occasion, you will want to start development of a brand-new project. You have two main options for accomplishing that:

1. Clone some existing project. An Android app project is just a directory of files, so you can make a copy of an existing app directory and modify the copy to serve as the base for your new project. We will examine that scenario later in this chapter.
2. Use the Android Studio new-project wizard to create a brand new project. This will give you a project that resembles the HelloWorld one seen in the early chapters of this book. We will examine that scenario shortly.

Key Decisions That You Need to Make

Regardless of how you intend to start your new project, you will have a few decisions that you will need to make towards the outset.

Application ID

The most important one is the application ID. This is the unique identifier for your app:

• Two apps cannot be installed on the same device at the same time with the same application ID
• Two apps cannot be distributed through the Play Store at the same time with the same application ID (and other distribution channels may have similar limitations)

From a technical standpoint, an application ID needs to be a valid Java/Kotlin package name (e.g., com.commonsware.this.is.valid). Beyond that, though, you want to try to avoid any accidental collisions with the application IDs of other developers.

The recommended approach is to:

• Purchase a domain name, perhaps one that you intend to use for marketing the app
• Reverse the domain name (e.g., if your domain is thisismydomainname.com, the reversed domain name is com.thisismydomainname)
• Append some segment to it that identifies your app (e.g., com.thisismydomainname.superapp)
• Use that as your application ID

The reverse domain name convention reduces the odds of accidental collisions with other developers. The app-identifying segment at the end reduces the odds of accidental collisions with other developers in your organization. Even if you are a solo developer, you might create other Android apps in the future, so having an application ID that is tied to a specific app, rather than just a domain name, is a good idea.

Unlike the other decisions in this section, this one will be somewhat difficult to change. In particular, once you start shipping the app, you cannot change the application ID. If you do, that will be considered a totally different app by Android and app distribution channels (e.g., the Play Store).

Project Directory

Your project files need to live somewhere!

Language

You can have a project that:

• Is Java-only
• Allows Kotlin

(there is no simple way to have a Kotlin-only project)

Switching from a Java-only to a Java-and-Kotlin project is not that difficult. However, for future-proofing, the best choice is to support Kotlin from the outset, even if you do not plan on using it for much right away.

Minimum SDK Version

The minSdkVersion indicates how old of an Android version you are willing to support.

There are competing pressures here:

• The higher the minSdkVersion, the simpler your testing becomes, because you do not need to worry about as many Android OS versions
• Also, the higher the minSdkVersion, the simpler some aspects of development become, because you do not have to do quite as many different things for older versus newer devices
• The lower the minSdkVersion, the more prospective users there will be for your app, since not everybody has an Android device with an up-to-date version of Android

From a practical standpoint, a minSdkVersion below 14 will be exceptionally difficult, as that is the minimum supported API level for the Jetpack. Certain pieces of the Jetpack have higher minimums than that, though 14 is fairly common.