In this post we go a little deeper into how stuff works on the actual devices that you as a designer design for.
Word of warning: the post may contain explicit technical language and/or imagery.
One of the more frequent patterns when designing mobile apps is using a component that recycles its sub-components. Better known as a TableView in iOS or a RecyclerView in Android, these components appear in almost every app out there.
It all started with the invention of the scrolling gesture. It seems so natural today to scroll or swipe but this wasn’t always the case. The first time scrolling gesture was first presented by Steve Jobs in the first iPhone presentation (2007).
“How do I move around my contacts? I just scroll through them” — Steve Jobs, first iPhone presentation.
Since this component is called in various names in different platforms, from here on we will refer to it as “Table” and to its sub-components as “Cells” (similarly to how it’s called in iOS).
The big idea behind the recycling Table component is that it can present infinite content items all while providing a smooth scrolling experience.
How Tables prevent bad user experience
Creating Cells is expensive relatively to reusing existing ones. The penalty for using expensive resources would be a choppy scrolling experience.
What this means to you and for Sketch to Code
If we look at Figure A below - we see a design for an app with a Table. The design shows a list of Cells which are all the same — except for the content they present. While in Sketch this is a great way to mock-up how the end result looks with real content, when exporting this design to code it doesn’t make sense to create a different Cell for each of these components.
When we export a Table into code the resulted Storyboard, as seen in Figure B, has only one Prototype Cell instead of 7 like we see in Figure A.
To sum up — there is no need to be alarmed if your Sketch file has multiple Cells that looks the same but only 1 Cell when generating code. That’s the way it should be!
Our mission at Anima is to empower designers to own their design. We are creating a tool for designers that enables designers to define, specify and architect all of the bits and pieces that encompasses User Interface/Experience and in the end automatically generate native code that is 1:1 to the original definition. This allows designers to be independent on other parties of the team such as engineering who sometimes have different priorities than the design team.