Get the most recent info and news about Spowdi on HackerNoon, where 10k+ technologists publish stories for 4M+ monthly readers.

SPOWDI - Solar Powered Water Distribution Spowdi ® - Invented for a greener tomorrow Spowdi is a solar powered water distribution system invented for the hundreds of millions small scale farms around the equator. Pumps well over 20,000 liters of water a normal sunny day without using any other energy source than the sun. The system is mobile and robust which allows the users to easily move and use the system wherever they want. The weight of the entire system is less than 15kg and it is designed to be carried by one person. The system is easily mounted and can be up-and-running in a few minutes.

Spowdi

spowdi

Moa uses the kind of biotechnology applied to human health in the critically important field of agricultureIt has been selected as a Top Innovator in the Smarter Climate Farmers Challenge run by UpLink,

Moa Technology wins World Economic Forum award for research tackling herbicide-resistant weeds that pose a global threat to food security

Welcome back to this series where we are learning how to integrate products into web application. AI Intro & Setup Your First AI Prompt Streaming Responses How Does AI Work Prompt Engineering AI-Generated Images Security & Reliability Deploying In this post, we are going to use AI to generate images. Before we get to that, let’s add a dialog component to our app. This is a modal-like pop-up designed to show content and be dismissed with the mouse or keyboard. https://www.youtube.com/watch?v=V3DjC6-sGBA&embedable=true Create A Dialog Component Before showing an image, we need a place to put it. I think it would be nice to have a dialog that pops up to showcase the image. This is a good opportunity to spend more time with Qwik components. By convention, our new component should go in the folder. I’ll call mine (or if you prefer TypeScript). A Qwik component file should have a default export of a Qwick component. ./src/components Dialog.jsx .tsx To create one, we use the function from . This function takes a function component that returns JSX: component$ @builder.io/qwik import { component$ } from "@builder.io/qwik";

export default component$((props) => {

  return (
    <div>
      
    </div>
  )
}) At the moment, it’s not very useful. Let’s plan out the API design for this dialog. It should have the following characteristics: Opened by clicking on a button. Can be opened programmatically from the parent. Closed by pressing the Esc key. Closed by clicking the dialog background. Can be closed programmatically from the parent. has a element which is great, but it doesn’t quite offer the API that I’m looking for. With a little bit of work, we can fill in the gaps. HTML <dialog> Let’s start with a component that provides a element for controlling the dialog and the element that will contain any content you put inside. Clicking the button should trigger the method. Clicking outside the dialog should trigger the method. <button> <dialog> dialog.showModal() dialog.close() Pressing the Esc key closes the dialog already, so that’s sorted. To trigger the dialog methods, we need access to the DOM node, which we can get by . In our dialog component, we can add content using a , a flexible space inside the dialog where you can put content. using a ref and a signal <Slot> We should also provide a btnText prop to allow for customization of the text on the button that opens the dialogue. Here’s what I have so far: import { component$, useSignal, Slot } from "@builder.io/qwik";

export default component$(({ btnText }) => {
  const dialogRef = useSignal()

  return (
    <div>
      <button onClick$={() => dialogRef.value.showModal()}>
        {btnText}
      </button>

      <dialog
        ref={dialogRef}
        onClick$={(event) => {
          if (event.target.localName !== 'dialog') return
          dialogRef.value.close()
        }}
      >
        <div class="p-2">
          <Slot></Slot>
        </div>
      </dialog>
    </div>
  )
}) Note the additional inside the . This lets me add some padding, but more importantly, it helps me track whether a click on the dialog happened in the background (the dialog element) or on the content (the div and children). This lets us close the dialog only when the background is clicked. <div> <dialog> That gets us some basic functionality, but for my use case, I want to be able to programmatically open the dialog from the parent, not just when the toggle button is clicked. For that, we need a small refactor. To control the dialog from a parent, we need to add a new prop and trigger the dialog methods as it changes. Rather than repeat the open/close functionality for internal external changes, let’s create a local state with to track whether the dialog should be shown or not. and useStore() Then, we can simply toggle the state and respond to those changes using a (it’s like in React). If the prop from the parent changes, we need to respond to that change using another task, but this time, we’ll use . Qwik task useEffect open useVisibleTask$() We also need to provide a way for the parent component to be aware of changes to the dialog’s visibility. We can do that by providing a custom prop that will call the function whenever the dialog closes. And lastly, if we’re providing programmatic control from the parent, we may want to provide a way to hide the . onClose$ <button> import { component$, useSignal, Slot, useStore, useTask$, useVisibleTask$ } from "@builder.io/qwik";

export default component$(({ btnText, open, onClose$ }) => {
  const dialogRef = useSignal()
  const state = useStore({
    isOpen: false,
  })

  useTask$(({ track }) => {
    track(() => state.isOpen)

    const dialog = dialogRef.value
    if (!dialog) return

    if (state.isOpen) {
      dialog.showModal()
    } else {
      dialog.close()
      onClose$ && onClose$()
    }
  })
  useVisibleTask$(({ track }) => {
    track(() => open)
    state.isOpen = open || false
  })

  return (
    <div>
      {btnText && (
        <button onClick$={() => state.isOpen = true}>
          {btnText}
        </button>
      )}

      <dialog
        ref={dialogRef}
        onClick$={(event) => {
          if (event.target.localName !== 'dialog') return
          state.isOpen = false
        }}
      >
        <div class="p-2">
          <Slot></Slot>
        </div>
      </dialog>
    </div>
  )
}) This is a lot better, but there’s still a little work to do. I like to make sure my components are and typed. In this case, since we’re using a button to control the visibility of the dialog, it makes sense to add and attributes to the button. accessible aria-controls aria-expanded To connect them to the dialog, the dialog needs an ID, which we can either take from the props or dynamically generate. Lastly, pressing escape will close the dialog, but we also need to track the dialog’s native event by attaching an handler. "close" onClose$ Here is my finished component, including : JSDoc type definitions import {component$, useSignal, Slot, useStore, useTask$, useVisibleTask$ } from "@builder.io/qwik";
import { randomString } from "~/utils.js";

/**
 * @typedef {HTMLAttributes<HTMLDialogElement>} DialogAttributes
 *
 * @type {Component<DialogAttributes  & {
 * toggle: string|false,
 * open?: Boolean,
 * onClose$?: import('@builder.io/qwik').PropFunction<() => any>
 * }>}
 */
