I'm currently working on an android app that has multiple variations of itself in terms of design. (i'm quite new to android)
So far I have created a Library Module (called app) that contains all my code for the app, and two Application Modules (A and B) that use this library module. Everything works great except that now I want to have different launcher_icons for theses applications.
No matter where I add my new icons, I can't access it through /#drawable/ in the manifests of A and B.
Which led me to wonder if I was right to build my project the way i did, and if yes, what is going wrong ?
Build-->Clean Build. AS has some caches sometime. Just refresh and rebuild.
Related
Some time ago i created a wear module on existing project.
Both modules have identical Application ID and packages.
Is there any possibility to solve this problem without creating new Android Library to contain classes which i want to be shared? (I have too many files and it will take too much time to fix project)
Afraid not (there is no "possibility... without creating new Android Library"). The handheld and wearable apps are distinct APKs, running on separate devices, and cannot share code at runtime. You need to move your common code into a library that will be compiled into into both.
I'm migrating from Eclipse to Android Studio, and I've done a bit of reading. I understand the theory of Eclipse workspaces/projects vs AS projects/modules, but I'm having a hard time figuring out how to best reproduce my Eclipse setup, or if it's even what Android Studio wants me to do.
I have two applications. For the sake of illustration, let's call them EmployeeApp and CustomerApp. These are different applications in every sense - different packages, wildly different source, everything; as far as I can see, they are certainly not just product flavours.
However they both use a lot of library modules, and for the most part, they use the same ones. They also live under the same structure in the same repo.
I wrote separate Gradle scripts for both apps before this migration, and that's what I used to import them. In that way, I can import the top level applications, and end up with two projects in two windows, like this:
The trouble with this is that if someone changes a library project, they at the very least need to know whether it's broken the two apps that depend on it, so ideally I want them in the same view.
First question then: now that it's 2016, does Android Studio allow me to do that, and is it regarded as an intended usage?
If so: how do I do it? I've tried importing the missing parts of one into the other using the 'Import Module' feature, but it apparently does very little.
I think I've resolved this myself. Only time will tell if it's actually an appropriate solution in practice or not.
The problem stemmed from the fact that I'd basically created two independent Gradle scripts, i.e:
Android\EmployeeApp\build.gradle
Android\CustomerApp\build.gradle
whereas what made this work was a top-level build as well, i.e.:
Android\build.gradle
Android\EmployeeApp\build.gradle
Android\CustomerApp\build.gradle
This didn't contain much:
dependencies {
project(":EmployeeApp")
project(":CustomerApp")
}
and then build.settings simply included one of these pairs for every project:
include ':Services'
project(':Services').projectDir = new File(settingsDir, './Services')
I then imported that top level build.gradle and almost all was well.
I did have to do a bit more, like move repositories and allProjects to the top level, but this will be specific to whatever you have.
I'm working with Android Studio 0.5.8.
I have a Working project, and I want to reuse all its contents to make an almost identical app with only another name and different colors.
Basically I want to make a library from the original app and reuse it in various identical apps, but I don't want to copy & paste inside each new app, I want to maintain and develop only one codebase (the project library).
I have read and read, but I can'tt find any real solution.
I tried this in my settings.gradle:
include ':AppCopy1', ':..:LibraryProject'
It works, but I cant use any classes in AppCopy1.
This sounds like a good candidate for Product Flavors. The Gradle build system has support for maintaining a single codebase and building multiple apps from that codebase that only differ by a few files changes. See the configuration examples here: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants for details.
It's quite often that we see two versions of an android app: a paid version and a free version. I'm also developing an app that would like to release two versions. What is the best way to do this? Creating two projects and copying files in between does not seem to be the best way in my mind.
Use Library Project, as the official dev guide suggested:
If you have source code and resources that are common to multiple Android projects, you can move them to a library project so that it is easier to maintain across applications and versions. Here are some common scenarios in which you could make use of library projects:
If you are developing multiple related applications that use some of the same components, you move the redundant components out of their respective application projects and create a single, reuseable set of the same components in a library project.
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
Update: This method is really only good for compiling with Eclipse, since Android Studio supports build flavors which can achieve exactly this.
While #yorkw's and #Nate's answers are both good, this is the method I use due to its simplicity. From the article:
com.example.myapp – Android Project Library - This is where my ENTIRE app lives. All the functionality for the FULL and LITE versions.
com.example.myapp.full - Android Application Project - This is a shell that contains graphics and resources needed for the full version only. Basically it’s a super lightweight shell.
com.example.myapp.lite - Android Application Project – This is another shell that contains nothing but graphics and resources needed for the lite version. Again, its a super lightweight shell.
I also keep a static variable IS_PRO in a library class which is set when the app launches. This should be used only for notifications, alerts, and so on (such as asking the user to upgrade to pro).
However, this method has one drawback: you must clean and rebuild any time the library or its resources are modified. Also be sure to read this post on sharing resources between a project and a library.
I would call this a FORK in development. Start a new App development, but have your common code coming from a common file location. Make your free based edits to the forked code, and try your best to keep that code completely separate.
I actually did this on an iPhone based app, I have a free version and 2 different payed versions (a single player only and a multi-player). I would do it the same way on Android.
U can use git for example.
Create branch "app_with_ads", and master will be your "paid" version.
Develop in master and merge periodically to another.
before publish u probably will have to change app package, or something else in Android\ Manifest.xml
Here's a little blog tutorial about doing this.
Basically a howto for building a Full and Lite version of the same app, using a library project to accomplish code reuse between the two versions.
I know there are a lot of questions out there about multiple Android versions pertaining to free/paid versions but this might be a little different.
My app currently uses AdMob for advertising and it's published on the Android Market and on the Samsung App Store. Unfortunately, the Samsung store will require everyone to migrate to their own Ad Network in the future, Samsung AdHub. Both AdMob and AdHub have their own libraries, their own SDKs.
I'm looking for a solution to build 2 different versions, one including AdMob the another including AdHub (and all the necessary code). What solutions do I have to easily build 2 versions without much hassle when it's time for a new version release?
Lots of solutions recommend to move the main project into a library project and then build 2 other apps which include the library project (the base project). But I'm not very fond of that solution (I prefer to keep my app in one single project, if possible) and I'm trying to look for alternatives and then make up my mind about which one is better for my needs.
I'd think you should make this possible in your code using the Strategy design pattern. It suites well and can be switched at any trigger your like (even on runtime). If you make a facade for each jar file you will be able to change the dependencies while building, having the same source code.
Other option with this method is just making some configuration in your application that determines which library to use.
Some interesting solutions can be found here:
https://groups.google.com/d/topic/android-developers/8pRugcnzR_E/discussion
The way to go now is to use Android Studio and use different Gradle flavors for each app. Thus, if you fix core functionality, you can quickly do a build for each appstore with it's own ad network.
Library Projects is the way to go. Create a base project where you implement all the common stuff and then create two separate project that use the common one as a "Library". then just implement the rest needed to make the Apps behave differently.