Let’s see what options do iOS provides and what can we build on top of it to not only make user experience better, but developer experience too.

Plain vanilla Mentions

The simplest approach to adding a specific UI treatment for mentions in UITextView would be to use NSAttributedString with background attribute. The code looks pretty simple to add background to given range of text:

let mention = NSAttributedString(string: "@rajdeep", attributes: [
     .backgroundColor: UIColor.systemBlue,
     .foregroundColor: UIColor.white
])

editor.attributedText = mention

However, as you can see, it looks pretty bland and there’s not much that we can do with just attributes. For instance, at the very least, it would be desirable to have rounded corners for the mention text. Unfortunately, it is not doable without really changing how backgrounds are drawn in NSLayoutManager.

Extending UITextView and NSAttributedString

Mentions is one of initial requirements that I looked at when I started working on Proton. I always felt that background style in NSAttributedString is severely limited in terms of what developers can do with it and hence I developed my own version of background style attribute, appropriately called backgroundStyle in Proton. Proton just extends a UITextView and NSAttributedString to add powerful new features, and a more intuitive API for existing features.

Let’s see how we can utilize backgroundStyle along with a few other attributes to build a perfect mention:

Starting off

Just like background example above, we can use backgroundStyle to get exact same output:

let mention = NSAttributedString(string: "@rajdeep", attributes: [
    .backgroundStyle: BackgroundStyle(color: .systemBlue),
    .foregroundColor: UIColor.white
])
editor.attributedText = mention

Adding style

Unlike background attribute though, it is just as simple to add rounding to the backgroundStyle:

let mention = NSAttributedString(string: "@rajdeep", attributes: [
   .backgroundStyle: 
      BackgroundStyle(color: .systemBlue, 
      roundedCornerStyle: .relative(percent: 50)),
   .foregroundColor: UIColor.white
])
editor.attributedText = mention

roundedCornersStyle may be a relative percentage of height of text to get perfectly rounded corners irrespective of text size, or it can have a absolute value for corner radius.

Not only that, if you wish, you can add also shadow and borders:

let mention = NSAttributedString(string: "@rajdeep", attributes: [
   .backgroundStyle: 
      BackgroundStyle(color: .systemBlue,
      roundedCornerStyle: .relative(percent: 50),
      border: BorderStyle(lineWidth: 1, color: .systemRed),
      shadow: ShadowStyle(color: .systemGray,
         offset: CGSize(width: 1, height: 1),blur: 2)),
   .foregroundColor: UIColor.white
])
editor.attributedText = mention

What about editing

Editing text with attributes like that for mentions bring along a whole new set of issues because of how attributes are treated in UITextView.

Bleeding attributes

This is one of the issues you might not realise until you see one. When a set of attributes are applied to string, these are automatically added to typingAttributes. This means, if you have applied background or backgroundStyle or for that matter any other attribute, it will automatically be carried forward in the following range:

Of course, this is not desirable. This can be fixed very easily in Proton by using another attribute called lockedAttributes. Any attribute that is not desired to be carry forward (in this case, backgroundStyle and foregroundColor), can be added to lockedAttribute to prevent bleeding these into the following range.

let mention = NSAttributedString(string: "@rajdeep", attributes: [
   .backgroundStyle: 
      BackgroundStyle(color: .systemBlue,
      roundedCornerStyle: .relative(percent: 50)),
   .foregroundColor: UIColor.white,
   .lockedAttributes: 
   [
        NSAttributedString.Key.foregroundColor,         
       .backgroundStyle
   ]
])
editor.attributedText = mention

Partial deletion

Another issue that this implementation would show is, that user can delete part of the mention. This is because it’s still just text in the UITextView which is editable.

A typical requirement would be that if a part of mention is deleted, the entire mention should be removed. This can be solved by adding yet another attribute called textBlock to the range. This makes the entire range of text with this attribute act as a single block i.e. you can only delete it as a single unit, and you can not have the cursor anywhere in the middle of it:

let mention = NSAttributedString(string: "@rajdeep", attributes: [
   .backgroundStyle: 
      BackgroundStyle(color: .systemBlue,
      roundedCornerStyle: .relative(percent: 50)),
    .foregroundColor: UIColor.white,
    .lockedAttributes: 
      [
           NSAttributedString.Key.foregroundColor,         
          .backgroundStyle
      ],
     .textBlock: true
])
editor.attributedText = mention

Wrapping

As with any other part of text, a mention may also be long enough that it wraps to next line. By default, it will show up as 2 capsules.

However, we may want to show the wrapping as a continuity. This can be achieved by providing another argument, hasSquaredOffJoins to backgroundStyle. This ensures that at for all the continuous ranges, having wrapped text, the inner edges would be squared off giving an impression that it is continuing from previous line:

let mention = NSAttributedString(string: "@rajdeep", attributes: [
   .backgroundStyle: 
      BackgroundStyle(color: .systemBlue,
      roundedCornerStyle: .relative(percent: 50),
      hasSquaredOffJoins: true),
    .foregroundColor: UIColor.white,
    .lockedAttributes: 
      [
           NSAttributedString.Key.foregroundColor,         
          .backgroundStyle
       ],
     .textBlock: true
])
editor.attributedText = mention

And as simple as that, we have a mention that works just as we expect in an editable text view.

This article is focussed on using open-source library Proton. If you have not yet checked it out, you may read more about it in stories in this list.

Ever since I have started working on Proton, I have been asked if it is just as easy to create a Tabular structure in Proton Editor, as it is to create another type of content, like a Panel or an Expandable content. And my answer would always be, yes- of course! However, I wasn’t able to make time to try it out, until now.

This article talks about my experience of creating a tabular structure that can be hosted within the Editor. Each of the cells further contain the Editor itself, which makes it possible to put any type of content in a cell, including another table. Read on to get to know more about the implementation.

Initial exploration

My original idea was to use UICollectionView with custom layout. On the face of it, it seemed pretty achievable and it probably still is if we only consider the rendering part of the Table. However, since Tables are supposed to be editable as well, it was proven early on that that cell resizing, as content is typed, would be difficult if not impossible in a UICollectionView. Moreover, I also had in mind that eventually there needs to be support to merge/split cells as well as resize columns. Looking at all these requirements, I dropped the idea of using a UICollectionView after just a couple of spikes.

Final Implementation

The failed spikes using UICollectionView made it clear to me that the UI of Table needs to be as dumb as possible, and responsible only for rendering Table cells based on some data. The core logic of cells, sizes, merge/split concern etc. all need to be outside the Table UI. Hence, I created a simple data structure that works off a collection of columns widths and row heights, and generates the frames for each of the cell inside the table.

Table in Proton is called GridView to avoid confusion with any existing iOS component, particularly UITableView. GridView constitutes of following components:

• Grid: Engine behind rendering of the GridView. Grid holds a collection of widths of each of the columns and heights for all the rows in separate array, ordered by respective indexes. It works off a CellStore that holds a collection of cell. GridView is responsible for logic of generating the frames of the cells, controlling the merging/splitting of cells and also additional logic/validating around adding/deleting rows and columns. This is internal to Proton.
• GridCellStore: Holds a collection of GridCell and is responsible for actual deleting and addition of cells including logic to adjust the row/column indexes following addition or deletion of row/column. This is internal to Proton.
• GridCell: A simple UIView that hosts a Proton EditorView and provides features like selection and customizing content like font, text color and background color. This is a public class.
• GridContentView: A scrollable view that is uses Grid to generate and layout cells in the Table. It also provides the gesture support for selecting cells and resizing columns. This is internal to Proton.
• GridView: Public class that encompasses all the aforementioned classes to provide a UIView that can then be used in an Attachment in Proton to be used within the Editor.

Implementation Overview

Generating cells:

One of the most interesting challenge was how to generate the cells such that they are able to be resized, merged and split back without involving complex logic or operations. There are multiple simple parts that come together to make one complex operation possible:

• Each cell has an associated array of column and row indexes. Merging cells means concatenating the rows and/or columns in these arrays, whereas Splitting would mean creating new cells with individual indexes for rows and columns.
• Information about Width and Height of each of the cell is not responsibility of the cell. In fact, cell only gets its frame whenever layout of grid takes place. A seperate object, Grid, holds the collection of widths for each of the columns and heights for each of the rows. This allows to calculate frame of the cell based on its index and column width configuration, which can be fixed or fractional (based on container).
• When a new row or column is added, the new height/width is appended to the row or column collection at the assigned index.
• Deleting a row or column deletes the item at given index from row heights or column widths.
• Having the row heights and column widths separate allows to simplify relayout calculations by a great degree. Frames are always calculated based on these collections, and relayout only requires updating these collections and rest all happens automatically.

