DEV Community: Dico

Building a Vue 3 native Android app with Capacitor on WSL2 (Ubuntu 20.04)

Dico — Sun, 14 Nov 2021 18:22:00 +0000

Capacitor is the spiritual successor to Cordova and Phonegap. Unfortunately they took this literally and left out actual instructions on how to compile the app to a native android app, because who needs those... At time of writing, Vue recommends either Capacitor or NativeScript, but NativeScript requires prior knowledge about native apps I do not have. If you can work with that, their installation guide is a lot clearer than Capacitor's is, and possibly a better fit for you.

Credit to the following resources for providing snippets to get this guide working: Install Android SDK CLI Ubuntu 20.04 WSL2 (Work in Progress) (by steveclarke), the documentation of NativeScript and a guide to building a react native app in WSL2 by bergmannjg.

Prerequisites and goals

At the end of this blog you will be able to:

Set up a Vue 3 app with Capacitor
Be able to run a test build on a real device from WSL2
Be able to build a version of your app that can be deployed to the Play Store

Notable things that I will not be touching upon are how to make this work with an emulator, and how to debug the app on a real device.

I expect you have already installed node (I have 16.13.0) and npm (I have 8.1.0). If not, go do that using your favourite method. I also assume you use bash (you can check with ps -p $$). If you do not use bash, there may be slight differences in syntax. I also expect you to have an android device you can connect to via usb, and where you already have enabled the USB debugger.

Creating a new Vue app and installing Capacitor

Added here for completeness sake. Chances are you already pulled this from some other guide.

vue create your-app
cd your-app
npm install @capacitor/core @capacitor/cli
npm install @capacitor/android
npx cap init "My beautiful app" com.something.my_beautiful_app --web-dir=dist
npx cap add android

Installing the Android SDK

After these initial steps the Capacitor documentation stops. You can run an debug build via the following command:

npx cap run android

This will likely yield the error

[error] native-run failed with error

        ERR_SDK_NOT_FOUND: No valid Android SDK root found.

        More details for this error may be available online:
        https://github.com/ionic-team/native-run/wiki/Android-Errors

Command line tools

We will tackle this problem one step at a time. First we will install the Android SDK command line tools. Obtain the most up-to-date download link for the command line tools only from the official android studio download page. Alternatively just install the version I used at time of writing (November 2021).

# Install unzip if it is not already installed
sudo apt install unzip

# We will install this in the home directory
cd $HOME
mkdir -p Android/cmdline-tools
wget https://dl.google.com/android/repository/commandlinetools-linux-7302050_latest.zip
unzip commandlinetools-linux-7302050_latest.zip -d Android/cmdline-tools
# This location is important, because otherwise you will get an error that the SDK root could not be determined
mv Android/cmdline-tools/cmdline-tools Android/cmdline-tools/latest

# And clean up after ourselves
rm commandlinetools-linux-7302050_latest.zip

While we have the command line tools, other tools like Capacitor relying on it do not know where to find it. For this we need to set the ANDROID_HOME environment variable. We also need to update our PATH environment variable so the command line knows where to find the sdkmanager for example.

# These changes last until the end of the current bash session. We will add a more permanent solution later
export ANDROID_HOME=$HOME/Android
export PATH="$ANDROID_HOME/cmdline-tools/latest:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$ANDROID_HOME/tools:$ANDROID_HOME/tools/bin:$PATH"

Installing some build tools and platforms

If you would to run the emulator now (npx cap run android), you'll notice it at least doesn't complain that it can't find an Android SDK root. It still doesn't work though. To fix this we will run the sdkmanager with some commands. If the sdkmanager complains with an error like Error: Could not determine SDK root. make sure that it is in the correct location. In my version it needs to be in a folder cmdline-tools/latest/bin to automatically detect where the root is.

# Make sure we have the latest information
sdkmanager --update

# We are installing version 31. To figure out what options *you* have, see below
# You'll have to accept licenses by pressing y. Ignore the clause where you sell your soul. That's normal.
sdkmanager "build-tools;31.0.0" "platform-tools" "platforms;android-31" "tools"

If you want to find out what other platforms you can use, you can list the options with sdkmanager --list | grep tools

Last but not least you need to accept any remaining licenses that did not pop up during the initial install.

sdkmanager --licenses

Making our changes permanent

If all of the above went as expected, we can make our changes to our environment variables more permanent. Otherwise figure out what you needed to change, and persist those changes instead.

Edit the ~/.bashrc file with an editor of your choice, then add the following lines to the bottom.

export ANDROID_HOME=$HOME/Android

# Note: I am exporting these from back to front from our previous command
export PATH=$ANDROID_HOME/tools/bin:$PATH
export PATH=$ANDROID_HOME/tools:$PATH
export PATH=$ANDROID_HOME/emulator:$PATH
export PATH=$ANDROID_HOME/platform-tools:$PATH
export PATH=$ANDROID_HOME/cmdline-tools/latest/bin:$PATH
export PATH=$ANDROID_HOME/cmdline-tools/latest:$PATH

You will need to restart your shell for these changes to take effect. Go do that now. Exit out of the shell (ctrl+d) and start it again. Then test if your path and android home variable are set by echo-ing them in the shell.

# should show a line with something like /home/youruser/Android
echo $ANDROID_HOME
# should show a loooong line, with our Android paths at the start
echo $PATH

Other dependencies

Gradle

Last but not least we need to make sure that gradle is installed. Gradle is used to build our source code into a nice apk that can be loaded on a device.

At time of writing the version of gradle in the Ubuntu repository is woefully out of date, so remove it if it is installed.

sudo apt remove gradle

Then install it from a different repository

sudo add-apt-repository ppa:cwchien/gradle
sudo apt-get update
sudo apt install gradle

# And check if it is higher than v4
gradle -v

Java JDK

You'll eventually also need the java jdk. You can check if one is already installed for you.

sudo apt list --installed | grep jdk

The easiest way to install the latest working version for you is probably installing default-jdk-headless, which installed openjdk-11-jdk-headless for me.

sudo apt install default-jdk-headless

Zipalign

To eventually be able to create a signed apk you can put in the Google Play Store you will need to have zipalign installed.

sudo apt install zipalign

Apksigner

Similar to zipalign, we will need the apksigner to... sign... the apk... that we want to put in the Google Play Store.

sudo apt install apksigner

Running a dev build

With the android build tools installed, everything will work fine... right? Right?

Unfortunately when running npx cap run android, we quickly figure out that the emulator is not working. We get the following error.

[error] native-run failed with error

        ERR_UNSUITABLE_API_INSTALLATION: No suitable API installation found. Use --sdk-info to reveal missing packages
        and other issues.

        More details for this error may be available online:
        https://github.com/ionic-team/native-run/wiki/Android-Errors

The proposed switch doesn't reveal anything, and the --verbose flag the link suggests doesn't do anything either. I have not been able to figure out how to get an emulator working on WSL2. You may be able to accomplish this by running adb on Windows instead by following the instructions on bergmannjg's gist or an article by Adrien Pellegrini showing how to use the Android emulator in Windows 10 with WSL2. What I did figure out is how to make the command deploy a test build to a connected device. Unfortunately this too takes some work.

Make usb devices visible to WSL

The first road block to overcome is to make usb devices visible to WSL2. If you run lsusb in WSL, you will notice that there are no usb devices listed.

To solve this problem we need to create a bridge service that sends usb data from Windows to WSL2. It's probably best to follow the instructions from the article that introduces it directly: Connecting USB devices to WSL by Ben McMorran. In short: install a service called usbipd-win on Windows, two libraries called linux-tools-5.4.0-77-generic and hwdata on WSL2 and finally add /usr/lib/linux-tools/5.4.0-77-generic to secure_path in the /etc/sudoers file. Finally restart the computer so the service starts.

