Main feature:

• Separate VoiceInput from VoiceDialogFragment acting as its presenter

Other features:

• Improve wrapping API to expose some SpeechRecognizer settings

Fixes:

• 1b5f5a1 - avoid race condition in a defensive programming way (@q-litzler let me know your thoughts on this!)

Refactor:

• Improve layouts
• Simplify some logic, use templated Strings

Voice library V2

• [x] Integrate @q-litzler's ripple design

• [x] Refactor Fragments to Kotlin

• VoiceDialogFragment:

  • [x] Improve state handling
  • [x] Refactor suggestions handling (support vararg params, simpler logic)
  • [x] Centralize UI Updates
  • [x] Remove unneccesary logs
  • [x] Better errors

• PermissionDialogFragment:

  • [x] Simplify while converting (LOC /2)

• [x] Move demo's helper functions in the library as Voice.foo()

• Update Kotlin version to 1.4.31
• Replace deprecated plugin kotlin-android-extension
• Migrate from android support to androidx
• Disable stop listening button click for Android 9 and 10 (due to this bug)
• Replace deprecated release process

Feat

• Make suggestions optional (adapting subtitle when any)

UI

• Hide "Try again" when the user clicks the button but already uttered something

Style

• Block body to avoid returning sth

Use latest coroutine version and API change. Tie coroutine lifecycle to attach / detach method calls. General dependencies update Change min SDK to 14

• Expose autoStop
• Expose Extension functions whenever valuable

  e.g. I felt turning isPermissionGranted(grantResult: IntArray) into IntArray.isPermissionGranted() would make sense, but only if done consistently with isRecordPermissionWithResults. As both Int.isRecordPermissionWithResults(grantResults: IntArray) and IntArray.isRecordPermissionWithResults(requestCode: Int) would feel weird, I stuck with staticness for both functions.

• Add @JVMOverloads when it improves Java DX

Feature

Flow for manual enabling of recording permission.

• Implementation in app, with default UI:

override fun onRequestPermissionsResult(requestCode: Int, permissions: Array<out String>, grantResults: IntArray) {
    super.onRequestPermissionsResult(requestCode, permissions, grantResults)
    if (Voice.isRecordPermissionWithResults(requestCode, grantResults)) {
        when {
            Voice.isPermissionGranted(grantResults) -> showVoiceDialog()
            Voice.shouldExplainPermission(this) -> Voice.showPermissionRationale(getPermissionView(), this)
            else -> Voice.showPermissionManualInstructions(getPermissionView())
        }
    }
}

• Users can customize the rationale's message/CTA (whyAllow, buttonAllow), and the manual instructions' message/CTA/instructions (whyEnable, buttonEnable, howEnable)
• If one wants a different UI, they can call Voice.openAppSettings() from their own UI logic

Questions

• As showPermissionRationale and showPermissionManualInstructions have two overloads for String and StringRes parameters, default arguments caused an Overload resolution ambiguity. The solution I found was a third overload with the minimum amount of arguments, but let me know if you have a better approach!

• WDYT of refactoring all those as Activity.* extension methods? I feel it improves DX by allowing this.showX() instead of Voice.showX(this), but might pollute the scope/prevent discoverability (for example with Activity.openAppSettings()). @q-litzler what's your take on this?

• Documenting overloads results in duplicated documentation. Is there a way to avoid that or is it a necessary evil? :thinking:

Persistence of VoiceDialogFragment's state. I considered persisting VoiceInput.State too, but realized that it would require moving away from

    override fun onPause() {
        super.onPause()
        input.stopVoiceRecognition()
    }

    override fun onResume() {
        super.onResume()
        input.startVoiceRecognition()
    }

to a more complicated handling of state. I feel it doesn't deserve the added complexity, as on fragment recreation we likely want to listen anyway (if there was an error/pause before the change, what's the value that restoring this state brings versus just listening again for input?)

• Use arguments instead of public variables in fragment
• I'm more in favor of camel casing const variables: RequestPermissionAudio rather than REQUEST_PERMISSION_AUDIO No need to yell (caps) and I always found that Kotlin required a more "smooth" approach 😆

Sorry about the "feature/feat".

Should have been just "feature", which is the default name proposed by git flow.

Takeaway:

• 4 spaces continuation indent instead of 8 (please 🙏 )
• Use object instead of class with a companion object
• Line breaks after class declaration
• Line breaks in constructor parameters
• Use = Unit for non empty methods
• Use = ... Syntax for function with simple return values (see Voice)

Update: separated VoiceInput from presenter, see #5 Refactoring:

• Update import value
• Leverage requireActivity in PDF

API Improvements:

• only require List in VDF's listener

Fixes:

• fix missing negation in Voice.hasRecordPermission