DEV Community: Arthur Denner

Build an extendable in-browser devtools

Arthur Denner — Tue, 16 Aug 2022 11:00:00 +0000

Devtools are useful and part of our daily work as developers. If you're developing for the web, you've probably used the browser's devtools to debug issues, test changes, investigate network requests and many other existing features.

While the browser devtools are great, every application has different needs and therefore, could use specific tools. In some scenarios, creating a browser extension is the solution but it requires writing specific code for each browser and, in many cases, you can build a devtools in the web application itself.

In this blog post, you'll learn how to start your own devtools and build the foundation to expand and adapt this knowledge to your current team and projects.

Prepare the project

PS: If you want to skip coding along, feel free to clone the final repository and jump straight to the "Create the devtools" section for explanations.

For demo purposes, we'll use Next.js. Start a new project with npx create-next-app@latest --use-npm. Feel free to remove the --use-npm flag if you prefer to use yarn and adapt all mentioned commands accordingly.

Once the project is created, open the folder on your preferred code editor.

We'll be using components from @chakra-ui/react to have a decent layout without much effort and to avoid adding CSS to this post. Following the Getting Started with Next.js guide, install all necessary dependencies:

npm i @chakra-ui/react @emotion/react@^11 @emotion/styled@^11 framer-motion@^6

Once all dependencies are successfully installed, open the pages/_app.js file and replace its content:

import { ChakraProvider } from '@chakra-ui/react';

function MyApp({ Component, pageProps }) {
  return (
    <ChakraProvider>
      <Component {...pageProps} />
    </ChakraProvider>
  );
}

export default MyApp;

Create a couple of pages

Update the pages/index.js file with the following content:

import Head from 'next/head';
import NextLink from 'next/link';
import styles from '../styles/Home.module.css';

const HomePage = () => {
  return (
    <div className={styles.container}>
      <Head>
        <title>Index Page</title>
        <meta name="description" content="Index Page" />
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>Index Page</h1>

        <NextLink href="/layout" passHref>
          Go to layout page
        </NextLink>
      </main>
    </div>
  );
};

export default HomePage;

Create a new pages/layout.js file and paste the following content:

import Head from 'next/head';
import NextLink from 'next/link';
import styles from '../styles/Home.module.css';

const LayoutPage = () => {
  return (
    <div className={styles.container}>
      <Head>
        <title>Layout Page</title>
        <meta name="description" content="Layout Page" />
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>Layout Page</h1>
        <NextLink href="/">Go to index page</NextLink>
      </main>
    </div>
  );
};

export default LayoutPage;

If you run npm run dev and visit localhost:3000, there should be a link on each page that takes you to the other. Now, let's move on to creating the extendable devtools!

Create the devtools

Create a new file at components/Devtools/Devtools.js with the following content:

import {
  Box,
  Button,
  Tab,
  TabList,
  TabPanel,
  TabPanels,
  Tabs,
} from '@chakra-ui/react';
import { useState } from 'react';

const Devtools = () => {
  const [isOpen, setIsOpen] = useState(false);

  if (!isOpen) {
    return (
      <Box bottom="0" left="0" padding="1rem" position="fixed" zIndex="100000">
        <Button onClick={() => setIsOpen(true)}>Show</Button>
      </Box>
    );
  }

  return (
    <Box
      backgroundColor="white"
      bottom="0"
      left="0"
      padding="1rem"
      position="fixed"
      right="0"
      zIndex="100000"
    >
      <Tabs isLazy variant="enclosed">
        <TabList>
          <Tab>One</Tab>
          <Tab>Two</Tab>
          <Tab>Three</Tab>
        </TabList>

        <TabPanels maxHeight="300px" overflowX="auto">
          <TabPanel>
            <p>one!</p>
          </TabPanel>
          <TabPanel>
            <p>two!</p>
          </TabPanel>
          <TabPanel>
            <p>three!</p>
          </TabPanel>
        </TabPanels>
      </Tabs>

      <Button onClick={() => setIsOpen(false)}>Hide</Button>
    </Box>
  );
};

export default Devtools;

The component has a piece of state to hold if the devtools are hidden or shown. When hidden, display a button to show it. When shown, display some hardcoded tabs from Chakra UI and a button to hide the devtools.

Now open _app.js and update it to display the devtools. We'll make use of next/dynamic to lazy-load the component and only load it in the client:

import { ChakraProvider } from '@chakra-ui/react';
import dynamic from 'next/dynamic';

const Devtools = dynamic(() => import('../components/Devtools/Devtools'), {
  ssr: false,
});

function MyApp({ Component, pageProps }) {
  return (
    <ChakraProvider>
      <Component {...pageProps} />
      <Devtools />
    </ChakraProvider>
  );
}

export default MyApp;

With these changes in place, you should be able to see a floating "Show" button that you can click on to open the devtools and play with them.

The tabs on our devtools are hardcoded and useless so far, there's no fun in that! Let's make them dynamic and contextual!

Make the tabs dynamic

We need our devtools UI to update every time there's a new tab or a tab is removed. Instead of pulling in a third-party library for this feature, let's extend the built-in Map.

Create a new file at components/Devtools/tabs.js and paste the following content:

import { useEffect, useState } from 'react';

// Extend the built-in Map to add some custom behaviour
class CustomMap extends Map {
  // Add a placeholder property to hold a callback function.
  // We'll override it later in our custom hook
  callbackFn = (updatedMap) => { /* TODO */};

  // Override the delete method to call the callbackFn
  // with the updated Map after deleting a key
  delete(key) {
    const result = super.delete(key);
    // Pass `this` to callbackFn
    // to give access to the updated values
    this.callbackFn(this);
    return result;
  }

