* fix(mobile): decode remote thumbnails at displayed size
* use nullable decode size and reuse the tapped thumbnail in the viewer
* clean up decode size naming and guards
* feat(mobile): handle Android ACTION_VIEW intent
- add ViewIntent Pigeon API and generated bindings
- implement Android ViewIntentPlugin + iOS no-op host
- route ExternalMediaViewer by ViewIntentAttachment
- buffer pending view intents and flush on user ready/resume
* feat(mobile): fallback to computed checksum for timeline match
- hash local asset on-demand when checksum missing
- search main timeline by localId or checksum before standalone viewer
- persist computed hash into local_asset_entity
* fix(mobile): proper handling is user authenticated
* feat(mobile): open ACTION_VIEW fallback in AssetViewer
drop ExternalMediaViewer route
* feat(mobile): add logger
* test(mobile): add unit tests for view intent pending/flush flow
* fix(mobile): fix format
* fix(mobile): remove redundant iOS code
update code related to LocalAsset model and asset viewer
* refactor(mobile): simplify view intent flow and support file-backed ACTION_VIEW assets
remove redundant view intent model/repository layer
handle transient ACTION_VIEW files in viewer/upload flow
clean up managed temp files for fallback assets
* refactor(mobile): extract MediaStore utils and resolve view intents via merged assets
* refactor(mobile): move deferred view intents into providers, split view-intent providers, and clean up ACTION_VIEW handling
* refactor(mobile): resolve merge conflicts
use NativeSyncApi for hash files instead method from removed BackgroundServicePlugin.kt
* style(mobile): format files
* style(mobile): format files #2
* refactor(mobile): lazily materialize view-intent files and clean up temp-file handling
* fix(mobile): flush pending view intents after login navigation
* refactor(mobile): split view intent handler by platform and trigger it from app events
* refactor(mobile): move view intent handling behind platform-specific factories
* refactor(mobile): simplify code
* fix(mobile): hand off deep-link viewer to main timeline after upload
Add MainTimelineHandoffCoordinator to switch the asset viewer to the main timeline once a view-intent asset is uploaded and becomes available, and guard viewer reload/navigation transitions to avoid race conditions and crashes.
* refactor(mobile): use remote asset ids for view intent handoff and simplify resolver
* refactor(mobile): resolve merge conflicts
* style(mobile): reformat code
* style(mobile): reformat code #2
* fix(mobile): stabilize Android view intent asset resolution and fallback viewer
* refactor(mobile): share AssetViewer pre-navigation state preparation
* fix(mobile): wait for main timeline before deferred view intent handoff
* refactor(mobile): decouple view intent asset resolver from providers
* fix(mobile): avoid double pop when canceling upload dialog
* fix(mobile): resolve view intent MIME type with fallbacks
* docs(mobile): clarify view intent fallback asset TODO
* fix(mobile): resolve merge conflicts
* cleanup
* lint
---------
Co-authored-by: Peter Ombodi <peter.ombodi@gmail.com>
Co-authored-by: shenlong-tanwen <139912620+shalong-tanwen@users.noreply.github.com>
Co-authored-by: Alex Tran <alex.tran1502@gmail.com>
Videos have recently been changed to support zooming, but this can make
the controls in the centre of the screen unergonomic as they will either
stay in the centre when dismissing, or stick to the video when zooming.
Neither is great. We should align the behaviour with other apps which
has the play/pause toggle at the bottom of the screen with the seeker
bar instead.
Co-authored-by: Alex <alex.tran1502@gmail.com>
The background of the photo view does not extend below the height of the
viewport, and so the asset details fade in over black with the photo
view, and the standard surface colour scheme of the scaffold for the
rest. This leads to a janky animation. We can't change the background of
the scaffold to black, as it in turn makes the iOS bouncing scroll
physics cut off incorrectly. The best fix is to remove background
decoration from the photo view, and defer to the parent to colour the
background.
Co-authored-by: Alex <alex.tran1502@gmail.com>
In order to scroll smoothly without interfering with the gesture
detector on the photo view, we have an offstate scroll view which we
defer all drags to, and then forward scroll offsets to the real scroll
controller. This works well, but it can be simpler. Instead, we can
create a custom scroll controller on a scroll view with never scrollable
physics, and then forward drag events to that, bypassing the need for a
proxy scroll controller.
Co-authored-by: Alex <alex.tran1502@gmail.com>
Consolidate video state into a single asset-scoped provider, and reduce
dependency on global state generally. Overall this should fix a few
timing issues and race conditions with videos specifically, and make
future changes in this area easier.
The image in the photo view has no height, and is therefore entirely
unconstrained. This causes the image to take up the full height of the
viewport during the hero animation, which can make look out of sync. In
some other cases, it can stretch or resize the image to fill the entire
viewport.
The changes in #25952 inadvertently removed an optimisation which
prevents the video player from being recreated when the tree changed.
This happens surprisingly often, namely when the hero animation
finishes. The widget is particularly expensive, so recreating it 2-3 in
a short period not only feels sluggish, but also causes the video to
hitch and restart.
The solution is to bring the global key back for the native video
player. Unlike before, we are using a custom global key which compares
the values of hero tags directly. This means we don't need to maintain a
map of hero tags to global keys in the state, and also means we don't
have to pass the global key down multiple layers.
This also fixes#25981.
Asset details are prematurely hidden when a drag ends if the simulation
shows that it will close given its current velocity. It makes for a much
more responsible feeling UI. However, this behaviour conflicts with the
logic which determines whether details are showing based on the current
offset. The result is that the details are hidden, then immediately
shown again, and then hidden once it passes the min snap distance
threshold.
This can be fixed by only evaluating the position based logic when a
drag is active, and then inferring upcoming state with a simulation.
Keeping track of the last scroll offset and guarding on scroll direction
is not necessary. The dead zone with kTouchSlop is more than sufficient,
and much simpler.
Co-authored-by: shenlong <139912620+shenlong-tanwen@users.noreply.github.com>
We have all the information we need to decide on whether we should pop
or not at the end of a drag. There's no need to track that separately,
and update the value constantly.
* wip
* Functional implementation, still need to bug test.
* Fixed flickering bugs
* Fixed bug with drag actions interfering with zoom panning. Fixed video being zoomable when bottom sheet is shown. Code cleanup.
* Add comments and simplify video controls
* Clearer variable name
* Fix bug where the redundant onTapDown would interfere with zooming gestures
* Fix zoom not working the second time when viewing a video.
* fix video of live photo retaining pan from photo portion
* code cleanup and simplified widget stack
---------
Co-authored-by: Alex <alex.tran1502@gmail.com>
* feat(mobile): tap behavior for next/previous image
This change enables switching to the next/previous photo in the photo
viewer by tapping the left/right quarter of the screen.
* Avoid animation on first/last image
* Add changes to asset_viewer.page
* Add setting for tap navigation, disable by default
Not everyone wants to have tapping for next/previous image enabled, so
this commit adds a settings toggle. Since it might be confusing behavior
for new users, it is disabled by default.
* chore: refactor
* fix: lint
---------
Co-authored-by: Alex Tran <alex.tran1502@gmail.com>
We were manually tracking whether gestures should be blocked, which was
a remnant of how the old code worked. This is no longer needed as we
have better heuristics for knowing whether we should skip drag updates
now.
Co-authored-by: Alex <alex.tran1502@gmail.com>
The drag intent was not set until it reached the kTouchSlop threshold.
This is not necessary as flutter already has its own heuristics for
preventing unintended drags.
The result of using kTouchSlop is that dismissing or scroll can feel a
little delayed, and will jump from 0 to kTouchSlop (18px) rather than
moving smoothly.
The existing implementation for showing asset details uses a bottom
sheet, and is not in sync with the preview or scroll intent. Other apps
use inline details, which is much cleaner and feels better to use.