Rendering grid:

Rendering the grid on the UI is another place where a very simple approach is used. Each of the GridCell is a UIView. Typically, adjacent views have autolayout constraints amongst each other. This would have been relatively straightforward with a simple table without merge/split behaviour. However, with operations like delete/add of rows and columns and merging/splitting of cells, it would have been very complex to maintain.

In order to simplify the approach, each of the cells is anchored from top and leading edge of the GridContentView which is a scrollable container for the cells. Each of the cells is laid out in reference to these edges. This means that the layout is actually based on the frame of the cell as calculated while generating the cells and will always work irrespective of merged cells placements with respect to other cells around it.

Following illustration tries to highlight the approach taken to render the grid:

Merging/Splitting rows and columns:

As mentioned above, merging and splitting only requires adding column or row indexes in the collection information held by the cell. This does not affect the row height and column width collection held by the Grid.

Following are the operations that occur when a cell is merged with another:

• Validate if the cells can be merged — for cells to be mergable, the aggregate frame of selected cells needs to be a rectangle without any holes in it.
• First cell is taken and it’s rows and columns collection are updated to include rows and columns of all the other cells passed in. Merge operation can be performed on any number of cells as long as the validation passes.
• The actual cell instances all cells other than first one are deleted from the CellStore which holds collection of all the cells.
• Once the cell information is updated, layout is invalidated which invokes relayout of grid:
• Frame of each of the cell is calculated based on container size.
• Top and Leading anchor constraints are updated based on the new frame values for the cells.
• Intrinsic content size is invalidated which updates the new information on the UI.

Split operation works pretty much the same but instead of adding row and column information in the cells, the cell’s row and column information is broken down to new cells with each having one index for row and columns. Also, newly generated cells are then added to the CellStore and new constraints are added for the top and leading anchors from container.

Relayout code for grid stays exactly the same when rendering grid for the first time, and also when merging/splitting and adding/deleting rows and columns.

Further exploration

To explore further, feel free to take a look at the Grid code in Proton. The implementation is pretty straightforward and hopefully, will be easy to follow. A good starting point would be this documentation.

Text with background

Often there are times when we want to add background to the text in a text view. The most simplest, and probably best, approach is to use backgroundColor attribute. You can provide any UIColor to a given range, and iOS takes care of rendering that color in the background of the text.

The only code you need is to add attribute backgroundColor: UIColor.cyan to the list of NSAttributedString.Key in the attributedText property of UITextView. While this works for most cases, it may feel too vanilla. You might want a fancier formatting like adding shadows or borders. At the very least, it is very likely that you would want rounded corners to the background. Unfortunately, none of these properties may be modified by just using attributes.

Better backgrounds

One of the principles I am following with Proton is to provide all that, we as developers, might want to customize and yet keep those customizations natural. What I mean is that all the customizations that you might want to do, should ideally not take anything more than adding an attribute with required information. For e.g. if you want to add lists to a UITextView, it should be as simple as adding a .listItem attribute to the range of text. You can read about my adventures with lists in Lists in UITextView. With Proton, you can add an attribute, very similar to backgroundColor, and achieve the following:

The only code you need to add is:

let style = BackgroundStyle(color: .green, cornerRadius: 5, 
border: BorderStyle(lineWidth: 1, color: UIColor.blue),  
shadow: ShadowStyle(color: .gray, offset: CGSize(width: 2, height: 2), blur: 3))

editor.addAttribute(.backgroundStyle, value: style, at: editor.selectedRange)

editor is the Proton counterpart for UITextView. Besides other features, it provides simple API to manipulate attributes.

Under the hood

If you want to understand how this has been achieved in Proton, please read on.

The layout and drawing of text is managed by NSLayoutManager. It provides two functions that can be overridden to achieve the desired behaviour:

Initial approach

The first approach I tried was using fillBackgroundRectArray. This function provides a finer control over drawing the background for the ranges with .backgroundColor attribute. This function gets invoked with all the rectangles defining the range with background color.

This approach works, but depending upon how content is added, fillBackgroundRectArray may be called multiple times even for the text that is in the same line. This results in rendering rounded corners based on words instead of lines of text:

If the content is pasted instead of being typed, the background is drawn as expected with no visible rounding per word as we see above.

Final approach

Spending a little more time with NSLayoutManager, I figured out that using drawBackground is a better option. Using similar code as above, you can achieve better results.

