ericbandrews

❤️

There are both technical and design reasons for the change.

Technically, it lets us rip out a lot of logic that handled the differences involved in loading and displaying your own profile vs someone else's; from a design perspective, this makes your profile page a much more logical grouping: "content you created" instead of "content you created and also content you saved." Feeds is already the root category for "content other users created," with each item (All/Local/Subscribed/Community) displaying a filtered subset of that content, a grouping into which Saved fits much more naturally.

Saved posts have moved to Feeds—you can find them alongside All/Local/Subscribed.

My bad, forgot a piece of the path! It's Settings -> General -> Open Links in Browser (first item in the list).

There are two options:

• In-app, which is basically Safari
• Your default system browser

You can pick which of these to use via Settings -> Open Links In Browser (on will use system browser, off will use in-app browser). Right now we don't support opening in a third, non-system-default browser.

There were a few reasons behind the change:

• Saved was the odd man out in the profile page--everything else there is your own authored content
• Saved is a feed containing a subset of content generated by other users. Every other such feed was under Feeds; now all such feeds are under Feeds
• This way, what you see on your profile page is the same as what other users see on your profile page
• By extension, the code is much nicer this way because we don't need to do as much conditional rendering and processing in the user page--we can use the same component with very little modification to display your own profile or somebody else's
• This also lets us add the Saved feed to the app shortcuts menu without making that horribly inconsistent--the four shortcuts are the four header items in the Feeds tab

They've moved from the profile to the feeds tab--you can find them in the feed/community list or by navigating from the header within that tab.

Thanks for the bug reports! Looks like there's an error in the refresh logic for save--posts should remain in the view when initially unsaved (to avoid losing them forever on accidental unsave), but should disappear when the view is refreshed (which does not appear to be happening).

As far as community blocking goes, that's mostly handled server-side--once you block a community, the app should filter posts from that community out of the currently displayed feed, and relies on the server-side block functionality to keep those posts from appearing in subsequent loads. We load in pages of ~50 posts, so if you block a community from, say, the profile page, it won't update that over on the Feeds tab (yet, we're looking at ways to implement that behavior but it's fairly involved) and so you'll still see those posts in the feed until the next load. In theory, simply refreshing the feed will clear them out because it'll fetch the page fresh from the server.

Thanks for the bug reports!

Highlighting new comments is a good idea! I'll have to take a look at what support there is API-side for it.

We'd like to remember collapse state, though that one's a little trickier technically--collapse state is client-side, so we have to do some caching tricks to make that work. We're reworking our backend modeling for 1.3 to include, among other things, a caching system, so we'll see if we can work that in.

Unfortunately the API doesn't support that and it's infeasible to do client-side, so not for now. They have an issue for it but it's closed as not planned, though they'll reopen it if anybody wants to work on it so hopefully we will be able to offer this feature in the future.

Unfortunately not--Mlem is written entirely in Swift and SwiftUI, which as of right now doesn't work on Android.