You may be surprised to learn that Bézier didn’t invent the curves named after him — he just made them famous. The code on which they are based was written by Paul de Casteljau, who is the computer scientist that created the recursive methods we use today, code that calculates the points which, taken together, form a curve like the ones seen here in red.
In math-speak, a Bézier curve is defined by a set of control points P0 through Pn, where n is called its order (n = 1 for linear, 2 for quadratic, etc.). …
I wrote an article the other day about using Bezier curves, the construction of which is built into Swift primitives. It’s super useful and works really well. Within that article, I mentioned in passing that the math behind it was mind-boggling. I was wrong. The math is simple. It’s the code that mind-boggling. Let’s dig deeper.
But wait, just before we jump in, why would you want to go down this rabbit hole? Here are three possible scenarios:
Apple has just launched the M1 MacBook and Moore’s law it seems is still in play, despite the naysayers warning that we had come to the end of the line. Now although I think many of us are become a little jaded by the claims that the new models are more than X times faster than the previous ones; I really do think Apple might be onto something here. The M1 is a new processor that is far more power-efficient than its Intel cousin and perhaps more interestingly almost three times as fast.
A challenge here within for a new M1 MacBook owner to…
When I wrote the first piece on drawing a pie in SwiftUI 2.0 my intention was to keep it brief. The bar chart series had taken three articles, and I wanted to jump to the solution quicker. But I wrong — drawing pies has come with a quagmire of conflicts. It certainly wasn’t a piece of pie. And here we are on version 4. What worked and what didn’t and is this really the final countdown.
Version 1 was well received, my editor thought it was awesome, and he is a good judge :) but no in brutal honestly there was some room for improvement. I focused within it on drawing pie pieces and used an observedObject to store data/make changes. It worked well, but I wasn’t happy with the end result since it quivered a little too much for comfort— I thought I could do better. …
OK, I hope you came here from part one. If you missed it, then you can go back to it here:
So what have we got here? Well, I took a step back from version 1 and thought very carefully about it. Maybe it was a great example of where you shouldn’t use an observable object, or at least use it differently. And on that basis, I went back to the drawing board: I think I can do better.
The problem is that we need to update several variables in our struct before we try to redraw the pie. Using an observed object, it starts to update the view as soon as we set the new value for the first slice — no, we need to rethink this a little more. …
In this article, I want to build an animated, autocoloured pie chart, one with a visual sort in it. In other words, I want to build the pie version of the bar chart races, which we covered in Part 3.
Now to save time, let’s take some of the lessons learned from the aforementioned article. I’m going to use an
observedObject to store the records of the changing data sets and the colouring function I mapped out for it too. I also want use some of the other utility functions I developed for the struct.
Now to draw a pie chart, you need some pizza pieces, or arcs in math speak. In SwiftUI, you have a dedicated type of view for building these. This view is called a
Shape, with the few lines of code shown here illustrating the syntax. …
I was pleased with the last pie I had. It was a big improvement on the initial build and has a mesmerising look, but I still felt that there was room for improvement. Thinking about another project I had worked on, it dawned on me I should use the Combine frame as the primary driver. With that in mind, I came up with this solution. Although wait — before you read this, you should take a quick look at the first two perhaps.
Bon, now just before I start, here is a quick side salad to illustrate where I am going. Below is a GIF showing five green dots on the screen. It is a transition that is managed externally through messages sent using the Combine framework. …
This is the third article in a series I’m putting together on building charts in SwiftUI 2.0. The bar chart your looking at, the Barron’s of bar charts, is an animated, autocoloured, value-shifting, visual-sorting one — a chart that I consider to be the one of the ultimate challenges in the bar charting domain: the bar chart race. These charts are all the rage right now.
So what’s it doing? Well, it’s simply a sorted bar chart, a dynamic one that’s constantly changing and visually resorting in the process.
How did I do it? The code in question — the Barron bar chart, lets call it — uses a struct with four values in it. The first is the text label, the second is the value to be sorted by, the third indicates its place in the overall chart, and lastly, we have the colour of the bar. The colour starts out as clear and is set on the first run, as it initially draws the chart. …
I wrote an article the other day in which I talked about building basic bar charts: “Linking Animations together to Build Bar Charts in SwiftUI.” I am not going to post the final code again, but I will show what we managed to build.
In short, it’s an animated, auto-coloured, data-refreshing bar chart. I kept it sweet and short, but couldn’t help but feel I wanted to do more.
Let’s do a new brief based on the bar chart theme. Here is a wish list: