I was using the ImageConfig.HARDWARE configuation for thumbnails since it seemed to help perfomance, but I got this exception when I was testing on a older emulator(API 24).

I did some research and it seems like Bitmap.Config.HARDWARE wasn't added until API 26. I changed what I use for ImageConfig to a variable that changes based on the API level, but I think this should be handled at the library level or at least give a warning.

2022-11-08 00:12:12.982 11097-11097/ca.gosyer.jui.android.debug W/ImageLoaderImageKt: Caused by: java.lang.NoSuchFieldError: No field HARDWARE of type Landroid/graphics/Bitmap$Config; in class Landroid/graphics/Bitmap$Config; or its superclasses (declaration of 'android.graphics.Bitmap$Config' appears in /system/framework/framework.jar)
        at com.seiko.imageloader.util.BitmapKt.toBitmapConfig(Bitmap.kt:19)
        at com.seiko.imageloader.component.decoder.BitmapFactoryDecoder.configureConfig(BitmapFactoryDecoder.kt:86)
        at com.seiko.imageloader.component.decoder.BitmapFactoryDecoder.decode(BitmapFactoryDecoder.kt:59)
        at com.seiko.imageloader.component.decoder.BitmapFactoryDecoder.access$decode(BitmapFactoryDecoder.kt:26)
        at com.seiko.imageloader.component.decoder.BitmapFactoryDecoder$decode$2$1.invoke(BitmapFactoryDecoder.kt:34)
        at com.seiko.imageloader.component.decoder.BitmapFactoryDecoder$decode$2$1.invoke(BitmapFactoryDecoder.kt:34)
        at kotlinx.coroutines.InterruptibleKt.runInterruptibleInExpectedContext(Interruptible.kt:51)
        at kotlinx.coroutines.InterruptibleKt.access$runInterruptibleInExpectedContext(Interruptible.kt:1)
        at kotlinx.coroutines.InterruptibleKt$runInterruptible$2.invokeSuspend(Interruptible.kt:43)
        at kotlinx.coroutines.InterruptibleKt$runInterruptible$2.invoke(Interruptible.kt)
        at kotlinx.coroutines.InterruptibleKt$runInterruptible$2.invoke(Interruptible.kt)
        at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:89)
        at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:161)
        at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)
        at kotlinx.coroutines.InterruptibleKt.runInterruptible(Interruptible.kt:42)
        at kotlinx.coroutines.InterruptibleKt.runInterruptible$default(Interruptible.kt:39)
        at com.seiko.imageloader.component.decoder.BitmapFactoryDecoder.decode(BitmapFactoryDecoder.kt:34)
        at com.seiko.imageloader.intercept.DecodeInterceptor.decode(DecodeInterceptor.kt:45)
        at com.seiko.imageloader.intercept.DecodeInterceptor.intercept(DecodeInterceptor.kt:19)
        at com.seiko.imageloader.intercept.RealInterceptorChain.proceed(RealInterceptorChain.kt:37)
        at com.seiko.imageloader.intercept.MemoryCacheInterceptor.intercept(MemoryCacheInterceptor.kt:31)
        at com.seiko.imageloader.intercept.RealInterceptorChain.proceed(RealInterceptorChain.kt:37)
        at com.seiko.imageloader.intercept.MappedInterceptor.intercept(MappedInterceptor.kt:12)
        at com.seiko.imageloader.intercept.RealInterceptorChain.proceed(RealInterceptorChain.kt:37)
        at com.seiko.imageloader.RealImageLoader.executeMain(ImageLoader.kt:64)
        at com.seiko.imageloader.RealImageLoader.access$executeMain(ImageLoader.kt:29)
        at com.seiko.imageloader.RealImageLoader$execute$2.invokeSuspend(ImageLoader.kt:50)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
        at kotlinx.coroutines.internal.LimitedDispatcher.run(LimitedDispatcher.kt:42)
        at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:95)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

