Here are the problems I want to solve:
The same app everywhere
It will run as a website, iOS app (also on macOS), and Android app. It will be responsive, supporting phone, tablet, and computer screen sizes along with everything in between.
And I’m not talking about simply resizing the interface. Navigation (e.g. sidebar or on mobile bottom tab bar) will match what you would expect to see on the device size you’re using. But everything else (e.g. posts) will look the same, which I hope will make it really easy to jump from mobile to desktop.
Onboarding and configuration
The app will allow you to configure it to look like a typical Reddit or Lemmy app. During the onboarding process, I will prompt you, asking which style of interface you prefer. Consider these presets, which change a bunch of more granular configuration options. I will also give you the ability to fully customize each option instead of picking a preset.
Caching and offline support
This is where it starts to get more tricky. Caching is easy. If you launch the app, it will have everything you previously saw still loaded.
I would like to make it so upvoting, for example, can be done offline. The app will optimistically apply the upvote to the post or comment, then when you reconnect to the internet, it will actually apply the upvote. This is a difficult problem to solve, so I can’t promise this will work, and it would likely be the last feature I add.
I need your feedback
This is a big project to undertake. I really want a Lemmy client that checks those boxes for myself, but I’m curious if any of those resonate with you? Is there anything I missed that you would like to see? If I do build this, I will likely have to keep the project very focused as far as features go initially.
Just for context, I’m using Voyager on iOS currently. I really like it, but the “the same app everywhere” concept and making it easier to onboard Reddit users are my main motivations for creating my own app. My app will also be fully open source
You can use the hash for image caching.
Got it. As you can see, I am myself very new to Lemmy and still learning their API. I still need to think through this more since even caching hashes will consume much more data than caching the text content of posts and replies.
Most likely I’ll want to give control to the user of what they want to cache. Either text or text + images.
Looks like lemmy api does not give the hash of the image, that’s unfortunate.
You’d need to use the link field instead.
Update on this matter:
I made a feature request for including an image hash with the
image_details
table but it seems like they will be adding a blurhash field instead, which is unique enough for a temporary cache that will at most probably cache ~100 images at best.Oh and yeah, you probably should get ready to support blurhash in your client. It both acts as a small hash and a way to show blurry “previews” of the image.
Links: https://github.com/LemmyNet/lemmy/issues/5238
https://github.com/LemmyNet/lemmy/issues/5142
I was just looking at image_details but for the height and width of the image. I see this exists in the TypeScript client schema, but I’m not seeing it populated for any posts. Any idea when this is actually populated?
Knowing the height and width of images before loading them would reduce layout shift.
Seems like the
image_details
table was added in Lemmy v0.19.6. if you are testing it with your current instance (LW), it’s still using Lemmy v0.19.3. That’s why.Link: https://github.com/LemmyNet/lemmy/compare/0.19.5...0.19.6
Ohhh that makes sense! Thank you!
np