How can I avoid using the app's package name in source code?

Question

My Android app source code includes this line:

import lfreytag.TideNowOR.R;

In order to use this source code in different projects, I would like eliminate the package name from the import, since I have to change it each project. I am using Android Studio. In other apps based on this source code, the package name last part varies such as TideNowOR, TideNowWA, TideNowCA, etc.

As background, I am trying to place all version-specific information inside the RAW directory as simple text files. So I can generate a new version with just changing the manifest and dumping in new collection of text files. Thanks.

Answer 1

You could package it up into an Android Library Project (AAR). That will let you share your code, and resources, across different programs.

Answer 2

Say hello to Android Studio Flavors!

Not only that you can create multiple builds with one command, but for each build you can specify its own package name and folder structure.

I would speak more about this but there are plenty already who done this all over the site.

Here is a great link: Using Build Flavors - Structuring source folders and build.gradle correctly

Answer 3

Long story short, don't worry about changing the Java package name. In fact, I would remove any specific identifiers from it so that it is generic, like com.lfreytag.tidenow.

When the new Gradle build system was introduced, they added the possibility to split the package name into two uses. One is the Java package name: this is the one that you reference in all of your Java code in import statements, and it makes up the directory structure of where you keep your .java files. The other use is the name that identifies your app to the Android package manager, which is now called applicationId. The two can be different, so that you can use the same code.

The R file is generated according to what you have set in AndroidManifest.xml as "package". This should be your more generic Java package name. In your app's build.gradle, set applicationId to the specific identifier that you want the Android OS to know about, which would probably include the name of the state that you are building for. More information on this can be found here: http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename

The cool thing about Gradle is that you can use flavors to set the applicationId for you, and it can be smart enough to include the correct files in the build process if you set it up right.

For example, in build.gradle, define your different flavors inside the android.productFlavors node like this:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"

    defaultConfig {
        applicationId "com.lfreytag.tidenow"
        minSdkVersion 7
        targetSdkVersion 23
        versionCode 1
        versionName "1.0"
    }

    productFlavors {
        wa {
            applicationId "com.lfreytag.tidenow.wa"
        }

        or {
            applicationId "com.lfreytag.tidenow.or"
        }

        ca {
            applicationId "com.lfreytag.tidenow.ca"
        }

        ... etc ...
    }

    buildTypes {
        ...
    }
}

dependencies {
    ...
}

Then, in your src directory, create new subdirectories named the same as the flavors, such as src/wa, src/or, src/ca, and etc. Within each of these directories, place your flavor-specific java, res, assets, and other directories.

When you pick your flavor to build, either via the Build Variants panel in Android Studio or via gradle, such as ./gradlew assembleWaDebug, Gradle will be smart enough to override the values and files in src/main with the more specific ones in your flavor directories.

Answer 4

When using java, remember that the package is the namespace that practically allows the programmer to keep your code organized. Please check this oracle's link to learn what it is and why you need it.

Now, is it possible to not use the package in the source code? May be, but surely is not very convenient, as you would have to tell the compiler where to find all of the classes you need, that would imply to set up a very heavy classpath(learn about class path here).

It may be possible that you do this for very simple java apps, but who knows what kind of ton of work you would need to do for a more complex app, like an android app.

In conclusion.. if it is not broken, don't try to fix it.

Answer 5

First, it's not too difficult to create a script that will go through your files and change the package name. So if you really just want to change the package name, I would run a script to change the package name and viola, you have a new app.

However, I would suggest this approach for your situation:

1. Create an Android Studio project
2. Make your present "application" a "library" module
3. Have as many "application" modules as you want inherit that library
4. The strings.xml in the "applications" will override the strings.xml in the library.

So, instead of trying to put the strings into the Raw directory, use the strings.xml as Android was designed. The Android Gradle compiler is pretty intelligent. If you have the same string defined in a strings.xml in the library module and in the app module, it will pick the app module's strings. That way you can implement multiple applications with different strings.

EDIT:

Another possible solution would be to include all of the files in the project and then switch which files are displayed for each individual app based on a criterion – like the app's name or package name. There is a Context.getPackageName() but that cannot be used in an import statement.

Another EDIT:

Basically, by choosing to put the files into the "raw" directory, you are tying the files to the package.R import. If you used the assets folder, you could get around that.

Answer 6

I'm not 100% sure what you're asking but I think the question is based on a number of misunderstandings that I'd like to eliminate.

import lfreytag.TideNowOR.R;

Is importing the references to the resources defined in a specific module (http://developer.android.com/sdk/installing/create-project.html#SettingUpLibraryModule). These resources include everything in the res folder (strings, ids, drawables, layouts etc.).

This import has to include the package name because that name is the namespace for your code. Namespaces are an essential element of all modern programming languages to avoid name collisions between multiple identifiers that share the same name.

The way to use common code in different projects (assuming you use Android Studio and Gradle to build) is to:

1. Create a separate project and add that projects as a dependency to your different apps, see e.g. here: Android studio add external project to build.gradle
2. Create a library module and reference that module in your app module: http://developer.android.com/sdk/installing/create-project.html#SettingUpLibraryModule
3. Use flavors to use different package names and "version-specific information"

In the first two cases the build tool will take care of "converting" your library lfreytag.TideNowOR package name to your app package name lfreytag.TideNowWA or whatever you need. It will basically create an aar package for reuse in other projects/modules.

From your description option 3 seems to be the best option and I'd like to explain how you could structure your project to be able to have the common code and different "apps".

The screenshot shows one of my projects that has a main node which would be your lfreytag.TideNowOR code you want to reuse in your different "apps". It can contain all the elements of a typical Android project like the actual Java code, resource files and files in the assets folder.

The app has different flavors and those flavors map to what you refer to as "apps" (in the screenshots the flavors are the free, pro and pro_amazon nodes).

A flavor is a variation of your app and can define its own package name, have its own manifest, set variables to be used in the manifest (e.g. the app name or ContentProvider authorities) or in your code (flags to distinguish different flavors, flavor specific strings etc.).

To use different package names in the manifest for the different flavors (or your "apps") you'd define the applicationId in the build file like so:

    defaultConfig {
        applicationId "lfreytag.TideNowOR"
    }

    productFlavors {
        wa {
            applicationId "lfreytag.TideNowWA"
        }
        ca {
            applicationId 'lfreytag.TideNowCA'
        }
// .. more flavors
    }

To use different app names for the different flavors you'd have:

defaultConfig {
    manifestPlaceholders = [appName: "Tide Now Oregon"]
}
wa {
    manifestPlaceholders = [appName: "Tide Now Washington"]
}

in the build file and the following the the manifest:

<application
    android:name="MyApp"
    android:label="${appName}"

As mentioned before you can do much more than that but this should suffice as an example. Quintessential is that the build file is the place to put flavor or "app" specific configuration while all flavor specific files go into the respective folder (raw files, asset files, resource files, code, manifest). When the application is built, each flavor is built into an apk and so the flavors indeed become your "apps".