I am sure that with as many dashboard apps out there, people have come across this issue. I have a SL app that needs to loop continuously, calling a RIA service to pull in data updates, with some minimal timer delay (e.g. 3 sec). It is an MVVM solution, and the data being refreshed on the client will likely be wrapped in a PagedCollectionView.
Are there any common (tr: tried and tested) approaches to fetching the data the first time and updating/appending new data in this fashion? It is purely read-only data, there is no editing to worry about.
You should be able to use a timer (that is not set to recur) to pull the data. When the data comes back, restart the timer.
Related
I have noticed that apps like instagram keep some data persistent through app closures. Even if all internet connection is removed (perhaps via airplane mode) and the app is closed, reopening it still shows the last loaded data despite the fact that the app cannot call any loading functions from the database. I am curious as to how this is achieved? I would like to implement a similar process into my app (Xcode and swift 4), but I do not know which method is best. I know that NSUserDefaults can persist app data, but I have seen that this is for small and uncomplicated data, of which mine would not be. I know that I can store some of the data in an internal SQL db, via FMDB, but some of the data I would like to persist is image data, which I am not sure exactly how to save into SQL. I also know of Core Data but after reading through some of the documentation I have become a bit confused as to whether or not it fits my purpose. Which of these (or others?) would be best?
As an additional question, regardless of which persistence method I choose, I feel as though every time the data is actually loaded from the DB (when internet connection is available), which is in the viewDidLoad, I would need to be updating the data in the persistent storage in case the internet connection drops. I am concerned that this doubling of my writing procedures will slow the app down? Is there any validity to this concern? Or is it unavoidable anyway?
Say I have a GridView, the GridView will display the data from database through WCF.
The only way I can think of is using
A timer to keep on query from WCF (simplest).
The best way to do is get notification when data changes in
database, so that would be using query notifications. But now, the
WCF is in the middle betweens the Silverlight Client and Database,
so the query notification will only goes the WCF. Then I will need
to make make the WCF to use duplex communication. (Sounds like overkill...)
Refresh...button.... (this is a joke)
Is there any better way doing it?
I used to work for a company that makes medical software, and we had an application that had to monitor doctors and orders, and be constantly updated. We used a timer, just as you described above. There were some extra components to it - for example, we could change the sampling rate in software, so that during busy times, we could ping the DB more often, during slower times, less often. Caching was implemented as well. There was also a system in place to pull a smaller amount of data first, then pull more only if needed. For example, if a doctor hadn't made his rounds since the last update, then there was no need to check to see if patient data was updated. Stuff like that.
I need to synchronize the data that "one client" updated and need to be refreshed on "other client" (on another room) of the same application.
1 - Which is the best approach to doing this?
I was thinking on SqlDependency but the application can also run on other database engines (I dismiss it)
I also think of a timer polling for updates, but I really don´t want to check for a change periodically.
Does anybody has this problem? How did you solve it?.
2 - Additionally. When the data must be updated in the UI without obstruct the work ofo the people in the other pc?
Scenario:
3 PC working with the same data. Creating / updating records that need to be synchronized (to get the last changes that every PC made).
I hope I was clear about my situation.
Thank in advance.
If you know that you are only gonna have 2 instances of the application, then you could do it with WCF. Each of the clients acts as a server for the other one when they want to send an update.
How you want to handle updates to data being edited by both clients... that can be tricky. It depends on your type of data, if the GUI is developed to handle updates and such things.
I am "slowly" moving into Silverlight from asp.net and have a question about how to deal with situation where some code needs to be executed after web service calls have completed. For example, when user clicks on the row in the data grid a dialog box is shown that allows editing of the record. It contains numerous combo boxes, check boxes etc. So I need to first load data for each of the combo boxes, and than when all finished loading, I need to set the bound entity. Since I am new to this async thing, I was thinking to have some kind of counter that will keep track on how many calls have been dispatched, and as they finish reduce them by one, until it is zero, at which point I could raise an event that load has finished, and I could proceed with what ever is dependent on this. But this seems very clunky way of doing it. I am sure many have faced this issue, so how do you do this. If it helps, we use Prism with MVVM approach and Ria Services with Dtos.
What you've described is pretty much the way to go. There may be more elegant things you can do with locks and mutexes, but your counter will work. It has the bonus that you can see how many operations are still "in progress" at any one time.
You could dispatch your events sequentially but that would defeat the whole purpose of asynchronous operations.
If you analysed what each part of your UI needs you might be able to do some operations before all of your async events have finished. Making sure you start the longest running operations first might help - but there's no guarantee that the other shorter operations will finish first. It all depends on what resources are available on both the client and server at the time the call is made.
howzit!
I'm a web developer that has been recently requested to develop a Windows forms application, so please bear with me (or dont laugh!) if my question is a bit elementary.
After many sessions with my client, we eventually decided on an interface that contains a tabcontrol with 5 tabs. Each tab has a datagridview that may eventually hold up to 25,000 rows of data (with about 6 columns each). I have successfully managed to bind the grids when the tab page is loaded and it works fine for a few records, but the UI freezes when I bound the grid with 20,000 dummy records. The "freeze" occurs when I click on the tab itself, and the UI only frees up (and the tab page is rendered) once the bind is complete.
I communicated this to the client and mentioned the option of paging for each grid, but she is adament w.r.t. NOT wanting this. My only option then is to look for some asynchronous method of doing this in the background. I don't know much about threading in windows forms, but I know that I can use the BackgroundWorker control to achieve this. My only issue after reading up a bit on it is that it is ideally used for "long-running" tasks and I/O operations.
My questions:
How does one determine a long-running task?
How does one NOT MISUSE the BackgroundWorker control, ie. is there a general guideline to follow when using this? (I understand that opening/spawning multiple threads may be undesirable in certain instances)
Most importantly: How can I achieve (asychronously) binding of the datagridview after the tab page - and all its child controls - loads.
Thank you for reading this (ahem) lengthy query, and I highly appreciate any responses/thoughts/directions on this matter!
Cheers!
There's no hard and fast rule for determining a long-running task. It's something you have to know as a developer. You have to understand the nature of your data and your architecture. For example, if you expect to fetch some info from a desktop database with a single user from a table that contains a couple dozen rows you might not even bother showing a wait cursor. But if you're fetching hundreds of rows of data across a network to a shared database sever then you'd better expect that it will potentially be a long-running task to be handled not simply with a wait cursor but a thread that frees up your UI for the duration of the fetch. (You're definitely on the right track here.)
BackgroundWorker is a quick and dirty way of handling threading in forms. In your case, it will very much tie the fetching of data to the user interface. It is doable, works fine but certainly is not considered "best practice" for threading, OOP, separation of concerns etc. And if you're worried about abusing the alocation of threads you might want to read up on the ThreadPool.
Here's a nice example of using asynchronous threading with the thread pool. To do data binding, you fetch your data in the thread and when you get your callback, simply assign the result set to the the grid view's datasource property.