A year ago as I was preparing to launch my brand new app called Twine - RSS Reader on the App Store and Google Play, I started going through the usual process of generating release artifacts, submitting the app to their respective stores, waiting for reviews and then finally handling rollouts or in some scenarios hotfixes in early stages. As a mobile developer, I am pretty used to this process, I have done this hundreds if not thousands of times, and I still hate this.

There are a few reasons why I'm not too fond of this process

• It's a manual process, generating artifacts for both platforms, tracking versioning, creating releases in respective stores and then handling phased rollouts individually.
• It doesn't scale well if I need to maintain different app variants, such as nightly builds and production releases.
• Trying to do hotfixes to these releases is a cumbersome process.

But the good thing is, I only had to do that for the first release. After that, I set up Tramline to release my app. Tramline is a service that lets you release your app without drowning in the process.

I had already used it for another app of mine called Pinnit. I loved it, so this was the first thing I set up when preparing to release the app.

In this article, I won't cover the setup process, as it's already well-explained in their documentation. Instead, I will now show what the release process for Twine looks like.

Release Process

My usual release process goes like this for Twine, I commit/merge all my changes to my main branch, and every night Tramline triggers a nightly release and deploys it to TestFlight and Google Play Internal Testing. Once I am happy with the changes, I click a couple of buttons and it triggers my GH Actions to build the artifacts with proper versioning and then deploy them to respective stores and I can manage hotfixes and phased rollouts right from the Tramline dashboard.

Now let's look at the 2 release trains (Release trains are the building blocks of the Tramline) Twine has.

• Nightly
• Release

Nightly Train 🌃🚃

The nightly release train is an automated train, that takes changes from my main branch every night and back merges them into a separate branch called nightly

During this process, Tramline handles building the artifacts using GitHub Actions, tracks app versioning using semantic versioning (semver) and generates the automated release notes for the nightly release.

In the above screenshot, two releases are skipped for the nightly release, that's because Tramline is smart enough to check if there are any changes in the trunk since the last release to prepare a new release.

Most of the time I don't do anything with this train, I just let it run automatically. But if there are scenarios where I want to test a new change immediately from the store, I do a manual release using the "prepare new release" option.

Next, let's look at the main release train.

Production Train ✨🚃

With the production release train, I don't have any automated releases configured. Instead, I do a manual release.

It goes like this, I commit/merge all changes to the main branch. Then, I click on the "prepare new release" option on Tramline.

That lets me select what kind of release I want to make, which determines the app versioning on both Android & iOS.

Once I click on start, Tramline will cut a new branch from the main branch with r/release/yyyy-mm-dd format and start the release process. Similar to the Nightly train, it starts the GitHub Action to build the artifacts and uploads them to TestFlight and Internal Testing as the first step, and then we start the production release.

First I edit the release notes, since it's a multiplatform app built using Compose and Kotlin. The changelog is mostly similar, for both Android and iOS.

