In some of my my viewmodels and some background running services, I need a second tick for all sorts of actions such as Statemachine progression etc..
To avoid having to create a Timer for every occasion, I have one TimerService which publishes a Messenger plugin message every second.
Those viewmodels or Services that need it just subscribe to this message.
This has worked well for over a year. Recently I noticed a rather long startup time of my app. After some debugging I found that after the launch of the first Viewmodel (it is correctly displayed), it takes about 25secs before the subscriptions start picking up on this message. Seems like something is holding back the publishing of these messages.
During those 20+ secs there is no activity by MvvmCross at all. Nothing is logged by Mvvmcross at all.
What could cause such behaviour ? When in the startup sequence does the messenger plugin start distributing its messages ?
I apologise for not posting code here, as it is a phenomenon that is just happening across the whole application. None of the singleton services that run in the background pick up these messages until after 20secs everything starts working properly.
EDIT: MvvmCross V3.5 is used along with latests stable updates of Xamarin. Problem occurs on every Android version tested.
After some experimenting (and reading all the MvxMessenger docs again) I tried using the SubscribeOnThreadPoolThread method instead of simple subscribe for one of the published messages that typically triggers updating the properties of a viewmodel on a regular basis in its handlers. This made the problem go away.
Normally the handling if this viewrefresh message is fast and doesn't require more then copying repository values (that are updated by a background service) to the visible viewmodel properties. I guess there's somewhere a synchronous call in one of the refresh handlers that make the messenger system block.Haven't found it yet.
What are typical situations that can make the Messenger plugin block ? I would be very interested to understand that a little better.
Related
I have no previous experience with programming Google Chrome plugins which is why I am starting here to see if what I want to accomplish is possible/reasonable. I do however have a pretty broad experience in programming in general.
What I want:
I want some kind of "trigger" to go off when a new Chrome Notification (you know these little pop ups above the system tray) is popping up. I want to execute some script/code depending on what information the notification contains so that I for example could have an alarm go off if I receive an email from a certain user with a certain key word in the subject and get a pop up from my Gmail Notifier extension.
This is however just an example and I have a bunch of ideas for different notifications from different extensions and websites so don't get caught up on that particular example.
When I look at the Chrome Notification API I see that there is a getAll method that supposedly is getting all the "notifications in the system" but I do not find any Event for new notifications.
I suppose a possibility would be to poll with getAll a couple of times per second (it needs to be really fast for some implementations I have in mind) but it feels very tacky.
Is there any way to easily access new Notifications programmatically in Chrome?
(I'm open to all solutions, programming languages and such...)
Well, I searched long and hard and got involved with the Chromium dev group and asked around there. As far as I could figure out there was no reasonable way of accessing all Notifications programatically.
So what I ended up doing was just download the source-code of Chromium and build my own custom version of chromium adding a very crude API. Worked like a charm and not as complicated as one might think.
Cheers!
I'm building an app which is made of a webserver (currently using NodeJS but doesn't really matter here) and a Chrome extension.
The point of the Chrome extension is to display some data from the server. For this, I need the extension to be aware of changes on the server-side. To do that, I see 3 possible strategies :
1. Websocket
Having a websocket in the background that triggers updates in real time.
2. Regular fetch
But I also can have a timer that will fetch new data on a defined frequency (something like every minute)
3. Event triggered fetch
Another solution would be to detect browser activity, and to trigger a server call during that activity (eg. on active tab changed)
The tradeof I see is browser memory/network usage vs. realtimeness.
To define realtimeness necessity, I'd compare it to an unread email indicator: it doesn't matter if the user is made aware a minute after, but conceptually, it means always displaying out-dated data, which doesn't sound great to me.
On the other hand, if using websockets, or event listeners come at a too high cost and will eventually slow down the browser too much, I'd rather have a minute delay. :)
But maybe fetching the server every minute with most of the time no update to send may be even more expensive than keeping a websocket alive...
Well, any insights on this tradeof and how to choose would be highly appreciated!
Special thanks to #Rob-w for helping me to reformulate the question.
I have a personal WinRT app I'm working on, and when the app is suspended, I would like to have it relaunch itself with different launch parameters.
I know you can kind of already do this with toast notifications, but I would like to know if it's possible to do without any user interactions.
Thanks!
Wow. I never thought of this before. Your only hope would have been to re-launch your application during the suspending event using protocol activation. But what happens is it is not re-launched, it is reactivated while in the suspending state and the activation is denied. You can't delay the re-activation either because all thread schedules are suspended once the app is terminated, too. I tried this in a test app just now and I'm right.
There's also no option with somehow triggering a background task. Though the ApplicationTrigger is coming with Windows 10, the rule still remains that a background task cannot invoke any UI. So, you can't use a background task.
Then I thought about file activation. Then I realized that file activation is identical to protocol activation and the result would be the same, too.
Yes, the idea of using a timed toast or scheduled reminder would sort of work. It would certainly require the user to tap the toast, and if toast were disabled, or the user didn't tap them (they are transient), you are left not running and nothing going to start you.
There is one more thing you can do. Since there isn't a WinRT solution here, remember there's almost always a Win32 solution. There is nothing wrong with a Win32 in-memory app listening for your app to be terminated and starting it again (like by using protocol activation). Your problem is solved unless you are running this on an ARM device - hopefully not.
I talk about protocol activation here:
http://blog.jerrynixon.com/2012/10/walkthrough-using-windows-8-custom.html
Best of luck!
I'm developing a WP8.1 SL app which uses background tasks (not agents!).
My task is triggered by a TimerTrigger - once every 30 minutes (which I believe is the minimum interval for Windows Phone, right?). It is doing a lot of work, and for some reason, sometimes it gets interrupted - that is, it stops in the middle of it. The way I know it's in the middle of it is because I log what's happening and the task's work is basically the same every time.
I deployed the app to my device yesterday to test a new approach, and everything was working fine - the background task was doing everything every time it was started - worked like a charm. Today my device needed a soft reset, so I did it (nothing was working, it happens from time to time since I updated to WP8.1). Since that moment, the background task gets interrupted every time, right in the middle of it, just as with the previous approach.
Any ideas what can cause this? I'm thinking it may be connected to the soft reset, because - 100% success rate before it, 0% after that.
What I've tried so far:
I'm logging errors, I have a try-catch around everything, I've subscribed to the UnobservedException event and to the task's Canceled event, and I'm logging the suspension count - none of these things help. There seem to be no errors, it's not suspended, and it's not canceled.
I'm logging the current memory usage from time to time, and it's about 16-17MB. On my device, the limit should be 30MB, so I don't think that's a problem.
I'm calling RequestAccessAsync wherever I can. I thought once should be enough, but since that soft-reset issue, i decided to put it in 1-2 other places to check if it's causing the issue. Well, it's not, or at least this didn't fix it.
What I'm not sure about:
I have no idea how to check the CPU time my task has consumed. I can't find a good/reliable way to do so. Also, I can't find any info that would explain why the task would be stopped in the middle sometimes, and other times - it would work fine.
Any ideas why my background task is sometimes stopped at the middle? I'm really having a hard time determining how to fix/improve the app and will it work at all.
Thanks.
So, I think I found what my problem was.
First of all, the background task just needed a lot of CPU time, more than the limit, and that's why it was getting killed in the middle.
The reason why it was working sometimes, was because sometimes the device on which I was testing treated the app as being in debug (or with attached debugger). In this case the restriction on CPU time is removed.
So, even if I uninstall the app and rebuild it in Release and redeploy, and start it without the debugger attached, the device was NOT enforcing the constraints. That only happens, if I have started the app with the debugger at least once (or maybe the first time) after it's deployed. Restarting the device (just power off and then turn on) fixes this.
While I was testing, using the same build of an app, its background task ran for 40 MINUTES on one device, and just 3-4 seconds on another. After I restarted the first device, the background task started behaving normally (running for just a few seconds).
So, if you want to test your background task for the CPU constraint:
You must be testing on a device, not on the Emulator.
Uninstall the app, if it's installed.
Restart the device.
Deploy a Release build of the app.
Run the app, so that it can register the background task, and then close it.
Wait for the background task to be invoked. (You could add a trigger that can be forced, like TimeZoneChanged or UserPresent, so that you could quickly test it.)
P.S. This may not be the perfect answer, but these are my observations, and they helped me solve my problem. This by far is the best method I have found for testing the CPU time, and it's far from perfect. So, if anyone has better ideas, please share them.
I have a RAP application which we deploy into a Tomcat instance. The application does some additional stuff during it's first startup.
Currently when the first user opens the webpage in a Browser, it takes quite a while until the application is ready because of this one-time initialization work.
This is bad for usability as the first user needs to wait a long time until this startup-work is done.
Is there a way to trigger or simulate a first session after the Tomcat is started so we can warmup the application and the first user receives feedback quickly?
I tried to do some simple URL-requests via URLConnection to simulate a browser, but it seems the protocol to trigger a new session is non-trivial.
I also tried to use HtmlUnit to request the page with JavaScript enabled, this works to some degree, but HtmlUnit is quite heavy for this simple step.
So is there an official API or at least some sort of workaround that allows me to pre-start and initialize the application?
Unless this initialization requires a UI session (i.e. a user), the configure method of your ApplicationConfiguration could be a suitable place. However, at this point, the ApplicationContext has not been completely set up, so it could be too early. Also, if your application is based on the workbench and extension points, you won't have an ApplicationConfiguration of your own.
Would you mind opening a bug report (http://eclipse.org/rap/bugs) and describe your use case? I think we should provide some kind of hook for applications to setup and clean up, e.g. an ApplicationContextListener?