Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dismissing a TapTargetSequence at the last target #294

Closed
FranziscaZarrai opened this issue Jun 11, 2018 · 0 comments
Closed

Dismissing a TapTargetSequence at the last target #294

FranziscaZarrai opened this issue Jun 11, 2018 · 0 comments

Comments

@FranziscaZarrai
Copy link

FranziscaZarrai commented Jun 11, 2018 •
edited
Loading

  • [ X ] I have verified the issue exists on the latest version
  • [ X ] I am able to reproduce it

Version used:
1.11.0

Stack trace:
No crash occurs

Android version:
8.1.0

Description
Following situation: Say we got a TapTargetSequence of three, the user taps on the first target (which then get's dismissed), then he taps on the second (which is also correctly dismissed). Then we call TapTargetSequence#cancel() - which will return "false" because when TapTargetSequence#showNext() was called for the last TapTarget, that last target was removed from the targets list, thus changing it's size to zero (i.e. isEmpty in TapTargetSequence#cancel() evaluates to "true"). Now I am not sure if this is by design. But that means, that we can't cancel (and ultimately reset) a TapTargetSequence if the last TapTarget is already showing (but has not been interacted with by the user).

Our scenario is as follows:

  • Start the TapTargetSequence
  • If the user switches off the screen before completing the TapTargetSequence, we reset it to the beginning - so the last TapTarget shown (before the user switched off the phone screen) does not to visually overlap with the new TapTargetSequence
  • The latter does not work and the overlap (new TapTargetSequence overlaps with last element of old TapTargetSequence) occurs
xiphirx added a commit that referenced this issue Jul 5, 2018
@xiphirx
Fix not being able to cancel on last target
82f17e0 
Simplifies an early return + properly unsets currentView. Fixes #294
@xiphirx xiphirx mentioned this issue Jul 5, 2018
Merged
xiphirx added a commit that referenced this issue Jul 5, 2018
@xiphirx
Fix not being able to cancel on last target (#299)
8036db5 
Simplifies an early return + properly unsets currentView. Fixes #294
ganny26 pushed a commit to wa2do/TapTargetView that referenced this issue Aug 10, 2018
@xiphirx @ganny26
Fix not being able to cancel on last target (KeepSafe#299)
07ac574 
Simplifies an early return + properly unsets currentView. Fixes KeepSafe#294
ganny26 added a commit to wa2do/TapTargetView that referenced this issue Aug 10, 2018
@ganny26
Rebase master (#2)
28c1dbb 
* Add startWith and startAt to TapTargetSequence (KeepSafe#228)

Previously it was cumbersome to restore state in a TapTargetSequence
after rotation due to the fact that you needed to manually modify the
list of targets you pass in to get back to your desired target. Now the
class supports starting from a specified target id or position in the
queue, allowing callers to keep a static list of targets for their
sequence.

* Added Support for React Native Projects (KeepSafe#230)

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Add notion of isDismissing and gate onReady() callbacks on it (KeepSafe#243)

* Add notion of isDismissing and gate onReady() callbacks on it

There was a race condition I came across where a view could be animating out at the same time as the animation for dismissing the tap target. If the view animated out before the taptarget, it would trigger a layout again, and potentially redisplay the taptarget again. This gates onReady callbacks against the notion of "isDismissing". Tested locally in my project and confirmed this resolves the issue.

* Return early (and earlier!)

* Fix NPE when dismiss is called immediately (KeepSafe#244)

Small "race" condition that shouldn't crash. Fixes KeepSafe#240

* 1.11.0

* Fix "sometimes" typo (KeepSafe#246)

* Update Gradle version (KeepSafe#253)

* Disable interaction during expand animation (KeepSafe#248)

* Fix build (KeepSafe#256)

* Update to latest support library + SDK version (KeepSafe#257)

Was pretty outdated previously.

* Use api configuration for public dependencies. (KeepSafe#258)

Some support annotations and the v7 support Toolbar are both part of the
public api, so they need to be specified as `api` in order for them to
transitively picked up by downstream dependants.

* Update build tools to most recent ones (KeepSafe#261)

* update build tools to most recent ones

* revert to last stable version and use gradle 4.5

* Use central build variables (KeepSafe#264)

* in module "taptargetview" buildToolsVersion was missing und request an install of 26.0.2
* variable SupportLibraryVersion was just in one module

* Handle dismiss before show

* Replacement of "compile" with "implementation" (KeepSafe#291)

As "compile" is going to be deprecated end-2018, this PR replaces with "implementation" that is the new usage.

* Fix NPE from dismissal before determining center (KeepSafe#298)

Fixes KeepSafe#279

* Fix not being able to cancel on last target (KeepSafe#299)

Simplifies an early return + properly unsets currentView. Fixes KeepSafe#294

* Fix decor related issues (KeepSafe#300)

This fixes issues relating to transparent nav bars, status bars and
multi window mode. The library will now detect when the window it is
attached to has a transparent system bar and properly adjust its clip
bounds. Fixes KeepSafe#233

* Release 1.12.0

* Updated readme to reflect latest version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@FranziscaZarrai