(I wish there was a unified text entry for this with an option to add a platform-specific changelog. Makes it a bit easier if it's a common codebase)

After that, I click start deployment, which starts the production release. Since these stores require reviews, Tramline shows an option to submit it for review and track the status of the review before making the release. (It's only available for iOS at the moment since Google Play API doesn't have this functionality). If you add Slack integration, Tramline can send notifications about these changes along with other useful release information.

Once the review process of the app is done, I start the release and a phased rollout starts. This is something I have configured when creating the release train step. App Store doesn't allow custom phase rollout strategies, so I am matching my Google Play rollout percentages with default App Store ones. That's why you use the "Increase Rollout" option in only one of them.

If everything is good with the release, it goes to 100% automatically. But if I notice any issues/crashes with the release that are critical. Which is easy to observe with the BugSnag integration in the Tramline dashboard. I just push my fixes to my release branch. Tramline then provides me the option to apply those fixes to individual releases.

If I apply these patches, the release now goes into patch mode. It starts to increase the patch version of the release and does the whole above process again.

Once the release is done, it's now locked and shows the reldex score and appropriate release information.

It also displays the release health information from BugSnag like adoption rate and stability right in the Tramline dashboard.

That's it, now new release of Twine is released to the App Store and Google Play. For me, Tramline gets rid of the manual release process of generating artifacts locally and handling the releases in individual stores, and also I don't have to directly interact with the App Store Connect or Google Play APIs.

I don't have to drown in the process and just start deploying, that's what I like about Tramline.

If you like this, you can try it by signing up at tramline.app

You can check out the GitHub Actions I have used for generating my release artifacts, here. Feel free to star the project on GitHub and leave a review on the App Store or Play Store.

GitHub - msasikanth/twine: Twine: A multiplatform RSS reader built using Kotlin and Compose

Twine: A multiplatform RSS reader built using Kotlin and Compose - msasikanth/twine

GitHubmsasikanth

Thanks for reading, until next time ✌🏾

Alright, here we go. Another weekend, another dev log. I am still trying to figure out how to structure this or how often I would want to post this. So bear with me as I figure that out.

Well now onto the dev log, this was a fun and eventful week. I decided to post about Twine on Hacker News and Lobsters, and both did well and reached the top of the main page.

That was a surprise for me because I had posted it in the past, but at that time I barely got any feedback on the project. However last time I didn't have a fully fleshed-out project README on GitHub with just a few images, and the app had slightly fewer features and not-so-great screenshots on both the App Store and Play Store. So, this time after receiving some feedback on Reddit, I had to do a fresh new set of screenshots on Figma for the app and I think they turned out well.

So, it's a learning experience for me to understand how important these things are. I always thought I just had to focus more on building the best product I could, but selling it is also a skill I need to learn and get better at.

Apart from this, I continued working on Twine, features, refactoring some stuff and of course fixing bugs like dealing with config changes on Android 🙃.

Starting, one of the smallest changes that will have a huge impact on the release on iOS for me is, switching to M1 machines on GitHub Actions. I just had to update my machine to macos-14 and it uses the new M1 machines.

Use Mac M1 runner for iOS prod release workflow · msasikanth/twine@03f6846

Twine: A multiplatform RSS reader built using Kotlin and Compose - Use Mac M1 runner for iOS prod release workflow · msasikanth/twine@03f6846

GitHubmsasikanth

This shaved off more than 5 minutes from my archive builds for iOS when making releases.

Migrated Twine to use Coil 3 multi-platform. This helped me remove a bunch of code I had to do for loading images on iOS and also offered better support for different formats and caching. I am glad this finally happened 🙌🏾

It was interesting and frustrating at times trying to figure out how to integrate some of the new changes into the dynamic content theming I had or DI, it's mostly to do with how I structured my code initially though, so did some refactoring around it. You can check the changes here:

Migrate to Coil3 Multiplatform (#268) · msasikanth/twine@dd2a89b

* Bump coil dependency to v3.0.0-alpha03 Also added the coil network package, since that's required to load network images now * Provide coil `ImageLoader` via `ImageLoaderComponent` *…

GitHubmsasikanth

Next up

Of course, I continue to work on new features and improving Twine in general. I have picked out a few features I want to get done this year (not in any order).

• Labels
• Per feed customisations
• Notifications
• Improve reader view

There is one more major change I want to implement.

Monetising Twine

My initial plan for Twine was to keep it open source and then get sponsors for the project on GitHub. So, that I can sustainably work in my free time.

Sponsor @msasikanth on GitHub Sponsors

Support Sasikanth’s open source work. These sponsors help me to build high quality projects on the side.

GitHub

But unfortunately, that did not work as expected. Most people aren't familiar with that or don't even have visibility about something like that when using the app, especially for people outside of the dev community.

So, late last year I was planning on introducing monetisation in the app and discussed it with a few people and these options seem like good options. Don't worry, I still want to keep the core app free, and I am not adding ads or making the app paid now. There are a couple of features I can potentially offer as an in-app purchase which provides value to users.

• Customisations (potentially app & reader view themes, app icons, etc.,?)
• Integrations
  • Provide support for 3rd party feed readers APIs like feed bin, self-hosted fever instances, etc.,
• Adding a tip option in the app

or as a completely new product

• Desktop apps (potentially?)

I think these act as a good way to monetise the app. What do you folks think? Are these something you are interested in or find value in? Let me know in the comments.

Edit: Forgot to mention this originally, but these changes will continue to be open source as well. In case you’re wondering.

If you want to continue receiving these dev logs, feel free to sign up below.

Lately, my YouTube recommendations are flooded with dev logs, showcasing the progress of building indie frontend projects or games. That inspired me to start logging my experience building Twine, my cross-platform RSS reader app or any of my programming explorations. But instead of doing a video, I have decided to write.

GitHub - msasikanth/twine: Twine: A multiplatform RSS reader built using Kotlin and Compose

Twine: A multiplatform RSS reader built using Kotlin and Compose - GitHub - msasikanth/twine: Twine: A multiplatform RSS reader built using Kotlin and Compose

GitHubmsasikanth

So, why am I doing this? There are a couple of things I want to achieve with this

• Capture different ideas and experiences I had when building Twine. I think this acts as a good way for me to keep track of my thought process, and explorations and potentially also helps others in their programming journey 🤞🏾
• Improve my content writing frequency and ability(?). I am not that consistent with my content writing, nor am I that great at writing articles in my opinion. So, I feel like this kinda of helps me with that, I don't need to have the pressure of doing something "cool" and instead just capture my experience working on Twine for that week or since I have written last.

Let's start dev log for this week (Week 04, 2024). So, what I have been up to?

• I have implemented the reader view for the app, it's been a long-requested feature, ever since I first open-sourced the project. So, it feels nice to finally close this one off.

To implement the reader view I had to fork Readability4J, to Kotlin multiplatform to process the RSS HTML content into a readable HTML. One thing that made this fork possible was fleeksoft/ksoup, which allowed me to replace Jsoup usages.

In terms of the reader view, I am just using a webview, to render the generated HTML. I had to write some HTML and CSS for formatting the reader view. It's been a while since I have done that, I felt so damn rusty 😂

• In RSS feeds you don't always receive full post content. So, one thing I have done with my reader view is the ability to pull the article from the web and convert it into a readable view with a button press. It was pretty straightforward as I just loaded the HTML and passed it through the readability class to generate the HTML and render it. But this is definitely a really useful thing to have for me. Here is a sample showcasing that.

Currently, I am waiting for a new webview release, which contains a couple of changes I contributed to. Once that is available I will push these changes to production.

• Next up, I finally started working on tags implementation for Twine. While I do have an idea of how the DB implementation is gonna look and work, one thing that I have been mulling over from the start is how the user experience is gonna look. After trying out a few implementations of this on different projects, I think I have an idea of how Twine implementation is gonna look like. Finishing this will bring Twine to feature match with most of the RSS readers out there, and also allow me to explore integrations for the project. So, that's something I am looking forward to.
• Apart from working on Twine, I have been playing Gran Turismo 7 and got Like A Dragon: Infinite Wealth today, so been playing those in my free time. As always been playing a ton of Overwatch 2 🥲

and that's it, for my first-ever dev log, and what I have worked on Twine this week. I will try to be consistent with these and at least try to write one every weekend. But I don't want to force myself if I haven't done anything instead decided to take a break.

Remember to subscribe so you can begin receiving more dev logs and other updates directly in your email.

Unless you're living under a rock, you might have heard of or used Figma before, whether to design or for handoff, it's a collaborative design tool built using web technologies. It's a fantastic tool!

We are not going to talk about why Figma is amazing today. Instead, we are going to focus on Figma Plugins. Plugins are how Figma allows us to extend the capabilities of Figma design or FigJam, it has a vibrant community of plugins that vary from generating text content for placeholders to linting for accessibility or generating full-fledged components or design systems.

Since Figma is built on top of web technologies, it requires plugins to be JavaScript module to run them. But, we can write the plugin in a different language though, for example when we create a new plugin from their template. It provides a TypeScript template and once you compile it, it outputs a JavaScript file that is used by Figma.

So, I wanted to try writing a plugin using Kotlin/JS. It's a similar concept, we write Kotlin code and it compiles to JavaScript. First, let's create a new Kotlin Multiplatform project in IntelliJ IDEA

That should create a simple project that just prints "Hello, world" to the console.

Let's compile the code to generate the JS module. You can run the following Gradle command to do that.

./gradlew browserDistribution

This would compile your project into a single JS module that is ready for distribution. You can find it under build/distributions

Alright, we have our JS file. Now how do we get Figma to run it? This is where we define a manifest file for Figma to import the plugin from. Let's create the following manifest.json file in the root directory of the project.

{
  "name": "Figma Plugin KT",
  "id": "737805260747778092",
  "api": "1.0.0",
  "main": "build/distributions/figma-plugin-kt.js",
  "capabilities": [],
  "enableProposedApi": false,
  "editorType": [
    "figma"
  ]
}

Then open Figma, navigate to Account > Plugins, and then select Import plugin from manifest from the In development section

That's it, now you have your plugin ready to use in Figma. You can now open or create a new Figma design file. Then press CMD/CTRL + / , and enter the plugin name to run it. Since this plugin prints a message, you have to open the console to view it. You can follow the same shortcut mentioned above and type "Open console".

But wait a minute, why is that toast message saying running plugin even after the message is finished? Well, that's because we haven't closed the plugin after performing our operation.

Let's jump back to your Kotlin code and do that. After the print statement let's add this JS code block, and then generate the distributions again.

fun main() {
  println("Hello, ${greet()}")
  js("figma.closePlugin('Operation successful ✅')")
}

Now, when you run your plugin in Figma, it will automatically close the plugin after printing the greeting and show this message.

So, that's it right? Well not exactly. As you can see even though we are building this project in Kotlin, we are still using raw JS strings to do the Figma-related operations, thus defeating any advantage we are getting by writing a plugin in Kotlin. I would like to have type safety when writing Figma plugin APIs and be able to use any Kotlin standard library functions that are compatible. Let's take a look at how we can do that.

Fortunately, Kotlin/JS offers a way other ways to run JavaScript code from Kotlin. That is via having custom bindings. Let's Figma API exposes a global object to interact with its APIs called figma.

We would have to create a new Kotlin file and add a variable with the same name as in their APIs. So, let's do that. Let's create a new Kotlin file that exposes the Figma API global object

external val figma: PluginAPI

external interface PluginAPI {

}

Here the external modifier indicates that the code implementation of it is in JavaScript, so it won't complain about not having any body in the code.

Let's add the closePlugin API we used before to the PluginAPI interface, so that we can use it in our main file.

external interface PluginAPI {
  fun closePlugin(message: String = definedExternally)
}

Here, the definedExternally indicates that the message is an optional parameter.

Now let's replace the JS code in our main file with this.

fun main() {
  println("Hello, ${greet()}")
  figma.closePlugin("Operation successful ✅")
}

When you run the plugin again in Figma, you should see everything working as expected. This time we are using type-safe Kotlin APIs rather than a raw JS string in Kotlin.

But, you might be thinking this seems tedious work to write all the external declarations manually one by one. Well, Kotlin folks think so too. That's why they have created an experimental library called Dukat, this would allow us to convert TypeScript definition files to Kotlin declarations. Let's install that

npm install -g dukat

Now we need the Figma plugin API typings. Fortunately, Figma exposes the plugin API typings via GitHub and npm, you can find them here.

Once we downloaded the typings repo, the files that are important to us are index.d.ts and plugin-api.d.ts. Let's run Dukat on that.

dukat -d \
~/Projects/figma-plugin-kt/types \
~/Downloads/figma-typings/index.d.ts \
~/Downloads/figma-typings/plugin-api.d.ts

This should generate the Kotlin declarations we need along with library declarations as well. Now, we have access to all the APIs that Figma Plugin provides. To test this, you can update your main code to this

fun main() {
  val interRegularFont = object : FontName {
    override val family get() = "Inter"
    override val style get() = "Regular"
  }
  
  figma.loadFontAsync(interRegularFont).then {
    val text = figma.createText()
    text.characters = "Hello, world"
    text.fontSize = 24

    figma.closePlugin("Operation successful ✅")
  }
}

Once we run the plugin, a text should be created in the Figma canvas.

Gotchas

• While Dukat helps generates the Kotlin declarations, it's far from perfect. Sometimes the generated files can have a lot of errors, like not having a override modifier, or having that when it's not needed, or wrong types, etc., So, there is some manual effort involved to resolve them accordingly before we can generate a JS module for distribution.

That's it, this is how we can create Figma Plugins using Kotlin/JS. Now I wonder if I can use Jetpack Compose UI here for plugin UI. Well, that's for a different time I guess. See you later 👋🏾

You can find the source code here

Recently I was looking into setting up templates for creating new projects. Obviously, a GitHub template was the first option, but I was not a huge fan of having to create a new GitHub repo from the template and then start changing things like app name, package name, application ID, removing unnecessary configurations, etc.,

Ideally, I wanted to have the option to configure things when creating a project so that I can pick and choose what I want. For example, whether or not I want to configure any CI checks, release pipeline, build configurations, etc.,

That's why I started looking into how Android Studio provides the project templates when creating a new project in the hopes of adding my own option to that new project wizard which would allow me to do those things. This post shows how you can create an IDE plugin to provide your templates in Android Studio's new project wizard.

Note: While the following approach and APIs used in this article are public, they are not documented and hence not considered "offical" approach for creating templates.

Alright, now let's get started...

Prerequisites

In order to create Android Studio plugins, we need to use IntelliJ IDEA CE (or IntelliJ IDEA Ultimate).

Once you installed IntelliJ IDEA, create a new project to create an IDE Plugin

After the project is created, open the build.gradle.kts or build.gradle file and let's configure the Gradle IntelliJ plugin to support the Android plugin. Add the following code to the intellij configuration block and sync the project.

intellij {
  type.set("AI") // Target IDE Platform
  version.set("2022.2.1.11")

  plugins.set(listOf(
    "org.jetbrains.android"
  ))
}

The above code sets the plugin dependency and changes the IDE type to use Android Studio. The version we used here is Android Studio Flamingo Canary 11. You can find the Android Studio versions here. (Depending on the Android Studio version, the APIs you have access to in your plugin may change)

Now open plugin.xml file, this is where you can configure all the information related to the plugin including things like id, name, version, depends on, etc.,

We are interested in the depends configuration. By default, the plugin depends on the IntelliJ platform only, but we also want to make sure the IDE has the Android plugin for our plugin to work. We can add the following two lines in the plugin.xml

  <idea-plugin>
    <depends>org.jetbrains.android</depends>
    <depends>com.intellij.modules.androidstudio</depends>
  </idea-plugin>
  

That's it, you have the project configured to build an Android Studio plugin.

Creating project templates

In order to provide your own project templates in the new project wizard, there are a couple of things we need to configure.

• Template: Describes a template available in the new project wizard. Describes the template and options available for the template and which context to show it in.
• Recipe: Instructions for generating the project for a template. Once the user selects the template from the wizard and inputs the params, the recipe is executed with parameters supplied by the user

Create Template

Android Studio provides a template DSL to create these templates. You can also take a look at existing templates to build your own templates.

So, let's create one. Create a new file called ProjectTemplate.kt, and add a new variable to provide the template.

import com.android.tools.idea.wizard.template.Category
import com.android.tools.idea.wizard.template.CheckBoxWidget
import com.android.tools.idea.wizard.template.FormFactor
import com.android.tools.idea.wizard.template.ModuleTemplateData
import com.android.tools.idea.wizard.template.PackageNameWidget
import com.android.tools.idea.wizard.template.TemplateConstraint
import com.android.tools.idea.wizard.template.TemplateData
import com.android.tools.idea.wizard.template.TextFieldWidget
import com.android.tools.idea.wizard.template.WizardUiContext
import com.android.tools.idea.wizard.template.booleanParameter
import com.android.tools.idea.wizard.template.impl.defaultPackageNameParameter
import com.android.tools.idea.wizard.template.stringParameter
import com.android.tools.idea.wizard.template.template
import java.io.File

val projectTemplate
  get() = template {
    name = "My Project Template"
    description = "My Project Template"
    minApi = 21
    constraints = listOf(
      TemplateConstraint.AndroidX,
      TemplateConstraint.Kotlin
    )
    category = Category.Application
    formFactor = FormFactor.Mobile
    screens = listOf(WizardUiContext.NewProject, WizardUiContext.NewProjectExtraDetail)

    val activityName = stringParameter { 
      name = "Activity name"
      default = "MainActivity"
    }
    
    val addComposeDependencies = booleanParameter {
      name = "Add Compose Dependencies"
      default = false
    }

    val packageName = defaultPackageNameParameter

    widgets(
      TextFieldWidget(activityName),
      CheckBoxWidget(addComposeDependencies),
      PackageNameWidget(packageName)
    )

    // I am reusing the thumbnail provided by Android Studio, but
    // replace it with your own
    thumb { File("compose-activity-material3").resolve("template_compose_empty_activity_material3.png") }

    recipe = { data: TemplateData ->
      projectRecipe(
        moduleData = data as ModuleTemplateData,
        packageName = packageName.value,
        activityName = activityName.value,
        canAddComposeDependencies = addComposeDependencies.value
      )
    }
  }

• Name: Name of the project template
• Description: Description of the template
• MinApi: Minimum SDK version required to build this template
• Constraints: Conditions under which the template should be rendered in the new project wizard. For example, we don't want to show this template if AndroidX or Kotlin support is not available or enabled in the IDE
• Category: Determines which menu entry the template belongs to. For example, Application, Activity, Compose, Service, etc.,
• FormFactory: Determines which form factor the template belongs to. Templates with particular form factors can only be rendered in the corresponding category. For example, when you're creating a new project you have the categories for templates like phone and tables, wear os, etc.,
• Screens: UI Context in which the template should be displayed. Should include all possible contexts. For example, we defined a context of NewProject and NewProjectExtraDetail in the above template. This means this template is only shown as an option when we are creating a new project. You can also add NewModule or MenuEntry and others. (Note: NewProjectExtraDetail will show an extra page after the initial configuration to allow for more customization)
• Widgets: Collecting of Widgets to render in NewProjectExtraDetail context. For example, this will be useful in case you wanna provide more config options after the default initial new project wizard page.
• Thumb: Thumbnail for the template to show in the new project wizard
• Recipe: The recipe used to generate the template output. It will be called after the user provides values for all the configuration parameters.

Create Recipe

Now let's create our recipe for generating the project. Create a file called ProjectRecipe.kt and an extension function for RecipeExecutor called projectRecipe

import com.android.tools.idea.wizard.template.ModuleTemplateData
import com.android.tools.idea.wizard.template.PackageName
import com.android.tools.idea.wizard.template.RecipeExecutor

fun RecipeExecutor.projectRecipe(
  moduleData: ModuleTemplateData,
  packageName: PackageName,
  activityName: String,
  canAddComposeDependencies: Boolean
) {
  
}

Basically RecipeExecutor is an execution engine for the instructions we provide in the recipe. So, let's provide some instructions to generate a project.

For this example let's keep it simple and create a project with empty activity and the ability to toggle whether or not we want to add Compose dependencies to it.

RecipeExecutor provides functions to do some common actions like adding dependencies, plugins, build features, etc., Let's use the addDependency function to add the required Compose dependencies.

private const val COMPOSE_BOM_VERSION = "2022.10.00"
private const val COMPOSE_KOTLIN_COMPILER_VERSION = "1.3.2"

fun RecipeExecutor.projectRecipe(
  moduleData: ModuleTemplateData,
  packageName: PackageName,
  activityName: String,
  canAddComposeDependencies: Boolean
) {
  addAllKotlinDependencies(moduleData)
  addMaterial3Dependency()
  
  if (canAddComposeDependencies) {
    addDependency(mavenCoordinate = "androidx.activity:activity-compose:1.5.1")

    // Add Compose dependencies, using the BOM to set versions
    addPlatformDependency(mavenCoordinate = "androidx.compose:compose-bom:$COMPOSE_BOM_VERSION")
    addPlatformDependency(mavenCoordinate = "androidx.compose:compose-bom:$COMPOSE_BOM_VERSION", "androidTestImplementation")

    addDependency(mavenCoordinate = "androidx.compose.ui:ui")
    addDependency(mavenCoordinate = "androidx.compose.ui:ui-graphics")
    addDependency(mavenCoordinate = "androidx.compose.ui:ui-tooling", configuration = "debugImplementation")
    addDependency(mavenCoordinate = "androidx.compose.ui:ui-tooling-preview")
    addDependency(mavenCoordinate = "androidx.compose.ui:ui-test-manifest", configuration="debugImplementation")
    addDependency(mavenCoordinate = "androidx.compose.ui:ui-test-junit4", configuration="androidTestImplementation")
    addDependency(mavenCoordinate = "androidx.compose.material3:material3")

    requireJavaVersion("1.8", true)
    setBuildFeature("compose", true)
    // Note: kotlinCompilerVersion default is declared in TaskManager.COMPOSE_KOTLIN_COMPILER_VERSION
    setComposeOptions(kotlinCompilerExtensionVersion = COMPOSE_KOTLIN_COMPILER_VERSION)
  }
}

Now that we configured our build file, let's create our empty activity. Android Studio templates use string templates to create the files. So, let's create an empty activity string template in EmptyActivity.kt file.

import com.android.tools.idea.wizard.template.escapeKotlinIdentifier

fun emptyActivity(
  packageName: String,
  activityClass: String
) = """
package ${escapeKotlinIdentifier(packageName)}

import androidx.appcompat.app.AppCompatActivity
import android.os.Bundle

class $activityClass : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
    }
}

"""

Finally, let's create the activity and save it in the recipe

fun RecipeExecutor.projectRecipe(
  moduleData: ModuleTemplateData,
  packageName: PackageName,
  activityName: String,
  canAddComposeDependencies: Boolean
) {
  // ...configuring dependencies
  
  val emptyActivity = emptyActivity(packageName, activityName)
  val emptyActivityPath = moduleData.srcDir.resolve("$activityName.kt")
  save(emptyActivity, emptyActivityPath)
  open(emptyActivityPath)
}

That's it you have created your first project template for Android Studio. While I only showcased adding dependencies and a Kotlin file. You can pretty much add any file type as they just rely on a string template. For example, you can create scripts or GH Actions or editor config, etc.,

If you tried to run/build the plugin now and test it in Android Studio you won't see the template show up just yet. There is one final step to provide this template to Android Studio.

Providing the templates to Android Studio

Android Studio provides templates to the new project wizard using something called a WizardTemplateProvider . It's an interface that implements a function to return a list of Templates.

The WizardTemplateProvider itself is exposed as a plugin extension, which means we can provide our own template provider to add to the already existing template provides. (Android Studio provides its own templates using a WizardTemplateProviderImpl class)

First, let's implement a class called MyProjectTemplateProvider which extends WizardTemplateProvider.

import com.android.tools.idea.wizard.template.Template
import com.android.tools.idea.wizard.template.WizardTemplateProvider

class MyProjectTemplatesProvider : WizardTemplateProvider() {

  override fun getTemplates(): List<Template> {
    return listOf(projectTemplate)
  }
}

Now, open the plugin.xml file and add a new extension to set our wizardTemplateProvider

<extensions defaultExtensionNs="com.android.tools.idea.wizard.template">
  <wizardTemplateProvider implementation="dev.sasikanth.myprojecttemplates.MyProjectTemplatesProvider"/>
</extensions>

That's it, now any Template you provide in MyProjectTemplatesProvider will be visible in the new project wizard after you install your plugin in Android Studio.

You can verify that the plugin and template are working as expected by running ./gradlew runIde.

Installing the plugin

Run the ./gradle buildPlugin command to generate the plugin jar. It should generate in our build/libs folder in the project.

Now open Android Studio and go to the plugins section and click on the gear icon to select install from disk option

Select the jar file you just created and restart the Android Studio.

Now when you create a new project, you should see your project template.

You can provide multiple project templates with this approach and configure the items when creating the project. You can find the sample used in this article here

Earlier today I was looking into automatically building an APK/AAB artifact for one of the projects I am working on, using GitHub Actions. After the basic setup, I had to run the assemble command and it generated the artifact then I upload that to the action, or I can publish it somewhere I want. Pretty straightforward.

But one issue is, I had to manually update the version code and version name every time I had to make a new release. While it's not that big of work, I instead let a computer take care of versioning than me.

On Simple, we use Bitrise which provides us with a step that sets the version when running the workflow. So, I wanted to do something similar to that.  I wanted to have a step that generates a version based on the current date and build/run.

So, one of the immediate approaches that came to mind for something like that was using gradle.properties. I can define a custom property and then read that in my build file when setting the version code and name. That would look something like this

appVersionCode=1
appVersionName=0.1

versionCode = providers.gradleProperty("appVersionCode").get()
versionName = providers.gradleProperty("appVersionName").get()

...and then I just have to pass the values I generated using properties in the Gradle command

./gradlew :app:assembleDebug \
-PappVersionCode=1 \
-PappVersionName=2022-12-24-1

That's it, this would generate the artifact with the version code and name I passed.

But I do want to see if there was a native way of doing this. After a bit of Googling and command clicking, I found that build tools have Gradle property that does help with this.

That's it, with these properties I didn't have to make any changes to the project build files and instead just had to pass the version information in the Gradle command

// version code and name are generated and are passed to this command

./gradlew :app:assembleDebug \
-Pandroid.injected.version.code=1 \
-Pandroid.injected.version.name=2022-12-24-1

This was a bit of a small thing I learned today, so wanted to share it. Hopefully, this will be useful for someone else as well :D

One of the common things you might see in a lot of popular desktop apps is, that they have a custom title bar that contains fancy toolbar icons or a search bar or some other custom view. Compose Desktop allows us to use our own title bar by just making our Window undecorated. But what if you won't make that toolbar draggable as well? Compose provides an API for that as well, which is aptly named WindowDraggableArea

The usage of it is pretty straightforward. We first start by making our Window undecorated, which allows us to use our own title bar.

Window(
  state = rememberWindowState(),
  undecorated = true,
  transparent = true,
  onCloseRequest = ::exitApplication
) {
  // content here
}

Now, we can define our fancy title bar composable and place it in the window content. To make our title bar draggable, we simply wrap it in WindowDraggableArea

Window(
  state = rememberWindowState(),
  undecorated = true,
  transparent = true,
  onCloseRequest = ::exitApplication
) {
   WindowDraggableArea {
	 AppTitleBar()
   }
}

Under the hood, WindowDraggableArea is a simple Box view that uses pointer inputs to allow us to drag our window.

@Composable
fun WindowScope.WindowDraggableArea(
    modifier: Modifier = Modifier,
    content: @Composable () -> Unit = {}
) {
    val handler = remember { DragHandler(window) }
    Box(
        modifier = modifier.pointerInput(Unit) {
            forEachGesture {
                awaitPointerEventScope {
                    awaitFirstDown()
                    handler.register()
                }
            }
        }
    ) {
        content()
    }
}

If you look at the function definition, you will also notice WindowDraggableArea is an extension of WindowScope . That means you can only use it in singleWindowApplication , Window and Dialog . If you want to use it in a different Composable, you need to pass WindowScope as a receiver.

@Composable
fun WindowScope.AppTitleBar() {
  WindowDraggableArea {
    // title bar content
  }
}

That’s it, now you can create your own custom title bar and have the option to drag it across the desktop, or have a draggable area anywhere in your app.

Gotchas

• When you mark your window as undecorated, along with the toolbar the window frame and the elevation that is handled by the OS are also disabled/removed. So, the app will not have any elevation like other apps. Unfortunately setting elevation on your content just clips it.
• Resizing undecorated windows is currently not supported. There is an open issue for that on the compose-jb repo.

Here is a Compose Desktop app with a custom title bar I had to implement recently.

Update (27/04/2022): Fixed JSON to have String as a key type. Thanks, @janhavisinghh for letting me know.

Keeping the app up-to-date has a lot of benefits for the user, they can use all the new features, have the latest bug fixes and improvements and have access to the latest security patches. While some users update the app periodically or have the background updates enabled, others might not.

Google has a library to address this issue, which is aptly named In-app updates. which allows us to prompt the users to update their app. It gives a lot of different information and allows us to start the update right from the app. One of the interesting properties available as part of this library is updatePriority . Which lets us handle how we want to display a message that there is an update or how we update the app (flexibile or immediate).

We can set integer values between 0 & 5 for update priority, with 0 being the default and 5 being the highest priority. In order for us to set the update priority, we have to use the Google Play Developer API, and then we can check it on the client-side using AppUpdateInfo#getPriority().

While this is a great way for us to define priorities for our updates, and handle them accordingly in our app. We are required to use Google Developer API to set this, there is no other way around it currently. We cannot update it from Google Play Console while making a release as well. Personally, I would like to have control over it. I want to be able to update the priority while or after making a release. For that, we can use Firebase Remote Config.

Firebase Remote Config is a service that lets us control the behavior and appearance of the app. It will fetch this information from the Firebase servers periodically and update them. We can use this to pass in a minimal JSON file that let us define essentially a key/value pair with version code being the key and priority being the value.

Something like this

{
 "8145": 1,
 "8150": 5
}

Now, all we have to do is parse this information and use it on the client-side.

There are a lot of JSON parsing libraries for Android out there. I am using Moshi for this, but you can use any one of them. We can first start by defining what type we are expecting the parsed JSON is and create a Moshi adapter for it.

val type = Types.newParameterizedType(Map::class.java, String::class.java, Integer::class.java)
val updatePrioritiesAdapter = moshi.adapter<Map<String, Int>>(type)

Then we can fetch our JSON from the Firebase Remote Config and use the adapter to parse it

val json = remoteConfig.getValue("update_priorities").toString()
val updatePriorities: Map<String, Int> = updatePrioritiesAdapter.fromJson(json)

So, we have our Map<Int, Int> which contains our update priorities information. Now we need to get the version code for the update from our app. For that, we can use the in-app updates library which provides us with other information like the available version code which is the version code of the update that is available from Google Play store.

appUpdateInfoTask.addOnSuccessListener { appUpdateInfo ->
  val availableVersionCode = appUpdateInfo.availableVersionCode().toString()
  val updatePriority = updatePriorities.getOrDefault(availableVersionCode, defaultUpdatePriority)
  // handle priority
}

That’s it. Now we can easily update the update priority for a new version without having to do that using Google Developer API 🙌