export default component$(({ toggle, open, onClose$, ...props }) => {
  const id = props.id || randomString(8)

  const dialogRef = useSignal()
  const state = useStore({
    isOpen: false,
  })

  useTask$(({ track }) => {
    track(() => state.isOpen)

    const dialog = dialogRef.value
    if (!dialog) return

    if (state.isOpen) {
      dialog.showModal()
    } else {
      dialog.close()
      onClose$ && onClose$()
    }
  })
  useVisibleTask$(({ track }) => {
    track(() => open)
    state.isOpen = open || false
  })

  return (
    <div>
      {toggle && (
        <button aria-controls={id} aria-expanded={state.isOpen} onClick$={() => state.isOpen = true}>
          {toggle}
        </button>
      )}

      <dialog
        ref={dialogRef}
        id={id}
        onClick$={(event) => {
          if (event.target.localName !== 'dialog') return
          state.isOpen = false
        }}
        onClose$={() => state.isOpen = false}
        {...props}
      >
        <div class="p-2">
          <Slot></Slot>
        </div>
      </dialog>
    </div>
  )
}) Cool! Now that we have a working dialog component, we need to put something in it. Generate AI Images With OpenAI Once the AI has determined a winner between opponent1 and opponent2, it would be cool to offer an image of them in combat. So why not add a button that says “Show me” after the results are available? After the text in the template, we could add a conditional like this: {state.winner && (
  <button>
    Show me
  </button>
)} Awesome! It’s just too bad it doesn’t do anything… To actually generate the AI image, we need to make another API request to OpenAI which means we need another API endpoint in our backend. We’ve already assigned a request handler to the current route. Let’s add a new route to handle GET requests to by adding a new file in . /ai-image /src/routes/ai-image/index.js In many cases, a new route may need to return HTML from the server to generate a page. That’s not the case for this route. This will only ever return JSON, so it doesn’t need to be a JSX file or return a component. Instead, we can export a custom like we did for post requests on the first page. To do that, we create a named export called that can look something like this: middleware onGet export const onGet = async (requestEvent) => {
  requestEvent.send(200, JSON.stringify({ some: 'data' }))
} Now, to get the route working, we need to do the following: Grab opponent1 and opponent2 from the request (we’ll use query parameters). Use the opponents to construct a prompt using LangChain templates. Create a body for the OpenAI API request containing the prompt and the image size we want (I’ll use ). "512x512" Create the authenticated HTTP request to OpenAI. Respond to the initial request with the URL of the generated image. For more details on working with images through OpenAI, refer to their . documentation Here’s how my implementation looks: import { PromptTemplate } from 'langchain/prompts'

const mods = [
  'cinematic',
  'high resolution',
  'epic',
];

const promptTemplate = new PromptTemplate({
  template: `{opponent1} and {opponent2} in a battle to the death, ${mods.join(', ')}`,
  inputVariables: ['opponent1', 'opponent2']
})

