I have some concern regarding the creation of existing android project written in Java language to kotlin language:
Can I create it from scratch.
Can I use same package name with same keystore and play console account.
Can I use same firebase config file for using firebase services.
I am asking all this because when I was recreating the project in debug mode it say uninstall the previous version to continue.
Thanks.
1)Yes, but you don't need to. Kotlin code can call java code, and java code can call Kotlin code. So you can convert 1 file or 1 part of your app at a time.
2)Yes. In fact I'd suggest it, unless you want to lose all your old users. The play store doesn't care if the language changes.
3)Yes, none of those services care about the language the app is written in.
A brief answer to all of your questions is "yes, you can. Absolutely!".
And for the configurations and stuff, Android Studio itself can handle it for you. Also, if you have already had a project, so you just don't need to re-create it from scratch in order to use Kotlin. You can just use a feature that Kotlin already has, which is interoperability (in this case, with JVM libraries or frameworks). So you can call Kotlin code from Java (in your current project) without an issue.
Related
As a team member, we work on creating an Android app with Github. We use PR's and code reviews. We also use Android Studio for development,
It's hard to do code reviews to the layouts without actually seeing them. I was wondering if there is some tool or method to share an instance of application in order to see changes?
Each member could simply clone the PR branch and perform the QA locally, I suppose.
I'm trying to write a barebones Vulkan app on Android. I'm finding that most of Google's example apps rely on vulkan_wrapper.h and vulkan_wrapper.cpp. Google's Vulkan documentation also says to use them.
I would love to use them but they are part of the example projects' code, not the SDK, and the header says that they are generated. So how is a developer supposed to generate them for their project? I have copied them from a sample app for the time being but am curious what the best practice is for generating them and keeping them up-to-date.
I'm not sure how they're generated, but you could just copy them into your project. There shouldn't be much need to regenerate them, since they only contain the core and WSI extension entrypoints normally provided by libvulkan.so; even if you regenerate it, it won't contain other extensions that might have been added to vulkan.h.
The only reason to use these is if you want to avoid linking against libvulkan.so directly, which only matters if you want your app to load and run on devices that don't have it (Marshmallow and older).
Not sure How they get generated but you can do something like that if you want it to. Vulkan layers come with the scripts and the xml file, you can modify the script to your requirements. We are already doing that in our projects. The script can be found here.
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/tree/master/scripts
We have one mobile project fully developed in native android using android sdk.
we want to migrate the code base to kotlin completely. So wanted to know what are
main things to keep in mind while migrating to Kotlin.
Before you convert your project from Java to Kotlin keep things in your mind.
Converting from Java to Kotlin will may cause your git track. Refer to avoid this problem
Android studio provide easy way to convert Java code into Kotlin in a automate way [Press Ctrl+Alt+Shift+K]. But it may arise some conflicts like "Some code in the rest of your project may require corrections after performing this conversion. Do you want to find such code and correct it too?". For example in your java file contains static variables. Because kotlin didn't support static. In this case you have to manually correct it. It took some time.
While developing you may maintain many branches. If you converted one file from Java to Kotlin will affect other branch.
I don't recommend to switch full code automatically to Kotlin.
The tool for converting to Kotlin is great but you have to review all code generated by the tool. Sometimes code generated are not really readable.
Java and Kotlin can be use together. You can convert files one by one. You have time to check and clean the converted code.
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 have an Android app that's downloaded primarily from Android Market (now, Google Play). We made a few tweaks to the source and also submitted to the Amazon App Store to see what sort of traction it gets. I'm now looking for a sustainable way to develop from a common code base and yet build so that I can submit to either/both.
Amazon's store has some restrictions about available APIs, and hence I'd like to conditionally remove/modify features from that version. Since Java doesn't support traditional conditional compilation, and conditionally including files in Eclipse doesn't seem trivial (is it even possible?), I wanted to ask what others are doing to solve this.
Admittedly, I'm no Eclipse/Java expert so feel free to school me.
What I'm looking for in a solution:
Building/debugging using Eclipse.
Static code files, with environment/settings toggles to control what to build.
No duplicate code or conditional logic in code to pick code flow at runtime
Is this something you've solved for Android apps specifically, or for other Java/Eclipse based projects? Suggestions for where to begin?
It's quite easy to do in the newest versions of ADT (version 17), though I do find it makes compilation a bit longer:
Create a new Android project (proj-A)
Go to Project->Properties, select Android, and check "Is Library"
Move all your common code to proj-A, import all the necessary libraries
Create a new Android project for Google Play (proj-B)
Go to Project->Properties, select Android, and add Proj-A to the Library
Repeat #4&5 for the Amazon version
If you have some variables that should be set differently for each sub project (i.e. boolean GOOGLE_PLAY_VERSION to enable Google Play specific functions), you have to create another project to contain these values since you can't have projects that reference one-another in a circular fashion. You can solve this by adding the following steps:
Pull all of your sub-project specific variables into one or more Classes that just serves as container(s) for these variables
Create a "dummy" Java project (dummy)
Config proj-A to add a new Source link to the bin directory of dummy
Add the config Classes in each sub-project with project-specific changes
Profits!
Note that the variables in dummy should not be set as final, otherwise it will override sub-project's setting.
This may seem like quite a bit of up-front work, but has worked quite well for me as far as version control goes.
Edit:
Now with Google's move to Android Studio & Gradle, it may be better to move to that if you are starting a new project if you want to support multiple APKs, see Android dev site's Building Your Project with Gradle#Work with build variants. It definitely doesn't hurt to evaluate that option before deciding.
Unfortunately, it's sort of a convention in Android to change flow at runtime based on what would be in C/C++-land conditional compilation.
Our app has to maintain different behavior for different API levels, so we've created some application-level constants that are initialized statically based on API-level information available to us, and used throughout the code. This is the way that Google does things in their examples (for example, see the ActionBarCompat compatibility library, and in particular the factory method used here).
You could create an interface CustomBuild, and implement it in AmazonBuild and GooglePlayBuild, then use a static getBuild() method to switch functionality as necessary:
if(getBuild().shouldEnableFeatureX()){
doStuff();
} else {
doDifferentStuff();
}
Then all you've got to worry about switching between builds is a line or two of code in the factory along with maintaining which things you want enabled in which versions. Or you could include a different version of a static class CustomBuild for each build.
I'm going to second the suggestion of others above re: switching to something like Maven for building; it should make your life much easier once you have it set up.
I'm also going to say you should make the core of the app a library as suggested above, and have two different modules (one for amazon, one for play store) that depend on the library but each only contain the one custom factory file (or just a static class for each type of build that contains the same "should I do this thing?" methods... once you have the infrastructure it's just a matter of preference).
I haven't actually tried this yet, but it's something I've thought about.
How about using Eclipse's ability to link to files from a directory outside your workspace?
Start with one Eclipse project: for the sake of argument, say it's the Google Play version.
Now build a second project, beginning with asking Eclipse to link (not copy) the source files from your first project.
To develop the second project, add classes that subclass ones from the original project to realize your modifications. For resources, you can use some combination of includes, attribute overrides, and selectors.
Where it's not possible to subclass or extend, then obviously you'll have to just copy the original source file and hack on it. If you're really OCD about it, you can probably just maintain a patch set rather than a whole redundant set of files.
What do you think, will it work?
You may create manually two projects in Eclipse pointing to the same source folders but with different inclusion/exclusion filters and different target directories.
Then two Ant targets using properties to switch excluded files from javac fileset are enough to generate corresponding jar files.
The aim is to get a clean application for each target, without any code from the other one.
With features listed as pluggable behaviors in a property file or XML configuration, your runtime will adapt itself with the addition of menu entries.