  // Override the set method to call the callbackFn
  // with the updated Map after setting a new key
  set(key, value) {
    super.set(key, value);
    // Pass `this` to callbackFn
    // to give access to the updated values
    this.callbackFn(this);
    return this;
  }
}

// Initialize a CustomMap in a module level
const tabsMap = new CustomMap();
// Create a helper function to convert the CustomMap into an array
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map/entries
const getTabs = () => Array.from(tabsMap.entries());

// Export a custom hook to expose the tabs array
export const useDynamicTabs = () => {
  const [tabs, setTabs] = useState(getTabs);

  useEffect(() => {
    // And subscribe so that any change to the map causes a re-render
    tabsMap.callbackFn = () => setTabs(getTabs);
  }, []);

  return tabs;
};

// Export a function to register a new tab
// which returns an "unsubscribe" function for that tab
export const registerTab = (key, value) => {
  tabsMap.set(key, value);

  return () => {
    tabsMap.delete(key);
  };
};

Take some time and read through the comments to understand what the code is doing. In summary, the code holds all tabs in a Map and causes a re-render through useDynamicTabs every time the Map changes.

If you're confused about getTabs being passed by reference: both useState and setState/setTabs accept a function as parameter, so getTabs is called implicitly on both cases.

Now let's change the components/Devtools/Devtools.js file to read the dynamic tabs and react to the changes:

import {
  Box,
  Button,
  Tab,
  TabList,
  TabPanel,
  TabPanels,
  Tabs,
} from '@chakra-ui/react';
import { useState } from 'react';
import { useDynamicTabs } from './tabs';

const Devtools = () => {
  const [isOpen, setIsOpen] = useState(false);
  const dynamicTabs = useDynamicTabs();

  if (!isOpen) {
    return (
      <Box bottom="0" left="0" padding="1rem" position="fixed" zIndex="100000">
        <Button onClick={() => setIsOpen(true)}>Show</Button>
      </Box>
    );
  }

  return (
    <Box
      backgroundColor="white"
      bottom="0"
      left="0"
      padding="1rem"
      position="fixed"
      right="0"
      zIndex="100000"
    >
      <Tabs isLazy variant="enclosed">
        <TabList>
          {dynamicTabs.map(([name]) => (
            <Tab key={name}>{name}</Tab>
          ))}
        </TabList>

        <TabPanels maxHeight="300px" overflowX="auto">
          {dynamicTabs.map(([name, content]) => (
            <TabPanel key={name}>{content}</TabPanel>
          ))}
        </TabPanels>
      </Tabs>

      <Button onClick={() => setIsOpen(false)}>Hide</Button>
    </Box>
  );
};

export default Devtools;

Now our devtools will only display the tabs that are registered and their respective panels. Currently, there are none since the dynamic tabs start as an empty map.

To test its dynamism, call registerTab in pages/_app.js passing a string as the first and seconds parameters - since strings are valid React nodes.

// other imports
import { registerTab } from '../components/Devtools/tabs';

registerTab('Tab #1', 'Our first tab');
registerTab('Tab #2', 'Our second tab');

const Devtools = dynamic(() => import('../components/Devtools/Devtools'), {
  ssr: false,
});
// rest of the code

With the code above, for example, you should get two tabs in the devtools:

Contextual tabs

As shown in the previous example, you can register "global" tabs, that will be visible on every page. However, specific tools can exist in specific contexts. Let's register a tab for each page and make them available only while the page is active.

Open the pages/index.js file and modify it to register a tab after the first render:

// other imports
import { useEffect } from 'react';
import { registerTab } from '../components/Devtools/tabs';

const HomePage = () => {
  useEffect(() => registerTab('Index', 'Devtools on the index page'), []);

  // rest of the code
};

export default HomePage;

Open the pages/layout.js file and modify it too:

// other imports
import { useEffect } from 'react';
import { registerTab } from '../components/Devtools/tabs';

const LayoutPage = () => {
  useEffect(() => registerTab('Layout', 'Devtools on the layout page'), []);

  // rest of the code
};

export default LayoutPage;

Now open the devtools and notice that the "Index" tab is only available while on the / page. When switching to the /layout page, "Index" is removed and the "Layout" tab is registered.

That's important because we won't have irrelevant UI on the page we're currently working on. It works like that because registerTab returns an "unsubscribe" function and useEffect runs that function when the page/component is unmounted.

Relevant notes

Although I've used React here, the concepts can be applied to Vue, Svelte and others.

Tabs can be registered by specific components too, not only pages. For example, your notification center, when available and visible, can register a tab that allows notifications to be created. The same goes for your theme picker or whatever other component exists on your web application.

These devtools can make HTTP requests, modify cookies and anything possible in a web application since they're just part of your main application. The sky is the limit!

You can also display devtools from third-party libraries within your own, for example, react-query ships a very useful devtools component that you can display globally.

Closing thoughts

As mentioned in the beginning, this blog post is introductory and I didn't cover everything. Here is a list of changes you should consider if you want to take this idea to the next level:

Render the devtools based on a specific cookie value
Allow the user to resize the devtools with an auto hide feature
Persist if the devtools are open or closed, and maybe other states, to restore them after a page refresh
Render the devtools only when process.env.NODE_ENV === 'development' or using another environment variable
Enable tree-shaking the custom Map logic based on the same environment variable used to render the devtools

If you think something else is relevant too, please leave a comment!

A more complete example

I know the examples in this blog post are very basic and our devtools only have strings. The goal of the blog post is to open your mind to the idea of building custom devtools and I hope it was achieved!

To help you picture the power behind this idea, I've created a more complete example. It uses TypeScript and integrates a few third-party packages. A live demo is available at this link and the source code is available on Gumroad as a way of supporting my work. Let me know what you think about it in the comments or via email.

