|
People are saying this is exaggerated and it probably is, somewhat. But there's some truth to it. Take a list of things for example -- let's say a list of contacts. On the web that's probably a styled <ul>. On iOS, it's a UITableView. So, let's say late in the game you're asked to sort contacts by first name, and put a little section indicator in for each letter. On the web that's easy, sort the array, then as you're iterating over it and rendering, insert your section header when the first letter changes. If the list changes, ajax the changes in and use an id on each item to update. Done. On iOS, first you'll need to set up a collation on your table view. Decompose your array of contacts into section arrays. For efficiency, you'll probably want to keep a pointer to that list. Change your section and row count delegates so they match the new structure. Now when you're rendering the cells, you'll need to locate the contact by section and row, and if a cell is tapped you'll need to change that too. If you support editing (delete, etc), there are several other places where you'll need to make similar changes. Speaking of which, what if the user deletes the last contact in a section? You can't delete the last row in a section without deleting the section as well, so you'll need to detect that and react appropriately. Can updates arrive while the list is displayed? You could just reload the whole list, but that will probably result in an annoying UI pause. Better to just update the cells that need to change, so you'll want to find each changed row in your collated lists and update it, being sure to watch for any sections you need to insert/delete... ...And on and on. None of this is rocket science, but the point is that there can be a lot of complexity behind a minor changes that someone with a web perspective would think of as trivial. |