[iOS] Add `initialQuery` param to `useSilentSwitch` and `addSilentListener`

[bbarthec]

Why

Current API shape does not expose any mechanism to check the initial state of the Ring/mute switch on iOS. I need to ignore the very first meaningful status report of Ring/mute switch state (true/false) in React-friendly way. Therefore, I suggest API change and exposing what's being tracked on the native iOS level.

How

• exposed initialQuery param via type RingMuteSwitchStatus = { isMuted: boolean; initialQuery: boolean } and type RingMuteSwitchEventCallback = (status: RingMuteSwitchStatus) => void;:
  • addSilentListener(callback: RingMuteSwitchEventCallback)
  • useSilentSwitch(): RingMuteSwitchStatus

API changes

breaking changes

• useSilentSwitch changes return type from boolean to RingMuteSwitchStatus
• addSilentListener changes parameter type from (status: boolean) => void to (status: RingMuteSwitchEventCallback) => void
• type eventCallback is replaced by RingMuteSwitchEventCallback

  new features

• introduced type RingMuteSwitchStatus = { isMuted: boolean; initialQuery: boolean }
• introduced type RingMuteSwitchStatusCallback = (status: RingMuteSwitchStatus) => void

Side effects / issues - possibly to be extracted to separate PRs

• [ ] I am using yarn@1.22.18 and it completely messes up the yarn.lock files format 🤔 Ideally, I would not change the format at all. What yarn version should I use? I've failed to find instructions on that in the repository.
• [ ] I found out that yarn lint was not working, because of two errors:
  1. babel.config.js imports non-existing file ../package.json
  2. there's no babel-plugin-module-resolver module installed in the root node_modules

Test plan

1. open iOS example app on physical device
2. see the changes in action:

preview

[hirbod]

@bbarthec incredible work - what else shall I expect from a SWM/Ex-Expo member. All suggestions are solid and I am going to merge this right away.

Regarding the yarn issue. I recently upgraded globally to yarn 3 - thats why that messes with your system. What you suggest here? Yarn 3 is solid and a lot faster than yarn 1. I think the upgrade is overdue but I find a lot of people still at yarn 1. I haven't had any issues with yarn 3 since the upgrade.

[hirbod]

I am just not sure right now what I shall do with that yarn.lock :D

[bbarthec]

@hirbod, let me check real quick this yarn@v3 and I'll clean up this PR 💪

[hirbod]

@bbarthec maybe when you're at it, could you have a look at #3? Events get swallowed up when you hold the volume button too long or click too long. Currently, there is a simple count check, maybe we could remember the last saved volume instead and skip emitting. You might have an idea.

[bbarthec]

@hirbod, it seems upgrading to yarn@3.2.3 helped a bit, but didn't clean up the yarn.locks mess completely 😞

[hirbod]

@bbarthec, released under v1.0.1 https://github.com/hirbod/react-native-volume-manager/releases/tag/v1.0.1

Thank you. If you have time by any chance, you might have a look at the issue #3. If not, thats fine also :) Thanks again for contributing!

[bbarthec]

@hirbod, cooperating with you is such a pleasure! 🤩 😊 Thank you for this rapid fast responses and merge 👏

Thank you. If you have time by any chance, you might have a look at the issue https://github.com/hirbod/react-native-volume-manager/issues/3. If not, thats fine also :)

In this very moment I do not have much time to spent on this one, but if I find time later I'll happily take a look 👀

Thank you again! 👏

[hirbod]

@bbarthec I fixed the issue myself :). Also added a new method to showNativeVolumeUI to disable the volume toast globally when using hardware keys. I was not able to register onKeyUp listeners in Android to implement it for Android as well though, still investigating.