I don't recall if this changed recently (I'm on 10.13), but when I call display notification in a fast loop, the notification changes to "N new notifications". Totally unhelpful for most of my scripts.
I've tried sporadically calling the notification with
if notificationCount / someDenom = (notificationCount / someDenom) as integer then display notification "etc."
which works if how long a loop will take is a known quantity. But half the time, I'm calling the scripts sometimes on a local drive, other times over a network, and the results are unpredictable. Either I don't get frequent enough notifications, or it collapses into the too many display sometimes.
Thinking it's entirely possible that this is baked into macOS and there's nothing I can do except the above, but thought someone might have a bright idea.
[Edited to add: just had one myself, a subroutine which notes the datestamp and elapsed time since the last call, then only calls the notification if N seconds have passed. I'll give that a try.]
[Edited again: well, that technically works, but it adds 0.68 seconds to every notification, which is a pretty high cost in a tight loop.]
Not sure if this is what you are looking for but it works for scripts:
delay 1
display notification "uno momento..."
delay 1
display notification "it works!"
Meaning, figure out a way to add a delay between notifications if they're not appearing / play with the delay time until it works for your purposes. I found using 1 sec is OK since users will read at that speed, and it allows the OS time to catch up and ensures all notifications are listed in order AND all of them show up / are displayed to user.
I found I also have to include a delay prior to the first notification, if sending notifications in a group...again ensuring first notify displays properly.
Related
Is there a way to implement the countdown feature for the slack message using Slack API?
The message should only be valid for specified amount of time and then it should disappear or stop user interaction with it.
Yes technically this is possible. To display the countdown you need to use two methods, that is chat.postMessage and chat.update. chat.postMessage is for posting the initial message that contains the full counter say 5 minutes. After the initial message is posted you will need to run a loop in you code that updates the initial message with the depreciating value (4 minutes, 3 minutes and so on) using the chat.update method. After the countdown ends you can now delete or update the blocks to remove the interactions (buttons and so on). I hope that provides some insight.
How to send Is Typing notification from bot application until bot process another response. I can see currently it is limited to 3 seconds, but I want to extend it until the next response come back from Bot.
Can anyone help me with this? I have seen a couple of approaches where they recommend showing recursively until your task finish its execution but not sure how to Implement this.
Currently, this is not a feature of bot framework. You cannot control the length of time of which the typing indicator is displayed for. Your best bet is to try to resend the typing indicator as many times as needed until you long-running task is completed. This will be a custom solution that there may already be examples of out there.
You can send the typing activity every couple seconds while your processing runs asynchronously. This uses a bit of extra bandwidth, so your call. e.g.
var search = searchclient.Documents.SearchAsync(query);
var typing = turnContext.Activity.CreateReply();
typing.Type = ActivityTypes.Typing;
do {
turnContext.SendActivityAsync(typing);
} while (!search.Wait(2000));
var results = search.Result.Results;
Or set the wait to 4 seconds, or a random number between 2 and 5 seconds, so it looks like the bot is typing a little, thinking, then typing more...
Virtually all chats employ forms of faking the "real time" presence of the typing indicator. You are best to not even try, instead letting it vary randomly at the client side, and heuristically altering to your own logic, and have any end event cancel it. Especially if your API footprint is part of your operating cost.
On Chrome something is seriously wrong with the performance of element.addEventListener("touchstart") in my system, in some cases reaching 100ms for a single call.
r00122 listen touchstart: 60.000ms
r00123 listen touchstart: 61.000ms
r00124 listen touchstart: 61.000ms
The above is the console.time output of a pure addEventListener call.
Identical calls for other events take 0ms.
The interesting thing is that every call or two the time taken goes up by another ms.
There is no difference when I turn on or off "Emulate touch events".
However, a simple test case on Chrome runs at 0.01ms/call, so there must be some other dependency. I can't think what it is, other than that fact that I have a large number of elements on the page and am setting up many event listeners (1000). But still, in my page on Mozilla and Safari the call is instantaneous. What on earth could be accounting for this?
I'm experiencing the same behaviour inserting listeners to over 1,000 elements, and indeed only in Chrome on desktop. I consider this to be a bug in Chrome, and created the following two-step workaround.
Check if the client supports the touch event; if not, then don't register it. The code I use to check for touch support is based on this answer:
var bTouchEnabled = 'ontouchstart' in window ||
('onmsgesturechange' in window &&
'msMaxTouchPoints' in window.navigator &&
window.navigator.msMaxTouchPoints);
Don't register all elements at once, but buffer the registering: register 50, call a setTimeout() with a delay of, say, 20 ms, which registers the next 50, repeat.
Combining these two techniques helped me to greatly improve performance of the script and avoiding user agent freezing. It's still a workaround, but checking for the existence of the touch events seems semantically correct.
What happens, if I send multiple ShellToast notifications from background agent at once, for example in ToDo list app I want to notify that 3 tasks should be finished today?
Is it allowed or recommended? Would the user see all three toasts or only the first one?
The scheduled agent only runs once and it's up to you to manage which toast will be shown. In those scenarios you should be using a counter...possibly.
The way I've worked around this sort of thing in the past is just track a time or which toasts have been shown in sort of a queue and just show one every update so you could just rotate through your queue throughout the day until the tasks in app are no longer valid. Or, based on the phone's time, determine what to show (they fire every 30 min or so).
Ultimately, the optimal way is probably having one toast that says "You have 3 tasks to complete" etc etc.
Hope one of those solutions might help!
// Jed
I'm interested in finding out why this is used on some Web sites for processing user-initiated search submissions, how it affects the request and response flow, and programmatically why it would be necessary (or beneficial). In an MVC framework it seems difficult to execute since you are injecting another page into the middle of the flow.
EDIT:
Not advertising related. For instance, most travel sites used to do this, and there were no ads... some banking sites do it too, where there is just a loader that says something like "Please wait while we process your transaction...".
It is often used in long running requests to prevent the web server from timing out the request. With an interstitial page, you are able to continuously refresh the page until you get results back.
EDIT:
Also, for long running requests, it is beneficial to have a "Loading.." page in order to show the user that something is happening. Without the interstitial page, the request can appear to have hung up if it takes too long.
To supplement what HVS said, interstitials which appear before, say a homepage loads, are very much there for the purpose of advertising, we've all seen the 'close this ad' link.
One instance where they can be helpful from a user experience point of view is when a user initiates an action which requires feedback from a process which may take some time to respond - either because it's slow, busy or just has a lot of processing to do.
Think of a site where you book a flight online for example. You often get an interstitial on hitting 'find flights' because the the system is having to go off and ask for all relevant flight information and then sort them for you before displaying them on your screen. If this round-trip of 'request, interrogate, return, display' is likely to take an amount of time beyond that which a normal webpage transitions from one to the next, a UXDesigner may consider an interstitial screen (or message) to let the user know something is happening whilst at the same time allowing the system the time it needs to complete the request. Any screen with this sort of face-time is going to get the attention of your marketing department from a 'well while we've got them we might as well show them something' point of view.
As a UX Designer myself interstitials like this are not always preferred as I'd love every system to return data immediately but if it can't for whatever reason, I'm very much for keeping the user in the loop as much as possible about what is happening - rather than leaving them to stare at the browser status bar until they either try again or get fed up and leave.
One final point when considering this is also to have a lower and upper time limit on a screen like this. If you need to show an interstitial, show it for long enough so people can read it and understand it but not too long that they get fed up of waiting. As a rough guide, leave it open for at least 3-4 seconds (even if the process averages 4 seconds but has finished after 1 on this occasion). Between 4 and 10 seconds check every second to see if the process has responded (and then take the user to the next page f it has) and after 10 seconds seriously consider telling the user to either try again or telling them you've failed (whilst at the same time getting your tech team to fix what is ultimately a problem which will affect your bottom line).
I believe the vast majority of interstitial pages are there to run advertising.