Conversation
…ented - doing that allowed us to push/pop anything we want to the navigation stack - added new link handling, now if a link looks even remotely "sus" I will ask Lemmy's servers if they know it, if they do know it: We push the appropriate object to the navigation stack if they don't know about it and it's an HTTP link, kept the old behavior otherwise I let the system try to open it (which is way nicer than telling the user "it's not supported" especially for mailto: links XD
…in there SwiftUI should pick up on it better (that solved a bug where the upvote/downvotes weren't updating correctly sometimes - updated every place that expects APIPostView.id == APIPostView.post.id to reference the correct id (usually .post.id) - Since ExpandedPost is not more independent made the postView within it it's state
…n-app # Conflicts: # Mlem.xcodeproj/project.pbxproj
…n-app # Conflicts: # Mlem/Views/Tabs/Posts/Components/Post/Components/Community View/Community Search/Community Search View.swift
- saved a new security on it - included touchID / FaceID
Had to commit some more crims to keep the SwiftUI state all synced up nicely Made sure to noty double up on the NavigationStack in the user page since it really crashs everything for some reason
# Conflicts: # Mlem.xcodeproj/project.pbxproj # Mlem/Extensions/View - Handle Lemmy Links.swift # Mlem/Views/Tabs/Posts/Components/Post/Components/Instance and Community List/Accounts Page.swift
ShadowJonathan
left a comment
There was a problem hiding this comment.
Thanks, no further nits, i'll leave @JakeShirley to review this further :)
|
should a blocking screen like this not be presented as a in the video we're only covering the central content, the navigation and tab bars remain visible which show potentially sensitive information like the users name and community names etc? Is interaction blocked on those visible elements? |
|
Another small thought, generally biometric locks like this on iOS will attempt authentication automatically when you open, as opposed to requiring the user to interact by tapping? |
|
I was still working on this, but in order to achieve this, we need to introduce some artificial delay since swiftUI doesn’t like it for some reason (and also a lot of times FaceID is so fast you don’t even notice the locking screen is there which is confusing and jarring especially if the faceID sensor is still warm from unlocking your phone) |
JakeShirley
left a comment
There was a problem hiding this comment.
Minor nit but "Account Settings" makes it sound like it will only apply to a single account but these seem to apply cross-account.
| } | ||
| } catch {} | ||
| // if all went well we shouldn't get here | ||
| // await MainActor.run { |
There was a problem hiding this comment.
Looks like some left over debug code
EricBAndrews
left a comment
There was a problem hiding this comment.
One nit, everything else looks good
| if let account = account { | ||
| if accountsTracker.accountPreferences[account.id]?.requiresSecurity == true { |
There was a problem hiding this comment.
else condition is idempotent, condense these into a single check
…pp, it takes a url and uses our cache to load it, and blurs it according to the users wishes if you marked it as NSFW introduced a new CachedImageProvider that can give you the uniform cached image view that's loaded from a URL and respects the nsfw setting Had to break the Markdown view since it wasn't flexible enough, so now the MarkdownView handles images before passing on the torch of actual markdown to the library's Markdown View
…faceId # Conflicts: # Mlem.xcodeproj/project.pbxproj
…mage-handling # Conflicts: # Mlem/Views/Shared/Markdown View.swift # Mlem/Views/Shared/Website Icon Complex.swift # Mlem/Views/Tabs/Posts/Components/Comment/Components/Comment Item Old.swift # Mlem/Views/Tabs/Posts/Components/Comment/Components/Comment Item.swift # Mlem/Views/Tabs/Posts/Components/Post/Components/Community View/Post Item/Post Types/Large Post.swift
…faceId # Conflicts: # Mlem/App Constants.swift # Mlem/Logic/File Management/Decode Data from File.swift # Mlem/MlemApp.swift # Mlem/Views/Tabs/Posts/Components/Post/Components/Community List View/Community List View.swift # Mlem/Views/Tabs/Settings/Components/Views/General.swift
- made faceID try automaticlly once the device *wakes up from sleep* or when the app returns from the background - also merged the better-ish-image-handling... don't
|
Whoa guys I didn’t notice all those Nits so let me address them all
1.2 1.3
3 and 5.
The Face ID protects per account |
I must say I disagree with this approach, any and all biometric lock I've seen implemented in iOS blocks all interaction with the application. FaceID/TouchID is a reliable system feature, and as long as we allow fallback to the users passcode they're not at risk of getting stuck unless they've lost their finger / face and forgot their code 🙃 What do other people think, should only part of the interface be obscured when locked? I can see some value in allowing it to be set by account, but to me again we'd block the entire interface, if someone needed out they could always swap the app away and when it re-opens it will be on the account screen, tapping on a protected account could prompt for biometrics before pushing into the user feed? --- EDIT Also, just to be clear I'm saying I disagree, I'm not the boss, it's just my opinion 🙃 |
|
We've been erring on the side of "do it the Apple way" pretty much every time it's come up, for consistency I'm going to agree with morm here |
|
I honestly don’t disagree. I think both approaches have a value to them, and I wanted to air on the side of caution (to me, that meant a lock that you can always escape from) So I'll gladly change it (I believe we should strive to be system, consistent and looking at a few examples I can confirm that the usual behavior is Face ID stop the interaction all together (so full cover), and when it comes to critical stuff when you can’t scan Face ID, or tap your passcode, it goes back to the previous interaction, which matches your description, so I’m also happy to change) I will change the behavior for this feature in my next update |
# Conflicts: # Mlem.xcodeproj/project.pbxproj # Mlem/Views/Shared/Markdown View.swift # Mlem/Views/Tabs/Posts/Components/Comment/Components/Comment Item Old.swift # Mlem/Views/Tabs/Posts/Components/Comment/Components/Comment Item.swift # Mlem/Views/Tabs/Posts/Components/Post/Components/Community View/Components/Sidebar.swift # Mlem/Views/Tabs/Posts/Components/Post/Components/Community View/Post Item/Post Types/Large Post.swift # Mlem/Views/Tabs/Posts/Components/User/Components/User View.swift
|
Heya @tht7, we have a new repo at https://github.com/mlemgroup/mlem, due to some shuffling around we couldn't get it migrated properly, but if you could reopen this PR there, and link it back here, then it can continue to be considered ^^ |




Checklist
Choose one of the following two options:
Choose one of the following two options:
Pull Request Information
Wop wop made a new place to place all changing account preferences that's way more reactive with SwfitUI
added a new option to lock an account with FaceID
Screenshots and Videos
RPReplay_Final1687620258.mov
Additional Context
Maybe mlemgroup/mlem#118