Hello folks :wave: I’ve created a lightweight Kotl...

# feed

[Vivien Mahé]

Hello folks 👋
I’ve created a lightweight Kotlin Multiplatform library called Alarmee 🔔 for easily scheduling alarms and local notifications on both Android and iOS.
If you’d like to skip the hassle of configuring alarms on both platforms, this library offers minimal setup and straightforward usage.
I’d love to hear your feedback or see contributions! Thanks ✨
https://github.com/Tweener/alarmee/

[Pablichjenkov]

I noticed it uses other libraries like Napier and tweener. When imported to another project those will be imported transitively. Is there a way to not use them in the release build

[Vivien Mahé]

For Napier, I will remove it and use a basic println instead.
For my other library, I could remove it as well but that means duplicating the code (which is what I try to avoid).
Just out of curiosity, which reasons motivates you to avoid other libs? (no judgement here, just asking to understand 🙂)

[Pablichjenkov]

In general there are a few things.
• If I am using the same library in my project, then I have to make sure my version is compatible with your version. Otherwise the App will crash at runtime. This is true especially for Android. On iOS you can get away with static compilation embedding 2 versions of the library in the final binary but then it affects the App size. However, even if you avoid the crash, the behavior of the library versions could be different leading to hard to find bugs.
• App size, the included library will end up in my final App too increasing its size.
• To that above, add possible security holes, transitive permissions, transitive minimum version, all these stuff that could get on the way.

[Vivien Mahé]

Thanks for your detailed answer!
I agree with you, these are things to take into account with libraries. But first of all, if you use one of my libraries in your projects, I'd be be very happy 😁
• About the library versions, this is something quite common and most of the time there are no issues with different versions. (For instance, if your library uses Kotlin 1.9 and I use it in my project, which uses Kotlin 2.0). If you face an issue with one of my libraries, I'm usually quite responsive and will come up with a fix quickly.
• About the app size, in the case of Alarmee, the other library of mine that I use is already quite light. But you can always optimize it with Proguard or R8 in your Android app (I might need to add things about it too). For iOS, I'm not sure what's the best option.
• For your last point, I'm opened to suggestions. This is not an area where I consider myself an expert so I'd be happy to improve the library if you have any ideas!
Thank you 🙏

[Pablichjenkov]

Well basically my last point is in regards to risks that we don't want to take importing transitive dependencies, the comment is not directed to your library but to what you depend on. What I mean to say is that devs will be hesitant to import Napier, let's say, or any other library that who knows what it does. That's why normally as a lib developer you want to depend on the least dependencies possible.

[Vivien Mahé]

Yes couldn't agree more. I'll make some changes regarding that.
Thank you for your feedback!

[Lukáš Kúšik]

Can you also schedule repeating notifications?

[Vivien Mahé]

It is not possible in the current version but that's something planned in the roadmap 🙂

[Vivien Mahé]

Hey @Lukáš Kúšik, in case you still in need of scheduling repeating alarms, I've added the feature to my library: Alarmee. Let me know if this is what you need!

[Lukáš Kúšik]

yes, looks great. I won't refactor my existing solution now as it works but I'll keep your library in my stars and use it for something new 🙂

[Vivien Mahé]

Of course, I completely understand! Perfect, thank you 🙂