Thanks for reporting, I'll have a look at it. It seems like bullets inside quotes break the Markdown rendering.
EDIT: Fixed here!
Multi-communities? Really? 😍
I'll put a disclaimer in the readme page.
I forgot to ask an important question: I am considering submitting the app to some stores now that we have a "real" release.
I would start with F-Droid and IzzyOnDroid, what do you think? Do you have any other recommendations?
The stacktrace of the exception, operative systm version and app version, the date when the crash happened (as well as statistics on the number of occurences over time), device manufaturer and model, whether the device is rooted, the system locale, whether the app is in background, battery level, orientation when the crash occurred. It could collect other data that classify as sensitive information (e.g. IP addresses which may give hint about the location) but these can be disabled.
It's not me, the developer, who can use this data for profit (which is quite obvious since I am a volunteer): what is really at stake here is whether it's worth putting these data in the hands of a corporation (this is not a self-hosted service, I would be running on their servers and using the free plan)... It's a cost-benefit tradeoff, plus the setup which is not exactly trivial, especially since I have to change the release pipelines for CI/CD because the build breaks.
Great news! I'll have a look at why the UI theme option is not transferred.
Ok I have changed the scale factors recently, maybe I made them too similar. I'll review them!
Ok I'll change the label in the next release.
Yes, there is an option to export settings to a JSON file and you can reimport them in the new app. It's a while since I last tried the procedure but it should work.
Since I worked on a Mastodon client, I know that there is a hide_collections parameter in the account settings which allows you to not disclose publicly your followers and following.
It's in the PATCH v1/accounts/update_credentials API request body, see documentation here.
No trouble at all, maybe this is a hint that the label is misleading, in the Lemmy lingo those are "saved items" not "bookmarks" (like, say, on Mastodon).
view more: next ›
Raising the min API level does not refer to the API level the app is compiled against or targeting, nor that it cannot use newer functionalities. It just means that there are some "if"s for when a newer system API is called to exclude its usage on older devices and, instead, use a fallback when possible.
Personally, I would not raise
minSdkbecause that would restrict the user base, which is already quite narrow. Rather, I am going to continuously raisetargetSdkbecause that ensures the app can use the latest features and works correctly on newest Android versions.Maybe you are referring to Summit supporting predictive back gestures and Raccoon not doing so. This is not related to the API level but to the fact that Raccoon uses Kotlin Multiplatform and Compose Multiplatform. Being a multiplatform app means that it's relatively easy to get an iOS or desktop build but there are restrictions on some native features such as predictive back.
Raccoon uses the Voyager library for navigation which still doesn't support predictive back (issue here) due to such difficulties. I've considered replacing it because AndroidX Compose navigation has been ported to multiplatform but it's not easy changing a core library like the navigation one.