I have now switched to Android Studio and saving my projects in Git with Source Tree. Whenever I add or remove any library from my module, its .iml file also changes. It really doesn't matter if I commit the *.iml because they get auto-generated in others Android Studio. However, here
it says you should store *.iml . My question is, do we really need to share our *.iml with others? If yes, why?
General best practice is to:
make projects as IDE-agnostic as possible,
do not commit generated files.
So the answer is: it's better to make such files ignored for VCS.
Yes, .iml Files are suitable for version control (see this comment)
It is also true to make projects as IDE-agnostic as possible, however, sharing .iml files does not break anything for people developing with another IDE. For them, they are just a bunch of relatively small files that don't concern them.
A good practice for teams using different IDEs simultaneously is to store each IDE's project files in the VCS, only excluding those which contain paths, environment variables etc. specific to a single developers environment. This way, anyone using one of the supported IDEs can enjoy the benefits of a proper, shared setup, like for example:
sharing build configurations
sharing dependencies
configurations for automatic code quality checks
There are more use cases, depending on the specific IDEs in play.
Edit: For IntelliJ, also see this FAQ
I agree that they are IDE-dependant files irrelevant to code and they should not be shared. But, then you should know how to regenerate them.
You may encounter with situations while your remote repo does not contain these files and when you clone the code and open in IDEA, it just shows a bunch of errors. Why? *.iml files are not regenerated.
You must import from IDEA with "File" - "New" - "Project from Version control". Only this can generated the files for you.
Rule of thumb - "Anything thats can be generated from source code should not be checked in" .
Related
Well I face this situation for long time in multiple projects. I always solve it on different ways, but I would like to know what is the best solution and explanation why this happens.
For example I git cloned new project from git and imported it in my android studio. At the beginning I am on master branch. Now I want to change to UnitTesting branch. But when I try to do it, I get message:
"Your local changes to the following files would be overwritten....". And it shows me misc.xml and gradle.xml files.
Why are these files changed and I don't have identical project that I cloned? I guess they contain some settings info related to the IDE that I use locally and the author of project on git has so it makes some differences to adapt project to my IDE..? Can I get little bit explanation.
And what is best approach to solve these kind of situations.
Thanks in advance!
We have decided to follow the process of creating a new SVN branch for every new feature that we add to our mobile app. The ultimate goal behind this is to preserve the history for every single code change (this doesn't happen when we manually copy project folders into SVN instead of creating & merging branches).
My problem is that so far I am unable to merge changes from one branch to another.
I have already referred the following posts without success:
How to merge branch with trunk using SVN in android studio.
Android Studio Update Project: Merge vs Rebase vs Branch Default.
How to merge branch to SVN with Android studio.
How do merge specific svn revisions from branch to trunk in Android Studio 2.0.
Here is what I have tried so far:
I have two feature branches as can be seen below in Tortoise SVN:
I want to merge the changes in the branch Feature_A3 into branch Feature_A2. To do this, I am using the Merge from option in Android Studio's VCS from the A2 working copy:
It then asks me to select the branch to merge from (A3) or configure other branches:
I click on Configure Branches, just to show you the existing branch config:
As you can see, A2 is the Trunk and A3 is the Branch. Is this correct?
It then asks me what part of A3 I want to merge into A2. I select the /src directory (where the relevant changes are present):
It then generously gives me three different ways to perform the merge operation:
I select the third option as it directly gives me the changes I need to merge:
I click on Merge Selected and BAM!!! I get this error every time:
There is no clue as to what the "unresolved conflicts" or "skipped items" are. Why am I getting this error, and what should I do to merge the changes in A3 into A2 ??? Can someone please help ? All answers will be appreciated. Thanks ...
I have been following the official Intellij IDEA documentation below:
Integrating Changes To/From Feature
Branches.
Merging, Deleting, and Comparing
Branches.
Please note that:
Currently I am using Subversion, not Git.
The directory structure of my local working copies is not exactly
identical to that of the SVN repos. Could this be the cause of the error ?
THE ANSWER ...
Thanks to Peter Parker and especially Yoav Aharoni for their valuable feedback. As Yoav correctly pointed out, it was indeed the manner in which the branch locations folder was specified. It needs to be the folder containing the branches, not the branch folders themselves: And as Peter rightly said, checking "Include merged revisions" shows the merged history. I am now able to merge from within the IDE itself, and view the merged history in TortoiseSVN.
NO command line! YAY!!!
However, one last problem is that I am unable to view the merged history in Android Studio (Intellij IDEA) as described in Viewing Merge Sources. Does anyone know how to achieve this in Android Studio?
Phew, haven't used SVN in a while... :)
But from what I can remember Branch locations should be the folder containing your branches folders (and not each individual branch folder).
You see, typically a SVN repo follows a standard naming convention and folder structure:
trunk/
branches/
Feature_A2/
Feature_A3/
tags/
v1.01/
v1.02/
and so on...
trunk is where the main development takes place, and branches are for features, long-term or risky projects, or for different stages (such as QA and pre-prod).
So, as far as I remember, Android Studio expects you to set Branch locations to branches folder. In your case I think it should be http://192.168.0.64/svn/.../Android/Feature.
Also, your trunk is not Feature_A2 - Feature_A2 is just another branch.
Although I can't see the content, I think http://192.168.0.64/svn/.../Android/Development might be your trunk.
Which shouldn't bother you much, since you don't have to merge to your trunk, you can also merge between branches (e.g. merge Feature_A3 into Feature_A2).
So, to recap:
Although not mandatory, I recommend renaming your folders to match the conventions (you can easily do it by right clicking in Tortoise SVN, but only AFTER all teammates commit, otherwise merge will be a HELL for them).
Try setting Branch locations to http://192.168.0.64/svn/.../Android/Feature
And Trunk to http://192.168.0.64/svn/.../Android/Development (only if it indeed contains sources, similar to Feature_A2/3)
Consider "tagging" your releases in a tags folder (it's pretty much just copying the trunk/branch folder to tags, but you have a command for that).
If you do so, you can also add tags folder to Branch locations, that way you'll be able to compare your current source with any previous release (which is handy).
P.S: "unresolved conflicts" error can also mean you have unresolved conflicts (duh :)). Conflicts are are usually created when both you and a teammate change the same lines in file (or if he deletes a file you changed) and you update to get his changes.
SVN won't let you merge until you manually resolve these conflicts/changes.
You can find conflicts in the Version Control tab at the bottom, they'll be mark in red.
(But I don't think that was the problem in your case)
Let me know if that works for you!
I'm not an SVN expert, but I think you will need to change you directory structure. I believe that even though it is just a convention, svn uses the directory structure for merging of branches. So your directory Structure should be:
SVN
/Android
/branches
/production
/featureA2
/featureA3
/tags
/trunk
/IOS
/branches
/production
/featureA2
/featureA3
/tags
/trunk
Even though the TortoiseSVN Repo-browser will allow you to move your directories around, a lot of meta-data is stored on each directory and is used to handle the merge process, so you may have to start your repo again. See the subversion best practices guide and strategories for repository layout for more details on how to setup your repos. All that said, I would hesitate to rely on Android Studio's svn integration to do heavy lifting like merging of branches as (although most things in JetBrains tooling is fantastic) it's handling of SVN leaves a lot to be desired.
I understand this might be an extremely obvious and ridiculous question to ask, but please excuse me as I'm a beginner. I want to integrate this file into my project so I can call its methods:
https://github.com/RomainPiel/Shimmer-android
The question is, what do I do with it? Is it considered a "module", "library" or "file"? Should I manually copy the source files and create new classes in my project, and then call the methods from there? This would be the most straight-forward but in the "how to use" section in that package, it was mentioned "compile 'com.romainpiel.shimmer:library:1.4.0#aar'"
What I tried:
I downloaded the file as a .zip and then File->New->Import Module then navigated to the unzipped file. I believe I'm then supposed to add "compile 'com.romainpiel.shimmer:library:1.4.0#aar'" so I went to the gradle file to try to add it.
There are two: build.gradle (Module:app) and (Project:ProjectName).
I've tried adding to either and\or both and got this error: (Error:9,0) The project 'ProjectName' may be using a version of Gradle that does not contain the method. Did I do something wrong? Is it supposed to be this easy?
I would be extremely grateful to anyone who can point me in the right direction :)
You have three option
Using the GitHub Desktop you can clone the project and open it like a local project. Every change you make will be tracked. You can then commit and push using the GitHub Desktop. It's all UI and simple to use.
https://desktop.github.com
On Android Studio, when you open it, you'll see this, select GitHub and continue by adding your credentials.
You can then commit and push directly from that.
Using the terminal / command line.
If you are new, I recommend the first. It's simple to use and you get a hang of using it as it is the same steps with any project on any IDE you use.
Note: Downloading it as zip and then using it a bad idea because you're making it difficult on yourself because you can't keep track of changes and you'll have to re-upload everything every time. Which defeats the purpose of version control
If that GitHub account is not yours, then you'll have to fork the project, this way you'll have a separate version of the code on you GitHub on which you can modify. If it is yours then you're good.
Typically, you do not want to include external source code manually. This inhibits your build tool's (i.e. Gradle's) ability to manage that source code. It's very easy in Gradle to, say, set the version (like you have done by specifying "1.4.0") and then later remind yourself what version you have by merely looking at your build.gradle file. However, how would you go about doing that with raw source code? Typically developers do NOT put the version number of the source code in the actual source code - that's what they use their version control system (e.g. git) for, usually with tags.
Another aspect of Gradle is downloading and caching (and compiling) the external project for you. So that's nice.
With that said, you typically want to put that "compile..." line in your module's build.gradle file. Not the Project's build.gradle.
A module corresponds to your application (or library) that you are building or using. Some project's have multi-module configurations, where one module acts as a dependency for another (or several others). A Project in gradle is more of a 'meta' configuration that you can apply to all of your modules. The gradle docs recommend you focus on your module's configuration first and adjust the Project's configuration only if you have a specific need and reason to do so.
For the error you mentioned, you might have some unnecessary configurations in your build.gradle file, or the tool version numbers might not reflect what's on your system - if you copied and pasted from the internet, you might want to correct this by letting your IDE generate that file (the brute-force approach would be to create a new project entirely, and use its build.gradle files as a reference). Before you do that, you might want to check if your IDE provides any warnings inside that file.
You have to add the dependency to your module's gradle file.
There are two gradle file present in an android project. One is the project gradle and the second is the module gradle for each individual module.
You just have to copy the given
compile '......' in the dependency block.
I have a mature app that needs to have an SDK brought in that wraps the camera and makes it do some spiffy processing while it's running. The SDK has come to me in the form of some aar files but my app still lives in Eclipse. Because of my massive, steaming pile of a branding structure and deadlines for this integration the uncertain timeline required to fully migrate to Android Studio will not work (for now) so I'm going for converting the aars and using them in my app via Eclipse.
The problem I'm having is that I need to kick off the activity in the library but even though I fixed up all my build time reference problems, when running the app once I get to the point that is supposed to kick off the activity I get this error.
I've read through and double checked dozens of how-tos explaining how to consume the aar files and I think I've followed every step including:
Unzip the aar files and dress them up as individual library projects, including the file structure with the resources, the manifest, and the .jar
Make the project that needs the libraries add them as such
Add the .jars contained in the library projects to the build path (this step was not listed in most articles, and wasn't necessary for the project to build, but nevertheless it did not help my problem)
Declare the activity in your AndroidManifest.xml that the library brings in and declares in its AndroidManifest.xml
As I've said, everything looks good at build time, so I'm not sure what else to check. Because I'm reading that Gradle and Android Studio mashes manifests together really well, I have a hunch that it's something I'm supposed to regulate between the manifests but I don't know what it could be if that is it. I've wondered if I'm declaring the 3rd party's activity properly, but I'm not sure how to test it because the only way I can think to test it is to provide gibberish for the namespace but even then there are no complaints. I've also tried dissecting the .apk to look at the .dex file but I could not decipher anything useful.
My guess is that the library may not be building properly in eclipse - even before it's being added as a dependency to the application project.
Try looking at out/classes/* and making sure you have a .class file for the activity in question. I think the .class should actually be in the library as well as end up in the application project's out/ dir also.
If there are any native files (x.so) (as I would imagine there might be for spiffy camera stuff), you can look for the x.so files being included in the out/ dirs of both the library and application projects as well as the library.jar file.
Another option to maybe consider for this use case: https://github.com/ksoichiro/gradle-eclipse-aar-plugin
It seems that our app had a bad version of the appcompat-v7 support library. The .jars in it were different sizes than the one that comes with the SDK and several resources were missing. I have no idea how we ended up that way or where this bad version came from. Once I replaced it, things went great.
Later, I did encounter the need to drop in the .so files into the libraries I made that came out of the .aar files as Stad Kurdziel said in his answer, but that was causing a different error (the exception explicitly states that the .so is missing) and I arrived at the solution independently.
I have seen samples for Mercurial ignore files for Visual Studio, amongst others.
I've just started playing around with Android development, and I also use this time to experimenting with Mercurial. So my question is: does anyone have a good example of a .hgignore file to use for Eclipse and Android development?
For starters I've got the following myself:
# use glob syntax
syntax: glob
# Ignore patterns
.metadata\
bin\
gen\
Are there any other ignore patterns that should be included? Should for instance the Eclipse files .classpath and .project be omitted from version control as well?
-- Edit below --
I haven't quite gotten the answers I hoped for yet, so I'll put out a bounty and try to specify a bit clearer what I'm looking for.
After experimenting a bit myself, I seem to have found that the suggested .hgignore listed above seems to be sufficient. The only addition I've made, is one line with .settings (this was a folder that appeared after I ran Android Tools -> Fix Project Properties). I've also found that (as mentioned by Ry4an) that the Eclipse files .classpath and .project should not be excluded.
I am however uncertain that this small ignore file will be sufficient when I get to projects a bit bigger than the basic tutorials (if it actually is all good, please explain why, and you'll get the credit). So to summarize what I'm looking for:
I want a concrete example for a .hgignore file for an Android project under Eclipse
The ignore file should be so that whenever I check out a copy of the repository at a new location, it should work straight away (i.e. without having to mess with paths and references, add missing files etc.)
Please also explain why your include file looks like it does (I want to understand why certain files/directories are excluded (and why some definitely should be included))
If you include OS specific excludes, please also state so (I'm running on Windows 7 btw.)
The eclipse files should definitely be added. The general guideline is to add:
everything that is hand written/typed
the minimal subset of everything else necessary to build the project
That last one is where your judgement comes in. It clearly excludes the .jar files you build yourself and your final .apk, but does it include third party .jar's you use? Some people do include them, but better is to include a configuration file for a dependency manager like 'ivy' which lets the next builder download the requirements they need automatically.
After auto-creating a project in my tools of choice, I'll just do a command like this:
hg status --unknown --no-status >> .hgignore
which adds the list of all unknown files to .hgignore. Then I go in and remove things I wants saved (ex: .project) and wildcard files that will grow siblings (ex: **.class)
There's a very nice sample .hgignore for Android at http://androidfragments.blogspot.com/2011/11/hgignore-for-android.html
Here is my hgignore:
syntax: regexp
\.DS_Store
.swo
.swp
.metadata/
/bin/
Whether it's a good one or not is a separate issue
well if its android projects than
local.properties should also be ignored
I have found a good example of .hgignore. It works for me.
#Mercurial Ignore Rules for Android
#Save as .hgignore in the repository base directory and add it to source control.
syntax: glob
*.class
*.apk
*.dex
*.ap_
*.suo
syntax: regexp
^(.*[\\/])?gen[\\/].*
^(.*[\\/])?bin[\\/].*
^(.*[\\/])?obj[\\/].*
^(.*[\\/])?log[\\/].*
^(.*[\\/])?obf[\\/].*
^(.*[\\/])?jars[\\/].*
^(.*[\\/])?jar-sources[\\/].*
^(.*[\\/])?javadoc[\\/].*
^(.*[\\/])?\.svn[\\/].*
^(.*[\\/])?\.metadata[\\/].*
^(.*[\\/])?\.settings[\\/].*
Source: http://androidfragments.blogspot.ru/2011/11/hgignore-for-android.html