If the image loader cannot successfully download an image on the first try, then, when caching is enabled, it does not make any attempt to download the image again at a later time. When the disk cache is enabled it does not even retry this when the application is terminated and started again. It seems that even in case of a download error something is stored in the cache which then blocks any further attempts. I tested this by removing my images from my server, then start the application, then copy the images back to the server while the application is still running. Switching screens or restarting the application does not force a re-load of the images. This all works when no caching is configured but this is no option for me.

I have configured caching like this:

    fun generateImageLoader(): ImageLoader {
        return ImageLoaderBuilder().apply {
            diskCache {
                DiskCacheBuilder()
                    .directory("... path to some cache directory ...".toPath())
                    .maxSizeBytes(1024 * 1024 * 50) // 50 MB
                    .build()
            }
            memoryCache {
                MemoryCacheBuilder()
                    .build()
            }
        }.build()
    }

For this part of your example usage code

private fun generateImageLoader(): ImageLoader {
    return ImageLoaderBuilder().build()
}

IntelliJ is giving me the error message

Expected class ImageLoaderBuilder does not have default constructor

This must be an IntelliJ issue because the code compiles and runs just well but maybe this error message could be avoided if you would just provide that default constructor in your code.

Otherwise your code seems to work nicely. Great job!

I have a ImageLoader with DiskCache and MemoryCache configured but it seems to only be using the MemoryCache. My images use a custom class that I have Mappers and Keyers setup for but it doesnt seem to allow them to be inserted into the DiskCache even though they are loading the images. This happens on both Desktop and Android.

I have tried with multiple configurations using the builder and even disabling the memory cache, which does not seem to help. It doesnt seem like its hitting the DiskCacheInterceptor at all and Napier says nothing about errors.

In general I cannot figure out whats wrong.

Please provide a changelog, or some other means, so we know what version of Compose each version matches with and which version of ktor it uses as well.

For the desktop version you are using the Batik based twelvemonkeys SVG renderer. Why do you do that? All desktop versions are also Skia versions and thus have the Skia SVG built in. It would save people from a lot of dependency downloads if you would drop that. The Skia SVG renderer works nicely on desktop so I don't see any reason to use the Batik one. It would make the final distribution bundles smaller.

Class 'com.seiko.imageloader.ImageLoader' is compiled by a pre-release version of Kotlin and cannot be loaded by this version of the compiler

I'm using: Kotlin 1.7.0 Compose JB 1.2.0-alpha01-dev753

This code in your Android SVG decoder

    if (svg.documentSVGVersion.startsWith("2")) {
        throw RuntimeException("Un support SVG version '2.0'")
    }

results in an NPE for many of my icons because documentSVGVersion returns null. After replacing this with

    if (svg.documentSVGVersion != null && svg.documentSVGVersion.startsWith("2")) {
        throw RuntimeException("Un support SVG version '2.0'")
    }

everything was good again.

Hi, this should add arm64 simulator target for iOS, so that people can run iOS apps on the arm64 simulator on M1/M2 Macs. I couldn't test it unfortunately as my machine fails to run iOS simulator from the IntelliJ IDEA (only works with Xcode and I couldn't get it working), but it should just work.

Thank you for producing and sharing this library; the power of the Compose/Multiplatform ecosystem is beginning to show!

While the cross-platform ability is great; I noticed you have focused API's on loading resources asynchronously. My use case is for showing SVG (and potentially other format) files from local bytes which are much faster to load and so the overhead of managing a progress 'spinner' etc. is undesirable.

If you are planning any major new features for this library; please consider building API's intended for local resources: that take byte data for images directly, and minimise overhead to display.

Thank you for maintaining this library! We desperately need something like this in the community.

The documentation is a little lacking, primarily on compatibility with what versions of Kotlin and Compose. I'm about to try out your library and I'm not confident whether it will work with my version of Kotlin / Compose.

There are also other things that seem to be lacking in the documentation around the configurability of the memory and disk caches.