I am starting a new project and am thinking of using Simple Injector interception (https://simpleinjector.readthedocs.io/en/latest/InterceptionExtensions.html) for tracing method entry/exit and logging parameters and return values etc. I have used this interceptor in the past and it works great. But my previous projects were not async/await. This new project has a lot of methods that are all async/await and I was wondering
will this interceptor work for async/await methods?
what changes are required in this interceptor to make it work for async/await methods?
I understand that decorators are a much better pattern than interception but writing a decorator for each and every interface that I want to trace is not something that I am looking forward to doing.
UPDATE:
I have tried this interceptor in my async/await code and it does inject my tracing code. However, I was getting weird results in some parts of my application. I didn't get chance to dig deeper into why disabling interception would make it work fine and why when interception was enabled it would not work as expected. It could very well be something wrong with my code.
I was hoping if someone, who has already used this interception extension in their code, would be able to point me in the right direction.
will this interceptor work for async/await methods?
Async code in C# is syntactic sugar on top of Task. This means that if your code needs to do anything useful after a call to an async method, you will have call ContinueWith on the returned Task (or use the C# syntax). If you take asynchronous into consideration in your interceptor, you won't be able to execute logic after the wrapped object.
So to make this work, you will have to explicitly check whether the wrapped method returns Task and if that's the case, you should make things async by hooking your 'after' code using ContinueWith.
This is one of the many reasons I consider interception to be inferior to using decorators. Decorators allow your code to be much cleaner, refrain from using reflection, give complete compile time support, give better performance, prevent having to depend on an interception library, and force you into a much more SOLID application design.
That said, the documentation's MonitoringInterceptor will look as follows when it takes asynchronicity into consideration:
class MonitoringInterceptor : IInterceptor
{
private readonly ILogger logger;
public MonitoringInterceptor(ILogger logger) {
this.logger = logger;
}
public void Intercept(IInvocation invocation) {
var watch = Stopwatch.StartNew();
// Calls the decorated instance.
invocation.Proceed();
var task = invocation.ReturnValue as Task;
if (task != null) {
invocation.ReturnValue = LogElapsedAsync(task, invocation, watch);
} else {
LogElapsed(invocation, watch);
}
}
private async Task LogElapsedAsync(Task task, IInvocation i, Stopwatch w) {
await task;
LogElapsed(i, w);
}
private void LogElapsed(IInvocation invocation, Stopwatch watch) {
var decoratedType = invocation.InvocationTarget.GetType();
this.logger.Log(string.Format("{0} executed in {1} ms.",
decoratedType.Name, watch.ElapsedMilliseconds));
}
}
Related
For my application I need to fetch some data asynchronously and do some initialization for each page. Unfortunately, a constructor does not allow me to make asynchronous calls. I followed this article and put all of my code into the OnAppearing method. However, since then I ran into multiple issues since each platform handles the event a little bit differently. For example, I have pages where you can take pictures, on iOS the OnAppearing is called again every time after the camera is closed while Android doesn't. It doesn't seem like a reliable method for my needs, which is also described here:
Calls to the OnDisappearing and OnAppearing overrides cannot be treated as guaranteed indications of page navigation. For example, on iOS, the OnDisappearing override is called on the active page when the application terminates.
I am searching for a method/way where I can perform my own initialization. The constructor would be perfect for that but I cannot perform anything asynchronously in there. Please do not provide me with any work arounds, I am searching for a solution that is the "recommended" way or maybe someone with a lot of experience can tell me what they are doing. (I also don't want to .Wait() or .Result as it will lock my app)
You can use Stephen Cleary's excellent NotifyTaskCompletion class.
You can read more how it works and what to do/don't in these cases in Microsoft's excellent Async Programming : Patterns for Asynchronous MVVM Applications: Data Binding. The highlights of this topics are:
Let’s walk through the core method
NotifyTaskCompletion.WatchTaskAsync. This method takes a task
representing the asynchronous operation, and (asynchronously) waits
for it to complete. Note that the await does not use
ConfigureAwait(false); I want to return to the UI context before
raising the PropertyChanged notifications. This method violates a
common coding guideline here: It has an empty general catch clause. In
this case, though, that’s exactly what I want. I don’t want to
propagate exceptions directly back to the main UI loop; I want to
capture any exceptions and set properties so that the error handling
is done via data binding. When the task completes, the type raises
PropertyChanged notifications for all the appropriate properties.
A sample usage of it:
public class MainViewModel
{
public MainViewModel()
{
UrlByteCount = new NotifyTaskCompletion<int>(
MyStaticService.CountBytesInUrlAsync("http://www.example.com"));
}
public NotifyTaskCompletion<int> UrlByteCount { get; private set; }
}
Here, the demo is about binding the returned asynchronous value to some bindable property, but of course you can you is without any return value (for simple data loading).
This may be too simple to say, but you CAN run asynchronous tasks in the constructor. Just wrap it in an anonymous Task.
public MyConstructor() {
Task.Run(async () => {
<Your code>
}
}
Be careful when doing this though as you can get into resource conflict issues if you accidentally open the page twice.
Another thing I like to do is use an _isInit flag, which indicates a first time use, and then never again.
Here's the code that I have:
public App()
{
InitializeComponent();
DB.CreateTables();
DB.GetSettings();
DB.PopulateTables();
SetResourceColors();
SetResourceDimensions();
MainPage = new MainPage();
activity = Helpers.Activity.Create();
VersionTracking.Track();
DeviceDisplay.MainDisplayInfoChanged += OnMainDisplayInfoChanged;
}
protected override void OnStart()
{
}
Can someone explain to me. Is there any difference between me placing the code such as I have in the constructor or in the OnStart() method? What's the normal way to do this?
I have been working with Xamarin.Forms for a long time now and this is how I and my fellow developers use the OnStart Method.
If you check the Microsoft documents it says the following about it :
OnStart - Called when the application starts.
So, first of all, you should know that there is no specific use of the OnStart method, to be very honest there is no major difference in between using the constructor or this lifecycle method because both get called on XF framework startup, first the constructor then the OnStart method.
Now let's come to the differences.
As Jason pointed out, the OnStart method is a lifecycle method and hence has a return type unlike the constructor, so you can even call an asynchronous piece of code in the OnStart method but you cannot do the same in the constructor as constructors cannot be asynchronous.
Which means if you have the below method:
public async Task<bool> IsSomeThingWorkingAsync(//SomeParams)
{
// Code
}
Now, this method cannot be asynchronously called from the constructor since constructors are forcefully synchronous and have no return types. But if you try doing that from the on start method it's quite easy and it will work. In this case, you use the OnStart method. Something like below:
protected override async void OnStart()
{
bool WasWorkSuccess=await IsSomeThingWorkingAsync();
//do something with the boolean
}
A constructor is intended to be used for wiring. In the constructor, you want to avoid doing actual work. You basically prepare the class to be used. Methods are intended to do actual work.
Note: There are no performance gains whatsoever by choosing one over the other - it's really a matter of preference and standard.
Please go through the details here
You can write the initialisation codes in App() constructor. But you need to be very careful abut registering events.
Reason is,
For example in Android, If the app is launched and it is in task list and if you try to launch the app again by clicking on app icon. The constructor of App() will call again. This will register the event multiple times and will create issues.
So for events I will suggest you to use overriden methods for registering events.
Again as Jason pointed it out, It is your personal preference where to write your code.
When using the Room library for Android the documentation clearly states that we cannot make calls on the main thread unless we specifically allow them. What I'm curious about is methods that have a void return type. It seems silly that returning LiveData will automatically run them off the main thread, but void types will not (unless I'm missing something). Is there any easy way I can do this without having to run this in my own managed thread?
My Query:
#Dao
interface UserDao {
#Query("DELETE FROM users")
fun clear()
}
I've even tried using Kotlin reflection + extension functions, but this seemed to fail during runtime:
fun KFunction<Unit>.execOn(executor: Executor, vararg args: Any?) {
executor.execute {
this.call(args)
}
}
Then make a call like:
myDb.userDao()::clear.execOn(diskExecutor)
Note what does work is:
diskExecutor.execute {
myDb.userDao().clear()
}
It seems silly that returning LiveData will automatically run them off the main thread, but void types will not (unless I'm missing something).
Without some sort of annotation, Room would have no idea that you want a void-returning DAO method to be run on a background thread. With a reactive return type (e.g., LiveData, Single), you are explicitly requesting background execution, so no additional metadata (e.g., an annotation) is required.
You might consider filing a feature request for such an annotation-based approach.
Is there any easy way I can do this without having to run this in my own managed thread?
If you are asking "does Room have a background-execution option for DAO methods other than those with reactive return types?", then the answer is no, at least at the present time.
In my ViewModel I load data in (overrided) Start method, like so:
public override async void Start()
{
base.Start();
await ProcessItems();
// or the following (no difference for Start method behavior)
await ProcessItems().ConfigureAwait(false);
}
However, it doesn't look like the await/async logic actually works with the method (I tested it with Android only, though).
"Doesn't work" means that right after calling my awaitable ProcessItems all the rest of ViewModel pipeline is called (like Initialize, ViewCreated, ViewAppearing etc.) before the awaitable method actually finished work.
Which brings up some further issues as the rest of methods expect the data initialization already finished.
So, what should I take into consideration here and how handle this situation.
Thanks!
The calling code can't await Start because it is returning void. Any exceptions being thrown in there are being swallowed. If the method returned Task or Task<T> then this would work as you expect. You pretty much never want to use async void except in an event handler. There is an MSDN article going further into detail as to why async void should be avoided.
This problem is fixed in MvvmCross 5 and later where you would do this same kind of initialization in Task Initialize method in place of this void Start method.
Since MvvmCross 5.0 there is a new lifecycle. https://www.mvvmcross.com/documentation/fundamentals/viewmodel-lifecycle#initialize
Please use Initialize for your stuff instead of Start.
Initialize: All heavy work should be run here. This method returns a Task, which means you can mark it as async and use await safely. If this method fails, the Navigate call that you are probably awaiting will fail, so you might want to catch that exception.
public async Task Initialize()
{
await base.Initialize();
await ProcessItems();
}
Im designing a small library and sometimes i write a couple lines and it just doesn't feel right, so i'd like to get the opinions/advices of an experimented java programmer.
Ive got a listener which handle 3 differents events and in one of my class I implement the methods that will actually fire the events
So what i did at first was something like this:
protected final void fireOperationStarted(){
OperationEvent event = new OperationEvent(this);
for (OperationListener listener : listeners) {
listener.operationStarted(event);
}
}
protected final void fireOperationEnded(){
OperationEvent event = new OperationEvent(this);
for (OperationListener listener : listeners) {
listener.operationEnded(event);
}
//omitted the 3rd method on purpose
but this code felt wrong because if someone want to implement their own event, they will basically need access to the whole listener arraylist (CopyOnWriteArraylist) and write the logic again and again.
So what i opted for is a Fireable interface with a single method "fire". And this is what i've done:
protected final void fireOperationStarted(){
fireOperation(new Fireable(){
#Override
public void fire(OperationListener listener, OperationEvent event) {
listener.operationStarted(event);
}
});
}
protected final void fireOperationEnded(){
fireOperation(new Fireable(){
#Override
public void fire(OperationListener listener, OperationEvent event) {
listener.operationEnded(event);
}
});
}
protected void fireOperation(Fireable fireable){
OperationEvent event = new OperationEvent(this);
for (OperationListener listener : listeners) {
fireable.fire(listener, event);
}
}
I'd like to get your opinions, I personally think its better than the first implementation even there is still a lot of boilerplate code. Maybe there is a better way to do this ? I've looked in the java.awt.events package source code to see how they were dealing with multiple events and how they fire them, but it seem way too complicated for my needs.
One thing that i was wondering also is about the lambda expression in Java 8, if i use them without importing any Java 8 packages and i compile, will it work on the JRE7 ?
Could be great to use the JDK8 to make my codes cleaner eventually.
Thanks for your help !
I think your first example is better. listeners has got to be an instance field, and so readily available to everybody.
(You might have only one method in OperationListener and use a value in OperationEvent to determine which action is involved. Then your methods could all pass the proper event to one method that calls the one listener method.)
Your second idea is interesting, but for use inside one instance of one class, I think it's overkill.
There's all different kinds of ways to store listeners. If you're not adding and removing them too fast, ArrayList is good. If there's any chance of adding and removing them on different threads and you're calling the listeners frequently, CopyOnWriteArrayList is much better.
Don't worry too much about "boilerplate". Java tends to go with wordy-but-simple as regards low level code. The two for loops in your first example call out to be combined somehow, but it's not worth worrying about until you've got a lot more of them.
Lambdas will reduce your lines of code (if you use simple ones; my C# lambdas all end up running 20 lines or more; might as well be anonymous classes!), but they'll add plenty of pages to the language manual. However, lambdas aren't there till JRE 8.