2

Display issues with multiple custom toasts

Hi João!

The fade-in animation on custom toasts is a real dealbreaker for me at the moment in terms of actually being able to use them. I really wish that new toasts would display instantly rather than fading in slowly over the top of the previous one. This is especially jarring and obvious when displaying different text or background colours in quick succession.

If we could remove the fade-in completely and furthermore make sure only one toast is shown at any one time (either implicitly when creating a new custom toast, or via a separate 'cancel existing custom toasts' action), then custom toasts would become really useful.

At present, they're more of a proof-of concept so instead I find myself having to use increasingly complicated scenes and associated logic to bypass these limitations.

Other really useful features would include an option for text alignment and to preserve whitespace when using HTML5 text tags for formatting.

Many thanks for all your hard work throughout the app!

1 reply

Hi! Can you please export an example of a task that shows the issue as an URI (not a link, but a direct URI) and paste it here so I can then import it and test it myself?

Thanks in advance!

F

Thanks for the quick response! The following task is simple nonsense, but hopefully it illustrates the issue:

taskertask://H4sIAAAAAAAAANVUy2rDMBA8x18h1Hsk2fILZEGhFHpuf0C1lWDS2EVWDP37aq0kdRLbhfZQ6suudkbDaneweFHdTpsHZRXqTIExqvq6wAwj2xc4WbN1mGEZrATwBoZ1SRxCbSXKSlktWZJFjMZpFPGUC+KLAOsvOA/DhOcsF0Sf4bqScSiIC3Bq9lqWh862e2Rb1VnUWVXu6maL6q47aEGAAMR3U0tGqSCQQMHYD+l0IMDxvrR12wy9qtJSjHpd4HRo2HXcVlrGPHNtQjbUnq3xbLM9siMsN237qgzyQRDH8eSnxp7Ibki9eiswxeRGiJ2VyO2900U2BYbX4Fg1WlDlC6pLoteaI4jPQ/E8lJyHePd4/EYDHBHTeY1s/qH55VsE8Quf2D2b2H1Ex6sfyVLPWoleGRmDvyAZWMTRvt/+xLinsGgB45fYwtPCX9k6CP6hr5cG/Re+phRM8lNfe4tNjT+fNYEg8BeWgY/+ry2DT5N0uF7DBQAA

Obviously you'd be unlikely to have such a sequence of toast / wait / another toast in a single task, but I'd love to be able to replace an existing displayed toast from one task with new information from a child task, rather than stacking it over the top.

A particular use case of mine: I rigged up some home automation scenes to control various wifi light switches around the house dependent on the direction they are swiped. These display a toast when I swipe confirming which switch I'm targeting, then fire a toggle command to the switch, wait for response and then show another (shorter duration) toast with the new state (coloured black / white according to off / on). Typically this all occurs within ~1s, and is especially useful when you're toggling switches from another room or glancing at your phone when away from the house altogether.

For the last couple of years I'd been displaying these custom toasts near-instantly via a (very janky) custom toast app I hacked together when I tried to learn a bit more about Java/Android coding over the pandemic. This simply fired toasts from a broadcast receiver, keeping them in memory while displayed and cancelling them whenever a new toast intent was received. Obviously with subsequent Android versions, calling custom toasts from the background has been severely limited, so I was intrigued and pleased when I realised you'd done some work on implementing an alternative, albeit the fade-in is so much slower with the Tasker toasts.

With regard to HTML white space preservation, I figured I could just do a search-replace to swap '\n' for '<br>'. Is there any way to get text centred or right-aligned using HTML text tags? Nothing I've tried seems to have any effect.

Thanks again for looking into this 👍

 

Hhmm, what about adding an "ID" field to the toast? If same id overwrite, if not, draw over :)

That way I can keep the current behaviour for people that need it and also get to have the behaviour you want... What do you think?

F

Actually yeah that would be fine for my purposes. I was going to suggest maybe just maintaining an array of extant toasts for the 8 available positions and having a non-default option to overwrite, but your idea would be more flexible than that even.

Any idea how it would look fading in when a previous toast with the same ID is dismissed? Or would it be possible to disable the fade completely perhaps? (Again as a non-default option to avoid conflicts with existing setups).

Ok, I added the ID field.

Can you please try this version? https://drive.google.com/file/d/1morX64lZg8qjAb0NLw5OH5lwo86rcRuK/view

If you want you can also check any previous releases here: https://drive.google.com/drive/folders/1GW55YKFiuOZhJVswnt_BQUCJoGm36ugF?usp=sharing

Hope this helps!

F

Thanks for your efforts and the quick turnaround, apologies I didn't get a chance to test it yesterday evening.

This seems to do the trick in terms of dismissing the old flash message before presenting the new one, although I still find the at-a-glance legibility is detrimentally affected by the slowness of the fade-ins. Is there any way to reduce this time in general? I thought it might be tied to one of the animation / transition speed settings available within developer options, but changing these doesn't seem to affect it.

Apologies if I'm asking a lot, I just find it very useful to make toasts I've generated myself from tasks consistent with each other, but very obviously visually different compared with those generated by the system or by Tasker itself. I tend to do this by using a lot of "<tt>" tags for monospace font, as well as colouring / position / text-alignment.

On alignment, I just found a discussion on reddit (about anchor tags) where you mentioned:

> "The problem is that native HTML parsing in Android is very limited. I would have to make the label a webview to make that work I think."

I think I remember having the same issue when I tried implementing my own custom toasts, and I ended up just setting the alignment for the whole view at instantiation (via a separate option within the intent extras) - would that be a possibility at all with Tasker custom toasts?

Thanks again!

F

One other thing I've noticed with Tasker layout toasts is that they fail to show at all if I use an empty variable for the icon - giving an error "path not supported: %f_icon".

All other params just revert to default if I supply an empty (or improper format) variable - would it be possible to implement this behaviour for the icons as well?

Ok, I now made unavailable icons not make the action fail and also made the animation quicker.

Can you please try this version? https://drive.google.com/file/d/1morX64lZg8qjAb0NLw5OH5lwo86rcRuK/view

F

Much appreciated, that looks so much better! And the icon failure handling is very helpful 👍.

I noticed if I use a similar deferred var strategy for the id field it also seems to interpret it as the literal string "%f_id". Maybe if an unset variable is referenced for the id it would be better to ignore it altogether? (I'm envisaging I'd probably usually set the flash id at a project level, occasionally overriding it as required).

The overwriting / cancelling itself seems to fail intermittently when I run my test task a second time - or run a child task with the same flash id. I had a look at my runlog but couldn't see any obvious errors indicating why / under what circumstances this might happen. It _seems_ to be if I attempt to show another flash within ~1s of the last one disappearing / being dismissed via touch. This is whether I call it via Tasker's UI or from another source (eg. a shortcut from my home screen).

My updated test tasks are as follows:

taskertask://H4sIAAAAAAAAANVVXU+DMBR9hl9Banx0pXwMlpQmJsZkz/pOKnRLsw1MuUP997Z0Q7YxTPRFebntPaen9zaHlj7zZiPUAwfuNSpDyCtbmSGCPGgzNJ+RWZAi5jrU8DoG6EEcmJxDi5KDYGSehsSPkzCMkohimzSw6OEgjRckStKAYtHDsmSxTuhgZtVOsGLfQL3zoOYNeA3wYiOrtSebZi8oNgRDfFWSJRSbYKYKPphWMcFM7wuQddVVygvwkdeKDCVdubreuhQsjlJdpBl1uSdQlq3WB3aI2KquX7jybKBYcyx5WcGRrI+o5dsM+QhfCJFeCV+uOy4kY2BwDg5VwwnVaGph3Dd2u8plOd7Q1NbnOw+g6DoUX4fmfUU3j4dvUNWAmFzXSK8fx+K0F4qtLUYcQkYcEvpDgwxkfctyaMsVi31NM4OOhTXte4+MHPcYFk5g0Sk20VrwK/O77j90/2g5f979vm+s9FP3WyOO9TT1Fyx3644mi8oKBQebmGt295YXXJU5iHfI6z1sZfV1ATsUpPb6HaG4G3TKWs68Etg8E8y10T4rzP0Eq/cC1mQGAAA=

taskertask://H4sIAAAAAAAAAK1VwY7bIBA9J1+BqPZUdQFjbEfCSCv1suftPaI2idBu7AqTbPfvF0xqOQkmrdRcGPOeJzNvnoH/kMOrMt+llWAwNYSgPekaEgjsqYbFI3nMKijWK+55I8O6gI17K9600ipBiooSzEpK8zLnKGx6WE1wVrFNTjaYcaQmWLeCVRy5xT91ByWa42D7A7C9HCwYrGxedbcHehiOCmQceYqn/jJaEIw58oHfMPZDONwv/vGpsbrvxmplYzEEJ1XDcizZ1dy3SrC8dIX6aNx7sSawzf7MplA87La65chhNyQykXZ9/1OaGeu5s39YmWPJtxpiiG4wmsDyBMbOGI1gxRkjAeMo6BCRhEQlqe5KEroFqabJdfFz2aZMt8UTcln9JZhdg/OsNJE1T73IFmcdmWIsw/U/z6B8GWLLUDFV9GXnft7jMf+VyxmqZTE2f+2PLOIPiuf2mKXFgbXiJ2kE8yX7YGQhR7vvkP//ySRao5HWyGVvUesnjqalD2Emy4M7qXqj7cdXclcenDBctjz4f/Bi5DyJiVokCrl24Oy1KpFyk5jT82E/0nTTheTZeUb+2D+8bxtp2q1Vv+22P9o33anpQlhxq52S35y2YzBmdun8vYX8xSXWYQ0XnVh/AmnKpLL2BgAA

Thanks. Do you have instructions on how to reproduce the issue with those tasks? Thanks!

F

It seems a bit inconsistent reproducing it - it happens most consistently if I rerun either task again a 2nd or 3rd time before the flash from the previous invocation of that task has hidden. It's much more infrequent if I wait longer and then rerun a task within ~1s of the previous flash hiding.

In either scenario, the initial flash in the task correctly hides any existing one, but any subsequent flashes within that task don't seem to take account of having the same id - they simply overlay as happened with the original behaviour.

I'm not sure if it would really even be an issue in day-to-day usage, I was just testing out a few different scenarios. Would there be any way of hiding a flash with a given id without requiring a new flash to be shown? Maybe specifying a timeout of 0?