In Proton, I added additional logic to calculate the rounded corners based on each of the lines that are overlapping and also used a trick that ensures that when there are borders, the borders are only drawn on outer edges of the rectangles with background.

The initial version with all the selected range looked like the following where the corners are rounded at outer edges, but there is still bottom line of the first rectangle that is causing this to appear as two separate background rectangles.

Using some simple logic, I was able to calculate the overlapping line, which is shown in yellow color below:

Once the overlapping line is identified, the only other thing that is left is to use the same color for the line as that for the background, so that the line disappears:

One more thing

With all the calculations that are put in place to draw background with rounded corners, it also helps drawing the background dynamically where it merges and splits the background based on the range of text having the backgroundStyle applied:

I hope you enjoyed reading about this just as much as I enjoyed developing this feature in Proton.

Background with rounded corners in UITextView was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have always been fascinated with the great Open Source community that all of us software developers enjoy. There have been some great frameworks which have come out of people’s passion for solving a problem or making a great thing even better. I have used so many open source frameworks throughout my career as a software developer and have always wanted to contribute back. However, I was not able to come up with a good problem to solve, until now. You already know from the heading — it’s a full fledged completely native iOS editor framework.

We use rich text editors almost all the time without even realizing — like I am using an editor on Medium to write this story. I am using features like adding headings, links, images etc. but I am thinking about the content, not about how to add all these formatting. In my experience as a developer, I have found numerous web based Rich Text Editors, however not many as feature rich on iOS. So that’s why, I thought of building one.

Introduction

It always seemed like a very interesting technical challenge to solve to be able to come up with a capable and extensible editor on iOS. While it is possible to have a web based editor running on iOS and which just works there are a few things which are not as simple to handle in a non-native technology. My inclination towards native editor is driven by the fact that there are so many native features like Dynamic Font sizing and theming which are relatively easy to implement in native but can be very challenging when using web based technologies as a native solution (hybrid).

Requirements

Instead of creating a Rich Text Editor that can just serve as a drag-drop component, I wanted to come up with a framework that can help any one create a Rich Text Editor. The primary reason for this was that I wanted people to be able to add any feature that they need and not be driven or restricted by what is provided out of the box.

At a high level, the requirements that I wanted to cater were:

• Be a standalone component — in its simplest form, it should be a straight replacement of UITextView and in its most complex form, it should be able to handle any functionality that can be expected out of a capable rich text editor.
• Should be extensible to support adding any view as content in the Editor such that it flows with the text.
• Resizing of content views should automatically resize the containing Editor and support this to nth nesting level.
• Should support extending the appearance of text as the content is typed — for e.g. changing text as it is typed using mark-up syntax or highlighting as typeahead character is entered — and yet, not be aware of any of these requirements directly.
• Should allow for working on multiple editors through the same toolbar based on where the focus is.
• Respect the bounds of the container i.e. resize to change when the device orientation changes.
• Support a default font and styling like alignment and head indentation.
• And of course, support all this on macOS Catalyst as well with almost no additional effort.

A framework is born

With all these requirements in my mind, I started working on a framework and in about 3 months, I had a working version that catered to almost all the initial requirements. I called it Proton — something that brings about positivity for developers that use it and for their end users using the great apps by these developers!

Proton is composed of following key components:

Editor

To allow for all the points listed above, Editor introduces some key concepts. These concepts allow for extending the Editor at various levels — even in ways that I have not explicitly designed the Editor framework for as we will see later.

* All screen captures shown below are from iOS simulator.

Attachments

One of the most basic concepts of Editor is Attachments. Attachments are what allow Editor to have any view within Editor text. With support of Attachments, Editor can contain an emoji, a panel or even a table as long as it can be represented as a UIView. An Editor can contain another Editor as well.

There are five types of Attachments which are provided out of the box:

• Matching content: An attachment that automatically resizes based on the size of the content i.e. as the content changes, the size of attachment changes to match that.

• Full width: An attachment that always takes the full width available in its container. If the width of container changes, the width of attachment would change to match that.

• Fixed width: An attachment that always respects a configurable fixed width.

• Width range: An attachment that always retains a minimum width even when empty but only grows up to the given maximum width.

• Percent width: An attachment that always takes up a certain percentage width of the container. As the container size changes, the size of attachment should change to respect the percentage that is used to create the attachment.

