AndroidX WorkManager currently does have a KTX module, but it doesn't provide a lot of utilities :/

API suggestions

• WorkInfo methods which return a Flow instead of LiveData (note: 2.9.0-alpha01 already offers such a feature, so we should provide a backwards-compatible Kotlin extension that emulates the 2.9.0-alpha01 methods on <=2.8.0)

• #4

  val workData = buildData {
    // Perhaps we can have similar utilities to that of a MutableMap?
    this += "key" to 123
    this += workDataOf(/* ... */) // Add existing data
    addData {
      // Add data from a Data.Builder
      putBoolean("abc", false)
    }
  
    this -= workDataOf(/* ... */) // Remove the mutable data's properties that are present in the specified Data
  }

• Add suspend methods for methods that return a LiveData

• Add worker request methods that accept a java.time.Duration/kotlin.time.Duration instead of a Long + TimeUnit

• Add top-level methods to create anonymous objects of interfaces (for e.g. RunnableScheduler)

AndroidX RecyclerView currently has no Kotlin extensions AFAICT.

API suggestions

• Kotlin properties for getters/setters that don't automatically map to their property equivalent (see issue 204918397 on Google's IssueTracker)
• ItemTouchHelper methods for:
  • Attaching a helper to a RecyclerView (this already exists from ItemTouchHelper -> RecyclerView via attachToRecyclerView, but there's no equivalent for the other direction - RecyclerView -> ItemTouchHelper)
  • Creating a SimpleCallback
  • Value class for specifying drag/swipe directions
• Convenience method to create a DiffUtil.ItemCallback with lambdas

Is there an existing issue for this?

• I have searched the existing issues

Library name

All

Library version

All

What happened?

It appears that Dokka's HTML format renders just fine if used as a "Javadoc" source - not sure if this is used internally for IntelliJ's quick documentation, but trying to open a Javadoc of for example the kotlin-logging library seems to work just fine.

Expected behaviour

No response

Reproduction steps

1. Open the javadoc jar file for say, common-enums-jvm
2. Note that the Javadoc-style format is used, instead of Dokka's HTML format

Relevant log output

No response

Possible solution

Switch to publishing 100% Dokka HTML docs, not sure if there'll be any unforeseen issues though

Additional context

While browsing the Javadocs for kotlin-logging, I noticed that they're using Dokka HTML docs and that it shows up just fine on https://javadoc.io

Is there an existing issue for this?

• I have searched the existing issues

Library name

Material Components for Android extensions

Problem

Material Components for Android's Date Picker currently expects a long to be used, which isn't very intuitive as to what you should pass to their APIs, especially when their parameters don't have a suffix that tells you what the unit should be:

@NonNull
@CanIgnoreReturnValue
public Builder<S> setSelection(S selection) {
  this.selection = selection;
  return this;
}

The datePicker static method for MaterialDatePicker.Builder returns a Builder<Long>, so it would look like such:

@NonNull
@CanIgnoreReturnValue
public Builder<Long> setSelection(Long selection) {
  this.selection = selection;
  return this;
}

Which is still confusing as to what unit to pass the selection as (milliseconds? seconds? etc).

Description

There should be extension functions to accept the more suitable java.time APIs first introduced in Java 8, and are designed to resolve the issue Java developers have with dates (and any existing bugs in the old Calendar/Date APIs).

I believe, however, that the Material Components for Android devs didn't go with this as it was only first introduced in Android Oreo (which first brought Java 8 support), so without core library desugaring it isn't possible.

Anyways, here's some proposed APIs:

• MaterialDatePicker.Builder.setSelection should take an Instant, or a Pair<Instant, Instant> for a single date/date-range picker respectively. This would proxy to calling its toEpochMilli method to get its milliseconds representation:

  fun MaterialSingleDatePickerBuilder.setSelection(instant: Instant) = setSelection(instant.toEpochMilli())
  fun MaterialDateRangePickerBuilder.setSelection(instants: Pair<Instant, Instant>) = setSelection(...)

• CalendarConstraints.Builder should take an Instant for its respective APIs that take a long:

  • setStart
  • setEnd
  • setOpenAt

• CalendarConstraints.Builder.setDayOfWeek should take a DayOfWeek

Alternatives?

Using the appropriate methods in the java.time APIs to retrieve its raw representation to then be passed to the existing Java API.

There are also already some example code snippets in some of the Javadocs for java.time.

Additional info

See EdricChan03/studybuddy-android@657c551 for context

For #14

Tasks

• Extract common top-level Kotlin configuration (done in c067e5d)
• Disable Android variant publication on KMP modules
  • Add suitable conventions for the libraryType Gradle lazy property
• Additional config for KMP, if any

I've noticed that the NotificationChannel class has some rather... interesting naming conventions for getters/setters of boolean properties:

/**
 * Sets whether notifications posted to this channel should display notification lights,
 * on devices that support that feature.
 *
 * Only modifiable before the channel is submitted to
 * {@link NotificationManager#createNotificationChannel(NotificationChannel)}.
 */
public void enableLights(boolean lights) {
    this.mLights = lights;
}

/**
 * Returns whether notifications posted to this channel trigger notification lights.
 */
public boolean shouldShowLights() {
    return mLights;
}

As a result, no synthetic Kotlin mutable properties are generated, resulting in having to use the Java getter/setter methods respectively.

Proposed extensions

• isBadgesShown: delegates to setShowBadge (setter)/canShowBadge (getter)
• isBubblesAllowed: delegates to setAllowBubbles (setter)/canBubble (getter)
• isDndBypassable: delegates to setBypassDnd (setter)/canBypassDnd (getter)
• isVibrationEnabled: delegates to enableVibration (setter)/shouldVibrate (getter)
• isLightsEnabled: delegates to enableLights (setter)/shouldShowLights (getter)

(API names are currently tentative, the names will change as further experimentation is done)

Additional tasks

• Add notice that the properties can't be modified once they have been submitted (perhaps a Kotlin opt-in annotation, something like ImmutableAfterCreation)

This change appears to be missed out from the initial 0.0.1 release, so we should cut a new release and add migration instructions to move to the new artifact:

• Add relocation POM to point to the io.github.edricchan03.androidx.common:common-enums artifact
• Add deprecation timeline for the old io.github.edricchan03.androidx.common.enums:common-enums artifact
• Cut the 0.0.2 release
  • Update projects that depend on this library

• Configuration Cache docs

Tasks

• Enable Configuration Cache
• Investigate any issues found from enabling Configuration Cache

Material Components for Android is (currently) a Java-only library.

API suggestions

• AlertDialog extensions
  • DSL to create/show an AlertDialog using a MaterialAlertDialogBuilder
  • Method to set all/individual background insets
• Date/time-picker extensions
  • Top-level method to create a date/time-picker dialog
  • Methods allowing for java.time.* equivalents to be used

material-color-utilities, used for Material 3 colour theming (adaptive colours, HCT theming, etc), should be published to Maven Central at some point

Dokka 1.9.0 was just released.

Updating it should be as simple as bumping the jetbrainsDokka Gradle lazy property for Dokkatoo:

dokkatoo {
  versions.jetbrainsDokka = "1.9.0" // Property.assign
}

Tracking issue for bumping Kotlin to 1.9.20 - there shouldn't be any issues, as Compose Compiler 1.5.4 supports Kotlin 1.9.20.

The latest version of Kotlin is 1.9.21 but there's no stable version of Compose Compiler that supports it as of this writing

Tracking issue for bumping Gradle to v8.4. There shouldn't be any issues when migrating afaict, but this issue exists just in case

Overview

Currently, when attempting to publish snapshots to the Sonatype repository, it results in a HTTP 400 bad request error.

This is because of the way the precompiled scripts are used such that the version is not actually set at that time, resulting in the default value of "unspecified", hence when the isRelease check is done, it presumes that the version is not a snapshot and so publishes to the staging repository instead of the snapshots repository.

Proposed solution

I aim to resolve this by moving all of the precompiled scripts to a common binary plugin which can be used across modules, and should hopefully reduce the amount of precompiled scripts that all modules must apply.

Additionally, the binary plugin can be made configurable through the use of Gradle's extension feature, and with Kotlin DSL lazy property assignment support enabled by default in Gradle 8.2+ will be more concise.

Alternatively, the afterEvaluate block can be used, but where's the fun in that :P
(And we might want to additionally allow for isRelease to be configurable via the command-line, which may not be possible with afterEvaluate)

Checklist

• Initial binary plugin
• Add default conventions
• Add Compose support (seems that this might not be possible as the AGP and KGP plugins aren't quite the same classpath? There's a Google IssueTracker link on this iirc) (fixed via b00b9a3)

Is there an existing issue for this?

• I have searched the existing issues

Library name

Browser KTX

Problem

AndroidX Browser has shipped a new stable 1.7.0 release, which includes new APIs that Browser KTX is now missing out on.

Description

From the 1.7.0 release notes:

Important changes since 1.6.0

• Added CustomTabsIntent.Builder#setBookmarksButtonEnabled that enables the bookmarks button in the overflow menu. (Ia792e)
• Added CustomTabsIntent.Builder#setDownloadButtonEnabled that enables the download button in the overflow menu. (Ia792e)
• Added CustomTabsIntent.Builder#setSendToExtraDefaultHandlerEnabled that enables sending initial urls to external handler apps. (Ia792e)
• Added CustomTabsIntent.Builder#setTranslateLanguage that specifies the target language that the Translate UI should be triggered with. (Ia792e)
• Added CustomTabsIntent.Builder#setBackgroundInteractionEnabled that enables interactions with the background app when a partial Custom Tab is launched. (Ia792e)
• Added CustomTabsIntent.Builder#setShareIdentityEnabled that allows Custom Tabs to obtain the caller's identity. (I7bf2b)
• Added CustomTabsIntent.Builder#setSecondaryToolbarSwipeUpGesture that sets a PendingIntent to be sent when the user swipes up from the bottom toolbar. (Id42a2)

Alternatives?

No response

Additional info

No response

This is the mega-tracking issue for Kotlin extensions support for the Android SDK's notifications APIs:

• #12
• Android NotificationChannelGroup extensions
• Android Notification extensions
• Android Notification.Action extensions

Having issue templates should standardise what to expect for a library/API request, or for bug fixes

New issue templates

• New libraries
• New APIs
• Bugs

It might be useful for end consumers to be able to use the common-enums artifact without the Android requirement :P

GitHub Packages currently requires a GitHub personal access token to be used.

Publishing to Maven Central should hopefully alleviate this requirement, and additionally as most projects likely already have an existing mavenCentral() repository declared in their build scripts, there should also no longer be a requirement to add GitHub Packages as a repo.

Checklist

• Attain access to publishing on Maven Central
• Setup project for Maven Central publishing
• #5
• Publish initial release 👀
• Fix broken precompiled scripts