The number of items in each category can become rather big (think of the list of drinks before a big party).
In the desktop view, displaying a couple of dozens of items and scrolling among them may be acceptable, but on the iPhone, this looks rather ugly.
An alternative to scrolling within a long page is to enable paging (version 1.3.28):
Save the model and start the application. If you now add a few more items, you will be able to page in the item list by clicking the page numbers and the paging symbols at the bottom of the page.
Paging works well with sorting - try sorting by category and paging along the list of items:
At the end of stage 4 we noted that the updater experiences two refreshes of the table upon any update – one due to the built-in refresh process in each of the buttons ('New', 'Update' or 'Delete'), and one due to the subscription to updates. We said that to overcome this problem, users should ignore updates made by themselves.
Now that we have paging, we may want to improve the subscription refresh even further, and for other users (not the updater) avoid refresh altogether if the relevant item is not included in the currently displayed page.
We'll use the 'Source' field of the publish-subscribe message to identify the publisher of each change. The publisher will "sign" any change message it publishes, and the subscribers will ignore any message signed by themselves.
Here is a possible way to model this behavior:
This is beyond the scope of this tutorial. If you want to implement the improvement, you may choose one of two approaches:
Download Model: Stage 9 (version 1.3.29)
For best results, use the Firefox browser..