All these examples use a text view that is added as an attachment in the main editor. You can add any view inside attachment and apply the sizing rule that fits best for your scenario.

Creating any of these attachments is just a few lines of code:

Commands

Besides adding different kinds of views as content, an editor should allow to change content attributes as well as contents based on user interaction. For e.g. a user might want to select some text to make it bold or select some text and put that in a Panel. All such interactions which change the appearance attributes of the text in the editor or the content in the Editor based on user’s interaction are made possible by Commands.

A command can be executed directly on a given Editor or be passed on to Command Executor so that it is automatically run on the Editor that has the focus.

Proton allows you to add your own commands, that you can add logic to, to carry out tasks like the ones shown above. For text formatting, Proton already provide a base class that can be extended to add any Font Traits supported by iOS.

Creating a command for making text bold is as simple as:

Executing a command is just another line of code which can be invoked on click of a button:

BoldCommand().execute(on: editor)

Based on your logic, a command can work on the selected text or the entire Editor.

Command Executor

A Command Executor allows you to execute the given command on any Editor that has the focus. This comes in handy if you have an attachment that contains an editor, and the command can be executed on both the main editor containing the attachment as well as the editor inside the attachment. It abstracts away the complexity of knowing which Editor the user is trying to run the command on. This is made possible by another concept called Context which binds the Editor to the Command Executor. All the Editors sharing the same context as the Command Executor will automatically be linked with Command Executor.

Context

A Context acts like a key to link between Command Executor and an Editor. A Context allows you to link multiple Editors with the same Command Executor. This can be useful in the scenarios where you have multiple Toolbars acting on one or more Editors i.e. Editor contained inside an Attachments and then added to another Editor.

Text Processors

An editor does not only require making changes on explicit user interactions, but also as the user is changing the text. One such example is a Type-ahead where the text is highlighted in blue as the trigger character is entered. Another example is when a user tries to use markup syntax to format the text as they type opening and closing markers.

Text Processors also allow setting the priority. An Editor may register multiple Text Processors. Whenever the text changes inside the Editor, all the registered Text Processors get an opportunity to change the text or add attributes as required.

Text Processors are given the opportunity to change text/attributes based on their respective priorities. The priority runs from High to Low and all the subsequent processors gets the text as changed by the processor that ran before it i.e. a processor will always get the updated text. This also allows to combine the effects from multiple Text Processors, if required. Besides high, medium and low, the Text Processor also has a priority called exclusive. If an Exclusive Text Processor is run, it prevents all the other Processors from executing. Instead, it notifies the other Processor that their processing has been interrupted so that the Processors can run any cleanup code, if required.

Just like Commands, you can add your own text processors to carry out the functionality like ones shown above.

Renderer

A Renderer always goes hand in hand with the Editor. Relation between Renderer and Editor is just same as that of UILabel and UITextView — it’s just a lot more powerful. In its simplest form, a Renderer is nothing but a read-only Editor. However, to provide an API that is easy to use and looks natural, Renderer encapsulated Editor and exposes its own set of features which are more suited to a Renderer. For e.g. having a TextProcessor would not make sense in the Renderer since the user cannot really type content inside the Renderer. However, Commands may be required to provide functionality like highlighting the text in the Renderer.

By virtue of the Editor, Renderer gains features like inspecting contents and scrolling to a given range. Both these capabilities can be used to create a feature like Find text.

Creating this command is just another few lines — thanks to the helper functions that Proton provides:

A recent addition to Proton is ListCommand and ListTextProcessor that takes care of all the formatting that you might want to have for creating lists in ` UITextView. To read more about lists, head over to Lists in UITextView.

And the story continues…

I plan to continue evolving Proton and add more features that I already have in my mind. I hope you have enjoyed reading about it and ready to take Proton out for a spin.

I would love to hear from you. Please feel free to share your comments/thoughts and any feature requests in comments section.

Building a native editor for iOS was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

It is really odd that something that is used so widely, is not supported natively by UITextView on iOS. When I came across a scenario (more on that later — be sure to read till the end 🙂) where I needed to implement a functional list in UITextView, it seemed that I had hit a roadblock. Right at the onset, I knew that the only option I have is to use custom attributes in NSAttributeString. However, as it turned out, I had to try more than a few approaches to finally be able to create an implementation that I was looking for.

First attempt

The first approach that I attempted was as follows:

1. Create a custom NSAttributedString attribute with name listItem.
2. Whenever a range is selected for applying list formatting, get all the lines separated by new line character, and add additional text before each line with bullet symbols. Also, update paragraphStyle attribute to add indents.

This approach had quite a few issues:

1. When the text was added (denoting bullet/number), the overall range of text changed making it difficult to loop through lines that were in the range originally selected by the user.
2. Keeping a track of index denoting the bullet/number was tricky especially when items got deleted/added in the middle.
3. Paragraph indentation needs to account for bullets/number widths, which in-turn needed to be right aligned.
4. It gets really tricky to control the indentation beyond first level of list items.

While this approach can work relatively well in case you are trying to show lists in a UILabel (where content does not change), it is far from perfect to use the same for UITextView where a user may change text and lists need to adjust dynamically.

NSLayoutManager to the rescue

The biggest learning from the first attempt was that I cannot use an approach that involves changing the text, programatically, to include markers for lists i.e. bullets/numbers etc. Giving it some more thought and traversing the documentation of key parts of TextKit, I figured out that customizing NSLayoutManager is probably the best bet to make it work.

At a very high level, the approach that worked is:

1. Subclass NSLayoutManager to override drawGlyphs function.
2. Loop over the content to find presence of a custom attribute .listItem in layoutManager.textStorage which can be applied by user by selecting a range of text.
3. Using enumerateLineFragments , loop over the line fragments in the layoutManager. It is important to note that a line fragment is actual laid out line in UITextView and not the line separated by new line character. Purpose of using this function is so that we get rect for each of the line, and use that to position custom drawing of glyphs (bullets/numbers) at the given location.
4. For each of the content range identified as a paragraph (i.e. separated by new line character), create a copy of NSParagraphStyle and update firstLineHeadIndent and headIndent.
5. Re-apply the updated paragraphStyle from above to the same range. A copy is required as if you change the existing attribute, it will apply to the entire range of that style which may be beyond a single line (ending in newline character) of text.
6. Using the line fragment rect that we got from enumerateLineFragments , calculate positions to draw custom image/text denoting the list markers i.e. bullet/numbers.

The benefit of using this approach is that since layoutManager is triggered on every key press effectively, it is easier to maintain the indexes for numbering the list items. i.e. when items get added/deleted in the middle of a list, it is automatically reindexed based on the layout.

However, this approach only takes care of list items in a selected range of text. When working with lists, users expects more than that. A text view should support the following:

1. Select range of text and apply list styling. This should automatically create as many list items as there are number of lines in the selected range.
2. When user presses enter key, it should create a new list item at the same level where user is at.
3. User should also be able to use tab/shift-tab (macOS Catalyst) to indent/outdent list item(s).
4. Hitting enter twice at the last list item should exit the list.

The aforementioned behaviour can be obtained by using UITextViewDelegate functions to intercept key presses and update the listItem attribute at given range. For intercepting shift-Tab, a UIKeyCommand may be used. This can then again be read by LayoutManager in overridden drawGlyphs and laid out as expected.

An easy way out

As mentioned in the beginning, I needed to create lists — and this requirement was for an open source project — Proton. Proton is a project that I work on in my spare time. The motivation for developing Proton came from the fact that while UITextView is very powerful, it only exposes very little of that power out of the box. You really need to put quite a lot of pieces (TextKit) together to come up with a native iOS/macOS Catalyst text editor that is capable of supporting different kinds of text formatting. Proton helps make that part easier.

What you see above in an example from Proton which encapsulates TextKit components to provide rich text editing capabilities. Proton is able to achieve lists using the following:

1. EditorView: The editable text view that internally uses a UITextView with custom NSTextStorage and NSLayoutManager .
2. ListCommand : Proton has a concept of commands that can be invoked on an EditorView. Commands can be internally created and registered with EditorView.
3. ListTextProcessor: A text processor is a piece of code that is executed as user changes the text. With this, it is easier to intercept special key inputs like Enter, Tab etc. along with key modifiers like Ctrl, Alt, Shift. Like commands, these only needs to be registered.
4. EditorListFormattingProvider: A protocol that you need to implement and set on editorView.listFormattingProvider. This is used to query the number/bullet that for each of the index. You can return a text value or even an image to be used as the list marker.

Code with Proton

When using Proton EditorView, you only need to add the following to get lists functionality:

let command = ListCommand()
let attributeValue: Any? = "anyValue"
command.execute(on: editor, attributeValue: attributeValue)

attributeValue can be any value that you can add to list items. This value is returned back along with the index of item to EditorListFormattingProvider and can be used to keep context like if the list is bullet or a numbered list.

To get functionality that handles (Shift) Enter, (Shift) Tab and backspace, all you need is:

editor.registerProcessor(ListTextProcessor())

ListTextProcessor takes care of all the formatting as user types text in a list including creating new items, indenting and outdenting lists as well as exiting lists.

A few more examples of lists in Proton running on macOS Catalyst app:

Thank you for your time to read this article. This is the first of a series of articles that I plan to write about Proton, the approaches that worked and ones that didn’t and my learnings. I look forward to seeing you in the next article.

Until then, take care and stay safe! 🙂

Lists in UITextView was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Have a perimeter shadow with1px width.
• Have an ambient shadow which will be variable to give an impression of elevation, as in Material design.

The expected result was as follows:

I wanted to make this elevationgeneric such that it can be applied to any view. My experience on this piece of code turned out to be rather eventful unlike what I was expecting. In this article, I am going to talk about the evolution of the code that I used for getting what our designer was looking for.

At first glance, it seemed like I can just use layer.border for the perimeter shadow, however it did not yield the result as what was expected. Using layer.borderseems much darker and has no spread like what you get if you use a shadow instead:

To keep the approach generic, I created an extension called applyShadowsover UIView and added the code as shown in snippets below.

1st attempt — Using BezierPaths

The first attempt was to use UIBezierPath on the layer of view:

And similarly, ambientShadow can also be created with the only difference being in shadowRadius and shadowOffset to give an impression of elevation. The following code then adds the shadow layers to the view’s layer:

While this worked, it seemed that using sublayers would simplify the code a little.

2nd attempt — Using Sublayers

When using a sublayer we can avoid the additional code required to define the shadowPath:

This code looks much cleaner and straightforward than using UIBezierPath and result is exactly the same output.

It all seemed to be working fine until I tried it on the view the elevation was expected to be applied. As shown in the graphic below, the elevation code did not account for rounding of subviews of the view on which elevation was being applied. This resulted in a broken UI:

As visible in the graphic above, while the parent view has rounded corners and shadows, the subview is not rounded.

3rd attempt — Insets on shadow layer

To fix the issue of rounding, I could not have used clipsToBound as it would result in shadows being clipped as well. As a workaround, I thought of using edge insets equal to the cornerRadius.

Using insets for the frame of the shadow seemed to fix the issue:

However, this approach can be used in some specific cases only. For e.g. this approach will not work if the subview is scrollable and is expected to be touching the parent view bounds while scrolling. Following graphic shows the issue visually:

In the graphic above, the yellow color is of the parent view and cyan is the subview. This approach was more of a hack than a solution. This hides the issue rather than fixing it.

4th attempt — Masking subviews

UIView provides a property called mask which seemed to be the solution to the problem I encountered in the 3rd attempt. Using a mask , we can round the subview without having the hack of insets on shadows:

With the masks applied, we get the expected result:

With this attempt, we solved the problem of non-rounding of subviews and we do not have any additional insets either. While it seems that this approach work, this again poses issues with scrollable subviews:

In the gif above, the blue color is of the parent view which contains a scrollable child view. The child view has 9 items but we see only 4 as others are hidden by the mask we applied.

5th attempt — Using additional view for shadows

So the solution to the problem that I kept running into again and again was clear — I’ll have to use clipToBounds on the view to get desired rounding at the corners. This also meant that I can no longer have shadows applied on the view in question. However, I can still achieve the desired appearance using the following approach:

• Create an additional view with same frame as the current.
• Add shadows using sublayers approach to the new view.
• Position the new view behind the current view.
• Set clipsToBounds on the current view.

and that’s it.

I then updated the code to add shadows to the shadowView:

With this change in place, we are able to get shadows applied to a view with rounded corners and a scrollable subview:

Bonus tips

• Layer names: you must have noticed that I have set layer.name to a value perimeterShadow. This serves as an identifier to remove/resize layers where I can just query all the sublayers to get the shadow layers.
• Background color for layers: If you don’t set the layer.backgroundColor, the shadows will not show up.
• Layer animation: You can query layer’s animation for key, position to get the duration and timingFunction of the view. This can then be used to resize the shadows with the view as the view size changes as a result of change in orientation.