Our app allows users to submit data to our servers.
Sometimes, users will need to make 3 submission in a row. After checking that the submission works properly (and thankfully it does), we call CustomForm().show() and the Form shows correctly. (CustomForm obviously extends Form.)
We use InteractionDialogs, just as in all other iterations, to handle validation by providing feedback to the user. We do so to mimic the Android Snackbar that provides a prompt and a Button to do an action. In the 1st 2 iterations, the InteractionDialogs show and dispose properly; in the 3rd iteration, the InteractionDialogs start acting erratically.
We also noticed that once that CustomForm (or any other submission forms) is shown 3 times (either the same Form 3 times in a row, or any combo of our submission forms 3 times altogether), a different Form displaying a BrowserComponent will fail – the BrowserComponent will not show anything at all, despite using a strong, unfiltered internet connection and having worked properly prior to the submissions being done. Neither the app nor the Form housing the BrowserComponent crashes -- the BrowserComponent simply does not show anything.
Is there a limit on how many instances of a given Form can be shown, or is there a memory issue?
Please, any ideas on how to solve this?
Thank you.
EDIT: I am adding a screenshot of the EDT thread -- it seems to have invokeAndBlock() called twice and then wait() is called, even though I wrapped my call to show the Form with the BrowserComponent with this try-catch:
try {
CN.invokeWithoutBlocking(() -> {
new FormWithBrowser().show();
)};
} catch (BlockingDisallowedException ex) {
e.getMessage();
}
The other issue is how do I fix InteractionDialogs in my submission form from being affected by invokeAndBlock() and wait() as well? I also don't get any BlockingDisallowedExceptions in my logs. Does that mean that wait() is really the issue?
Thanks again.
Related
I'm using the ToastBar messages with timeout 6 seconds. If I click another button within 6 seconds which will display another toastbar message, second one will overlap with first one in some instances. How can a dispose first message and display second message without overlapping if the button is clicked before timeout occurs. Please advise.
ToastBar.showErrorMessage("Test Message", 6000);
Thanks
Make sure you are always invoking this method from the EDT and not from a separate thread e.g. the network thread. Use the edt error detection tool in the simulator to try and track such issues.
I have the same issue. First I tried to make sure that I do not call each message using the same object reference, but also use local variable instances to allow the Garbage Collector (GC) dispose them since the instance is discarded when the task is done.
However, this may take some time and the message still appears overlapping or even worse, it repeats itself with out a trigger, but less likely (infrequent) now because the GC collects the object.
It may be tempting to call the GC manually if possible, but then you need to assess performance impact.
I have not attempted yet the approach I am about to suggest, but let me know what you think.
Making it so, that ToastBar messages appear one on top of the other when triggered. Maybe a List<ToastBar> object or other similar may prove useful. This may be described as a ToastBar "buffer".
The other way around is to clear() the message but then if it is too long it will not allow the user the necessary time to read the feedback.
I have this in my TODO list but will follow up when I make some additional progress.
I use react.js + es6 + webpack to develop my application.
recently, I find if I click a button multiple times in short time, the click handler will trigger multiple times.
I think it's a common case, code snippet like this:
#debounce()
onMidCardClick(url) {
console.count('onMidCardClick trigger times : ');
window.location.href = url;
}
before navigate to the url address, onMidCardClick event handler will triggers multiple times.
So, my way is create a debounce.decorator.js to handle this situation.
I think my way's advantage is easy to read and keep maintainability.
My question is:
1. Is it necessary to handle this? I mean, maybe react synthetic event will handle this for me?
2. My application has many events, I add debounce decorator for many of them. I test it, it works fine, but I am not sure I am correct. Because I saw many applications not deal with this.
No, all you need to do is, the moment user clicks a button, disable the button till you get the response. You can also disable other buttons too if required. Ex.
<button type="button" disabled={!this.clicked}>Button</button>
From a usability point of view, if the user clicks on a button/li/div element and you are executing some logic, it is better to give a visual indicator that some processing is happening, with a loader or a progress bar.
You can write a react component for a full page loader like this and show it to the user, which effectively prevents the user from clicking the element again while giving a visual clue as well.
I am facing an issue, while trying to start a phone call from my iOS app using:
UIApplication open(_:options: completionHandler:)
iOS shows an confirmation popup/alert before starting the call with two button Call & Cancel and CompletionHandler called with a Bool parameter having true/false based on button action in iOS 10.
But now in iOS11 the problem is that the completionHandler is being called automatically before tapping on "Cancel" or "Call" button of confirmation popup, always having true value.
Is this a bug in iOS11 or is there something that I am doing wrong?
There has been a behavior change in when the closure is called in iOS 11. I cant say if this behavior will be reverted or if this is a bug.
But one of the ways you can identify when the user interacted with the popup is by adding a notification listener around UIApplicationDidBecomeActive in the completion closure of openURL(). To identify whether the call was clicked or not you will need to create another custom notification and listener on the CTCallCenter. That was the best way through which I was able to identify it, there might be better solutions though :D
completionHandler will get a call if your given URL gets open success or failure, this has nothing to do with Cancel & Call buttons on Alert
see what Apple docs has to say about it HERE
completionHandler
The block to execute with the results. Provide a
value for this parameter if you want to be informed of the success or
failure of opening the URL. This block is executed asynchronously on
your app's main thread. The block has no return value and takes the
following parameter:
success
A Boolean indicating whether the URL was
opened successfully.
We have an edit form that only allows one user to edit a form at a time. The form is quite large and has quite a bit of Knockout.js code in it and this code intercepts the Submit button click to do validation, then if everything is fine it submits the form.
Nothing has changed on the server side or view side, yet just in the last few days we are having a large amount of OptimisticConcurrency errors being logged.
Store update, insert, or delete statement affected an unexpected number of rows (0). Entities may have been modified or deleted since entities were loaded. See http://go.microsoft.com/fwlink/?LinkId=472540 for information on understanding and handling optimistic concurrency exceptions.
The only other correlation is that some users are complaining about the site running slow. I was hoping someone may have a guess as to what is causing this? It is probably affecting less than 1% of our forms but this still causes a lot of inconvenience. It is a MVC 5 site on a load balanced server.
Aside from what may be causing this, is there some other idea of what I should do to solve the problem, like switching to a client wins concurrency exception? These are medical records so any data loss could be detrimental.
Update
From the comments, here is the code that runs when the submit button is pressed.
self.saveClick = function () {
validationTests();
if (self.validationError()) {
return false;
} else {
return true;
}
}
So that wouldn't disable the button from being pressed multiple times, would it? This may be the problem, now that the site is running slow.
As you're getting multiple submits from the same user it's probably worth ensuring that your submit button is disabled on a click.
Here's a question with an example of how to do this
Disable submit button on form submit
worth noting that as you're doing lots of validation then you need to re-enable the button if it fails validation.
I'm looking for a good way to implement a truly modal dialog in Silverlight 5. Every example that I find that claims to create a modal dialog really isn't modal in that the calling code waits until the dialog is closed.
I realize this is a challenge because we can't actually block the UI thread because it must be running in order for the dialog (ChildWindow) to function correctly. But, with the addition of the TPL in SL5 and the higher level of adoption Silverlight has seen over the past few years, I'm hoping someone has found a way around this.
A good representative scenario I am trying to solve is an action (say clicking a button or menu item) that displays a login dialog and must wait for the login to complete before proceeding.
Our specific business case (whether logical or not) is that the application does not require user authentication; however, certain functions require "Manager" access. When the function is accessed (via button click or menu item selected, etc), and the current user is not a manager, we display the login dialog. When the dialog closes, we check the user's authorization again. If they are not authorized, we display a nice message and reject the action. If they are authorized, we continue to perform the action which typically involves changing the current view to something new where the user can do whatever it is they requested.
For the sake of closure...
What I ended up with is a new TPL-enabled DialogService with methods like:
public Task<Boolean?> ShowDialog<T>()
where T : IModalWindow
The method creates an instance of the dialog (ChildWindow), attaches a handler to the Closed event and calls the Show method. Internally, it uses a TaskCompletionSource<Boolean?> to return a Task to the caller. In the Closed event handler, the DialogResult is passed to the TrySetResult() method of the TaskCompletionSource.
This lets me display the dialog in a typical async way:
DialogService.ShowDialog<LoginDialog>().ContinueWith(task =>
{
var result = task.Result;
if ((result == true) && UserHasPermission())
{
// Continue with operation
}
else
{
// Display unauthorized message
}
}, TaskScheduler.FromCurrentSynchronizationContext());
Or, I could block using the Task.Wait() method - although this is problematic because, as I mentioned in the original post, it blocks the UI thread, so even the dialog is frozen.
Still not a true modal dialog, but a little bit closer to the behavior I am looking for. Any improvements or suggestions are still appreciated.