/** @type {import('@builder.io/qwik-city').RequestHandler} */
export const onGet = async (requestEvent) => {
  const OPENAI_API_KEY = requestEvent.env.get('OPENAI_API_KEY')

  const opponent1 = requestEvent.query.get('opponent1')
  const opponent2 = requestEvent.query.get('opponent2')

  const prompt = await promptTemplate.format({
    opponent1: opponent1,
    opponent2: opponent2
  })

  const body = {
    prompt: prompt,
    size: '512x512',
  }

  const response = await fetch('https://api.openai.com/v1/images/generations', {
    method: 'post',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${OPENAI_API_KEY}`,
    },
    body: JSON.stringify(body)
  })
  const results = await response.json()

  requestEvent.send(200, JSON.stringify(results.data[0]))
} It’s worth noting that the response from OpenAI should look something like this: {
  "created": 1589478378,
  "data": [
    {
      "url": "https://..."
    },
    {
      "url": "https://..."
    },
  ]
} Also worth mentioning is the lack of validation for the opponents. It’s always a good idea to validate user input before processing it. Why don’t you try addressing that as an additional challenge? Provide AI Images With Art Direction In the code example above, you may have noticed the array that gets joined and appended to the end of the prompt. This is worth a callout. mods Generative images are tricky because the same prompt can return drastically different results. You might get a cartoon, an oil painting, or a sketch. So, it’s important to include a couple of hints to the AI to match the aesthetic of your application. I found that using an array with several different options allowed me to easily toggle off various features. In fact, in my actual project, I keep a much longer list of options, organized by style, format, quality, and effect. const mods = [
  /** Style */
  // 'Abstract',
  // 'Academic',
  // 'Action painting',
  // 'Aesthetic',
  // 'Angular',
  // 'Automatism',
  // 'Avant-garde',
  // 'Baroque',
  // 'Bauhaus',
  // 'Contemporary',
  // 'Cubism',
  // 'Cyberpunk',
  // 'Digital art',
  // 'photo',
  // 'vector art',
  // 'Expressionism',
  // 'Fantasy',
  // 'Impressionism',
  // 'kiyo-e',
  // 'Medieval',
  // 'Minimal',
  // 'Modern',
  // 'Pixel art',
  // 'Realism',
  // 'sci-fi',
  // 'Surrealism',
  // 'synthwave',
  // '3d-model',
  // 'analog-film',
  // 'anime',
  // 'comic-book',
  // 'enhance',
  // 'fantasy-art',
  // 'isometric',
  // 'line-art',
  // 'low-poly',
  // 'modeling-compound',
  // 'origami',
  // 'photographic',
  // 'tile-texture',

  /** Format */
  // '3D render',
  // 'Blender Model',
  // 'CGI rendering',
  'cinematic',
  // 'Detailed render',
  // 'oil painting',
  // 'unreal engine 5',
  // 'watercolor',
  // 'cartoon',
  // 'anime',
  // 'colored pencil',

  /** Quality */
  'high resolution',
  // 'high-detail',
  // 'low-poly',
  // 'photographic',
  // 'photorealistic',
  // 'realistic',

  /** Effects */
  // 'Beautiful lighting',
  // 'Cinematic lighting',
  // 'Dramatic',
  // 'dramatic lighting',
  // 'Dynamic lighting',
  'epic',
  // 'Portrait lighting',
  // 'Volumetric lighting',
]; I’ve also found that it’s better to include these modifiers at the end of the prompt, otherwise, they can be forgotten. Request an AI-Generated Image Now that our endpoint is ready, we can start using it. We need to send an HTTP request with query parameters including opponent1 and opponent2. We can pull those values from the s on demand, but I prefer to maintain some reactive state that gets updated any time a user types into the s. <textarea> <textarea> Let’s modify our to include properties for opponent1 and opponent2: state const state = useStore({
  isLoading: false,
  text: '',
  winner: '',
  opponent1: '',
  opponent2: '',
}) Next, let’s add an event handler that will update the state. The event handler should probably also clear any previous text results and winners. Note that we need to do this for both inputs. onInput$ <Input
  label="Opponent 1"
  name="opponent1"
  value={state.opponent1}
  class={{
    rainbow: state.winner === 'opponent1'
  }}
  onInput$={(event) => {
    state.winner = ''
    state.text = ''
    state.opponent1 = event.target.value
  }}
/> Now that we have the values conveniently available, we can construct the HTTP request. We could do this when the “Show me” button is clicked, but we already made the function in . Might as well reuse it. All it needs is a with the data to send. jsFormSubmit the third post of the series <form> Let’s create a form that submits to our route, prevents the default behavior, and submits the data with instead. We can use hidden inputs to put the data in the form without impacting the UI. /ai-image jsFormSubmit {state.winner && (
  <form
    action="/ai-image"
    preventdefault:submit
    onSubmit$={async (event) => {
      const form = event.target
      console.log(await jsFormSubmit(form))
    }}
    class="mt-4"
  >
    <input
      type="hidden"
      name="opponent1"
      value={state.opponent1}
      required
    />
    <input
      type="hidden"
      name="opponent2"
      value={state.opponent2}
      required
    />
    <button type="submit">
      Show me
    </button>
  </form>
)} It looks the same as it did before, but now, it actually does something. I would show you a screenshot, but it’s pretty much just a button. Unremarkable, but effective. Show the Image in the Dialog The last step is to put it all together. The user submits the two opponents, and the AI returns a winner. The image generation will be available, showing the user the “Show me” button. <form> When the user clicks the button, the API request gets submitted. At the same time, we’ll programmatically open the dialog with some initial loading state. When the request returns, we’ll display the image. For that, I’ll create a new store for the image state using . It’ll hold a state, an state, and the . I’m also going to move the form’s submit handler into a dedicated function called so it’s not nested in the template and all the logic can live together. useStore showDialog isLoading url onSubmitImg The body of the function will activate the dialog, set the loading state, submit the form with , set the image URL from the results, and disable the loading state. obSubmitImg jsFormSubmit const imgState = useStore({
  showDialog: false,
  isLoading: false,
  url: ''
})
const onSubmitImg = $(async (event) => {
  imgState.showDialog = true
  imgState.isLoading = true

  const form = event.target

  const response = await jsFormSubmit(form)
  const results = await response.json()

  imgState.url = results.url
  imgState.isLoading = false
}) Man, I love that function! It lets the HTML provide the declarative HTTP logic and simplifies the business logic. jsFormSubmit Ok – with the state setup, the last thing to do is connect the component. Since we’ll be opening it programmatically, we don’t need the built-in button. We can disable that by making the prop falsy. We can connect the prop to . We’ll also want to update that state when the dialog closes via the event. <Dialog> btnText open imgState.showDialog onClose$ And the contents of the dialog should either show something for the loading state or show the generated image. <Dialog
  btnText={false}
  open={imgState.showDialog}
  onClose$={() => imgState.showDialog = false}
>
  {imgState.isLoading && (
    "Working on it..."
  )}
  {!imgState.isLoading && imgState.url && (
    <img src={imgState.url} alt={`An epic battle between ${state.opponent1} and ${state.opponent2}`} />
  )}
</Dialog> Unfortunately, we now have a button that programmatically opens a dialog element without accessibility considerations. I thought about including the same ARIA attributes as we have on the toggle, but if I’m honest, I’m not sure if a submit button control a dialog. should In this case, I’m leaving it out because I don’t know the right approach, and sometimes doing accessibility wrong leads to a worse experience than doing nothing at all. Open to suggestions. :) Closing Okay, I think that’s as far as we’ll get today. It’s time to stop and enjoy the fruits of our labor. Okay, OpenAI isn’t the best AI image generator, or maybe my prompt skills need some work. I’d love to see how yours turned out. A lot of the things we covered today were a review: building Qwik components, making HTTP requests to OpenAI, state, and conditional rendering in the template. The biggest difference, I think, is how we treat prompts for AI images. I find they require a little more creative thinking and finagling to get right. Hopefully, you found this helpful. In the video version, we covered a really cool SVG component that I think is worth checking out, but this post was already long enough. Functionally, the app is as far as I want to take it, so In the next post, we’ll focus on reliability and security before we get into launching to production. Intro & Setup Your First AI Prompt Streaming Responses How Does AI Work Prompt Engineering AI-Generated Images Security & Reliability Deploying Thank you so much for reading. If you liked this article, and want to support me, the best ways to do so are to , , and . share it sign up for my newsletter follow me on Twitter Originally published on . austingil.com

AI for Web Devs: How to Generate Images Using AI

Introduction: In many collaborative environments, managing access to specific data in Google Sheets is critical for maintaining data accuracy and privacy. This article demonstrates how to create a system where users can edit specific cells only after providing their details. We'll achieve this using Google Apps Script, a powerful automation tool for Google Sheets. Setting Up the Google Sheet: To get started, create a Google Sheet, and structure it to include user details. For this example, we'll use columns for "Name," "Email," and "Details." The "Details" column will be used to indicate whether users have provided their details. The Role of Google Apps Script: Google Apps Script is at the heart of our solution. This scripting tool allows us to automate tasks in Google Sheets. In this case, it will help control cell access and track user edits. We'll begin by creating a script that checks if users have provided their details. This script will grant edit access to specific cells once a user's details are confirmed. Script to Manage Cell Access: function onEdit(e) {
  var sheet = e.source.getSheetByName("YourSheetName");
  var editedRange = e.range;
  var username = Session.getActiveUser().getEmail();
  var timestamp = new Date();

  // Check if user's details are in place.
  var detailsRange = sheet.getRange("B2:B10"); // Adjust to your specific details range.
  var userRowIndex = detailsRange.createTextFinder(username).findNext().getRow();

  if (userRowIndex > 0) {
    // Grant edit access to specific cells (e.g., columns C and D).
    var editRange = sheet.getRange(userRowIndex, 3, 1, 2);
    var protection = editRange.protect();
    protection.removeEditors(protection.getEditors());
    protection.addEditor(username);
  }
} This script, when triggered by an edit event, checks if a user's details are in the "Details" column. If found, it grants edit access to specific cells (e.g., columns C and D). Users can edit only after their details are confirmed. Making a Special Google Sheet With a "Lock Cells" Button Imagine you have a special Google Sheet where you want to let people fill in some information, but only after they tell us who they are. This article will show you how to do it, and we'll even add a "Lock Cells" button to make it easier! Step 1: Create Your Google Sheet First, open Google Sheets. Click on extensions Make a new sheet, and add some columns for names, emails, and other stuff. Step 2: Use a Magic Script (Google Apps Script) Google Apps Script is like magic for your Google Sheet. It can do things for you automatically. Here's a special script we'll use. It checks if someone has shared their name and email. THE NAME OF THE SHEET MUST MATCH WITH THE “YourSheetName“ IN THE CODE function onEdit(e) {
  var sheet = e.source.getSheetByName("YourSheetName");
  var editedRange = e.range;
  var username = Session.getActiveUser().getEmail();
  var timestamp = new Date();

  // Check if someone shared their details.
  var detailsRange = sheet.getRange("B2:B10");
  var userRowIndex = detailsRange.createTextFinder(username).findNext().getRow();

  if (userRowIndex > 0) {
    // Let them edit special cells (e.g., columns C and D).
    var editRange = sheet.getRange(userRowIndex, 3, 1, 2);
    var protection = editRange.protect();
    protection.removeEditors(protection.getEditors());
    protection.addEditor(username);
  }
} Step 3: Add a "Lock Cells" Button We'll make it even easier. Let's add a "Lock Cells" button to your Google Sheet. So, when someone wants to lock their cells, they just need to click the button. function onOpen() {
  var ui = SpreadsheetApp.getUi();
  ui.createMenu('Lock Cells Menu')
    .addItem('Lock Your Cells', 'lockYourCells')
    .addToUi();
}

function lockYourCells() {
  // This is where we lock the cells when someone clicks the button.
  // They can only click it after sharing their details.
} Here is the complete code if you do not want to create two separate codes. Save the script, and click on “Run.“ The system will give you the prompt below. The complete code: function onOpen() {
  var ui = SpreadsheetApp.getUi();
  var currentUserEmail = Session.getActiveUser().getEmail();
  
  if (currentUserEmail === "admin@example.com") {
    ui.createMenu('Lock Menu')
      .addItem('Lock Cells', 'showDialog')
      .addToUi();
  }
}

function showDialog() {
  var ui = SpreadsheetApp.getUi();
  var result = ui.prompt(
    'Lock Cells',
    'Enter the cell range to lock (e.g., A1:A10):',
    ui.ButtonSet.OK_CANCEL
  );

  if (result.getSelectedButton() == ui.Button.OK) {
    var rangeToLock = result.getResponseText();
    lockCells(rangeToLock);
  }
}

function lockCells(rangeToLock) {
  var spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
  var activeSheet = spreadsheet.getActiveSheet();

  // Lock the specified cell range.
  var protection = activeSheet.getRange(rangeToLock).protect();
  protection.removeEditors(protection.getEditors());
  protection.addEditor(Session.getActiveUser());

  // Apply a background color to indicate locked cells.
  var lockedColor = '#e6e6e6'; // Light gray color.
  var range = activeSheet.getRange(rangeToLock);
  range.setBackground(lockedColor);
  
  // Create a time-based trigger to unlock the cells after 3 minutes.
  ScriptApp.newTrigger("unlockCells")
    .timeBased()
    .after(3 * 60 * 1000)  // 3 minutes in milliseconds
    .create();
}

function unlockCells() {
  var spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
  var activeSheet = spreadsheet.getActiveSheet();
  
  // Define the range of cells to unlock, matching the locked range.
  var rangeToUnlock = "A1:A10";  // Adjust this to your specific range.

  // Remove the protection and clear the background color.
  var protection = activeSheet.getRange(rangeToUnlock).protect();
  protection.remove();
  activeSheet.getRange(rangeToUnlock).setBackground('');
} In this script: The admin can click "Lock Cells" to lock the specified cells and apply the background color. After locking, a time-based trigger is created to run the function after 3 minutes. unlockCells Set the background color after effectively unlocking the cells. Only the admin/you will see the LOCK MENU Replace "admin@example.com" With the Actual Admin's Email Address in the Code. Step 4: Make a Schedule You want the cells to lock themselves at a certain time, like bedtime. We'll use a special clock (time-driven trigger) to do that. Leave it as “Head.“ Step 5: Share the Sheet Now, you can share your Google Sheet with your friends or team members. They can use the "Lock Cells" button to lock their cells. Conclusion: With this magic system and the "Lock Cells" button, you can control who gets to edit your Google Sheet. It's like inviting friends to your party, but they need to tell you their names before they can play with your toys. I would be glad to help if you need any assistance.

How to Create a Custom Lock Menu in Google Sheets - The Magic of Automation

Nowadays, Jetpack Compose gains an adoption and it definitely deserves it. It is a real paradigm shift in UI development. So much creating lists boilerplate was eliminated there. And it’s beautiful. Android I believe that many projects are still using the View framework and therefore using RecyclerView for having lists. There are a few reasons for it, as I see: Some in-house proprietary solutions around RecyclerView doesn’t match with Compose easily, so migration costs are high Developers are not familiar enough with Compose yet There is no confidence about performance of Compose (yet) But anyway, Compose is the future and this is why I’m using the word “vintage” in a title. Vintage means old but gold. This article is the result of a compilation of my experience with RecyclerView, and for those who are still on track with it, I’ll tell about my vision to building a framework around RecyclerView. Requirements The framework should provide a sane level of scalability. So the main scenarios should be handled with a minimum amount of boilerplate, but it shouldn’t get in the way if the user wants to create something custom. I would define the base set of scenarios during work with RecyclerView as next: Effective update of data. It is known best practice during working with RecyclerView is using API for updating a data in list. We are not going to re-invent a wheel here, so we’ll focus on leveraging and also will try to reduce a ceremony for its implementation. DiffUtil DiffUtil Defining heterogeneous lists. It is natural to have several types of views in a list. Screens of mobile devices are constrained by height and different devices has different screen sizes. So even your content is fitting to screen at one device without scrolling, it could require to be scrolled at another device. That’s why it can be a good idea to develop some screens on the top of RecyclerView. Decorating list items Decorations are a very common case for lists. And although you can have decorations merged to items layouts, what is can look straightforward, it’s not very flexible: same items types can require different decorations at different screens or even different decorations depending on item position in a list. Foundation options The first option is to make everything from scratch. It’s giving full control over implementation, but we can always do it. There are a bunch of third party open-source frameworks that allowing to work with RecyclerView with less boilerplate. I’m not going to enumerate all, but want to show two of them with completely opposite approaches: Epoxy Solution from AirBnb for creating complex screens with RecyclerView. It is adding a bunch of new APIs and even a code generation to reduce a boilerplate as much as possible. But I can't get rid of the feeling that resulting code is looking foreign. Also, an annotation processing adding another layer of complexity. AdapterDelegates Tiny library, that actually provides a concise bunch of functions and interfaces that only suggest you a way to split your heterogeneous list to set of delegated adapters. In fact, you can create such own solution in relatively short time. I like small native solutions that simple enough to keep all the behavior at fingertips and that doesn’t hide under carpet all the implementation details. That’s why I believe that AdapterDelagates and its principles are a good candidate for the foundation of our framework. List items The very basic thing for the beginning is a common declaration of list items. List items in the real world are very different, but the only thing we are confident in – we should be able to compare it. I suggest to referring to API of DiffUtil.ItemCallback interface ListItem {

 fun isItemTheSame(other: ListItem): Boolean

 fun isContentTheSame(other: ListItem): Boolean {
   return this == other
 }
} It is a minimalistic (and therefore solid, IMO) declaration of a list item in the framework. Semantic of methods is intended to be the same as a DiffUtil using: checks identity of and isItemTheSame other this checks the data in and isContentTheSame other this The most common way to provide a stable and unique identity is using identifiers that came from the server. So let’s have an abstract implementation to reduce a bit of possible boilerplate: abstract class DefaultListItem : ListItem {

 abstract val id: String

 override fun isItemTheSame(other: ListItem): Boolean = when {
   other !is DefaultListItem -> false
   this::class != other::class -> false
   else -> this.id == other.id
 }
} in the vast majority of cases will be quite simple (an equality check), if implementations of ListItem will be a . isContentTheSame data class Keeping separate is still reasonable in cases when you have items in your list that are not projection of server data and haven't any sane identity. For example, if you have a footer and header as items in a list, or you have a single item of some type: ListItem data class HeaderItem(val title: String) : ListItem {

 override fun isItemTheSame(other: ListItem): Boolean = other is HeaderItem
} Suggested approach allows us to have a very natural and single callback implementation: DiffUtil object DefaultDiffUtil : DiffUtil.ItemCallback<ListItem>() {

 override fun areItemsTheSame(oldItem: ListItem, newItem: ListItem): Boolean = 
    oldItem.isItemTheSame(newItem)

 override fun areContentsTheSame(oldItem: ListItem, newItem: ListItem): Boolean = 
    oldItem.isContentTheSame(newItem)
} And the final step here is a declaration of default adapter that extends from AdapterDelegates: AsyncListDifferDelegationAdapter class CompositeListAdapter :
AsyncListDifferDelegationAdapter<ListItem>(DefaultDiffUtil) Heterogeneous lists AdapterDelegates library provides a handy way to declare delegates for a particular view type. Only thing we can improve is reduce a boilerplate a bit: inline fun <reified I : ListItem, V : ViewBinding> defaultAdapterDelegate(
 noinline viewBinding: (layoutInflater: LayoutInflater, parent: ViewGroup) -> V,
 noinline block: AdapterDelegateViewBindingViewHolder<I, V>.() -> Unit
) = adapterDelegateViewBinding<I, ListItem, V>(viewBinding = viewBinding, block = block) For showcase purposes, let’s consider an example how would declaration of some , containing one text field could look like: TitleListItem data class TitleListItem(
 override val id: String,
 val title: String,
) : DefaultListItem() and delegate for it fun titleItemDelegate(onClick: ((String) -> Unit)) = 
  defaultAdapterDelegate<
    TitleListItem,
    TitleListItemBinding
  >(viewBinding = { inflater, root -> TitleListItemBinding.inflate(inflater,root,false) }) {
    itemView.setOnClickListener { it(item.id) } 
    bind {
      binding.root.text = item.title
    }
  }
} Decorated lists Originally, because of the API of , setting decorations are made separately from setting data to list. If you have some logic for decorations like: , or than creating decoration becomes a pain. RecyclerView all items should have offset at the bottom except the last one all items should have a divider at the bottom, but headers should have an offset at bottom Often teams coming with “god” decorator that can be configured: class SmartDividerItemDecorator(
 val context: Context,
 val skipDividerFor: Set<Int> = emptySet(),
 val showDividerAfterLastItem: Boolean = false,
 val showDividerBeforeFirstItem: Boolean = false,
 val dividerClipToPadding: Boolean = true,
 val dividerPaddingLeft: Int = 0,
 val dividerPaddingRight: Int = 0
) : ItemDecoration() You can only imagine implementation details and how fragile and not scalable it is. We can use an old proven approach with mimicry to some API and delegating an implementation. RecyclerView So I’m starting with a data: interface Decoration Interface marker for decorations, that will be presented in the future. interface HasDecorations {
 var decorations: List<Decoration>
} This interface should be implemented by our data items to declare that this particular item wants to be decorated with a given list of decorations. Decorations are in sake of simplicity to change it in runtime, if needed. var Very often an item has a single decoration, so to reduce boilerplate with wrapping a single item to we can do such maneuver: listOf() interface HasDecoration : HasDecorations {
 var decoration: Decoration

 override var decorations: List<Decoration>
   get() = listOf(decoration)
   set(value) {
     decoration = when {
       value.isEmpty() -> None
       value.size == 1 -> value.first()
       else -> throw IllegalArgumentException("Applying few decorations to HasDecoration instance is prohibited. Use HasDecorations")
     }
   }
} Next stage is mimic to API: ItemDecoration interface DecorationDrawer<T : Decoration> {

 fun getItemOffsets(
   outRect: Rect,
   view: View,
   parent: RecyclerView,
   state: RecyclerView.State,
   decoration: T
 )

 fun onDraw(
   c: Canvas,
   view: View,
   parent: RecyclerView,
   state: RecyclerView.State,
   decoration: T
 )
} As you can see, it completely repeats with a single difference – now it’s aware of the decoration type and instance is coming. ItemDecoration Possible implementations for is a topic of the second article, now let’s focus only on interface and how it should be handled to presenting decorations. DecorationDrawer class CompositeItemDecoration(
 private val context: Context
) : RecyclerView.ItemDecoration() {

 private val drawers = mutableMapOf<Class<Decoration>, DecorationDrawer<Decoration>>() // [1]

 private fun applyDecorationToView(parent: RecyclerView, view: View, applyDecoration: (Decoration) -> Unit) {

   val position = getAdapterPositionForView(parent, view) // [2]

   when { // [3]
     position == RecyclerView.NO_POSITION -> return
     adapter.items[position] is HasDecorations -> {
       val decoration = (adapter.items[position] as HasDecorations).decorations
       decoration.forEach(applyDecoration)
     }

     else -> return
   }
 }

 override fun getItemOffsets(
   outRect: Rect,
   view: View,
   parent: RecyclerView,
   state: RecyclerView.State
 ) {
   applyDecorationToView(parent, view) { decoration ->
     val drawer = getDrawerFor(decoration)
     drawer.getItemOffsets(outRect, view, parent, state, decoration)
   }
 }

 override fun onDraw(c: Canvas, parent: RecyclerView, state: RecyclerView.State) {
   parent.forEach { child ->
     applyDecorationToView(parent, child) { decoration ->
       val drawer = getDrawerFor(decoration)
       drawer.onDraw(c, child, parent, state, decoration)
     }
   }
 }

 private fun getDrawerFor(decoration: Decoration): DecorationDrawer<Decoration> {
 // [4]
}


 private fun getAdapterPositionForView(parent: RecyclerView, view: View): Int {
   var position = parent.getChildAdapterPosition(view)
   if (position == RecyclerView.NO_POSITION) {
     val oldPosition = parent.getChildViewHolder(view).oldPosition
     if (oldPosition in 0 until (parent.adapter?.itemCount ?: 0)) {
       position = oldPosition
     }
   }
   return position
 }
} Cache for created drawers is not something specific to decoration applying, it’s just a method for correctly resolving adapter position for given view getAdapterPositionForView() Iterating through decorations of instance HasDecorations This piece is a topic for second article “Decorations à la carte” Conclusion This article discovered an approach to build a list framework around . Delegation used as a base principle for wrapping list items and list decorations. RecyclerView I believe that the main advantages of the suggested solution is: Nativeness. Implementation is not depending on third party libraries, that can reduce flexibility in the future. AdapterDelegates was chosen to consider exactly these criteria – it’s very simple and natural and all the behavior at your fingertips. Scalability. Thanks to delegation and separation of concerns principle, we are able to decouple implementations of items delegates or decorations drawers. It’s easy to integrate incrementally to an existing project In the second part, we’ll discuss all types of list decorations that we probably expect to see in an Android application.

Super-Powered Vintage Lists in Android: Delegation as a Foundation

অ্যান্ড্রয়েডে সুপার-পাওয়ারড ভিনটেজ তালিকা: একটি ফাউন্ডেশন হিসাবে প্রতিনিধি

Superstarke Vintage-Listen in Android: Delegation als Grundlage

Listas vintage con superpoderes en Android: Delegación como base

Listes vintage super puissantes dans Android : la délégation en tant que fondation

एंड्रॉइड में सुपर-पावर्ड विंटेज सूचियाँ: एक फाउंडेशन के रूप में प्रतिनिधिमंडल

Android の超強力なヴィンテージ リスト: 基盤としての委任

Android의 강력한 빈티지 목록: 기초로서의 위임

Listas vintage superpoderosas no Android: delegação como base

Android'de Süper Güçlü Vintage Listeler: Temel Olarak Delegasyon

Danh sách cổ điển siêu mạnh trong Android: Ủy quyền với tư cách là một nền tảng

Android 中超级强大的复古列表：委托作为基础

How to Use Swift for Web Development

ওয়েব ডেভেলপমেন্টের জন্য কীভাবে সুইফট ব্যবহার করবেন

So verwenden Sie Swift für die Webentwicklung

Cómo usar Swift para el desarrollo web

Comment utiliser Swift pour le développement Web

वेब डेवलपमेंट के लिए स्विफ्ट का उपयोग कैसे करें

Swift を Web 開発に使用する方法

웹 개발에 Swift를 사용하는 방법

Como usar o Swift para desenvolvimento web

Web Geliştirme için Swift Nasıl Kullanılır?

Cách sử dụng Swift để phát triển web

如何使用 Swift 进行 Web 开发

Fully Covering I/O File Based Applications in .NET C# Using Unit Tests

RECAPITULATION OF THE CHIEF OBSERVATIONS ON DROSERA ROTUNDIFOLIA

, , , and similar items are very essential tools to enhance the user experience on an application regardless of platform. Snack Bars Alert Dialogs ProgressIndicators Intro Welcome to another exciting blog, this is the 8th part of the series . So, far we made , some like the app bar and bottom nav bar, and also implemented a global . In the last two sections, we created and wrote the for registration and sign-in methods to use with the Firebase project. In this section, we'll use flutters' features to give users visual feedback. Flutter App Development Tutorial Splash Screen global widgets theme UI backend You can find the source code . here Show Progress Indicator During Registration/Sign In Head over to the class and make some changes. auth_state_provider Create an enum outside of class, to toggle the Application Process State State. // Outside of any class or function
// Make an enum to togggle progrss indicator
enum ProcessingState {
  done,
  waiting,
} Inside of Provider class let's create a field of type and a  function that switches these values/states. ProcessingState ProcessingState _processingState = ProcessingState.done;
  // getter
  ProcessingState get processingState => _processingState;

  void setPrcState(ProcessingState prcsState) {
    _processingState = prcsState;
    notifyListeners();
  } We'll display the CircularProgressIndicator whenever the application is busy and remove it when done. For instance, after pressing the register/sign-in button we can show the progress indicator in place of the button and then remove it when firebase sends a response. So, let's first start by adding the function inside the register function. We'll make changes inside auth_form_widget files after this. Update Processing State In Register Function // Our Function will take email,password, username and buildcontext
  void register(String email, String password, String username,
      BuildContext context) async {
    // Start loading progress indicator once submit button is hit
    // #1
    setPrcState(ProcessingState.waiting);
    try {
      // Get back usercredential future from createUserWithEmailAndPassword method
      UserCredential userCred = await authInstance
          .createUserWithEmailAndPassword(email: email, password: password);
      // Save username name
      await userCred.user!.updateDisplayName(username);

      // After that access "users" Firestore in firestore and save username, email and userLocation
      await FirebaseFirestore.instance
          .collection('users')
          .doc(userCred.user!.uid)
          .set(
        {
          'username': username,
          'email': email,
          'userLocation': null,
        },
      );
      // if everything goes well user will be registered and logged in
      // now go to the homepage
      GoRouter.of(context).goNamed(APP_PAGE.home.routeName);
    } on FirebaseAuthException catch (e) {
      // In case of error
      // if email already exists
      if (e.code == "email-already-in-use") {
        print("The account with this email already exists.");
      }
      if (e.code == 'weak-password') {
        // If password is too weak
        print("Password is too weak.");
      }

    // #2
      setPrcState(ProcessingState.done);
    } catch (e) {
      // For anything else
      print("Something went wrong please try again.");
      // #3
      setPrcState(ProcessingState.done);
    }
    // notify listeneres
    notifyListeners();
  } In the registration function, we'll start to toggle the ProcessState to (which's by default) right before the Try block. waiting done We'll only switch it back to once the servers send an error response, at the end of the Catch block. We'll not switch it back at the end of the try block because, in case of success, we'll move on to the next page as well as display a Snackbar which we'll implement after this section. done Please make similar changes to the and the functions by yourself. Sign In Log Out Now, we'll need to tell the application, that when the processing state is in , display a progress indicator, and then remove the indicator once the processing state is done. To do so let's head over to . Right after we instantiate an AuthStateProvider, create a new variable of the type ProcessState whose value is equal to that of AuthStateProvider's process state. waiting auth_form_widget Widget build(BuildContext context) {
    final AuthStateProvider authStateProvider =
        Provider.of<AuthStateProvider>(context);

    // make new ProcessState var
    ProcessingState prcState = authStateProvider.processingState; After that, down where we have our elevation button, let's make it a conditionally rendering widget. if (prcState == ProcessingState.waiting) const CircularProgressIndicator(),
  if (prcState == ProcessingState.done)
              Row(
                mainAxisAlignment: MainAxisAlignment.end,
                children: [
                  TextButton(
                    onPressed: () {},
                    child: const Text('Cancel'),
                  ),
                  const SizedBox(
                    width: 20,
                  ),
                  ElevatedButton(
                    onPressed: () {
                      // call _submitForm on tap
                      _submitForm(authStateProvider, context);
                    },
                    child: Text(registerAuthMode ? 'Register' : 'Sign In'),
                    style: ButtonStyle(
                      elevation: MaterialStateProperty.all(8.0),
                    ),
                  ),
                ],
              ), The progress indicator will activate and deactivate at the right time. Display Information on Snackbar As mentioned earlier, we'll be using to display information like "Authentication Successful", "Welcome Back", etc. To do so let's again create a simple function on AuthStateProvider class. Snackbar // Right after setPrcState function
 //  create function to handle popups
  SnackBar msgPopUp(msg) {
    return SnackBar(
        content: Text(
      msg,
      textAlign: TextAlign.center,
    ));
  } This function will take a custom message and return a SnackBar to display on the screen. Snackbar works in conjunction with class. So, we'll pass this msgPopUp method in at the end of the block operations, and just before we call GoRouter. ScaffoldMessenger ScaffoldMessenger.of(context) try Inside Registration Function ScaffoldMessenger.of(context)
          .showSnackBar(msgPopUp("The account has been registered."));
// Before GoRouter
GoRouter.of(context).goNamed(APP_PAGE.home.routeName); Inside Login Function ScaffoldMessenger.of(context).showSnackBar(msgPopUp("Welcome Back")); With this when the authentication operation succeeds user will see a snack bar at the bottom of the application. Alert Error on Authentication With Alert Dialog The snack bar is useful because it subtly displays short messages. However, because of its subtlety, it is not very appropriate to be used in case of errors. In such cases, it's better to alert users using a dialog pop-up such as the widget. So, right after the msgPopUp function, let's create another function. AlertDialog // #1
  AlertDialog errorDialog(BuildContext context, String errMsg) {
    return AlertDialog(
      title: Text("Error",
          style: TextStyle(
            //text color will be red
            // #2
            color: Theme.of(context).colorScheme.error,
          )),
      content: Text(errMsg,
          style: TextStyle(
            //text color will be red
             // #3
            color: Theme.of(context).colorScheme.error,
          )),
      actions: [
        TextButton(
          // On button click remove the dialog box
           // #2
          onPressed: () => Navigator.of(context).pop(),
          child: const Text('OK'),
        ),
      ],
    );
  } Our method will take two arguments: an error message and a build context. Our alert box will have texts with the color red. On click, the dialog box will be removed from the screen. The build context is required here to call method. Navigator.pop On both registration and sign-in methods, we are only printing the error messages. Now, let's replace those print statements with errorDialog() and pass the same messages into the function. Inside Register Function's Catch Blocks on FirebaseAuthException catch (e) {
      // In case of error
      // if email already exists
      if (e.code == "email-already-in-use") {
        showDialog(
            context: context,
            builder: (context) => errorDialog(
                context, "The account with this email already exists."));
      }
      if (e.code == 'weak-password') {
        // If password is too weak
        showDialog(
            context: context,
            builder: (context) =>
                errorDialog(context, "Password is too weak."));
      }
      setPrcState(ProcessingState.done);
    } catch (e) {
      // For anything else
      showDialog(
          context: context,
          builder: (context) =>
              errorDialog(context, "Something went wrong please try again."));
      setPrcState(ProcessingState.done);
    } This is what the box will look like. Please, add these alerts to your sign-in method by yourself. Summary A few changes were made in AuthStateProvider and AuthFormWidget classes. We created an Enum to address process states. Progress indicators were implemented based on Processing Status. A simple snack bar function was built to display information for users when authentication succeeds. An error handler was created to display error messages on an alert dialog box. Support Us Was this an informative blog? If so, hit the like button, ask us some questions and share this with your colleagues. The next part is going to be on App Permissions and Google Places API. So, to get notifications. subscribe and follow us This is Nibesh Khadka from Khadka's Coding Lounge. We are a freelancing agency that makes websites and mobile applications. Also published . here

Improving the User Experience in Flutter

Introducing InAppWebView Plugin For Flutter

Redux saga is a middleware between an application and redux store, that is handled by redux actions. This means, it can listen to actions, intercept actions it is interested in and replace them with other actions. This may be useful for plenty of things. In particular, using sagas you can keep your components as simple as possible and move all the logic to sagas. When you start working with Redux saga, it seems quite natural to write sagas that describe behavior of a single component or a single page. And it works fine in simple applications that have two or three pages and everything is loaded synchronously. But when a project grows, this may lead you to a mess in sagas department, where sagas don’t have clear purposes and duplicate each other in many ways. It will be difficult to manage, debug and make even small changes. The thing is that sagas’ work should be coordinated. After some time of struggling with this mess and finally reading the documentation we in DashBouquet came up with a new approach, which has always been there. Describe a full flow in a saga. This is what the documentation implies, you should just read carefully. Let’s see, what it looks like. It looks like a flow, isn’t it? Sure, describing full flow in saga doesn’t mean that there should be only one saga. The point is that everything is handled from one place. Now, let’s take a look at an actual example. Say, in our app a user is able to fill up a job application and send it to the server for further processing. We want to create a saga that will describe full flow of this process. Everything starts on route when a user clicks an “Apply for a job” button and is redirected to the application form. /create_application_page {take, call, put, select, fork, cancel, race} 'redux-saga/effects'; { , } 'react-router-redux'; {takeEvery} "redux-saga"; * api './api'; import from import LOCATION_CHANGE push from import from import as from createApplication(data) { put( (`/application_form`)); function* yield push { saveApplication } = yield race({saveApplication: take(SAVE_APPLICATION),cancelApplication: take(CANCEL_APPLICATION),}); const (saveApplication) { { data } = saveApplication; api.saveApplication(data); put( (`/application_saved`));} else {yield put( (`/application_cancaled`));}} watchCreateApplication() { createApplicationTask = takeEvery(CREATE_APPLICATION, createApplication); if const yield yield push push function* const { {payload: {pathname}} = yield take( ); (pathname.search(/^\/create_application_page\/?$/) !== -1) { cancel(createApplicationTask); }}} while (true) const LOCATION_CHANGE if yield break; Here is an action dispatched when a user clicks “Apply for a job”. Then he is redirected to another page with a form. After the user fills up the form and clicks Submit or Cancel, he is redirected further depending on which action was dispatched. And data is sent to the server only if the user clicks Submit. CREATE_APPLICATION Also the user may change his mind in the middle of filling up the form and just go by another link without clicking “Cancel”. In this case if he later comes back to where the saga is injected asynchronously, it will be injected one more time, and the data on the server will be created twice, while the user intended to do it only once. We certainly don’t want that, so we need to cancel the task on LOCATION_CHANGE dispatched by redux-router, hence checking the pathname in . /create_application_page watchCreateApplication And just to make things a bit more complicated, we assume, that in the middle of filling up the form, the user can call a dialog with another form, in which he can choose, say, a country and a city he is applying from and submit this data to the server. We can do this by simply forking another saga that would be quite similar to saga: createApplication chooseLocation() { put(showDialog()); { saveLocation } = yield race({saveLocation: take(SAVE_LOCATION),cancelLocation: take(CANCEL_LOCATION),}); (saveLocation) { { data } = saveLocation; api.saveLocation(data);} put(closeDialog());} function* yield const if const yield yield createApplication() { put( (`/application_form`)); createLocationTask = takeEvery(CREATE_LOCATION, createLocation) function* yield push const ... cancel(createLocationTask); yield } Here we handle the dialog with and sagas. In two words, they should set some value in the store to tell a page, if the dialog has to be shown or hidden at the moment. In more detail it is a subject for another article. showDialog closeDialog It is important not to forget to cancel the forked tasks. If at some point you find an avalanche of requests going to the server when it was supposed to be only one or two, you probably missed this somewhere. It is a quite simple example. A flow may be much more complicated, with any amount of subflows (though it might be a bad idea from UX point of view). But anyway, what this approach gives is that you can build your flow step by step. You can make changes later quite easily and they will not lead to unexpected behavior from other sagas. You can make it more complicated, if you need to, but no matter, how many forks your flow has, you never get lost in it. _After applying few simple manipulations to the result of Normalizr’s work we get data that we can keep in store_hackernoon.com Using Normalizr to organize data in stores — practical guide _Why reselect is so good_hackernoon.com Usage of Reselect in a React-Redux Application _The second part of the article about how to use Normalizr to organize data in stores._hackernoon.com Using Normalizr to organize data in store. Part 2 _Javascript has two major ways of dealing with asynchronous tasks — callbacks and Promises. In general Promises are…_hackernoon.com How to Stop Using Callbacks and Start Living Written by Ilya Bohaslauchyk

Missing part of Redux Saga Experience

I hate code comments. I hate reading comments and I hate writing comments. It’s one of the first things I notice in a new project, and it’s usually a red flag about the code quality. I know people that swear by code comments. They feel helpless if the code is not commented extensively. And they usually have several arguments for why comments are needed. I have to explain what a method does. /*** Retrieves the registration info of the user* @param args The user's id*/public String getInfo(int args){...} I agree that is not a method you would like to use without a comment explaining what it actually does. But why don’t you use a better name for it? It doesn’t cost you anything to rename it: String getInfo(int args) /*** Retrieves the registration info of the user* @param userId The user's id*/public String getRegistrationInfo(int userId){...} Wow! It looks like the comment is not needed anymore, is it? It’s actually duplicating information and violating the . DRY principle Sadly, this kind of redundant comments is much too often found in actual code. Many times the comments are added because of stupid coding style rules mandating every method to be commented. And what’s a poor to do? Just add a comment to satisfy the law… programmer /*** Set the user's name*/public void setName(String name){...} If I received a dollar each time I deleted such a comment, I could probably make a living out of just deleting useless comments. But it’s not doing any harm! Except for making code harder to read, yes, it’s not doing any harm. For now. But I guarantee you that at one point in the future somebody will need separate methods to get/set the first and last name. They will most likely use their IDE’s refactoring and rename the method, forgetting to rename the comment as well: tool /*** Set the user's name*/public void setLastName(String lastName){...} BAM! Misleading comments. Extrapolate to several years of this and you start to slowly go insane. But what if I can’t find a good name for a method? /*** Display an error message to the user, log the error* and navigate to the login screen** @param exception The exception*/public void handleError(Exception exception){...} I agree, . Start by actually writing the best name you can think of. If doesn’t exactly roll off the tongue, ask yourself why. Ah, too many verbs, you say? Maybe it’s because the method does too many things? May I remind you of a little thing called the principle? Why don’t you split it into 3 smaller methods: , and ? naming things is difficult displayAndLogErrorThenGoToLogin() Single Responsibility displayErrorMessage(Exception e) writeToLog(Exception e) navigateToLoginScreen() I need to document this method with ambiguous arguments /*** Display a dialog at a certain position on the screen** @param type One of Dialog.ALERT, Dialog.ASK or Dialog.NEGATIVE* @param isBlocking True if the dialog should block the UI*/public void showDialog(int x, int y, int type, boolean isBlocking){...} Oh boy… Where do I begin? Boolean arguments? 99% of the time, that’s a method begging to be split in two. How about and ? showBlockingDialog() showNonBlockingDialog() You have to document the supported values for a parameter? What’s stopping someone from passing in ? Or ? Create an enum to hold the possible values and restrict anyone from passing in a wrong value. Or consider using a factory to create different types of dialogs. 42 Integer.MIN_VALUE But you see, I have this one weird trick I need to document… ...Blob blob = getLastUsedBlob();// the blobs are spread out in memory to make attacks difficultint nextAddress = blob.getMemoryAddress() >> blob.getByteSize();Blob nextBlob = Blob.getFromAddress(nextAddress); I agree, this is the kind of obscure knowledge that needs to be documented. Sometimes it helps to encapsulate this knowledge in a separate method or class. In this specific example, it would make sense to encapsulate it in the class itself: Blob /*** Find the next blob*/public Blob getNextBlob(){// the blobs are spread out in memory to make attacks difficultint nextAddress = getMemoryAddress() >> getByteSize();return Blob.getFromAddress(nextAddress);} Now, not only you made life easier for anyone who works with blobs, you also made your code safer. No more accidental instead of . Yay! << >> Code can be such a beautiful thing. And, like most beautiful things, it takes hard work to create. Unfortunately, it’s easy to write bad code. And . But don’t delete the comments and call your code beautiful. Write it in a way that doesn’t need comments in the first place. bad code comments requires So go forth and code (without comments)! is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Stories, News & Mentions about SPOWDI

Spowdi’s Stories on HackerNoon

Spowdi's News & Mentions