I'm using library and handle event from library (for example onUpgrade). The problem is that this event can be called very often, therefore I need handle my onUpgrade event with debounce 3 seconds.
Please help me how can this be done? I used already Rx java debounce, but with edit text, and I don't understand how it can be applied to an event onUpgrade from the library.
onUpgrage: (Data) -> Unit
Related
We were looking into rerunning handpicked events from axon. A use case would be along the lines of the following.
If the user's registration event failed even though the command was successful, we want to rerun that particular event for that specific event handler(s).
We looked into using the tracking event processor, but that seems to be of replaying a set of events FROM a specific point in time. However, in our case, if there were 100 events yesterday, we would only want to rerun a particular event in the middle.
At the moment we are in migration of migrating to Axon and as such have decided to go with SubscriptionEventProcessors predominantly as it is more synchronous (i.e. errors are propagated up the command handler). And we do understand that subscription processors are stateless, as in they only process what they received via the event bus.
So I am assuming that we cannot use the tracking processor? and instead, we need to load the particular event and re-push it to the event bus?
How could we achieve this? (With or without the above suggestion)
Also with regards to identifying exceptions, we are thinking of using aspects and logging and reading the particular log line for exceptions. However we did notice a tracing module for axon and spring boot. https://github.com/AxonFramework/extension-tracing However it is mentioned to be in beta and there was not much reference documents we could find yet either. Is there a better more axon based solution to this as well?
To be quick about it, I would use a similar response as I have posted on this question.
The rehash my response over there quickly, it can be summarized by:
Create a Query Model containing the required #EventHandler annotated methods to "re-handle", which you'd provide as input to Axon's AnnotationEventHandlerAdapter constructor. You would call the subsequent AnnotationEventHandlerAdapter with a filtered event stream based on the requirements you have. As a result, the Query Model will be updated to the format you need.
Thus instead of performing it as a form of query because the users requires that information, you would perform the operation upon an exceptional case. Regardless, you will still form the Query Model anew, but just based on a specific set of events.
By the way, when it comes to the choice of Event Processor, I'd still go for the TrackingEventProcessor. Yes it means an event failure would not issue a rollback, but in essence the event states it has occurred. Thus rolling back because something else fails handling that event is incorrect; the command still succeeded, so it should stay as such too.
Lastly, you are looking for logging logic. The Tracing Extension you've shared has just recently been pulled from it's beta status and thus can be used safely. Next, basic logging can already be achieved by configuring the LoggingInterceptor as a MessageHandlerInterceptor and MessageDispatchInterceptor (documentation on this can be found here). And if you are looking to introduce Aspect logic: Axon has a similar mechanism to tie into each message handler out there. Have a look at the HandlerEnhancer/HandlerEnhancerDefintion on this page.
Hope all this helps you out #MilindaD!
This problem is for Xamarin Android C# , but if someone can help in java I'm sure I can convert the code over ..
I'm trying to get some sort of automatic notification on a db that data has been inserted / deleted / etc.
There is outside apps that have access to the db in question, that insert / etc..
I've tried a file observer but it misses most of the inserts.
I've tried using content observer but it never fires a onchange
I've tried using the content observer inside a cursor but no onchange happens either.
(if I understand correctly they will only fire if I register a change occurred which is what I don't want)
Now I've discovered that loaders might be a solution..
They seem to have their own observer that fires when the data changes.
If this is also not an answer then perhaps a database trigger of some kind to notify my app the data was modified ?
I really need guidance here.. no idea how to properly implement a loader..
or if the content observer can be sufficient somehow with some sort of auto trigger as such..
OK, So!
The reason that file Observer was missing db inserts is because a SQLite DB is actually a 2 - 3 file object .. if you watch "Example.DB" then you can miss insert that can happen on Example.DB-shm or Example.DB-wal..
The fix to this, and its not a great fix, is to instead watch the folder ..
doing this will catch all inserts/deletes ..
The problem with this is that it will cause multiple OnChange() 's to execute..
So when coding a file observer like this, you have to either call the stopwatch() while you process the call and switch it on afterwards
OR
Have a "Global Variable" (C# guys are gonna swear at me for calling it that)
or static var
that lets the app know that you are already busy on the event so don't execute the code till the previous call has been completed ..
I am coming from Java but have been doing some Node.js lately, and have been looking at the EventEmitter module in Node.
What I don't understand is the fundamental difference between Event-driven programming and 'regular' programming.
Here is some psuedo-code to demonstrate my idea of "event-driven" programming.
EventEmitter ee = new EventEmitter();
Function f = new SpecialFunction();
ee.on('grovel',f);
ee.emit('grovel'); //calls function 'f'
the only work the EventEmitter object seems to be doing is creating a hash relationship between the String representation of an event (in this case 'grovel') and a function to respond with. Seems like that's it, not much magic there.
however, my question is - how does event-driven programming really work behind the scenes with low-level events like mouse-clicks and typing? In other words, how do we take a click and turn it into a string (like 'grovel') in our program?
Okay. I will take a run at this.
There are a couple of major reasons to use event emitters.
One of the main reasons is that the browser, which is where JavaScript was born, sometimes forces you to. Whether you are wiring your events straight into your HTML, using jQuery or some other framework/library, or whatever, the underlying code is still basically the same (erm, basically...)
So first, if you want to react to a keyboard or mouse event, like you mentioned, you could just hard bind directly to an event handler (callback) like this:
<div onclick="myFunc(this)">Click me</div>
...or you could do the exact same thing in JS by DOM reference:
document.getElementById('my_element').onclick = function (evt) {
alert('You clicked me');
};
This used to be the primary way we wired up click handlers. One lethal drawback to this pattern is that you can only attach one callback to each DOM event. If you wanted to have a second callback that reacted to the same event, you would either need to combine write it into the existing click handler or build a delegate function to handle the job of calling the two functions. Plus, your event emitter ends up being tightly coupled to the event listener, and that is generally a bad thing.
As applications became more complex, it makes more sense to use event listeners, instead. Browser vendors (eventually) settled on a single way to do this:
// Build the handler
var myHandler = function (evt) {
alert('You clicked me too');
window.myHandlerRef = this; // Watch out! See below.
};
// Bind the handler to the DOM event
document.getElementById('my_element').addEventListener('click', myHandler);
The advantage to this pattern is that you can attach multiple handlers to a single DOM event, or call one single event handler from several different DOM events. The disadvantage is that you have to be careful not to leak: depending on how you write them, event-handling closures (like myHandler above) can continue to exist after the DOM element to which they were attached have been destroyed and GCed. This means it is good practice to always do a removeEventListener('click', myHandler). (Some libraries have an off() method that does the same thing).
This pattern works well for keyboard events as well:
var giveUserAHeadache = function (evt) {
alert('Annoying, isn\'t it?');
};
document.addEventListener('keypress', giveUserAHeadache);
Okay. So that is how you usually handle native browser events. But developers also like to use this pattern of event delegation in their own code. The reason you would want to do this is so you can decouple your code as much as possible.
For example, in a UI, you could have an event emitted every time the user's browser goes offline (you might watch navigator.onLine for example). Maybe you could have a green/red lamp on your page header to show the online state, and maybe you could disable all submit buttons when offline, and maybe also show a warning message in the page footer. With event listeners/emitters, you could write all of these as completely decoupled modules and they still can work in lock-step. And if you need to refactor your UI, you can remove one component (the lamp, for example), replace it with something else without worrying about screwing up the logic in some other module.
As another example, in a Node app you might want your database code to emit an error condition to a particular controller and also log the error -- and maybe send out an email. You can see how these sorts of things might get added iteratively. With event listeners, this sort of thing is easy to do.
You can either write your own, or you can use whatever pattern is available in your particular environment. jQuery, Angular, Ember and Node all have their particular methods, but you are free to also build your own -- which is what I would encourage you to try.
These are all variations of the same basic idea and there is a LOT of blur over the exact definition or most correct implementation (in fact, some might question if these are different at all). But here are the main culprits:
Observer
Pub-Sub
Mediator
I have a big Java application.
each in-charge of a specific task.
what I'd like to do is to be able to dispatch events with parameters from one class and to be able to catch them in other classes and to execute functions according to them.
for example.
In one of the classes I have a function called userPuchaseGift4Himself so I want to add an event called USER_PURCHASE_GIFT_FOR_HIMSELF that will have 2 parameters, userid and amount. and I want any part of the code to be able to add an event listener to this event and when it connects to this event to execute a code with the relevant parameters the ever dispatched with the event.
can anyone please provide an example on how to do so ? that would be really great.
any information regarding the issue would be greatly appreciated.
thank you so much!
Check the EvenBus in Google Guava.
EventBus allows publish-subscribe-style communication between components without requiring the components to explicitly register with one another (and thus be aware of each other).
how can I add a listener to the computer's processor? I want the mouse cursor to change when the processing is hight.
You are going to have to drop to native code to get the CPU info. Here is an article on doing that.
You would have to write a class that then makes use of that native call and provides the API you want for the listener.
Edit:
Hmmm... you might also check out http://support.hyperic.com/display/SIGAR/Home.