So I'm building an application with a dev, test and release version. I have additional fragments in the dev and test version which I don't want to show up in the release version. Currently hide those fragments in the actionbar and prevent the user from swiping to different fragments (thereby preventing them from going to the hidden fragments).
I have a final static variable which I set to dev, test or release which then builds the app with/without the tabs. Can I make it somehow that it doesn't even compile those fragments in the release version? I know I could possibly recreate 3 projects with the differences in them but I was looking for just one copy of the source code so I don’t have to keep track of changes in the core app.
If the fragments are totally unused in some builds, you can use the ProGuard tool to remove them from the APK.
Yes this can be done, all you need to do is to use Gradle based new build system.
One goal of the new build system is to enable creating different
versions of the same application.
There are two main use cases:
Different versions of the same
application For instance, a free/demo version vs the “pro” paid
application.
Same application packaged differently for multi-apk in
Google Play Store. See
http://developer.android.com/google/play/publishing/multiple-apks.html
for more information.
A combination of 1. and 2.
More detail here http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
Related
I have a source code for android project and I want to integrate and embed this app inside another app ...
In other words, I need to mix 2 apps with different packages inside one app ...
Thanks for your help and waiting your review..
It depends on what you mean by "mixing two apps":
If you want to store the two projects in the same repository, you can do that without any problems.
If you want to have them in the same project to be able to edit them at the same time, why not open them both simultanously in two separate windows? When opening the project, Android Studio will ask you whether you want to open the project in this window or in a new window. Just click "New window" and you will be able to edit the projects side by side without any fancy mixing going on.
If you wish to reuse the code from one project in the other project, consider creating an android library module. That way, changes in the common code will automatically be reflected in both projects whereas when you copy-paste the code, you will have to copy changes back and forth, too.
I'm a C programmer doing some Android development using Eclipse and my application needs to have several different variations for "private labeling" for different companies. These variations will have different strings on the GUI, different backgrounds for the home screen (containing the companies logo for each of the different companies), different app icons, different app names, etc.
So far every time I've released an update I've gone through and manually changed each of these things in the code and resource files to build a custom apk for each of the multiple companies we are providing the "branded" app for... which is a pain in the ass and fraught with potential error.
In C I would just set up build configurations with different predefines and trigger code in or out based on the predefined values. Then I can just switch the configuration, build the project, switch to the next configuration, build the project, etc.
There has to be a way to do this with Eclipse... please tell me there is!
If you're using Maven to build your project, Maven profiles feature is what you need.
I built our application using the Netbeans Framework. It's working great, we have a bundle of modules that we update using NBM (NetBeans module files).
When we ship out our product, our customers install it, and it comes default pointed to our update center web server. There it pulls the current updates.xml, containing the version number etc and downloads the relevant NBM file to update a module. It works well.
However, we have a module that's out, and I would like to push an update that would deactivate it, or even uninstall it.
I accomplished a quick fix by closing it immediately with this.close(). It's a top component so it opens by default, and it's basically a useless module right not. It causes clutter initially.
That to me is a total hack, there must be a graceful way to accomplish this in the Netbeans NBM delivery system.
I can provide some code, but I'm unsure what is helpful. This is OOB Netbeans framework functionality, so there's not a lot to show.
Thank you
Some ideas:
Post to one of NetBeans mailing lists where you can get answer from developers (https://netbeans.org/community/lists/index.html)
Add a ModuleInstall class to another module that will run a code as a part of startup procedure. Search lookup for ModuleInfo representing module that should be disabled and call ModuleManager.disable() (likely requires dependency on some internals / non-public API)
Keep the module as it is but add another one depending on it and override the top component there (make it non-vosible by default, hide action to show it, ...)
I recently started learning about Android app development. It's also my first experience with the Java language.
There are some debugging tools that I want to incorporate into my app development in a form of Java package dependency. For obvious reasons, I would like to include it only for debug builds.
In iOS, we can use build configuration to link with debugging libraries only for debug builds, and use macros to remove parts of code that deals with debugging. This makes it really easy to switch between debug and production builds. Anyway to achieve the same for Android?
So far, the closest I got is using Maven profiles to overwrite properties files, which gets loaded by the application, but this requires that the debugging libraries are still imported.
To clarify my question, here is what I want to do:
I built a library that will let you browse the SQLite database on your browser. It's really useful for debugging purposes, but I don't want to ship my app with the library.
Another purpose is to use HockeyApp. HockeyApp provides two features: Update notification, and crash reporting. I need three different builds for this to work:
Production: Crash reporting On, Update notification Off
Beta: Both On
Debug: Both Off
In the manifest's <application>, you can set the debuggable attribute. Eclipse does this for you automatically if you omit the attribute. Debug builds have debuggable=true, well exported builds have debuggable=false.
This affects Log.d, and you can conditionally check in code using the following:
boolean isDebuggable = (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE));
In addition to Maven, one way is to use a dependency injector like Dagger
By building on standard javax.inject annotations (JSR-330), each class is easy to test. You don't need a bunch of boilerplate just to swap the RpcCreditCardService out for a FakeCreditCardService.
Dependency injection isn't just for testing. It also makes it easy to create reusable, interchangeable modules. You can share the same AuthenticationModule across all of your apps. And you can run DevLoggingModule during development and ProdLoggingModule in production to get the right behavior in each situation.
One way to solve this is to check the return value of PackageManager#getInstallerPackageName. It returns null if the apk was installed manually through adb, through a web page, or through a service like HockeyApp. In fact, I recently added a similar check to our sdk, see this commit.
Note that this solution is only reliable if you only distribute your (paid) app though Google Play. Last time I checked, alternative stores like the Amazon App Store or AndroidPIT were not setting the installer source (it is possible to set it since API level 11, see PackageManager#setInstallerPackageName).
Another option is to check the package name at runtime. For your beta builds, you would append ".beta" to the package name and then check for this suffix to enable in-app updates or debug stuff. You can do this by moving your code base into a library project and set up two app projects that reference this library project: one for the store app, one for the beta app. Our use aapt with the option --rename-manifest-package to change the package name of beta builds (see details here).
do you have use BuildConfig.DEBUG, this is created by android adt tool
/gen/BuildConfig
My Android main application will consist in a main program, with a few pre-installed modules.
Then I want to offer different modules later, best would be as separate files. Modules like: location, weather, agenda.
How would you accomplish this?
I want to keep in the database the modules that are installed/present. So I must put sometimes the modules into database, maybe by detecting if there are present at launch time. The main app will work based on these modules.
How can I build these modules as separate files? They won't be an entry point in my application. So they must not be an application in the navigation menu.
Is this possible?
How do I have to create this using Eclipse?
In what format will I offer the modules?
How will the user add/remove modules?
Android allows you to loosely couple applications together with Intents and ContentProviders, so it should be possible to achieve what you're looking for. The hard part will be planning everything up front, so you have logical divisions of functionality (and so things plug together easily).
I want to keep in the database the modules that are installed/present. So I must put sometimes the modules into database, maybe by detecting if there are present at launch time. The main app will work based on these modules.
You can register a BroadcastReceiver for ACTION_PACKAGE_ADDED, which will fire whenever a new application is installed. Your main application should be able to use this to determine when additional modules are installed.
In what format will I offer the modules?
You probably want to still package the modules as apks so they can be uploaded to the marketplace. If you want them to not appear in the launcher (the app drawer), you can always remove the default <intent-filter> and the app will not be launchable (but still be removable).
How do I have to create this using Eclipse?
Your modules would still be standalone applications.
How will the user add/remove modules?
From the marketplace or direct downloads off of the web (if you want).