How to implement a search shortcut (OpenSearch) on any website

Arthur Denner — Thu, 03 Mar 2022 19:24:32 +0000

What is OpenSearch?

OpenSearch is a way for websites and search engines to publish search results in a standard and accessible format. One of its pieces is description files and that's the focus of this article.

A description file allows a website to describe a search engine for itself so that a browser or other client application can use that search engine.

Example

If you open Chrome and type "egghead.io", there will be an option to search directly there. If you press Tab or Space, type your query and press Enter, you'll navigate directly to the search results page.

If you never visited their site before, you may need to refresh the page after opening it for the first time

Implementation

To implement the same feature on your website, you need an XML file and an HTML tag. The description file should be an XML file with the following structure and must be available in a public URL such as https://yoursite.com/opensearch.xml.

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">
  <ShortName>[SNK]</ShortName>
  <Description>[Search engine full name and summary]</Description>
  <InputEncoding>[UTF-8]</InputEncoding>
  <Image width="16" height="16" type="image/x-icon">[https://example.com/favicon.ico]</Image>
  <Url type="text/html" method="get" template="[searchURL]" />
  <moz:SearchForm>[https://example.com/search]</moz:SearchForm>
</OpenSearchDescription>

Most tags describe what the browser will show to the user. The important tag to the actual search is the <Url />, where you put the template URL for your search page.

In egghead's case, this is the file, available at https://egghead.io/opensearch.xml.

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">
  <ShortName>egghead</ShortName>
  <Description>Search egghead</Description>
  <InputEncoding>UTF-8</InputEncoding>
  <Image width="16" height="16" type="image/x-icon">https://egghead.io/favicon.ico</Image>
  <Url type="text/html" method="get" template="https://egghead.io/q?q={searchTerms}&ref=opensearch"/>
  <moz:SearchForm>https://egghead.io/q</moz:SearchForm>
</OpenSearchDescription>

What you type in the address bar replaces the {searchTerms} variable in the template https://egghead.io/q?q={searchTerms}&ref=opensearch.

The next step is to instruct the browser where to find the XML file adding a link tag to the head element of your HTML. This enables the browsers to autodiscover the description file.

<link rel="search" type="application/opensearchdescription+xml" href="/opensearch.xml" title="ShortName">

Testing

To test the changes locally, you need a secure URL pointing to our localhost environment (aka tunnelling). Feel free to use any tool you know, I can recommend ngrok or localtunnel. You can find other options on this blog post.

Chrome and Safari

Visit the secure URL on your browser
Refresh the page - the browser has read the link tag and indexed it
Type the URL again and the search shortcut should be available

Firefox

Firefox requires you to manually index the site as a search engine. The different ways to do it are described in their documentation.

Example

If you want to see the mentioned implementation on egghead, a Next.js application, have a look at this pull request.

Wrapping up

I hope you enjoyed this post and it's helped you in any way. It's very different from anything I've written before but I felt like I needed to write it.

Let me know your thoughts in the comments.

Subscribe to my newsletter and follow me for more.

References

A tale of knowledge building

Arthur Denner — Tue, 27 Apr 2021 15:28:34 +0000

I love to learn and how we build up knowledge.

Also, I love to apply my knowledge somewhere, so here's a story about this.

Disclaimer

This post doesn't try to teach about the technologies it mentions but to describe a recent experience and highlight my thought process on a specific topic. If you get curious about the topic, the most relevant links are in the Resources section at the end of this article.

Building knowledge

Some time ago, Jason Lengstorf did a show with Laurie Barth about Babel plugins. I liked that show a lot, and it led me to Nicolò Ribaudo's talk about Babel plugins.

I had a look at creating Babel plugins in the past but didn't get it well enough. These two resources cleared a lot of things for me!

Nicolò's talk led me to Kent C. Dodds's babel-plugin-macros, which "defines a standard interface for libraries that want to use compile-time code transformation".

I had seen the plugin before but didn't quite understand it.

Now, I had more knowledge about it so I had to apply this knowledge.

Applying knowledge

Context

super-expressive is a library to create Regular Expressions (RegExp) in almost natural language. It's useful, simple and well-documented. One downside it's that it's a runtime library, something else to add to our bundle.

I saw an issue on its repository asking if there was a way to generate the RegExp at build time - link here - and I thought: "A Babel macro, maybe?", but I didn't understand them well enough back then. When I learned more about Babel plugins as explained before, I remembered about this issue and decided to give it a try.

The process

Those videos gave me a base for the task but I needed more sources to achieve it, so I read a lot of source code for other libraries built with babel-plugin-macros, read the plugin's authoring documentation and Jamie Kyle's Babel Handbook.

After a couple of weeks of playing around with the idea and learning much more about Babel plugins in the process, I released super-expressive.macro - a macro to generate Regular Expressions (RegExp) at build-time with super-expressive.

It's far from perfect, I'm not 100% satisfied with it, but it's an actual result of the things I learned! For me, that's the best way to persist any knowledge: building something! This leads us to learn more than from the resources we consumed before. In my case, I went beyond those videos.

Extending knowledge

After releasing super-expressive.macro, I was thinking about where else I could apply this knowledge. To be honest, I'm not using the macro, I don't know if anyone will ever use it, so I wanted to apply the knowledge to something I use every day.

That's when I realised that to create ESLint rules, we use a similar approach to Babel plugins.

At Kindred Group, where I currently work, we have an internal ESLint config and there were a few custom rules we could create to help our teams in some cases. At that point, there was only documentation suggesting X or Y, nothing integrated into our workflow.

I decided to create these rules and learned even more in the process. Once again, I was reading the source code of ESLint plugins out there to get to the result I was aiming for and, fortunately, I did! We have a set of rules now our teams can benefit from every day. 🎉

I mentioned some of the plugins I went through in the #8 edition of my newsletter.

Reflecting on the journey

As I'm writing this, I don't have other places where to apply this knowledge. Maybe I'll move to the next thing to learn, maybe I'll have more ideas for macros or ESLint rules, I'll see.

Although this post highlights the happy path and results, of course, I had bumps along the way.

I thought about giving up on super-expressive.macro when I couldn't get anything to work with the things I learned from the videos. "No one needs this, why bother and waste my time?"

But I've learned over the years that persistence is very important - in and outside our job. Just step away from the problem for some time, return with a clear mind and give it another try.

It works every time! Plus:

"If you're learning, no time is wasted."
"Abandoning something before we learn anything doesn't do anyone any good. It actually makes things worse because we feel like quitters."
"Every new project furthers our discovery process."

The quotes above are from Jason's blog post about "wasting time". I read it while writing this post and it's a perfect fit for my reflection above. Give it a read.

Resources

Wrapping up

I hope you enjoyed this post and it's helped you in any way. It's very different from anything I've written before but I felt like I needed to write it.

Let me know your thoughts in the comments.

Subscribe to my newsletter and follow me for more.

How to debug postMessages

Arthur Denner — Tue, 23 Feb 2021 17:00:39 +0000

TL;DR



monitorEvents(window, 'message')
// or
window.addEventListener('message', console.log)

Concept

From the MDN docs:

The window.postMessage() method safely enables cross-origin communication between Window objects; e.g., between a page and a pop-up that it spawned, or between a page and an iframe embedded within it.

That's pretty cool, right?

Demo

Here is a demo of postMessage usage.

Debug

But how can we debug these messages?

Run the following in the Console tab:



// On Safari and Chromium-based browsers
monitorEvents(window, 'message')

// On Firefox
window.addEventListener('message', console.log)
// ^ It works in all the other browsers too

If you're testing in CodeSandbox, run the command in the Console of its detached window.

Result

After the setup, when receiving messages, you should see something like this:

That's it!

I hope you enjoyed this post and follow me on any platform for more.

#JavaScriptmas

Arthur Denner — Fri, 18 Dec 2020 10:55:13 +0000

I decided to participate in Scrimba's Advent Calendar this year.

I enjoyed it a lot and here are my solutions:

#1 - Candies
#2 - Deposit Profit
#3 - Chunky Monkey
#4 - Century from Year
#5 - Reverse a string
#6 - Sort by length
#7 - Count Vowel Consonant
#8 - The Rolling Dice
#9 - Sum Odd Fibonacci Numbers
#10 - Adjacent Elements Product
#11 - Avoid Obstacles
#12 - Valid Time
#13 - Extract Each Kth
#14 - Maximal Adjacent Difference
#15 - Carousel
#16 - Insert Dashes
#17 - Different Symbols Naive
#18 - Array Previous Less
#19 - Alphabet Subsequence
#20 - Domain Type
#21 - Sum of Two
#22 - Extract Matrix Column
#23 - Tweet Input Component
#24 - Test Your Agility

I hope you enjoy my solutions! Any feedback is appreciated.

Save data from push notifications to SQLite

Arthur Denner — Tue, 01 Sep 2020 14:20:29 +0000

Introduction

In this tutorial, you'll learn how to create a background service using Kotlin to listen to push notifications even when the app is closed, handle them and save them to SQLite.

Even though the context is a Flutter app, this is applicable to native development as you'll have to write native Android code anyway.

Jump to the final code or keep reading for a detailed walkthrough.

Context

In a recent personal project (Notificador LTV), I had to add push notification capabilities to the Flutter app. I used OneSignal for it and the integration was really easy.

One requirement was to save the received notification in the SQLite database. Implement everything in Flutter was straightforward using sqflite, however another requirement was that this behavior should also happen when the user has closed the app completely. For that, I needed to implement a background service on Android.

OneSignal provides the NotificationExtenderService class that you can extend to add such functionality so you only need to deal with the SQLite code.

Setup

Listen to push notifications

The first step is to create a class that extends NotificationExtenderService. Create CustomNotificationExtender.kt under the folder android/app/src/main/kotlin/your/package/name, alongside with MainActivity.kt.

Add the following code to this file:

package your.package.name

import com.onesignal.NotificationExtenderService
import com.onesignal.OSNotificationReceivedResult

class CustomNotificationExtender : NotificationExtenderService() {
  protected override fun onNotificationProcessing(receivedResult: OSNotificationReceivedResult): Boolean {
    return false
  }
}

This class only listens to the background notifications and allows them to be displayed on the UI by returning false - check OneSignal's documentation about it.

Declare class in manifest

Add the following to your AndroidManifest.xml:

<service
   android:name=".CustomNotificationExtender" // change this if your class has another name
   android:permission="android.permission.BIND_JOB_SERVICE"
   android:exported="false">
   <intent-filter>
      <action android:name="com.onesignal.NotificationExtender" />
   </intent-filter>
</service>

Describe the database

In order to interact with SQLite, you need to describe the database and tables used. Create a helper class for it and for the sake of the example, the table will have only two columns: id and title.

Inside the same file you've created add the following code:

package your.package.name

import android.database.sqlite.SQLiteDatabase
import android.database.sqlite.SQLiteOpenHelper
import com.onesignal.NotificationExtenderService
import com.onesignal.OSNotificationReceivedResult

object MyData {
  const val TABLE_NAME = "mytable"
  const val COLUMN_NAME_ID = "id"
  const val COLUMN_NAME_TITLE = "title"
}

class MyDbHelper(context: Context) : SQLiteOpenHelper(context, DATABASE_NAME, null, DATABASE_VERSION) {
  private val CREATE_MY_TABLE =
    "CREATE TABLE ${MyData.TABLE_NAME} (" +
      "${MyData.COLUMN_NAME_ID} INTEGER PRIMARY AUTOINCREMENT," +
      "${MyData.COLUMN_NAME_TITLE} TEXT)"

  override fun onCreate(db: SQLiteDatabase) {
    db.execSQL(CREATE_MY_TABLE)
  }

  override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {
    onCreate(db)
  }

  companion object {
    const val DATABASE_VERSION = 1
    const val DATABASE_NAME = "my_database.db"
  }
}

class CustomNotificationExtender : NotificationExtenderService() {
  protected override fun onNotificationProcessing(receivedResult: OSNotificationReceivedResult): Boolean {
    return false
  }
}

Now you've created an object that describes some static values for table and columns name - it will be helpful later on - and an object that extends SQLite's OpenHelper that describes what it should do when connecting to the database - and versions it too.

Persist the notification data

Now you need to access the data received and persist it. Let's break it into a few steps:

Update imports
Access the data received
Check if the data should be persisted
Persist the data
Handle errors

Update imports

import android.content.ContentValues
import android.content.Context
import android.database.sqlite.SQLiteDatabase
import android.database.sqlite.SQLiteOpenHelper
import android.util.Log
import com.onesignal.NotificationExtenderService
import com.onesignal.OSNotificationReceivedResult

Access the data received

The receivedResult variable has the property payload of type OSNotificationPayload which can be used to get the notification message, additional data and more. It also has restoring and isAppInFocus which gives the state of the app.

In this example, we only want the title as the id is autogenerated when a record is inserted:

val title = receivedResult.payload.title

Check if the data should be persisted

Depending on how you're handling notifications on the Flutter code, you may not want to do anything in the native code. If that's the case, you can do something like:

if (receivedResult.isAppInFocus || receivedResult.restoring) {
  Log.i("ExtenderIgnored", "App is in focus or restoring")
  // `false` allows the notification to be displayed
  return false
}

You may want to run a query on SQLite before deciding if the data should be persisted - prevent two notifications with the same title in this example:

val context = getBaseContext()
val dbHelper = MyDbHelper(context)
val db = dbHelper.getWritableDatabase()
val cursor = db.query(MyData.TABLE_NAME, null, "title = ?", arrayOf(title), null, null, null, null)

// Don't persist data if another record has the same title
if (cursor.count > 0) {
  // `false` allows the notification to be displayed
  return false
}

Persist the data

You need a ContentValues object to persist data:

val values = ContentValues()
values.put(MyData.COLUMN_NAME_TITLE, title)

db.insert(MyData.TABLE_NAME, null, values)

// `false` allows the notification to be displayed
return false

Handle errors

Some of the code above can fail, therefore you should wrap it in a try/catch.

Final code

package your.package.name

import android.content.ContentValues
import android.content.Context
import android.database.sqlite.SQLiteDatabase
import android.database.sqlite.SQLiteOpenHelper
import android.util.Log
import com.onesignal.NotificationExtenderService
import com.onesignal.OSNotificationReceivedResult

object MyData {
  const val TABLE_NAME = "mytable"
  const val COLUMN_NAME_ID = "id"
  const val COLUMN_NAME_TITLE = "title"
}

class MyDbHelper(context: Context) : SQLiteOpenHelper(context, DATABASE_NAME, null, DATABASE_VERSION) {
  private val CREATE_MY_TABLE =
    "CREATE TABLE ${MyData.TABLE_NAME} (" +
      "${MyData.COLUMN_NAME_ID} INTEGER PRIMARY AUTOINCREMENT," +
      "${MyData.COLUMN_NAME_TITLE} TEXT)"

  override fun onCreate(db: SQLiteDatabase) {
    db.execSQL(CREATE_MY_TABLE)
  }

  override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {
    onCreate(db)
  }

  companion object {
    const val DATABASE_VERSION = 1
    const val DATABASE_NAME = "my_database.db"
  }
}

class CustomNotificationExtender : NotificationExtenderService() {
  protected override fun onNotificationProcessing(receivedResult: OSNotificationReceivedResult): Boolean {
    try {
      if (receivedResult.isAppInFocus || receivedResult.restoring) {
        Log.i("ExtenderIgnored", "App is in focus or restoring")
        return false
      }

      val title = receivedResult.payload.title

      val context = getBaseContext()
      val dbHelper = MyDbHelper(context)
      val db = dbHelper.getWritableDatabase()
      val cursor = db.query(MyData.TABLE_NAME, null, "title = ?", arrayOf(title), null, null, null, null)

      // Don't persist data if another record has the same title
      if (cursor.count > 0) {
        return false
      }

      val values = ContentValues()
      values.put(MyData.COLUMN_NAME_TITLE, title)

      db.insert(MyData.TABLE_NAME, null, values)

      return false
    } catch (e: Exception) {
      // Report it to an external service if you wish
      Log.e("NotificationExtenderServiceError", e.toString())
      return false
    }
  }
}

Notes

Check OneSignal's documentation for more details.

If you're using a different solution or have any suggestions to improve this example, share them in the comments.

As this was my first time writing native Android code, if I've done something wrong or not recommended, please let me know.

I haven't implemented the same behaviour on iOS so if you have resources to link on this topic, share them in the comments.

I hope you enjoyed this post and follow me on any platform for more.

Update Heroku environment variable after GitHub release

Arthur Denner — Fri, 17 Jul 2020 23:50:11 +0000

Context

If we are using GitHub releases as part of our release workflow, we can use GitHub Actions to accomplish many tasks, such as notifying services about the new release.

This is very helpful as we can use a single step on our workflow to keep all integrated services in sync.

In this tutorial, we'll update an environment variable on Heroku. A real-world scenario for this is an API built with Node.js that has an endpoint for its current version running or uses the version on error monitoring clients like Sentry's.

Services

Heroku

Heroku is a container-based cloud Platform as a Service (PaaS) that supports several programming languages. It enables simple application development and deployment and it's very beginner-friendly.

GitHub Actions

GitHub Actions enables automation of our software workflows. It's possible to run workflows with many triggers and perform many tasks from them.

There are thousands of actions available on the marketplace and built by the community that enables us to lint, format, test, build, deploy our projects... The use cases are endless.

Setup

Heroku

In order to communicate with Heroku, we need an auth token. Generate one by running heroku authorizations:create on the Heroku CLI or through the dashboard.

Secrets

We need to setup 2 GitHub secrets on our repo. Go to Settings > Secrets and create the following:

HEROKU_API_KEY: Heroku auth token created before;
HEROKU_APP_NAME: Name of the project created on Heroku.

Workflow

With all the setup finished, create a YAML file under .github/workflows, e.g. create-releases.yml with the following content:

name: Create releases
on:
  release:
    types: [published]
jobs:
  update-heroku-env-variable:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@master
      - name: Trim tag name
        run: echo '::set-env name=API_VERSION::${{ github.ref }}'
      - name: Update API_VERSION on Heroku
        run: heroku config:set API_VERSION=${API_VERSION##*/} -a ${{ secrets.HEROKU_APP_NAME }}
        env:
          HEROKU_API_KEY: ${{ secrets.HEROKU_API_KEY }}

And that's it! Now, every time we publish a new release on GitHub, the API_VERSION environment variable on Heroku will be updated accordingly.

Note: The "Trim tag name" step will modify the tag name from refs/tags/x.x.x to only x.x.x.

Check out an example repo here. Check out the Actions tab to see details of the workflow.

Notes

The example above only updates the environment variable when our GitHub release is published. However, it's possible to run workflows on other events of a release - see GitHub's documentation.

It's possible to run other Heroku commands through the workflow. Check out their CLI documentation for more commands or check out this post for details on an entire deployment workflow.

I hope you enjoyed this post and follow me on any platform for more.

Create Sentry releases after GitHub release

Arthur Denner — Fri, 10 Jul 2020 12:21:07 +0000

Context

If we are using GitHub releases as part of our release workflow, we can use GitHub Actions to accomplish many tasks, such as notifying services about the new release.

This is very helpful as we can use a single step on our workflow to keep all integrated services in sync.

In this tutorial, we'll notify an error monitoring service called Sentry and create a new release on it with the same version of our app. A real-world scenario for this is an API built with Node.js that uses the Sentry client to report errors.

Services

Sentry

Sentry is a service for error monitoring that helps discover, triage and prioritize errors in real-time.

It's a very helpful and powerful tool as we can receive e-mails on new and reoccurring errors. It's possible to integrate it with many different services and create releases to monitor in which version of our apps an error has happened.

GitHub Actions

GitHub Actions enables automation of our software workflows. It's possible to run workflows with many triggers and perform many tasks from them.

There are thousands of actions available on the marketplace and built by the community that enables us to lint, format, test, build, deploy our projects... The use cases are endless.

Setup

Sentry

In order to communicate with Sentry, we need an auth token. Generate one by going to Settings > Account > API > Auth Tokens > Create New Token. We need a token with org:read and project:releases scopes.

We also need to have the GitHub integration configured and the repository added to our account. Otherwise, the action will fail.

Secrets

We need to setup 3 GitHub secrets on our repo. Go to Settings > Secrets and create the following:

SENTRY_AUTH_TOKEN: Sentry auth token created before;
SENTRY_ORG: Name found on Settings > Organization Settings;
SENTRY_PROJECT: Name of the project created on Sentry.

Workflow

With all the setup finished, create a YAML file under .github/workflows, e.g. create-releases.yml with the following content:

name: Create releases
on:
  release:
    types: [published]
jobs:
  create-sentry-release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@master
      - name: Create a Sentry.io release
        uses: tclindner/sentry-releases-action@v1.2.0
        env:
          SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
          SENTRY_ORG: ${{ secrets.SENTRY_ORG }}
          SENTRY_PROJECT: ${{ secrets.SENTRY_PROJECT }}
        with:
          tagName: ${{ github.ref }}
          environment: <env>

And that's it! Now, every time we publish a new release on GitHub, a new release for the same version will be created on Sentry.

Note: environment is a required property that helps filtering issues - see Sentry's documentation. Example values are prod and qa.

Check out an example repo here. Check out the Actions tab to see details of the workflow.

Notes

The example above only creates a Sentry release when our GitHub release is published. However, it's possible to run workflows on other events of a release - see GitHub's documentation.

The tclindner/sentry-releases-action accepts other parameters in the with section. Other examples of parameters are available in the Action's documentation.

I hope you enjoyed this post and follow me on any platform for more.

Light and dark theme in Flutter with themeMode

Arthur Denner — Sat, 16 May 2020 09:59:59 +0000

Flutter has built-in support to light and dark themes.

The MaterialApp widget has a property called themeMode. If we specify the darkTheme and theme properties, we can use themeMode to control it. The property defaults to ThemeMode.system, which will use the correct theme based on the device's settings.

But what if we want to enable the user to change it and persist their change? We can use theme_mode_handler!

arthurdenner / theme_mode_handler

Flutter widget to change `themeMode` during runtime and persist it across restarts.

With this package, we can accomplish the task and have total control on where to persist the user's choice: SharedPreferences, Hive, Firebase... anywhere.

Usage

Create a class that implements the IThemeModeManager interface:



class MyManager implements IThemeModeManager {
  @override
  Future<String> loadThemeMode() async {
    // Load from wherever you want...
  }

  @override
  Future<bool> saveThemeMode(String value) async {
    // Save wherever you want...
  }
}

Import the ThemeModeHandler widget, wrap MaterialApp with it and pass an instance of the manager to it:



import 'package:theme_mode_handler/theme_mode_handler.dart';

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ThemeModeHandler(
      manager: MyManager(),
      builder: (ThemeMode themeMode) {
        return MaterialApp(
          themeMode: themeMode,
          darkTheme: ThemeData(
            brightness: Brightness.dark,
            // other properties...
          ),
          theme: ThemeData(
            brightness: Brightness.light,
            // other properties...
          ),
          home: MyHomePage(title: 'Flutter Demo Home Page'),
        );
      },
    );
  }
}

Change themeMode with:



ThemeModeHandler.of(context).saveThemeMode(value);

Get the current themeMode with:



ThemeModeHandler.of(context).themeMode;

Notes

The package allows us to set the default themeMode in case we want to force the light or dark theme by default;

Check out an example repo here.

If you're using a different solution or have any suggestions to improve this example, feel free to share it in the comments.

I hope you enjoyed this post and follow me on any platform for more.

Run checks for Flutter projects with GitLab CI

Arthur Denner — Fri, 08 May 2020 14:12:25 +0000

On a previous post, I demonstrated how to run checks during a git commit with Lefthook.

That workflow is good, however, it's very easy to bypass the checks with the --no-verify flag.

An improvement to that workflow is to run those checks on a pipeline to make sure that every merge request will be formatted and all tests are passing.

Let's see how to achieve this using GitLab CI.

Create the file .gitlab-ci.yml on the root directory;
Define the stage on the file:

image: cirrusci/flutter:stable

before_script:
  - flutter pub get

stages:
  - analyze-and-test

analyze-and-test:
  stage: analyze-and-test
  script:
    - flutter build aot
    - flutter analyze
    - flutter test
  only:
    - merge_requests

And that's it! Now, whenever you open and update a merge request, flutter build aot, flutter analyze and flutter test will run after Java and Flutter are installed in the pipeline. If any of the commands fail, the merge request will get a failed check. ❌

Bonus - Test Coverage report

Another improvement is to report code coverage on every merge request. The example below uses Codecov but there are other services for it too - although the usage will be probably different.

To integrate it, we need to generate a token in Codecov after linking our repository - see documentation - and add it as the CODECOV_TOKEN environment variable on GitLab through Settings > CI/CD > Variables - see documentation.

As the last step, we update the workflow with:

    - ... # same as before
    - flutter analyze
    - flutter test --coverage
    - bash <(curl -s https://codecov.io/bash)
  only:
    - merge_requests

Make sure the CODECOV_TOKEN environment variable is set.

Check out the Codecov documentation for more information.

Check out an example repo here.

Notes

The example runs only on merge requests but GitLab CI supports other triggers - see documentation;
The example uses the stable channel of Flutter but there are images for other channels and specific versions as well - see list and GitHub;
The example uses GitLab CI but the workflow can be achieved using other pipeline services too - TravisCI, CircleCI, etc.
- Example with GitHub Actions here.

If you're using a different solution or have any suggestions to improve this example, feel free to share it in the comments.

I hope you enjoyed this post and follow me on any platform for more.

Test behavior of widgets in Flutter

Arthur Denner — Mon, 27 Apr 2020 08:08:27 +0000

Our widget tests should give us confidence about how they respond to user interactions - its behavior.

Using the CustomButton widget from a previous post, we can test if it fires its onPressed callback when tapped on all platforms.

Testing the behavior

import 'package:flutter/cupertino.dart';
import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'path/to/CustomButton.dart';

void main() {
  Widget buildApp({VoidCallback onPressed}) {
    return MaterialApp(
      home: CustomButton(
        onPressed: onPressed,
      ),
    );
  }

  group('CustomButton >', () {
    group('behavior >', () {
      testWidgets(
        'calls onPressed when tapped on iOS',
        (tester) async {
          debugDefaultTargetPlatformOverride = TargetPlatform.iOS;

          final log = <int>[];
          final onPressed = () => log.add(0);

          await tester.pumpWidget(buildApp(onPressed: onPressed));
          await tester.tap(find.byType(CustomButton));
          expect(log.length, 1);
          await tester.tap(find.byType(CustomButton));
          await tester.tap(find.byType(CustomButton));
          expect(log.length, 3);

          debugDefaultTargetPlatformOverride = null; <-- this is required
        },
      );

      testWidgets(
        'calls onPressed when tapped on other platforms',
        (tester) async {
          final log = <int>[];
          final onPressed = () => log.add(0);

          await tester.pumpWidget(buildApp(onPressed: onPressed));
          await tester.tap(find.byType(CustomButton));
          expect(log.length, 1);
          await tester.tap(find.byType(CustomButton));
          await tester.tap(find.byType(CustomButton));
          expect(log.length, 3);
        },
      );
    });
  });
}

Using the same approach to override the platform, we can easily verify that our widget behaves properly on all platforms.

Now, if we change our implementation, our tests will assert if the behavior was maintained.

We can change from a CupertinoButton to a Container + GestureDetector on iOS and our tests will continue to pass because it's the same behavior:

Widget buildCupertinoWidget(BuildContext context) {
  return GestureDetector(
    onTap: onPressed,
    child: Container(
      child: Text('Click me'),
    ),
  );
}

But if we remove the GestureDetector, our tests will fail because the widget doesn't behave as before:

Widget buildCupertinoWidget(BuildContext context) {
  return Container(
    child: Text('Click me'),
  );
}

Notes

We must reset debugDefaultTargetPlatformOverride to null by the end of every test case, otherwise Flutter will throw an error;
The example here is a bit specific, but you should take the approach and apply to all your widgets.

If you're have any suggestions to improve this example, feel free to share it in the comments.

I hope you enjoyed this post and follow me on any platform for more.

Write and test platform-specific widgets in Flutter

Arthur Denner — Mon, 27 Apr 2020 08:08:13 +0000

With Flutter, it's possible to display a CupertinoButton on iOS and a RaisedButton on Android, giving an even more native looking to our apps.

Display a widget on a specific platform is a reasonable requirement and it can apply to other platforms that Flutter supports too - Fuchsia, Linux, macOS and Windows.

In this post, let's see the approach I use to achieve this requirement using a CustomButton widget as example.

Figuring out the platform

Although the Platform class from dart:io provide this information, it's not possible to mock it and our tests always run on Android so we can't test the widget on other platforms.

Alternatively, we can use Theme.of(context).platform, which returns a TargetPlatform and can be overwritten on tests with the debugDefaultTargetPlatformOverride property.

Writing the widget

A very simple implementation.

import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';

class CustomButton extends StatelessWidget {
  const CustomButton({
    Key key,
    this.onPressed,
  });

  final VoidCallback onPressed;

  Widget buildCupertinoWidget(BuildContext context) {
    return CupertinoButton(
      onPressed: onPressed,
      child: Text('Click me'),
    );
  }

  Widget buildMaterialWidget(BuildContext context) {
    return RaisedButton(
      onPressed: onPressed,
      child: Text('Click me'),
    );
  }

  Widget build(BuildContext context) {
    final _platform = Theme.of(context).platform;

    return _platform == TargetPlatform.iOS
        ? buildCupertinoWidget(context)
        : buildMaterialWidget(context);
  }
}

Testing the widget

import 'package:flutter/cupertino.dart';
import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'path/to/CustomButton.dart';

void main() {
  Widget buildApp({VoidCallback onPressed}) {
    return MaterialApp(
      home: CustomButton(
        onPressed: onPressed,
      ),
    );
  }

  group('CustomButton >', () {
    group('output >', () {
      testWidgets(
        'displays CupertinoButton on iOS',
        (tester) async {
          debugDefaultTargetPlatformOverride = TargetPlatform.iOS;
          await tester.pumpWidget(buildApp());
          expect(find.byType(CupertinoButton), findsOneWidget);
          debugDefaultTargetPlatformOverride = null; // <-- this is required
        },
      );

      testWidgets(
        'displays RaisedButton on other platforms',
        (tester) async {
          await tester.pumpWidget(buildApp());
          expect(find.byType(RaisedButton), findsOneWidget);
        },
      );
    });
  });
}

Abstracting the logic

One improvement to this approach is to create an abstract class that computes which method to call and extend your widget from it:

import 'package:flutter/material.dart';

abstract class PlatformWidget extends StatelessWidget {
  const PlatformWidget({Key key}) : super(key: key);

  Widget buildCupertinoWidget(BuildContext context);
  Widget buildMaterialWidget(BuildContext context);

  @override
  Widget build(BuildContext context) {
    final _platform = Theme.of(context).platform;

    return _platform == TargetPlatform.iOS
        ? buildCupertinoWidget(context)
        : buildMaterialWidget(context);
  }
}

and then:

class CustomButton extends PlatformWidget { ... }
// Remember to remove the `build` method

This way, if you add another method to a different platform, all widgets will be requested to override it.

Bonus - Test behavior to improve your tests

Better than test what the widget is displaying to each platform, we should assert the behavior is the same on all platforms. See how to do that in this post.

Notes

We must reset debugDefaultTargetPlatformOverride to null by the end of every test case, otherwise Flutter will throw an error.

If you're using a different solution or have any suggestions to improve this example, feel free to share it in the comments.

I hope you enjoyed this post and follow me on any platform for more.

DEV Community: Arthur Denner

Build an extendable in-browser devtools

Prepare the project

Create a couple of pages

Create the devtools

Make the tabs dynamic

Contextual tabs

Relevant notes

Closing thoughts

A more complete example

Further reading

How to implement a search shortcut (OpenSearch) on any website

What is OpenSearch?

Example

Implementation

Testing

Chrome and Safari

Firefox

Example

Wrapping up

References

A tale of knowledge building

Disclaimer

Building knowledge

Applying knowledge

Context

The process

Extending knowledge

Reflecting on the journey

Resources

Wrapping up

How to debug postMessages

TL;DR

Concept

Demo

Debug

Result

#JavaScriptmas

Save data from push notifications to SQLite

Introduction

Context

Setup

Listen to push notifications

Declare class in manifest

Describe the database

Persist the notification data

Update imports

Access the data received

Check if the data should be persisted

Persist the data

Handle errors

Final code

Notes

Update Heroku environment variable after GitHub release

Context

Services

Heroku

GitHub Actions

Setup

Heroku

Secrets

Workflow

Notes

Create Sentry releases after GitHub release

Context

Services

Sentry

GitHub Actions

Setup

Sentry

Secrets

Workflow

Notes

Light and dark theme in Flutter with themeMode

arthurdenner / theme_mode_handler

Flutter widget to change `themeMode` during runtime and persist it across restarts.

Usage

Notes

Run checks for Flutter projects with GitLab CI

Bonus - Test Coverage report