I have understood that using the "Index view model" to display data is not the the preferred way to show data at start-up. I therefore hoped to execute a periodic action in Index to redirect to the correct start page. But I do not see how I do this in practice? Has anyone used "Index" as start page with good results or has any one managed to execute the redirect action?
Since the index is rendered with MVC - it must have a client side timer to execute any periodic action. I do not think there is one added currently - I think there was at one point but the ambition to keep the MVC pages clean removed it.
Related
I am currently using VIP architecture and I was wondering when I should make an API call.
For example, I have two views. A connection view leading to a list view.
The list needs the user to connect to load.
My question is, where should I make my API call to fetch data for the second view ?
Should I make the request as soon as the connection succeeds, and then launch the 2nd view once I get the data of this request.
Or
Should I launch the 2nd view first and then make the request for this view ?
The first solution seems slightly faster, but the second one feels cleaner.
What do you think ?
First of all, VIP/MVC/MVVM architecture has nothing to do with your issue, none of there architectures has rules about when you need to make API calls.
Everything depends on your needs and tech requirements.
As for me there is two most important points:
if your second screen is data sensitive and you need to be sure, that it display latest data - make API call after this screen was displayed and update it UI with latest data.
if you don't care if data that you display is latest/ or you this data would not be updated very often/ or you show static data that would be rarely changed, BUT for you is important that user will see next screen immediately - make API call as soon as it possible(preferably on app launch)
If both previous points is not important for you - make API call after screen will be displayed. It will guaranty that you has latest data.
But you need to remember that there is no rule about it, so make API calls when you really need it.
We are using xamarin forms with prism. We have simple pages with small amount of data to be displayed on each page and include simple calculations. We are using prism navigation service to navigate between pages. We are experiencing some latency from clicking a button to navigating to next page. Data is fetched inside OnNavigatedTo since navigation parameter changes the data. Can someone shed some light of why is there a latency, it is close 1+ second and sometimes 2 seconds.
Also, it seems like each page is getting rendered twice... Once before OnNaviagatedTo and then data changes. OnProperty or OnCollection changed is fired from within OnNavigatedTo and it seems to cause the rendering again.
Version 6.3.0 introduced the concept of OnNavigatingTo, while OnNavigatedTo has been around for a while. There is a distinct difference between the two. Understanding the order in which things occur should help you create a nicer user experience.
New Page is created
OnNavigatedFrom is called
OnNavigatingTo is called
New Page is pushed onto the Navigation Stack and becomes visible
OnNavigatedTo is called
Applications that have to reach out and fetch data can often experience latency issues because it takes time to reach out to the remote service and get the data we want and then parse that data into a usable object. This particular problem was one in which many developers wanted to cut down the demand on the UI with having to refresh as the bindings were being updated which led to the introduction of OnNavigatingTo.
While neither one will reduce network latency it gives you an ability to make the calling page enter an IsBusy state that may display some sort of loading icon which would then be updated to false when NavigateAsync completes and your new page is displayed already loaded.
Assume a page that shows a complex data structure (for example, an article with many details). This view will be reused from time to time by rebinding it to different articles.
Now, I noticed that the ODataModel keeps all used article entities in memory (also if they are no longer bound to any control).
This will lead to two issues:
Memory consumption increases over time (if application will not be reloaded).
If the application forces a refresh of the data model, all entities will be loaded (also not used).
The second issue seems to be the bigger problem. It slows down the speed of the application.
I have not found a solution for that problem. If I use refresh(true, true) it seems all data will be reloaded.
Is there an way to clean the model?
Edit
Lets say you have a list of thousands of articles. User can click on one of the articles and will navigate to a detailed screen of that article.
The OData model in client side will cache this. To see it, do something like:
var oModel = this.getModel("modelName");
look with the debugger into oModel.oData.
If the user now navigates back and chooses the next article, this will be cached as well.
If user does this 1000 times, all articles are now in the model.
If you trigger a oModel.refresh(true);, all these data (of 1000 articles) will be reloaded not only the one bound to the view.
Now my application is not about showing article information. It's a more complex structure with subitems. Each time user is visiting this page, more data will be cached (and re-fetched in case of a refresh call on the model).
Edit 2
The function updateBindings(bForceUpdate?) seems to help a little bit.
Anyhow, the data accumulation is still there in the ODataModel class.
That means: Each visited data path will stay in memory since the next reload (F5) of the full page. If someone uses such an application over a day, the data accumulates and a refresh call on the model will read all data again, if still bound to a view or not.
Try deleteCreatedEntry(oContext). Even though this is not the supposed use case for this method it might work to delete an entity from the model without triggering a backend request.
You could also try if updateBindings(bForceUpdate?) only triggers an update on actually bound entities.
1) I do not really understand your problem here. What is it exactly that you do? OData always holds the result of your request plus a queue of changes to that request. If you create lots of entries while your application is running, of course the memory consumption will increase. If you want to revert back to the original request you can use resetChanges(). THis way the used memory should decrease again. But you lose all your changes to the model.
2) Maybe you should look into Odata filtering (http://www.odata.org/getting-started/basic-tutorial/) so that you only load the entities you really want. If you only want a part of the entity loaded then you should maybe redesign your entities to avoid a lot of overhead.
It is hard to speculate what your exact problem is.
Well, if you know exactly what are you doing, you can try something like this:
this.getModel("modelname").aBindings = []
Better solution would be go through the aBindings array and remove redundant bindings.
I'm building an app that deals with customer queries, where I want to route the query through a decision tree showing appropriate views before taking some automated action against their query. Kind of like the game "20 questions"! Based on the answers at each stage, the path through the app will change.
I was thinking of using MVC, because there are only a few "types" of route and outcome - so I could build fewer pages that way, one to handle each type rather than one for each step. I was also thinking of using Workflow 4 to manage the page flow, because the flowchart model maps pretty nicely to what I'm trying to do.
Does anyone know any good reference apps that use Workflow for this kind of thing?
Thanks
Richard
There where a number of examples using WF3 doing this sort of thing but I haven't seen any for WF4. I suppose it is possible to do but it means running the workflow synchronously and checking the bookmarks as soon as it becomes idle to see which operations are enabled at the moment. That should be possible using a custom SynchronizationContext that does things synchronous and using the Idle callback on the WorklfowApplication to check the current bookmarks.
I actually went with a different option in the end - I wrote a "GetNextAction" function that returned an ActionResult object based on my flowchart logic and state of objects. The controller processes whatever form inputs it's received, updates the object, then calls GetNextAction and returns the result of that function. Seems to be working out ok!
Did anyone hear about asynchronous executing of an EF query?
I want my items control to be filled right when the form loads and the user should be able to view the list while the rest of the items are still being loaded.
Maybe by auto-splitting the execution in bulks of items (i.e. few queries for each execution) all in same connection.
I posted a feature suggestion to Microsoft, please share them with your ideas as well.
Not wanting to sound like a commercial, but I noticed that the latest DevExpress grid gives features like this in their WPF grid. Essentially you want to load visible-count items first, then load the rest in a background thread so your UI isn't freezing up. The background thread should probably load another page at a time and make them available to the UI thread.
It's something you would want to think about carefully and make sure you get it right, or simply buy a control that does the hard work for you.
I take from your link that this is a web app. Is that correct?
A Query must complete and return data before rendering can begin. An EF feature will not help you here. Rather. look at breaking up your process into several processes that can be done at once.
Keep in mind that ASP.NET cannot return a response to a browser if it is not done rendering the HTML.
Let me assume you are executing a single query, getting the results back and displaying them to a page.
Best option: Page your results. if you Have 4000 records, show the first 50. If you show 200+ records to a user, They cannot digest that much information.
If that does not fit your needs, look at firing one query for 50 results. Make an Ajax call to the the remaining records and build the UI from there, in (reasonably sized) chunks.