As we’ve started locking down our architecture at Cuvva we reached a point where every new feature required very similar boilerplate, and building all of this by hand was getting tedious.
The obvious solution here was to create file templates using Android Studio. I won’t go into much detail as to how these are made (there’s some good resources available for this already), but I wanted to quickly share how we automated setting these up for team members.
Obviously it makes sense to store these in your GitHub repo so that your teammates can access them. But installing them is pretty annoying - you have to move them into:
Applications/AndroidStudio.app/Contents/plugins/android/lib/templates/other/$YOUR_TEMPLATES_HERE
So, can we automate this? Naively, we could add a script to our repo that simply copies the contents of templates to where we need it:
#!/bin/bash
cp -R templates/. Applications/Android\ Studio.app/Contents/plugins/android/lib/templates/other/
But there’s a couple of issues. This doesn’t support Android Studio installations with different names (Android Studio 4.1 Preview.app, for instance), and I would imagine that most Android developers run some combination of Stable, Beta and Preview. So we can improve this:
#!/bin/bash
find /Applications \( -name "*Android Studio*.app" \) -maxdepth 1 -type d -print0 | while read -r -d $'\0' folder; do
cp -R templates/. "$folder/Contents/plugins/android/lib/templates/other"
done
Neat. This worked great, but there’s a catch. For those using the awesome JetBrains Toolbox the templates folder is in a wildly different place, which looks more like this:
~/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/193.6264773/Android Studio.app/Contents/plugins/android/lib/other$YOUR_TEMPLATES_HERE
Eurgh. What’s more, Toolbox keeps multiple copies of Android Studio so you can rollback if you end up installing an unstable version. Can we handle this case too? Sure thing:
#!/bin/bash
find ~/Library/Application\ Support/JetBrains/Toolbox/apps/AndroidStudio \( -name "*Android Studio*.app" \) -maxdepth 3 -type d -print0 | while read -r -d $'\0' folder; do
cp -R templates/. "$folder/Contents/plugins/android/lib/templates/other"
done
Here we have to search a little deeper in the directory structure to ensure we find all installations, but it’s no big deal. We simply combine the “traditional” installation script with the Toolbox one, and we can ensure that any new team member gets the correct templates, no matter how they prefer to install Android Studio:
#!/bin/bash
printf "Searching for JetBrains Toolbox installations"
find ~/Library/Application\ Support/JetBrains/Toolbox/apps/AndroidStudio \( -name "*Android Studio*.app" \) -maxdepth 3 -type d -print0 | while read -r -d $'\0' folder; do
printf "\nInstalling to %s", "$folder"
cp -R templates/. "$folder/Contents/plugins/android/lib/templates/other"
done
printf "\nSearching for manual installations "
find /Applications \( -name "*Android Studio*.app" \) -maxdepth 1 -type d -print0 | while read -r -d $'\0' folder; do
printf "\nInstalling to %s", "$folder"
cp -R templates/. "$folder/Contents/plugins/android/lib/templates/other"
done
printf "\nDone. Please restart Android Studio if you don't see the new template(s)."
Going further again, we’ve referenced this script from yet another script called bootstrap.sh, which:
- Clears all file headers
- Installs our codestyle into Android Studio using ktlint
- Installs a pre-commit hook which formats all changed files using ktlint
Now when a new engineer joins the company they can run a single bash script to get up and running in seconds. I really like this way of onboarding new teammates, and then there’s no ambiguity over silly issues like formatting, or PRs getting told off by Danger.
For those with mad bash chops this is quite a simple script. But I don’t think this is a unique problem, and figured it was worth sharing to save other people some time.