Yesterday a colleague of mine started experiencing a weird issue with their android studio. Whenever they’d build the code, a change would be written to codeStyleSettings.xml file automatically.

The change at the first glance was clearly unrelated to something they had been working and hence they weren’t able to figure out what could be the cause of this issue.

What did the change look like?

<Objective-C-extensions>
  <option name="GENERATE_INSTANCE_VARIABLES_FOR_PROPERTIES" value="ASK" />
  <option name="RELEASE_STYLE" value="IVAR" />
  <option name="TYPE_QUALIFIERS_PLACEMENT" value="BEFORE" />
  <file>
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Import" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Macro" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Typedef" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Enum" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Constant" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Global" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Struct" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="FunctionPredecl" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Function" />
  </file>
  <class>
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Property" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="Synthesize" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="InitMethod" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="StaticMethod" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="InstanceMethod" />
    <option name="com.jetbrains.cidr.lang.util.OCDeclarationKind" value="DeallocMethod" />
  </class>
  <extensions>
    <pair source="cpp" header="h" />
    <pair source="c" header="h" />
  </extensions>
</Objective-C-extensions>

Clearly it wasn’t something related to our code since we aren’t doing anything with Objective-C in our android project. This made me want to check the android studio config on that machine, to see if some preferences were changed by mistake, or through an update or any other means.

Quickly searching for objective-c, I found that there were changes being written to the Inspections in the IDE. However, the dev denied making any such changes.

What do you think was the next obvious step for me?

Turns out, this was an old issue that someone asked about, on StackOverflow 3 years ago, and this, was the top rated and accepted answer that led us to the solution.

The <Objective-C-extensions> Section is added by the Android NDK Support Plugin. Which was added in 1.3 and is activated by default. 
If you have activated this plugin it adds the Section to your codeStyleSettings.xml. Otherwise it will be removed.

Answer by devtribe

Even though the dev had not activated this plugin on their own, maybe an update introduced this change and started causing this weird behaviour.

Here are the steps to fix the problem:

Step 1: Open Preferences in your Android Studio. Shortcut on Mac OS is Command + , (comma) and on Windows is Control + Alt + S
Step 2: Goto Plugins and find the Android NDK Support plugin
Step 3: Uncheck the box to deactivate this plugin, As soon as you do that, a warning dialog will appear asking you to disable Android APK Plugin, Click OK
Step 4: Once deactivated, click on Apply and restart your Android Studio!

Now you can remove the file from your git change log if it appears there, restart Android Studio and the problem would be fixed.

Warning: The solution requires you to disable two plugins which you might want to use at a later stage, so keep that in mind before you do that.

Since git is an integral part of my development life cycle and I spend quite sometime committing things to it, I always felt there was something missing, until I did my Android Nanodegree at Udacity where I learned about structured commits.


Why structure your commits?

  1. Keeps your git history neat & meaningful.
  2. Easy to generate change logs

Lets look at how I structure my commits.

The Commit Prefixes

  • feat — a new feature
  • fix — a bug fix
  • docs — changes to documentation
  • style — formatting, missing semi colons, etc; no logical code change
  • refactor — refactoring production code
  • test — adding tests, refactoring test; no production code change
  • chore — updating build tasks etc; no production code change

But you’ll be wondering how is it productive when you have to type those tags into each commit message.

So here’s a script you might want to see

https://github.com/ishan1604/productivity/blob/master/commit

Just put it into your PATH and access it easily like so

$ commit feat

So now when I do

git log --oneline --decorate --graph

Here is what it yields

This is just half the fun

Now when I want to generate a change log, I have a python script that picks up all the commits with the tags feat or fix to generate a change log for me.

Here is the python script

https://github.com/ishan1604/productivity/blob/master/commit

So the output of the python script looks something like this in a change-log.json file

{  
"features":[
"feature 1",
"feature 2",
"feature 3"
],
"fixes":[
"fix 1",
"fix2",
"fix 3"
],
"major":0,
"minor":9,
"patch":11
}

You can then use this to easily curate your CHANEGLOG.md or tell your boss what you did over the last X days.

You can change this variable in the python script on line number 14 to generate the change log from the date you want

afterDate = '2016-09-12'

I’ll be adding more productivity related stuff to it soon. Till then you can give some love to the repo.

https://github.com/droidchef/productivity/