One Layout To Rule Them All.
What is Plastic?
Plastic is a library to programmatically code fully responsive views in iOS very effectively and efficiently. With Plastic we set a few simple goals for ourselves. Plastic should:
Help build fully responsive mobile UIs. The idea is that any view, be it a full-screen view, or a smaller view, should scale nicely as its size changes. When we say scale nicely, we want the view to maintain the proportions and positions of all of its elements (including font sizes and images) as they were intended by the UI designer.
Make the process utterly efficient. We want our UIs to be responsive, but we don’t want to spend too much time doing it. Plastic should make coding a fully responsive view no more time consuming than hard-coding a fully static one.
Display top-notch performance. Our views should render as fast as possible. We don’t want the need for responsiveness to noticeably slow down user interaction.
Be widely compatible. So far, Plastic is thought for iOS, and works on any version of iOS that it is reasonable for an app to support (we didn’t bother checking for iOS 5 or earlier, but we suspect it would work).
Be easy to learn, pleasant to write, and immediate to read. OK, this is some kind of catches-all goal, but we didn’t want to have too many of them. The point is, Plastic needs to be a pleasure to work with.
Web has been responsive for some time now. A quick Google search tells us that:
Responsive design is an approach to web page creation that makes use of flexible layouts, flexible images and cascading style sheet media queries. The goal of responsive design is to build web pages that detect the visitor's screen size and orientation and change the layout accordingly.
We think this is important not just for the web, but also for mobile:
Apps run on a number of (sometimes very) different screens;
Unresponsive views don’t make good use of different screen sizes, which is especially critical on small, mobile screens.
Consequently, unresponsive design means that fewer devices are properly supported, and this will result in a poorer user experience for those users, and so presumably (at least marginally) lower sales.
Why using Plastic? Aren’t the tools available out there good enough? We at Bending Spoons think they aren’t. At least those we have tried so far.
We started off by laying out views by setting their frames directly, which means we were stating the exact position and size of all subviews within a certain view. Although this way we had full control and great performance, we also faced some major challenges:
Views wouldn’t be responsive, at least not by default;
You’d be writing a lot of (not-so-readable) code;
Doing things right could be time consuming, at least for complex views, as one had to do a lot of calculations manually to ensure the view would be at least partially responsive;
Most people found this approach unnecessarily brainy and complex to master.
So, we tried the supposedly best-in-class solution: Auto Layout. Auto Layout is a technology developed and highly recommended by Apple itself. Its purpose is to help developers describe views in terms of constraints, so, rather than calculating and stating a view’s position and size directly, one would instead write stuff like: “this view should be as wide as that, positioned to the left of that other one, and 50% as tall as this last one view.” To make our lives easier we decided to use Auto Layout in combination with a wrapper library called Masonry, whose reason for existing is simplify the fairly verbose and complicated syntax of Auto Layout.
While this solution had some advantages compared to our previous one (simpler syntax, partial responsiveness), it still didn’t really cut it for us:
Views would still not be properly responsive (one would have to manually scale images, font sizes, and even paddings would often be an annoyance and require adding lots of extra views);
Performance in terms of speed of rendering was poor for complex views (we spent lots of time optimizing views);
We had some significant compatibility problems, when it came to running our apps on older versions of iOS;
Complex views might at times be incredibly time consuming to code and debug, due to a lack of control over certain layout behaviors, and the black-box nature of the tool.
While we could have solved at least one or two of these issues by extending the existing library, we felt a truly satisfactory solution required developing our own approach and toolset. So we created Plastic.
How does it work?
Are you curious to know how does plastic works?
Check the Wiki!!!
How to contribute
git clone email@example.com:BendingSpoons/plastic-lib-iOS.git pod install open Plastic.xcworkspace
If you want to contribute to Plastic, feel free to open a pull request. We will review it as soon as possible.
Plastic is available under the MIT License.
Copyright (c) 2016 Bending Spoons, http://bendingspoons.com/