Connecting a phone to WSL2

This section largely follows what cjshearer commented on a github issue about adb and uses some information in the article linked in the previous paragraph. If anything is unclear, you may want to consult these posts.

First, open Powershell on Windows as administrator. Then open a WSL2 command line window. This makes sure that Ubuntu is actually running. Next plug in your Android test device, and run the following command in Powershell.

usbipd wsl list

In my case there is a whole list of usb devices, but the one I want is marked as

1-6    SAMSUNG Android ADB Interface, SAMSUNG Mobile USB Modem, ...  Not attached

1-6 is the bus id of my phone, so I will bridge it to WSL2 with the following command in Powershell

usbipd wsl attach --busid 1-6

Enter your WSL2 sudo password.

You should now see your device in WSL2 if you execute the lsusb command. Remember that you need to enable this bridge whenever you remove the usb cable from the device and put it back in. It will not remember to bridge the usb (and this is probably for the best).

Giving adb permissions to the phone

When you now do the adb devices command, you'll notice that it shows you a device number and something like

no permissions (missing udev rules? user is in the plugdev group); see [http://developer.android.com/tools/device.html]

So... we have to set up the udev rules for this device. Izzy does a very good job in their answer android.stackexchange.com explaining what to do, so I recommend just following that answer. In short, make note of the device id in the output of lsusb, craft a line with it in a specific rule file, then restart udev and reload the udevadm service, and replug the device. The group you select for this device should be one you are in. Adb suggests plugdev as te group name. You can check your own groups with the groups command.

sudo service udev restart
sudo udevadm control --reload

You may need to do this after every computer restart.

You can now deploy your app for testing purposes to the connected device. Make sure that you authorize the computer on the phone. adb devices should show you the device id followed by "device". If it shows unauthorized, you still need to authorize it on the phone. If it shows no permissions you may need to restart the services listed above, and you may need to replug your phone.

Building for production

Eventually you probably want to publish your app in the Google Play Store. To do this you will need to generate a signed apk. Since we don't have a GUI in WSL2, we will have to do this from the command line as well. Use the official documentation on building your app from the command line as a guideline.

Preparing a key to sign

To sign an apk with a key, we first need... a key. This key needs to be constant between releases, so generate it once and make sure to save it to your repository. First, navigate to the android subfolder of your project.

cd /path/to/your/project/android

Then generate a key. We use the alias "release", since aliases can be enumerated anyway with the keystore's password so there is no value in making it obscure. Store the password of the keystore securely somewhere outside the repository.

keytool -genkey -v -keystore release.jks -keyalg RSA -keysize 2048 -validity 10000 -alias release

Assemble and sign your build

We first want to assemble an apk that is ready for release, but still needs to be signed. To do this, we just run gradle.

cd /path/to/your/project/android
gradle assembleRelease

Your apk will be generated somewhere deep in the app/build folder. You can quickly get the path with find . -type f -name '*.apk' or hope it is in ./app/build/outputs/apk/release/app-release-unsigned.apk like it is for me.

If you run into problems with an out-of-date version of gradle, scroll up to Other dependencies > Gradle.

Next we zipalign the entire thing:

zipalign -v -p 4 ./app/build/outputs/apk/release/app-release-unsigned.apk ./app/build/outputs/apk/release/app-release-unsigned-aligned.apk

Finally sign the apk. Use the password that you securely stored somewhere several paragraphs ago.

apksigner sign --ks release.jks --out ./app/build/outputs/apk/release/app-release-signed.apk ./app/build/outputs/apk/release/app-release-unsigned-aligned.apk

And finally verify that everything went well.

apksigner verify ./app/build/outputs/apk/release/app-release-signed.apk

Finally copy that file somewhere where you will be able to access it to put it in the Google Play Store.

VIM cheat sheet for common actions

Dico — Sat, 08 Aug 2020 20:48:19 +0000

When editing files over ssh, I prefer to use VIM over editors like nano. While it is certainly easier to find the save button in nano, most other actions in nano are just clunky. And while I never really understood the obsession with home row navigation, since my brain is usually the limiting factor rather than how fast I can type or navigate through an editor, I do prefer how VIM just gets the job done.

One thing I would have benefited from when learning to use this editor is just a cheat sheet with the most common actions you would want to do in an editor like VIM. So I made one.

Understanding VIM

VIM over SSH. Annotated: (1) Cursor location, (2) Highlighted bracket matching bracket under cursor, (3) Filename, 18 lines, 288 characters, (4) line number 1, column 1

When opening a file with VIM, you start in a sort-of command mode. You can navigate the file, but you can not edit. To enter edit-mode, press i or insert. If you press insert more than once, you toggle between insert-mode (add text under the cursor) and replace-mode (replace text under the cursor). To get back into command-mode, press Esc.

If you are stuck, you can usually get out of whatever you just did by mashing Esc and sometimes typing : q Enter. When you are back in command mode, and there is no weird prompt anymore in the bottom you can return to edit mode via i or insert.

When in command mode, pressing keys like :, / and ? will move the cursor to the bottom. These are the beginning of commands. If you don’t want to do a command, just mash Esc to get back to what you were doing.

VIM over ssh with an arrow pointing at the bottom command line

Cheat sheet

All of these commands happen in command mode (see above). Get in the habit of pressing Esc before doing any of these.

Critical commands

Esc Esc Esc: Get back into command mode
i or insert: Enter edit mode
: w enter: Save the current file
:w new_file_name.ext enter: Save to a (new) file new_file_name.ext
: q enter: Quit VIM
: q ! enter: Force quit VIM (discarding changes)
: w q enter: Save changes and quit VIM

That’s all you really need to get going. You can just navigate using the arrow keys and keys like home, end, page up and page down do exactly what you expect them to do.

Cut / Copy / Paste

VIM has it’s own “clipboard”. If you paste something that is not copied through one of VIM’s commands, just enter insert mode and (if you are using ssh for example) press the right mouse button to paste your own clipboard.

insert right mouse button: Paste from own clipboard (in ssh)
y y: Copy the current line
d d: Delete the current line (works like the cut action, as you can paste this line elsewhere)
p: Paste what you have copied or cut
v: Enter visual mode. In visual mode you select text between the character where you entered visual mode and where your cursor is now. If you press y you copy that entire area and if you press d you delete/cut that entire area. To exit out without doing anything, use Esc.

VIM over ssh. Annotated: (1) Position where visual mode was activated with “v”, (2) current position of the cursor (e.g. reached by “down”, “down”, “end”), (3) the bottom bar shows that visual mode has been activated.

When combined, you can do many things. For example

y y p: Duplicates the current line by copying the current line and pasting it immediately
d d p: Move the current line below the following line
v, some navigation, d to cut a section, then navigate to the new position and p to put it back in that position.

Undo / redo

u: Undo the last action (and you can keep pressing it to undo more)
ctrl + r: Redo whatever you did just undo

Navigation

In VIM you can search from the beginning of the file to the end of the file with / and from the end of the file to the beginning of the file with ?. This only affects the order of the search results you get.

/ your search term enter: Finds the first occurence of your search term in the file
? your search term enter: Finds the last occurence of your search term in the file
n: When searching, finds the next result. For / this is later in the file, while for ? this is earlier in the file. If no more results can be found, it will go back to the first result.
shift + n: When searching, goes to the previous result.
: some line number enter: Goes to the specified line number. (e.g. :18 goes to line 18)

When pressing “n”, if no more search results can be found, the bottom row will tell you that it continued back at the edge of the file you started searching at.

The post appeared first at VIM cheat sheet for common actions

Nested sets: Performant attribute calculation on collections

Dico — Sat, 08 Aug 2020 14:41:13 +0000

We all know what a tree is. Computer science taught us that the root is in the top, that it is occasionally red and black and that leaves look exactly like the trunk of the tree. It teaches you that if you want to store a tree, you have various options to do so: Nodes with a parent and position, nodes with a parent, left child and right sibling or even a node with parent, left and right child for binary trees. Obtaining things like a parent, children or siblings is usually not a problem with these storage formats. Obtaining properties such as all ancestors, all descendants or depth however quickly becomes a chore when trying to obtain them in a mysql database.

I only became aware of nested sets as a way of storing trees after a co-worker mentioned it to me. Unlike the previously mentioned storage methods, nested sets have an elegant way of obtaining all these properties, often only in a single query.

Tree represented as a nested set. Picture made by 0x24a537r9 and released in the Public Domain.

Nested sets are based on set theory, but they have some interesting properties. If we have a node A that appears as the child of node B in a tree, with nested sets we represent that as a set A that is contained in a set B. In the example above, “Slacks” is a child of “Suits” in a tree with 4 layers. While sets are usually just collections in a dimensional universe, we need to introduce the concept of “order” in sets to be able to order the children of a node. This will allow us model trees with sets.

Storing a node as a nested set then only requires three fields, namely:

The id of the parent
The left edge of this node’s set
The right edge of this node’s set

Strictly speaking you could omit the id of the parent node and still define a well-formed tree, but it would make querying direct children and the direct parent of a particular node unnecessarily hard. Instead of the parent id you could instead store the depth of a node instead, but calculating the depth with a sql query is an easier task than calculating the direct parent of a node.

The problem

As mentioned before, obtaining various complex properties for a single node is fairly simple with nested sets. I will go in more detail how nested sets accomplish that later, but I want you to realise that while we sometimes are only interested in a single node, or a couple of nodes, we sometimes want to know these special properties for an entire tree. With 10.000 nodes. Meaning that a naive approach costs a whopping 40.000 queries, where some contain nested queries. Is it possible to do that in a reasonable time? The answer is yes. As it turns out, all of these properties can be calculated by visiting each node only once.

Properties on single nodes

Simple properties

Calculating the simple properties of a node, namely the children and parent node are usually easy to calculate and this is no different for nodes stored as a nested set.

Since we store the parent id on nodes itself, getting the parent node is as simple as reading a field on the node. Getting a node’s children is simply a query on a parent node:

SELECT * FROM `nodes` WHERE `parent_node` = ?

Compact nested set representation of the tree above.

Complex properties

From here on I will be using the graphical representation as shown above to showcase why properties are calculated as they are. This representation represents exactly the same tree as the first image on this page.

Descendants of node “Women’s”

Descendants are all nodes that are in a subtree of a given parent node. That subtree contains the children of the parent node, as well as their children etc. Since we defined that if a node appears under a parent node, they are contained in the set of the parent node, getting all descendants becomes very easy. Those descendants are represented by all nodes within the set of the parent node. Since we stored the left and right edge of that set, we can simply query for all nodes within the left and right bounds of a given node.

First we find the left and right bounds of that node

SELECT `left`, `right` FROM `nodes` WHERE `id` = ?

Then we use those values to find all nodes contained within those bounds.

SELECT * FROM `nodes` WHERE `left` > ? AND `right` < ?

Ancestors of node “Sun dresses”

Ancestors are all nodes you would need to travel through if you wanted to reach a given node from the root. In the case above, the ancestors of “Sun dresses” are “Clothing”, “Women’s” and “Dresses”.

Finding ancestors is a little bit harder to wrap your head around, but remember that I told you that all the descendants of a node are within the bounds of that node? Well, we can use that.

See, all ancestors of our node have one thing in common, namely that our node is in the descendants property of each of the ancestor nodes. Meanwhile, there are no other nodes that has that node in their descendants property. If our node must be within the bounds of its ancestor nodes, the ancestor nodes of our node must have their bounds outside our bounds.

Similarly as with obtaining the descendants, we start with finding our own bounds.

SELECT `left`, `right` FROM `nodes` WHERE `id` = ?

Then we find all nodes that begin left of our node and end after the end of our node

SELECT * FROM `nodes` WHERE `left` < ? AND `right` > ?

The depth of a node is how many layers deep a node is nested. It directly correlates with how many ancestor nodes a given node has.

I keep repeating myself, but once again we start with finding our own bounds

SELECT `left`, `right` FROM `nodes` WHERE `id` = ?

Then we simply count the number of ancestor nodes

SELECT COUNT(*) + 1 as `depth` FROM `nodes` WHERE `left` < ? AND `right` > ?

The position (or index or order) attribute of a node in relation to its sibling is basically an integer that allows you to order nodes under the same parent. It is arguably the least useful of the attributes described here if you are designing a tree and controllers for it from the ground up. In our case we transitioned from a different tree structure to nested sets and needed this attribute to prevent us from having to rewrite the front-end. Instead of sending a position and a parent to move nodes around, you are better of using a parent node id and/or a sibling node id to pinpoint the location you want to move/insert a node to/at.

To find this attribute, we simply need to count how many siblings appear before us under the same parent.

You can probably guess what we are about to do first…

SELECT `left`, `parent_node_id` FROM `nodes` WHERE `id` = ?

Afterwards, we find all nodes under the parent, then filter on what is before the current node, and then count the result

SELECT COUNT(*) as `position` FROM `nodes` WHERE `parent_node_id` = ? AND `left` < ?

Finding properties on collections

As outlined in the problem statement, a naive approach to finding these properties on a collection of nodes is to repeat the queries above on each node. While this approach does not seem to be that bad on a small tree, the number of queries and processing on those queries required for large trees gets out of hand quickly. Luckily we have more tricks we can use.

The following techniques all assume that you are working with a complete tree or a complete subtree. All functions only work on the data that is passed to that function. If you pass a complete subtree, it will find properties as if that subtree was the complete tree. In other words, if you calculate the ancestors property on a node while passing only a subtree, it will only contain the ancestors in that subtree. You would need to manually add the other ancestors if you wanted to calculate the ancestors of that node in the entire tree.

Flat tree using depth-first walk

A depth-first walk, pre-order or NLR-traversal starts at the root of a tree and visits the left subtree of each node completely before visiting the right subtree of each node. There are two great things about this:

You are guaranteed to visit all parents of any given node before visiting that node itself
It is extremely easy to create a nested tree (where children are put in a children attribute of their parent) from a flat tree created this way

Why do I bring this up? The first property of this walk is extremely useful when finding the complex properties we talked about earlier. The other reason I bring this up, is because it is extremely easy to get a pre-order walk directly from the database. If you look closely at the image above and scan through the image from the left to the right, you will notice that if you write down the name of a node when you encounter its left edge, you will end up with the pre-order walk we just talked about. In other words: We only need to sort our nodes by their left edge.

SELECT * from `nodes` ORDER BY `left` ASC

We found “Sun dresses” in our walk

Ancestors

The ancestors property is probably the easiest to calculate on a collection. In fact, if your language supports generators, you can easily yield nodes in pre-order while adding this property to your nodes.

When creating the ancestor property we will use the fact that we have found all ancestors of a node before reaching that node, as well as the fact that if we have reached the right edge of a parent node, we have encountered all nodes that needed that parent node as an ancestor. If we combine those two things, we can create a running stack of ancestors we can easily keep up-to-date.

If we look at the image, the light coloured area is what we have already processed. The darker areas are nodes we have processed, and have removed from the ancestor stack already. Let’s take a closer look at the code we are executing when calculating the property for the node “Sun dresses”. At the beginning of the loop we start with an ancestor stack containing “Clothing”, “Women’s”, “Dresses” and “Evening gowns”. We then purge “Evening gowns”, because the right side of this node is before the left side of the node we are currently processing. Afterwards we add our new ancestor stack containing “Clothing”, “Women’s” and “Dresses” as an attribute on our node and then pass it on. Finally we add “Sun dresses” to the ancestor stack before starting at the beginning of the loop to process “Skirts”.

If you are processing a subtree rather than an entire tree, you can seed $ancestor_stack with the ancestors of the root node to get the ancestors relative to the entire tree rather than the ancestors relative to the subtree.

Descendants and children

Getting the descendants of each node is a bit more troublesome. Just like ancestors of a node are guaranteed to appear before a node, descendants are guaranteed to appear after that node when going through the nodes in a pre-order walk. However, we are not able to use the same trick of keeping a running stack of descendants like we did with ancestors, not even if we go through the nodes from the end to the beginning.

Descendants of node “Women’s”

Since we require data after the current node to calculate the descendants property, we are stuck in one of the following situations:

We need to cache all nodes to be able to yield them one by one
We need to prepare the entire output before returning it
We need to yield the nodes in a different order

Each of these situations have their up- and downsides, but I will give two examples for the first two situations.

If we want to yield nodes the moment we process them, we need a reliable way to find all descendant nodes. When we do a pre-order walk, we process the node itself, then its left subtree, then its right subtree. In other words: When we process a node, we then get a list of all our descendant nodes before going back up to our parent node. Thus, if we know how many nodes are in the subtree, we can use this information to get that many nodes after the current node.

Each node has a left and a right bound, and none of the bounds in a normalised tree overlap. This means that each node takes up two “spaces”. In a normalised tree, the left and right bound of a parent node should fit snugly around the nodes in its subtree. Since a single node takes up a fixed amount of space, we can calculate how many nodes are between the bounds of the parent node with the following calculation. That is exactly what we are going to use in our code.

numberOfNodes = (right - left - 1) / 2

We can find the children attribute by using the fact that the sets of sibling nodes touch each other, start at the left edge of the parent node and end at the right edge of the parent node. Finding the first child is easy… the node after the parent node is either the first child of that node, or some unrelated node after the right bound of the parent node. To get the next sibling all we need to do is skip over the subtree of the current sibling. All we need to do for that is figure out how many nodes are in that subtree using the left and right bound of that node, then skip ahead that many nodes.

I leave it as a reader’s exercise to combine these snippets to get the children and descendants attribute at the same time.

As an alternative, we can instead use the code structure we used to determine the ancestors. If we have all the ancestors of a node, all those ancestors have that node as their descendant. We can gradually build up the descendant attribute of each node in that ancestor stack. This means we need to either keep the entire (flat) tree in memory until the end, or yield the nodes when we pop them from the stack, scrambling the tree.

Positions / index / order

The position / index / order attribute as mentioned earlier is easiest calculated when adding the children one by one, by simply counting the number of children at the time of adding the child. Since both techniques outlined above use this approach, I will leave it to the reader to write those two lines.

Combining all of the above

We combined some of these snippets into some unsightly loop, which I will not share here. The result was that an api call that previously took between 15 and 20 seconds now barely took 2. I have not looked too closely at what is hindering performance right now, but my gut feeling is that initialising up to 10.000 models has something to do with it.

DEV Community: Dico

Building a Vue 3 native Android app with Capacitor on WSL2 (Ubuntu 20.04)

Prerequisites and goals

Creating a new Vue app and installing Capacitor

Installing the Android SDK

Command line tools

Installing some build tools and platforms

Making our changes permanent

Other dependencies

Gradle

Java JDK

Zipalign

Apksigner

Running a dev build

Make usb devices visible to WSL

Connecting a phone to WSL2

Giving adb permissions to the phone

Building for production

Preparing a key to sign

Assemble and sign your build

VIM cheat sheet for common actions

Understanding VIM

Cheat sheet

Critical commands

Cut / Copy / Paste

Undo / redo

Navigation

Nested sets: Performant attribute calculation on collections

The problem

Properties on single nodes

Simple properties

Complex properties

Finding properties on collections

Flat tree using depth-first walk

Ancestors

Descendants and children

Positions / index / order

Combining all of the above

Further reading