I've read the following post about how to push data from BlazeDS without recieve message from Flex client?. I did not posted on that thread because is old.
I've implemented such mechanism and it seems to work well. The only thing that I did not managed to do is to stop the thread, if the client is closed. My hunch is that the client is closed, but the consumer is not unsubscribed, unless the method unsubscribe() is not called and I would say, that this is a normal behavior. The problem is that if I want to call the unsubscribe method when the client (in my case a browser) is closed, I did not find such handlers (e.g onExiting, dispose...) in flex web, only for air applications. I'm developing my application using Flex 3.6 and BlazeDS 3.2.0. Thanks.
There is no default handle for that in flex.
However, what you could try is the following:
Hook into the javaScript onBeforeUnload method => JavaScript + onbeforeunload
In this javascript method, call a Flex function via the ExternalInterface API
In your Flex app unsubscribe
Cheers
Related
So I'm integrating SignalR and HotTowel, although really I think this is a matter of how to integrate with Durandal itself.
The issue is I have obviously multiple views. Some of these views I want to respond to SignalR messages. The question is how to do this integration considering that SignalR events have to be started before I call SignalR's hub start method.
So take the example I have view1 and view2. I want each to do something when a SignalR message is received and in the context of that view (so let's say update the DOM somehow). It's an SPA obviously so calling the SignalR start method for each view seems like a bad idea, so starting SignalR once at boot sounds like the right plan, but at that point my views may not have been loaded, and still how would I ensure that my events have the right context for the page.
This is based on my understanding that all events for SignalR have to be registered before I call start. Any thoughts clever people of StackOverflow?
Edit to expand on the problem
Part of the website involves uploading files for parsing and processing to import into a database. I have created a view where the file is selected and uploaded (using FineUploader) to a WebApiController. The controller does the basic steps of checking the uploaded file and then starts an async task to actually do the parsing and processing, while immediately returning the basic "Yep that uploaded fine" message.
This causes the list of 'in progress' files to refresh and the file appears with an 'Uploaded' status. As the async task occurs, the file is parsed, then processed against a rules system, and then finally imported into another back end data store. As each of these status changes occur, SignalR sends messages to the client to notify them of these changes, and thus update the status against the filename. In order for this to occur I must attach a function to the event as it received in SignalR. That even needs some kind of reference to my view (actually viewmodel) so it can update the correct value.
As SignalR should be started once with a call to hub.Start(), I am trying to do it during the 'boot' phase. However when my SPA starts, that view has not been loaded, and therefore neither has that viewmodel, and therefore my function that is responsible for initialising SignalR can have no understanding of the view/viewmodel it must update.
Examples I've seen on using SignalR show it being used in one view, but that doesn't really work surely if you need it in multiple views (you can't just keep calling hub.start() can you)?
Sorry, if this still doesn't make sense I'll post some code or something.
If you use
$.connection.myHub.on("myMethod", function (/* ... */) { /* ... */ });
instead of
$.connection.myHub.client.myMethod = function (/* ... */) { /* ... */ };
you can add client-side hub methods after calling $.connection.hub.start();
I'm building a newsreader app for wp7. I'd like to have some background activity occur, like writing downloaded content to isolated storage. Is there any way to do this without blocking the UI thread?
The DownloadStringCompleted event of WebClient is asynchronous, right? Could I just do it there?
It is asynchronous, but it's recommended not to do any non trivial processing using WebClient since that work will be done on the UI thread as Indy rightly points out.
Webclient does this to offer you the convenience of not having to invoke the Dispatcher.
Dispatcher.BeginInvoke( () => { /* ui update code */ } );
This comes at the cost of ALL of your processing in the callback being executed on the UI thread.
HttpWebRequest (used by WebClient itself) will allow you to keep most your processing off the UI thread and just do your UI updates on the UI thread by way of the Dispatcher (refer above).
Note that you can still block the UI thread if you do this with too much intensity. Spacing your UI updates with Thread.Sleep(xxx) will help to keep the UI reponsive in such cases.
For a deeper understanding of the differences between HttpWebRequest and WebClient and a working project sample to demonstrate, refer my post here.
WebClient, HttpWebRequest and the UI Thread on Windows Phone 7
Yes, it does. Here is how you can expose asynchronous features to any type on WP7.
You can certainly update the UI using the Dispatcher.BeginInvoke method, to avoid cross-thread exceptions. It is however advisable to use HttpWebRequest instead of WebClient since WebClient returns on the UI thread. Here is a recent MSDN Blog post that could help you understand the model and perhaps aid in developing your app.
All network access in WP7 is asynchronous, most of the network api classes don't even expose synchronous methods, you have to fight the framework pretty hard to try in fact.
As noted in the other answers what you have to be aware of is that you need to update the UI through the UI thread, you can use Dispatcher.BeginInvoke if you're working with the code-behind. If you're using some sort of MVVM style pattern then INotifyPropertyChanged events are automatically dispatched back to the UI thread so you don't need to worry about it (INotifyCollectionChanged from ObservableCollection isn't for reasons unknown).
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.
We have an application that hits a web service successfully, and the data returned updates our DB. What I'm trying to do is allow the user to continue using other parts of our web app while the web service processes their request and returns the necessary data.
Is this asynchronous processing? I've seen some console app samples on the msdn site, but considering this is a web form using a browser I'm not sure those samples apply. What if the user closes the browser window mid request? Currently we're using the Message Queue which "waits" for the web service to respond then handles the DB update, but we'd really like to get rid of that.
I'm (obviously) new to async requests and could use some help figuring this out. Does anyone have some code samples or pertinent articles I could check out?
Yes, what you're describing is async processing.
The best solution depends to some degree on the nature of the web services call and how you want to handle the results. A few tips that might help:
One approach is to send a request from the initial web request to a background thread. This works best if your users don't need to see the results of the call as soon as it completes.
Another approach is to have your server-side code make an async web services call. This is the way to go if your users do need to see the results. The advantage of an async call on the server side is that it doesn't tie up an ASP.NET worker thread waiting for results (which can seriously impair scalability)
Your server-side code can be structured either as a web page (*.aspx) or a WCF service, depending on what you want to have it return. Both forms support async.
From the client, you can use an async XMLHTTP request (Ajax). That way, you will receive a notification event when the call completes.
Another approach for long-running tasks is to write them to a persistent queue using Service Broker. This works best for things that you'd like users to be able to start and then walk away from and see the results later, with an assurance that the task will be completed.
In case it helps, I cover each of these techniques in detail in my book, along with code examples: Ultra-Fast ASP.NET.
If you're not blocking for a method return you're doing asychronous processing. Have a look at Dino Esposito's article on using AJAX for server task checking.
You can perform asynchronous web service calls using both Web Service Enhancements (WSE) and Windows Communication Foundation (WCF) in your C# code. WSE is discontinued, so its use is not recommended. Generically speaking, if you were to terminate program execution in the middle of an asynchronous call before the response returned, nothing bad would happen; the client would simply not process the result, but the web service would still be able to perform its processing to completion.
If your client web application is responsible for updating the DB, then without anything else in your client code, quitting in the middle of an asynchronous operation would mean that the DB was not updated. However, you could add some code to your client application that prevented the browser from quitting entirely while it is waiting for an asynchronous response while preventing new web service calls from being run after Close is called (using Javascript).
You have 2 distinct communications here: (1) from web browser to web application and (2) from web application to web service.
diagram http://img697.imageshack.us/img697/6713/diagramo.png
There is no point of making (2) asynchronous: you still would have to wait for web service to finish processing request. If you end HTTP request from browser to web application the client would have no clue what the result of request was.
It is much better to make asynchronous request from web browser to your web application. Ajax is ideal for that. In fact, that's what it was created for. Here's couple of links to get you started:
jQuery Ajax
ASP.NET AJAX
I'm looking for a way to get the status of a stream from Flash Media Server to action script. I need to know if a stream has any publishers/listeners from flex/ActionScript.
Take a look at the Adobe Flash Media Server Administration API. There are calls that might help you, such as getNetStreams() and get NetStreamStats(). You could try writing a server-side action script class that makes these calls to the admin API, then pushes the results back to your Flex application through a callback on your NetConnection.