I have a pivot app where all the pivot items are web dependent.These pivot items update themselves when user navigates to them.So is there any way I can stop whatever the current pivot item is doing(be it web access,updating database) so that my app doesn't lag and the reaction time is quick? Currently it hangs a bit if the current pivot item is getting updated(async web retrieval of images etc).
I want the effect just like the "People" hub.
if you choose to stop the activities of current pivot,it will also take same time and the problem will still exist.i would suggest you to put loader with timer(1 second) for each pivot item.When you will move to next pivotitem,first start the timer(dont start any other activity) and when that timer expires,start other activities in timerTick. So the user experience will be good and It will not give the zigzag experience,
Related
As title says, I would like to know how to decide which row model to choose and the reason why, depending on how the data change and the number of rows, for example.
Viewport - Use when you need to show realtime data, the server will maintain an open connection to update the grid whenever new data is ready.
Pagination/Virtual Paging - these are both about the same, just depends on what you want for your UI. In both situations you would use them if you have a lot of rows to show, but don't want the user to wait 10 min for the server to respond. Probably works best if you sort/filter on the server side.
Other notes:
In my opinion, if you have pagination, then don't have any scroll. I hate scrolling a table to realize that what I am looking for isn't on that page, then scrolling through another page. The only exception for this is if you have some sorting to your paging, like if the first page was all the A's, or had only from 2000, or just January's data.
Also, Pagination can be used in situations where you don't have a lot of data to request from the server, it could just be a UI preference.
I have an MVVM WP8 app that loads a large Pivot to start. From one of my pivots, users can filter one of the lists on that pivot item. I want to display the filter options on a separate page, process the filter on my list, and then redirect them back to the pivot in its prior state - while at the same time, updating the list on my pivot item with the filtered list.
I don't want to reload my entire pivot at that point, I want to go back to the pivot I came from and update its data context/items source only.
What's a good strategy for getting something like this done?
I have a UI that looks similar to the mail app. A table view along the left with a single column of items. When one of the those items on the left is selected, details about that item are shown on the right.
When some event occurs in my app that requires the data in the left table view to be reloaded, the current selection is lost and then the right detail view and left master view get out of sync.
The way i hoped to solve this problem was, when it was time to reload the table data, I would:
1. Save the current selected item
2. reload the table data
3. Handle a delegate method or notification that let me know when the reloading was done.
4. Re-select the proper item by finding it in the new list of items in the table.
Unfortunately I cannot find any way to determine when the table is done reloading. Is there a. any way to figure this out, or b. a more elegant solution to this problem?
thanks.
update: In case my problem was unclear, imagine you are in the mail app and you have some message selected. That summary cell is shown as selected on the left, and the details of the message are shown on the right. Suppose new mail comes in which appear as new cells at the top of the table. How is the message you are currently viewing preserved, and not de-selected?
reloadData is something of a sledgehammer. 10.7 offers a better solution.
Instead of using reloadData, when you have new rows to add, use insertRowsAtIndexes:withAnimation: . When you have rows to delete, use removeRowsAtIndexes:withAnimation: . And, of course, if an existing row has changed, there's reloadDataForRowIndexes:columnIndexes.
These should remember the selection for you (at least, the equivalents on iOS do).
If you can't target 10.7, some of the other suggestions will probably help out. noteNumberOfRowsChanged may also be helpful but I've not actually used it.
You can save selection on tableView(_:shouldSelectRow:) then select the row right after you create the cell in tableView(_:viewFor:row:) using selectRowIndexes(_:byExtendingSelection:).
It is pretty reliable no matter how / when / how many times you reload the table.
I know that you can capture the event when a person clicks a "like" button from within a Facebook tab via the edge.create method, but what im wondering is if there is a way to capture when the Facebook like button at the top of a page is clicked, the purpose being to be able to find out which tab within my fan page is generating likes.
When the page reloads i will know that the page IS liked, but i dont know if the like was generated from one tab, or another tab on the same page.
The only solution I can think about which is sufficiently accurate is the following:
Start a session on server side with the first app request.
Remember the like state from the signed_request and the timestamp when it was issued.
Embed a javascript interval in your tab app(s), firing an AJAX request to your server every couple seconds. I think you have go with something between 2 and max 5 seconds.
The AJAX request refreshes only the timestamp in the session.
If the user clicks like on top of the page, now, the whole facebook page gets reloaded - so does your app and you get a new signed request which has the liked state now set to 1.
Have a look at your session > was the state 0 before? Yes? Is the timestamp max. 6-10 seconds old? Yes? Well, its most likely then that the user liked the page while being on the tab.
I hate the solution with the AJAX interval polluting the network (and on a big site with many users this will stress your server), but I can't think of any other solution, because there is no other way to keep track if the user is still looking on your tab. If the interval is too high, the user would be able to navigate away to the wall or info section and like the page there. If he directly returns to your tab after this, you wouldn't be able to track if he left the tab at all...
Another solution would be to listen for the body.unload event and fire a AJAX request to the server, telling you that the user has left the tab, but it is possible that the event never gets fired on certain browsers or the AJAX request is not fast enough to be processed before the tab page unloads. On the other hand would this solution take way less resources of both the users network and your servers performance.
This are just theoretically solutions and have to be tested, first!
I think this could be accomplished like this:
When the like button on top of the page or on the left side are clicked, facebook refreshes the currently displayed tab.
You can capture this refresh if you record the like state from the signed request, and when a tab transitions from not-liked to liked you can count it as a conversion.
This should work, have never used it, and it's better then nothing. You will probably need to add a limit on the user ip address to prevent unlike/like events increasing the counter.
Good luck, and please post here if you find a better solution, this can be interesting.
For a Windows Phone 7 app, I have several Customer records that I need to display based on when the customers where created, so something like a start date and end date filter (maybe some canned entries listbox that lets you pick - tomorrow, week, month, custom)
Any UI guidance of how to do this so that the interface is kept clean and still leaves enough space for the records to get displayed?
Thanks,
Pratik
You could reserve the majority of the display space for your data and show a brief indication of the current filter in place.
This filter could be an active control of your choice that when tapped takes the user to another page where you provide the criteria selection.
Initially it could show "No filter (tap for criteria)" or some such.