I'd like to add [coil-svg](https://coil-kt.github.io/coil/) to the repository. ### Justification The current method of loading icons: * Use the provided `loaders` to retrieve an `IconLoader.Result` from memory, disk, http etc * Decode the retrieved `IconLoader.Result` using the given `decoders` to create an `Icon` * If `Icon` is null, generate the `Icon` The Gecko `ImageDecoder` `decode` fun takes a URI which does not conform to the current architecture described above, as Fenix decoders are expected to ingest a `ByteArray`. The Coil SVG decoder however allows us to plug and play a decoder to work within the current structure. Important to note this is __only__ using the decoding mechanism provided by Coil, the resource is still fetched through our network stack. * What is this dependency going to be used for? Allows SVG decoding with a ByteArray * How often does it update? See [changelog](https://github.com/coil-kt/coil/releases) * How much community support is there for it? Well maintained * What are some risks? The API exposes other functions for fetching/caching/loading images * How can we integrate it into our codebase with appropriate guardrails? I welcome any suggestions on this * Licence: Apache-2.0 ### Checklist - [x] Fill out this bug - [ ] Post to team slack channel and email distribution list - [ ] Gather feedback in the comments in this bug - [ ] Solicit appropriate level of sign-offs - [ ] Mark as "DONE" if accepted; mark as "WONTFIX" if rejected (so we can revisit this decision if we ever need to in the future).
Bug 1862251 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I'd like to add [coil-svg](https://coil-kt.github.io/coil/) to the repository. This is an enabler for the [PR to add SVG decoding to Fenix](https://github.com/mozilla-mobile/firefox-android/pull/4166/files). ### Justification The current method of loading icons: * Use the provided `loaders` to retrieve an `IconLoader.Result` from memory, disk, http etc * Decode the retrieved `IconLoader.Result` using the given `decoders` to create an `Icon` * If `Icon` is null, generate the `Icon` The Gecko `ImageDecoder` `decode` fun takes a URI which does not conform to the current architecture described above, as Fenix decoders are expected to ingest a `ByteArray`. The Coil SVG decoder however allows us to plug and play a decoder to work within the current structure. Important to note this is __only__ using the decoding mechanism provided by Coil, the resource is still fetched through our network stack. * What is this dependency going to be used for? Allows SVG decoding with a ByteArray * How often does it update? See [changelog](https://github.com/coil-kt/coil/releases) * How much community support is there for it? Well maintained * What are some risks? The API exposes other functions for fetching/caching/loading images * How can we integrate it into our codebase with appropriate guardrails? I welcome any suggestions on this * Licence: Apache-2.0 ### Checklist - [x] Fill out this bug - [ ] Post to team slack channel and email distribution list - [ ] Gather feedback in the comments in this bug - [ ] Solicit appropriate level of sign-offs - [ ] Mark as "DONE" if accepted; mark as "WONTFIX" if rejected (so we can revisit this decision if we ever need to in the future).
I'd like to add [coil-svg](https://coil-kt.github.io/coil/) to the repository. This is an enabler for the [PR to add SVG decoding to Fenix](https://github.com/mozilla-mobile/firefox-android/pull/4166/files). ### Justification The current method of loading icons: * Use the provided `loaders` to retrieve an `IconLoader.Result` from memory, disk, http etc. * Decode the retrieved `IconLoader.Result` using the given `decoders` to create an `Icon` * If `Icon` is null, generate the `Icon` The Gecko `ImageDecoder` `decode` fun takes a URI which does not conform to the current architecture described above, as Fenix decoders are expected to ingest a `ByteArray`. The Coil SVG decoder however allows us to plug and play a decoder to work within the current structure. Important to note this is __only__ using the decoding mechanism provided by Coil, the resource is still fetched through our network stack. * What is this dependency going to be used for? Allows SVG decoding with a ByteArray * How often does it update? See [changelog](https://github.com/coil-kt/coil/releases) * How much community support is there for it? Well maintained * What are some risks? The API exposes other functions for fetching/caching/loading images * How can we integrate it into our codebase with appropriate guardrails? I welcome any suggestions on this * Licence: Apache-2.0 ### Checklist - [x] Fill out this bug - [ ] Post to team slack channel and email distribution list - [ ] Gather feedback in the comments in this bug - [ ] Solicit appropriate level of sign-offs - [ ] Mark as "DONE" if accepted; mark as "WONTFIX" if rejected (so we can revisit this decision if we ever need to in the future).
I'd like to add [coil-svg](https://coil-kt.github.io/coil/) to the repository. This is an enabler for the [PR to add SVG decoding to Fenix](https://github.com/mozilla-mobile/firefox-android/pull/4166/files). ### Justification The current method of loading icons: * Use the provided `loaders` to retrieve an `IconLoader.Result` from memory, disk, http etc. * Decode the retrieved `IconLoader.Result` using the given `decoders` to create an `Icon` * If `Icon` is null, generate the `Icon` The Gecko `ImageDecoder` `decode` fun takes a `URI` which does not conform to the current architecture described above, as Fenix decoders are expected to ingest a `ByteArray`. The Coil SVG decoder however allows us to plug and play a decoder to work within the current structure. Important to note this is __only__ using the decoding mechanism provided by Coil, the resource is still fetched through our network stack. * What is this dependency going to be used for? Allows SVG decoding with a ByteArray * How often does it update? See [changelog](https://github.com/coil-kt/coil/releases) * How much community support is there for it? Well maintained * What are some risks? The API exposes other functions for fetching/caching/loading images * How can we integrate it into our codebase with appropriate guardrails? I welcome any suggestions on this * Licence: Apache-2.0 ### Checklist - [x] Fill out this bug - [ ] Post to team slack channel and email distribution list - [ ] Gather feedback in the comments in this bug - [ ] Solicit appropriate level of sign-offs - [ ] Mark as "DONE" if accepted; mark as "WONTFIX" if rejected (so we can revisit this decision if we ever need to in the future).
I'd like to add [coil-svg](https://coil-kt.github.io/coil/) to the repository. This is an enabler for the [PR to add SVG decoding to Fenix](https://github.com/mozilla-mobile/firefox-android/pull/4166/files). ### Justification The current method of loading icons: * Use the provided `loaders` to retrieve an `IconLoader.Result` from memory, disk, http etc. * Decode the retrieved `IconLoader.Result` using the given `decoders` to create an `Icon` * If `Icon` is null, generate the `Icon` The Gecko `ImageDecoder` `decode` fun takes a `URI` which does not conform to the current architecture described above, as Fenix decoders are expected to ingest a `ByteArray`. The Coil SVG decoder however allows us to plug and play a decoder to work within the current structure. Important to note this is __only__ using the decoding mechanism provided by Coil, the resource is still fetched through our network stack. * What is this dependency going to be used for? Allows SVG decoding with a ByteArray * How often does it update? See [changelog](https://github.com/coil-kt/coil/releases) * How much community support is there for it? Well maintained * What are some risks? The API exposes other functions for fetching/caching/loading images * How can we integrate it into our codebase with appropriate guardrails? I welcome any suggestions on this * Licence: Apache-2.0 ### Dependencies output \--- io.coil-kt:coil-svg:2.4.0 +--- androidx.core:core-ktx:1.9.0 -> 1.12.0 (*) +--- com.caverock:androidsvg-aar:1.4 +--- io.coil-kt:coil-base:2.4.0 | +--- androidx.annotation:annotation:1.6.0 -> 1.7.0 (*) | +--- androidx.appcompat:appcompat-resources:1.6.1 (*) | +--- androidx.collection:collection:1.2.0 (*) | +--- androidx.core:core-ktx:1.9.0 -> 1.12.0 (*) | +--- androidx.exifinterface:exifinterface:1.3.6 | | \--- androidx.annotation:annotation:1.2.0 -> 1.7.0 (*) | +--- androidx.profileinstaller:profileinstaller:1.3.1 (*) | +--- androidx.lifecycle:lifecycle-runtime:2.6.1 -> 2.6.2 (*) | +--- org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.1 -> 1.7.2 (*) | +--- org.jetbrains.kotlin:kotlin-stdlib:1.8.21 -> 1.8.22 (*) | +--- com.squareup.okhttp3:okhttp:4.11.0 | | +--- com.squareup.okio:okio:3.2.0 -> 3.3.0 | | | \--- com.squareup.okio:okio-jvm:3.3.0 | | | +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.0 -> 1.8.22 (*) | | | \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.8.0 -> 1.8.22 | | +--- org.jetbrains.kotlin:kotlin-stdlib:1.6.20 -> 1.8.22 (*) | | \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.20 -> 1.8.22 (*) | \--- com.squareup.okio:okio:3.3.0 (*) \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.21 -> 1.8.22 (*) ### Checklist - [x] Fill out this bug - [ ] Post to team slack channel and email distribution list - [ ] Gather feedback in the comments in this bug - [ ] Solicit appropriate level of sign-offs - [ ] Mark as "DONE" if accepted; mark as "WONTFIX" if rejected (so we can revisit this decision if we ever need to in the future).
I'd like to add [coil-svg](https://coil-kt.github.io/coil/) to the repository. This is an enabler for the [PR to add SVG decoding to Fenix](https://github.com/mozilla-mobile/firefox-android/pull/4166/files). ### Justification The current method of loading icons: * Use the provided `loaders` to retrieve an `IconLoader.Result` from memory, disk, http etc. * Decode the retrieved `IconLoader.Result` using the given `decoders` to create an `Icon` * If `Icon` is null, generate the `Icon` The Gecko `ImageDecoder` `decode` fun takes a `URI` to "fetch and decode" which does not conform to the current architecture described above, as Fenix decoders are expected to ingest a `ByteArray`. The Coil SVG decoder however allows us to plug and play a decoder to work within the current structure. Important to note this is __only__ using the decoding mechanism provided by Coil, the resource is still fetched through our network stack. * What is this dependency going to be used for? Allows SVG decoding with a ByteArray * How often does it update? See [changelog](https://github.com/coil-kt/coil/releases) * How much community support is there for it? Well maintained * What are some risks? The API exposes other functions for fetching/caching/loading images * How can we integrate it into our codebase with appropriate guardrails? I welcome any suggestions on this * Licence: Apache-2.0 ### Dependencies output ``` \--- io.coil-kt:coil-svg:2.4.0 +--- androidx.core:core-ktx:1.9.0 -> 1.12.0 (*) +--- com.caverock:androidsvg-aar:1.4 +--- io.coil-kt:coil-base:2.4.0 | +--- androidx.annotation:annotation:1.6.0 -> 1.7.0 (*) | +--- androidx.appcompat:appcompat-resources:1.6.1 (*) | +--- androidx.collection:collection:1.2.0 (*) | +--- androidx.core:core-ktx:1.9.0 -> 1.12.0 (*) | +--- androidx.exifinterface:exifinterface:1.3.6 | | \--- androidx.annotation:annotation:1.2.0 -> 1.7.0 (*) | +--- androidx.profileinstaller:profileinstaller:1.3.1 (*) | +--- androidx.lifecycle:lifecycle-runtime:2.6.1 -> 2.6.2 (*) | +--- org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.1 -> 1.7.2 (*) | +--- org.jetbrains.kotlin:kotlin-stdlib:1.8.21 -> 1.8.22 (*) | +--- com.squareup.okhttp3:okhttp:4.11.0 | | +--- com.squareup.okio:okio:3.2.0 -> 3.3.0 | | | \--- com.squareup.okio:okio-jvm:3.3.0 | | | +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.0 -> 1.8.22 (*) | | | \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.8.0 -> 1.8.22 | | +--- org.jetbrains.kotlin:kotlin-stdlib:1.6.20 -> 1.8.22 (*) | | \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.20 -> 1.8.22 (*) | \--- com.squareup.okio:okio:3.3.0 (*) \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.21 -> 1.8.22 (*) ``` ### Checklist - [x] Fill out this bug - [ ] Post to team slack channel and email distribution list - [ ] Gather feedback in the comments in this bug - [ ] Solicit appropriate level of sign-offs - [ ] Mark as "DONE" if accepted; mark as "WONTFIX" if rejected (so we can revisit this decision if we ever need to in the future).
I'd like to add [coil-svg](https://coil-kt.github.io/coil/) to the repository. This is an enabler for the [PR to add SVG decoding to Fenix](https://github.com/mozilla-mobile/firefox-android/pull/4166/files). ### Justification The current method of loading icons: * Use the provided `loaders` to retrieve an `IconLoader.Result` from memory, disk, http etc. * Decode the retrieved `IconLoader.Result` using the given `decoders` to create an `Icon` * If `Icon` is null, generate the `Icon` The Gecko `ImageDecoder` `decode` fun takes a `URI` to "fetch and decode" which does not conform to the current architecture described above, as Fenix decoders are expected to ingest a `ByteArray`. The Coil SVG decoder however allows us to plug and play a decoder to work within the current structure. Important to note this is __only__ using the decoding mechanism provided by Coil, the resource is still fetched through our network stack. * What is this dependency going to be used for? Allows SVG decoding with a ByteArray * How often does it update? See [changelog](https://github.com/coil-kt/coil/releases) * How much community support is there for it? Well maintained * What are some risks? The API exposes other functions for fetching/caching/loading images * How can we integrate it into our codebase with appropriate guardrails? I welcome any suggestions on this * Licence: Apache-2.0 ### Dependencies output ``` \--- io.coil-kt:coil-svg:2.4.0 +--- androidx.core:core-ktx:1.9.0 -> 1.12.0 (*) +--- com.caverock:androidsvg-aar:1.4 +--- io.coil-kt:coil-base:2.4.0 | +--- androidx.annotation:annotation:1.6.0 -> 1.7.0 (*) | +--- androidx.appcompat:appcompat-resources:1.6.1 (*) | +--- androidx.collection:collection:1.2.0 (*) | +--- androidx.core:core-ktx:1.9.0 -> 1.12.0 (*) | +--- androidx.exifinterface:exifinterface:1.3.6 | | \--- androidx.annotation:annotation:1.2.0 -> 1.7.0 (*) | +--- androidx.profileinstaller:profileinstaller:1.3.1 (*) | +--- androidx.lifecycle:lifecycle-runtime:2.6.1 -> 2.6.2 (*) | +--- org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.1 -> 1.7.2 (*) | +--- org.jetbrains.kotlin:kotlin-stdlib:1.8.21 -> 1.8.22 (*) | +--- com.squareup.okhttp3:okhttp:4.11.0 | | +--- com.squareup.okio:okio:3.2.0 -> 3.3.0 | | | \--- com.squareup.okio:okio-jvm:3.3.0 | | | +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.0 -> 1.8.22 (*) | | | \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.8.0 -> 1.8.22 | | +--- org.jetbrains.kotlin:kotlin-stdlib:1.6.20 -> 1.8.22 (*) | | \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.20 -> 1.8.22 (*) | \--- com.squareup.okio:okio:3.3.0 (*) \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.21 -> 1.8.22 (*) ``` ### Checklist - [x] Fill out this bug - [x] Post to team slack channel and email distribution list - [ ] Gather feedback in the comments in this bug - [ ] Solicit appropriate level of sign-offs - [ ] Mark as "DONE" if accepted; mark as "WONTFIX" if rejected (so we can revisit this decision if we ever need to in the future).
I'd like to add [coil-svg](https://coil-kt.github.io/coil/) to the repository. This is an enabler for the [PR to add SVG decoding to Fenix](https://github.com/mozilla-mobile/firefox-android/pull/4166/files). ### Justification The current method of loading icons: * Use the provided `loaders` to retrieve an `IconLoader.Result` from memory, disk, http etc. * Decode the retrieved `IconLoader.Result` using the given `decoders` to create an `Icon` * If `Icon` is null, generate the `Icon` The Gecko `ImageDecoder` `decode` fun takes a `URI` to "fetch and decode" which does not conform to the current architecture described above, as Fenix decoders are expected to ingest a `ByteArray`. The Coil SVG decoder however allows us to plug and play a decoder to work within the current structure. Important to note this is __only__ using the decoding mechanism provided by Coil, the resource is still fetched through our network stack. * What is this dependency going to be used for? Allows SVG decoding with a ByteArray * How often does it update? See [changelog](https://github.com/coil-kt/coil/releases) * How much community support is there for it? Well maintained * What are some risks? The API exposes other functions for fetching/caching/loading images * How can we integrate it into our codebase with appropriate guardrails? I welcome any suggestions on this * Licence: Apache-2.0 ### Dependencies output ``` \--- io.coil-kt:coil-svg:2.4.0 +--- androidx.core:core-ktx:1.9.0 -> 1.12.0 (*) +--- com.caverock:androidsvg-aar:1.4 +--- io.coil-kt:coil-base:2.4.0 | +--- androidx.annotation:annotation:1.6.0 -> 1.7.0 (*) | +--- androidx.appcompat:appcompat-resources:1.6.1 (*) | +--- androidx.collection:collection:1.2.0 (*) | +--- androidx.core:core-ktx:1.9.0 -> 1.12.0 (*) | +--- androidx.exifinterface:exifinterface:1.3.6 | | \--- androidx.annotation:annotation:1.2.0 -> 1.7.0 (*) | +--- androidx.profileinstaller:profileinstaller:1.3.1 (*) | +--- androidx.lifecycle:lifecycle-runtime:2.6.1 -> 2.6.2 (*) | +--- org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.1 -> 1.7.2 (*) | +--- org.jetbrains.kotlin:kotlin-stdlib:1.8.21 -> 1.8.22 (*) | +--- com.squareup.okhttp3:okhttp:4.11.0 | | +--- com.squareup.okio:okio:3.2.0 -> 3.3.0 | | | \--- com.squareup.okio:okio-jvm:3.3.0 | | | +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.0 -> 1.8.22 (*) | | | \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.8.0 -> 1.8.22 | | +--- org.jetbrains.kotlin:kotlin-stdlib:1.6.20 -> 1.8.22 (*) | | \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.20 -> 1.8.22 (*) | \--- com.squareup.okio:okio:3.3.0 (*) \--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.21 -> 1.8.22 (*) ``` ### Checklist - [x] Fill out this bug - [x] Post to team slack channel and email distribution list - [x] Gather feedback in the comments in this bug (see linked issue) - [x] Solicit appropriate level of sign-offs - [x] Mark as "DONE" if accepted; mark as "WONTFIX" if rejected (so we can revisit this decision if we ever need to in the future).