DiffyTables is a practical and efficient way to use tables in WatchKit apps.
Instead of manipulating the table directly from an interface controller, you can now simply generate a representation of the table. DiffyTables then uses a diffing algorithm to compare new table row data with what's currently on screen and intelligently sends only the truly necessary updates to the watch.
(Yep, kind of like React.)
- Read my article: Practical and efficient WatchKit tables with view model diffing. It explains how to structure your application so you can use DiffyTables. Seriously, go read it, I can wait.
- Check out the demo project in the
Demo/
folder - Copy
Diffing.swift
,WatchKitUpdatable.swift
, andDiffyTables.swift
fromSource/
to your project. - Now you can create your view models (conforming to
TableRowModel
) and make your row controllers conform toUpdatableRowController
- Boom, you can now use
table.updateViewModels()
to do all the updating for you 😊 - Bonus: You can make your app even faster by adopting lazy loading. Read Lazy WatchKit tables for more info
Note: if you're on Swift 2, please use the the swift2
branch.
Add this to your Cartfile:
github "radex/DiffyTables"
and follow the usual steps for watchOS frameworks
Since I published this post, Apple has announced a native SDK for the Watch to be released in the fall. You might conclude that this makes this post obsolete and there’s no reason to implement the view model-based architecture in your app. I believe this conclusion to be false.
First of all, even though the native SDK is available for us to play with, your users will still have to use the WatchKit 1 app until the fall. This is a pretty long time to live with a frustratingly slow app. You can improve their experience with limited effort by using the techniques presented above.
Second of all, I believe that the architectural benefits of this approach still apply on watchOS 2. Decoupling your business logic from interface logic makes your code cleaner and easier to reason about. So does treating the UI as a function of application state.
Some of the optimizations, like the
update(...)
helpers won’t be needed anymore. But the diffing algorithm is actually still useful. Although conceived as a performance trick, it has a side effect of nicely animating row insertions and deletions without you having to do anything.
If you have comments, complaints or ideas for improvements, feel free to open an issue or a pull request.
Radek Pietruszewski
DiffyTables is available under the MIT license. See the LICENSE file for more info.