जियो फाइनेंस एक फाइनेंशियल सुपर ऐप | Jio Finance is a financial super app (India), Y2026_M1W422

जियो फाइनेंस एक फाइनेंशियल सुपर ऐप | Jio Finance is a financial super app (India), Y2026_M1W422

 

The Jio Finance ecosystem Overview.

The Jio Finance ecosystem Overview:

The Jio Finance ecosystem is a comprehensive, digital-first platform designed to be a "one-stop" destination for all your financial needs. By integrating daily transactions, wealth creation, credit access, and insurance, it offers a diversified, trusted, and smart way to manage money within a single mobile interface.

At the heart of the daily experience is the Transact pillar, which handles routine financial tasks with ease. Users can manage essential chores like UPI and bill payments, open a CASA (Current Account Savings Account) with associated debit cards, and even handle complex tasks like tax filing and planning directly through the app.

Security and convenience are prioritized through modern payment technologies. The ecosystem supports biometric-enabled payments to ensure high security, alongside a tap-and-pay feature for quick physical transactions. These tools are designed to make the checkout process seamless whether you are shopping online or in person.

For those looking to grow their wealth, the Invest section provides several accessible avenues. Users can put their money into Mutual Funds, explore Jio Gold, or utilize the Savings Pro feature to ensure their capital is working effectively for them over time.

To help you stay on top of your financial health, Jio Finance includes a dedicated wealth tracking dashboard. This "Finances" feature allows you to monitor your absolute returns and total invested amount across different assets, providing a clear bird's-eye view of your financial progress.

When it comes to financial flexibility, the Borrow pillar offers a wide range of credit solutions. Whether you are looking for a Home Loan to buy a new property or a Loan against Property for liquidity, the platform provides structured options to meet significant capital requirements.

The ecosystem also allows you to leverage your existing investments for credit. You can access a Loan against Mutual Funds (LAMF), a Loan against Shares (LAS), or even a Loan against ETFs, allowing you to unlock the value of your portfolio without having to sell your assets.

Safety and risk management are addressed under the Protect category. This section offers comprehensive Insurance coverage, including Health insurance and Life insurance (both term and non-term), as well as dedicated policies for your car and two-wheeler.

The app further simplifies social and administrative tasks through its Quick Actions menu. From here, users can split payments with friends, check their credit score for free, and view their rewards, making the app more than just a bank—it is a lifestyle tool.

Ultimately, the Jio Finance ecosystem is built to provide a holistic financial journey. By combining smart technology with a trusted brand, it ensures that every aspect of your money—from spending it today to protecting it for tomorrow—is handled within a single, easy-to-use digital environment.

Top 10 Most Common Mobile App Design Mistakes

The mobile app market is saturated with competition. Trends turn over quickly, but no niche can last very long without several competitors jumping onto the bandwagon. These conditions result in a high failure rate across the board for the mobile app market. Only 20% of downloaded apps see users return after the first use, whereas 3% of apps remain in use after a month.

If any part of an app is undesirable, or slow to get the hang of, users are more likely to install a new one, rather than stick it out with the imperfect product. Nothing is wasted for the consumer when disposing of an app - except for the efforts of the designers and developers, that is. So, why is it that so many apps fail? Is this a predictable phenomenon that app designers and developers should accept? For clients, is this success rate acceptable? What does it take to bring your designs into the top 3% of prosperous apps?

The common mistakes span from failing to maintain consistency throughout the lifespan of an app, to attracting users in the first place. How can apps be designed with intuitive simplicity, without becoming repetitive and boring? How can an app offer pleasing details, without losing sight of a greater purpose? Most apps live and die in the first few days, so here are the top ten most common mistakes that designers can avoid.

Only 3% of mobile apps are in use after being downloaded.

Common Mistake #1: A Poor First Impression

Often the first use, or first day with an app, is the most critical period to hook a potential user. The first impression is so critical that it could be an umbrella point for the rest of this top ten. If anything goes wrong, or appears confusing or boring, potential users are quickly disinterested. Although, the proper balance for first impressions is tricky to handle. In some cases, a lengthy onboarding, or process to discover necessary features can bores users. Yet, an instantly stimulating app may disregard the need for a proper tutorial, and promote confusion. Find the balance between an app that is immediately intuitive, but also introduces the users to the most exciting, engaging features quickly. Keep in mind that when users are coming to your app, they’re seeing it for the first time. Go through a proper beta testing process to learn how others perceive your app from the beginning. What seems obvious to the design team, may not be for newcomers.

Improper Onboarding

Onboarding is the step by step process of introducing a user to your app. Although it can be a good way to get someone quickly oriented, onboarding can also be a drawn out process that stands in the way of your users and their content. Often these tutorials are too long, and are likely swiped through blindly.

Sometimes, users have seen your app used in public or elsewhere, such that they get the point and just want to jump in. So, allow for a sort of quick exit strategy to avoid entirely blocking out the app upon its first use. To ensure that the onboarding process is in fact effective, consider which values this can communicate and how. The onboarding process should demonstrate the value of the app in order to hook a user, rather than just an explanation.

Go easy on the intro animation

Some designers address the issue of a good first impression with gripping intro animations to dazzle new users. But, keep in mind that every time someone wants to run the app, they’re going to have to sit through the same thing over and over. If the app serves a daily function, then this will tire your users quickly. Ten seconds of someone’s day for a logo to swipe across the screen and maybe spin a couple times don’t really seem worth it after a while.

Common Mistake #2: Designing an App Without Purpose

Avoid entering the design process without succinct intentions. Apps are often designed and developed in order to follow trends, rather than to solve a problem, fill a niche, or offer a distinct service. What is the ambition for the app? For the designer and their team, the sense of purpose will affect every step of a project. This sensibility will guide each decision from the branding or marketing of an app, to the wireframe format, and button aesthetic. If the purpose is clear, each piece of the app will communicate and function as a coherent whole. Therefore, have the design and development team continually consider their decisions within a greater goal. As the project progresses, the initial ambition may change. This is okay, as long as the vision remains coherent.

Conveying this vision to your potential users means that they will understand what value the app brings to their life. Thus, this vision is an important thing to communicate in a first impression. The question becomes how quickly can you convince users of your vision for the app? How it will improve a person’s life, or provide some sort of enjoyment or comfort. If this ambition is conveyed quickly, then as long as your app is in fact useful, it will make it into the 3%.

Often joining a pre-existing market, or app niche, means that there are apps to study while designing your own. Thus, be careful how you choose to ‘re-purpose’ what is already out there. Study the existing app market, rather than skimming over it. Then, improve upon existing products with intent, rather than thoughtlessly imitating.

Common Mistake #3: Missing Out On UX Design Mapping

Be careful not to skip over a thoughtful planning of an app’s UX architecture before jumping into design work. Even before getting to a wireframing stage, the flow and structure of an app should be mapped out. Designers are often too excited to produce aesthetics and details. This results in a culture of designers who generally under appreciate UX, and the necessary logic or navigation within an app. Slow down. Sketch out the flow of the app first before worrying too much about the finer brush strokes. Often apps fail from an overarching lack of flow and organization, rather than imperfect details. However, once the design process takes off always keep the big picture in mind. The details and aesthetic should then clearly evoke the greater concept.

Common Mistake #4: Disregarding App Development Budget

As soon as the basis of the app is sketched, this is a good time to get a budget from the development team. This way you don’t reach the end of the project and suddenly need to start cutting critical features. As your design career develops, always take note of the average costs of constructing your concepts so that your design thinking responds to economic restraints. Budgets should be useful design constraints to work within.

Many failed apps try to cram too many features in from launch

• 
• 
• 

Common Mistake #5: Cramming in Design Features

Hopefully, rigorous wireframing will make the distinction between necessary and excessive functions clear. The platform is already the ultimate swiss army knife, so your app doesn’t need to be. Not only will cramming an app with features lead to a likely disorienting User Experience, but an overloaded app will also be difficult to market. If the use of the app is difficult to explain in a concise way, it’s likely trying to do too much. Paring down features is always hard, but it’s necessary. Often, the best strategy might be to gain trust in the beginning with a single or few features, then later in the life of the app can new ones be ‘tested’. This way, the additional features are less likely to interfere with the crucial first few days of an apps’ life.

Common Mistake #6: Dismissing App Context

Although the conditions of most design offices practically operate within a vacuum, app designers must be aware of wider contexts. Although purpose and ambition are important, they become irrelevant if not directed within the proper context. Remember that although you and your design team may know your app very well, and find its interfacing obvious, this may not be the case for first time users, or different demographics.

Consider the immediate context or situation in which the app is intended to be used. Given the social situation, how long might the person expect to be on the app for? What else might be helpful for them to stumble upon given the circumstance? For example, UBER’s interface excels at being used very quickly. This means that for the most part, there isn’t much room for other content. This is perfect because when a user is out with friends and needing to book a ride, your conversation is hardly interrupted in the process. UBER hides a lot of support content deep within the app, but it only appears once the scenario calls for it.

Who is the target audience for the app? How might the type of user affect how the design of the app? Perhaps, consider that an app targeted for a younger user may be able to take more liberties in assuming a certain level of intuition from the user. Whereas, many functions may need to be pointed out for a less tech savvy user. Is your app meant to be accessed quickly and for a short period of time? Or, is this an app with lots of content that allows users to stay a while? How will the design convey this form of use?

A good app design should consider the context in which it is used.

Common Mistake #7: Underestimating Crossing Platforms

Often apps are developed quickly as a response to changing markets or advancing competitors. This often results in web content being dragged into the mobile platform. A constant issue, which you’d think would be widely understood by now, is that often apps and other mobile content make poor transitions between the desktop, or mobile platforms. No longer can mobile design get away with scaling down web content in the hope of getting a business quickly into the mobile market. The web to mobile transition doesn’t just mean scaling everything down, but also being able to work with less. Functions, navigation and content must all be conveyed with a more minimal strategy. Another common issue appears when an app developing team aspires to release a product simultaneously on all platforms, and through different app stores. This often results in poor compatibility, or a generally buggy, unpolished app.The gymnastics of balancing multiple platforms may be too much to add onto the launch of an app. However, it doesn’t hurt to sometimes take it slowly with one OS at a time, and iron out the major issues, before worrying about compatibility between platforms.

Common Mistake #8: Overcomplicating App Design

The famous architect Mies Van der Rohe once said, “It’s better to be good than to be unique”. Ensure that your design is meeting the brief before you start breaking the box or adding flourishes. When a designer finds themselves adding things in order to make a composition more appealing or exciting, these choices will likely lack much value. Continue to ask throughout the design process, how much can I remove? Instead of designing additively, design reductively. What isn’t needed? This method is directed as much towards content, concept and function as it is aesthetics. Over complexity is often a result of a design unnecessarily breaking conventions. Several symbols and interfaces are standard within our visual and tactile language. Will your product really benefit from reworking these standards? Standard icons have proven themselves to be universally intuitive. Thus, they are often the quickest way to provide visual cues without cluttering a screen. Don’t let your design flourishes get in the way of the actual content, or function of the app. Often, apps are not given enough white space. The need for white space is a graphic concept that has transcended both digital and print, thus it shouldn’t be underrated. Give elements on the screen room to breath so that all of the work you put into navigation and UX can be felt.

The app design process can be reductive, rather than additive.

Common Mistake #9: Design Inconsistencies

To the point on simplicity, if a design is going to introduce new standards, they have to at least be consistent across the app. Each new function or piece of content doesn’t necessarily have to be an opportunity to introduce a new design concept. Are texts uniformly formatted? Do UI elements behave in predictable, yet pleasing ways throughout the app? Design consistency must find the balance between existing within common visual language, as well as avoiding being aesthetically stagnant. The balance between intuitive consistency and boredom is a fine line.

Common Mistake #10: Under Utilizing App Beta Testing

All designers should analyze the use of their apps with some sort of feedback loop in order to learn what is and isn’t working. A common mistake in testing is for a team to do their beta testing in-house. You need to bring in fresh eyes in order to really dig into the drafts of the app. Send out an ad for beta testers and work with a select audience before going public. This can be a great way to iron out details, edit down features, and find what’s missing. Although, beta testing can be time consuming, it may be a better alternative to developing an app that flops. Anticipate that testing often takes 8 weeks for some developers to do it properly. Avoid using friends or colleagues as testers as they may not criticize the app with the honesty that you need. Using app blogs or website to review your app is another way to test the app in a public setting without a full launch. If you’re having a hard time paring down features for your app, this is a good opportunity to see what elements matter or not.

The app design market is a battleground, so designing products which are only adequate just isn’t enough. Find a way to hook users from the beginning - communicate, and demonstrate the critical values and features as soon as you can. To be able to do this, your design team must have a coherent vision of what the app is hoping to achieve. In order to establish this ambition, a rigorous story-boarding process can iron out what is and isn’t imperative. Consider which types of users your app may best fit with. Then refine and refine until absolutely nothing else can be taken away from the project without it falling apart.

This article was written by Kent Mundle, a Toptal Technical Editor.

Writing Testable Code in JavaScript: A Brief Overview - Kapil Sharma

Whether we’re using Node paired with a test framework like Mocha or Jasmine, or spinning up DOM-dependent tests in a headless browser like PhantomJS, our options for unit testing JavaScript are better now than ever.

However, this doesn’t mean the code we’re testing is as easy on us as our tools are! Organizing and writing code that is easily testable takes some effort and planning, but there are a few patterns, inspired by functional programming concepts, that we can use to avoid getting into a tough spot when it comes time to test our code. In this article, we will go through some useful tips and patterns for writing testable code in JavaScript.

Keep Business Logic and Display Logic Separate

One of the primary jobs of a JavaScript-based browser application is listening to DOM events triggered by the end user, and then responding to them by running some business logic and displaying the results on the page. It’s tempting to write an anonymous function that does the bulk of the work right where you’re setting up your DOM event listeners. The problem this creates is that you now have to simulate DOM events to test your anonymous function. This can create overhead both in lines of code and the time it takes for tests to run.

Instead, write a named function and pass it to the event handler. That way you can write tests for named functions directly and without jumping through hoops to trigger a fake DOM event.

This applies to more than the DOM though. Many APIs, both in the browser and in Node, are designed around firing and listening to events or waiting for other types of asynchronous work to complete. A rule of thumb is that if you are writing a lot of anonymous callback functions, your code may not be easy to test.

// hard to test
$('button').on('click', () => {
    $.getJSON('/path/to/data')
        .then(data => {
            $('#my-list').html('results: ' + data.join(', '));
        });
});

// testable; we can directly run fetchThings to see if it
// makes an AJAX request without having to trigger DOM
// events, and we can run showThings directly to see that it
// displays data in the DOM without doing an AJAX request
$('button').on('click', () => fetchThings(showThings));

function fetchThings(callback) {
    $.getJSON('/path/to/data').then(callback);
}

function showThings(data) {
    $('#my-list').html('results: ' + data.join(', '));
}

Use Callbacks or Promises with Asynchronous Code

In the code example above, our refactored fetchThings function runs an AJAX request, which does most of its work asynchronously. This means we can’t run the function and test that it did everything we expected, because we won’t know when it’s finished running.

The most common way to solve this problem is to pass a callback function as a parameter to the function that runs asynchronously. In your unit tests you can run your assertions in the callback you pass.

Another common and increasingly popular way to organize asynchronous code is with the Promise API. Fortunately, $.ajax and most other of jQuery’s asynchronous functions return a Promise object already, so a lot of common use cases are already covered.

// hard to test; we don't know how long the AJAX request will run
function fetchData() {
    $.ajax({ url: '/path/to/data' });
}

// testable; we can pass a callback and run assertions inside it
function fetchDataWithCallback(callback) {
    $.ajax({
        url: '/path/to/data',
        success: callback,
    });
}

// also testable; we can run assertions when the returned Promise resolves
function fetchDataWithPromise() {
    return $.ajax({ url: '/path/to/data' });
}

Avoid Side Effects

Write functions that take arguments and return a value based solely on those arguments, just like punching numbers into a math equation to get a result. If your function depends on some external state (the properties of a class instance or the contents of a file, for example), and you have to set up that state before testing your function, you have to do more setup in your tests. You’ll have to trust that any other code being run isn’t altering that same state.

In the same vein, avoid writing functions that alter external state (like writing to a file or saving values to a database) while it runs. This prevents side effects that could affect your ability to test other code with confidence. In general, it’s best to keep side effects as close to the edges of your code as possible, with as little “surface area” as possible. In case of classes and object instances, a class method’s side effects should be limited to the state of the class instance being tested.

// hard to test; we have to set up a globalListOfCars object and set up a
// DOM with a #list-of-models node to test this code
function processCarData() {
    const models = globalListOfCars.map(car => car.model);
    $('#list-of-models').html(models.join(', '));
}

// easy to test; we can pass an argument and test its return value, without
// setting any global values on the window or checking the DOM the result
function buildModelsString(cars) {
    const models = cars.map(car => car.model);
    return models.join(',');
}

Use Dependency Injection

One common pattern for reducing a function’s use of external state is dependency injection - passing all of a function’s external needs as function parameters.

// depends on an external state database connector instance; hard to test
function updateRow(rowId, data) {
    myGlobalDatabaseConnector.update(rowId, data);
}

// takes a database connector instance in as an argument; easy to test!
function updateRow(rowId, data, databaseConnector) {
    databaseConnector.update(rowId, data);
}

One of the main benefits of using dependency injection is that you can pass in mock objects from your unit tests that don’t cause real side effects (in this case, updating database rows) and you can just assert that your mock object was acted on in the expected way.

Give Each Function a Single Purpose

Break long functions that do several things into a collection of short, single-purpose functions. This makes it far easier to test that each function does its part correctly, rather than hoping that a large one is doing everything correctly before returning a value.

In functional programming, the act of stringing several single-purpose functions together is called composition. Underscore.js even has a function _.compose, that takes a list of functions and chains them together, taking the return value of each step and passing it to the next function in line.

// hard to test
function createGreeting(name, location, age) {
    let greeting;
    if (location === 'Mexico') {
        greeting = '!Hola';
    } else {
        greeting = 'Hello';
    }

    greeting += ' ' + name.toUpperCase() + '! ';

    greeting += 'You are ' + age + ' years old.';

    return greeting;
}

// easy to test
function getBeginning(location) {
    if (location === 'Mexico') {
        return '¡Hola';
    } else {
        return 'Hello';
    }
}

function getMiddle(name) {
    return ' ' + name.toUpperCase() + '! ';
}

function getEnd(age) {
    return 'You are ' + age + ' years old.';
}

function createGreeting(name, location, age) {
    return getBeginning(location) + getMiddle(name) + getEnd(age);
}

Don’t Mutate Parameters

In JavaScript, arrays and objects are passed by reference rather than value, and they are mutable. This means that when you pass an object or an array as a parameter into a function, both your code and the function you passed the object or array to have the ability to alter the same instance of that array or object in memory. This means that if you’re testing your own code, you have to trust that none of the functions your code calls are altering your objects. Every time you add a new place in your code that alters the same object, it gets increasingly hard to keep track of what that object should look like, making it harder to test.

Instead, if you have a function that takes an object or array have it act on that object or array as though it were read-only. Create a new object or array in code and add values to it based on your needs. Or, use Underscoreor Lodash to clone the passed object or array before operating on it. Even better, use a tool like Immutable.js that creates read-only data structures.

// alters objects passed to it
function upperCaseLocation(customerInfo) {
    customerInfo.location = customerInfo.location.toUpperCase();
    return customerInfo;
}

// sends a new object back instead
function upperCaseLocation(customerInfo) {
    return {
        name: customerInfo.name,
        location: customerInfo.location.toUpperCase(),
        age: customerInfo.age
    };
}

Write Your Tests Before Your Code

The process of writing unit tests before the code they’re testing is called test driven development (TDD). A lot of developers find TDD to be very helpful.

By writing your tests first, you are forced to think about the API you are exposing from the perspective of a developer consuming it. It also helps to ensure you’re only writing enough code to meet the contract being enforced by your tests, rather than over-engineering a solution that’s unnecessarily complex.

In practice, TDD is a discipline that can be difficult to commit to for all your code changes. But when it seems worth trying, it’s a great way to guarantee you are keeping all code testable.

Wrap Up

We all know there are a few pitfalls that are very easy to fall for when writing and testing complex JavaScript apps. But hopefully with these tips, and remembering to always keep our code as simple and functional as possible, we can keep our test coverage high and overall code complexity low!

This article was written by JOSHUA MOCK - FREELANCE SOFTWARE ENGINEER @ TOPTAL

Learn more about the best JavaScript resources here.

Electron Cross Platform Desktop App - Kapil Sharma

Earlier this year, Github released Atom-Shell, the core of its famous open-source editor Atom, and renamed it to Electron for the special occasion.

Electron, unlike other competitors in the category of Node.js-based desktop applications, brings its own twist to this already well-established market by combining the power of Node.js (io.js until recent releases) with the Chromium Engine to bring us the best of both server and client-side JavaScript.

Imagine a world where we could build performant, data-driven, cross-platform desktop applications powered by not only the ever-growing repository of NPM modules, but also the entire Bower registry to fulfill all our client-side needs.

Enter Electron.

Building Cross-platform Desktop Apps with Electron:

In this tutorial, we will build a simple password keychain application using Electron, Angular.js and Loki.js, a lightweight and in-memory database with a familiar syntax for MongoDB developers.

The full source code for this application is available here.

This tutorial assumes that:

The reader has Node.js and Bower installed on their machine.

They are familiar with Node.js, Angular.js and MongoDB-like query syntax.

Getting the Goods

First things first, we will need to get the Electron binaries in order to test our app locally. We can install it globally and use it as a CLI, or install it locally in our application’s path. I recommend installing it globally, so that way we do not have to do it over and over again for every app we develop.

We will learn later how to package our application for distribution using Gulp. This process involves copying the Electron binaries, and therefore it makes little to no sense to manually install it in our application’s path.

To install the Electron CLI, we can type the following command in our terminal:

$ npm install -g electron-prebuilt

To test the installation, type electron -h and it should display the version of the Electron CLI.

At the time this article was written, the version of Electron was 0.31.2.

Setting up the Project

Let’s assume the following basic folder structure:

my-app

|- cache/

|- dist/

|- src/

|-- app.js

| gulpfile.js

… where: - cache/ will be used to download the Electron binaries when building the app. - dist/ will contain the generated distribution files. - src/ will contain our source code. - src/app.js will be the entry point of our application.

Next, we will navigate to the src/ folder in our terminal and create the package.json and bower.json files for our app:

$ npm init

$ bower init

We will install the necessary packages later on in this tutorial.

Understanding Electron Processes

Electron distinguishes between two types of processes:

The Main Process: The entry point of our application, the file that will be executed whenever we run the app. Typically, this file declares the various windows of the app, and can optionally be used to define global event listeners using Electron’s IPC module.

The Renderer Process: 

The controller for a given window in our application. Each window creates its own Renderer 

Process.

For code clarity, a separate file should be used for each Renderer Process. To define the Main Process for our app, we will open src/app.js and include the app module to start the app, and the browser-window module to create the various windows of our app (both part of the Electron core), as such:

var app = require('app'),

    BrowserWindow = require('browser-window');

When the app is actually started, it fires a ready event, which we can bind to. At this point, we can instantiate the main window of our app:

var mainWindow = null;

app.on('ready', function() {

    mainWindow = new BrowserWindow({

        width: 1024,

        height: 768

    });

   

    mainWindow.loadUrl('file://' + __dirname + '/windows/main/main.html');

    mainWindow.openDevTools();

});

Key points:

                 We create a new window by creating a new instance of the BrowserWindow object.

                 It takes an object as a single argument, allowing us to define various settings, amongst which the default width and height of the window.

                 The window instance has a loadUrl() method, allowing us to load the contents of an actual HTML file in the current window. The HTML file can either be local or remote.

                 The window instance has an optional openDevTools() method, allowing us to open an instance of the Chrome Dev Tools in the current window for debugging purposes.

Next, we should organize our code a little. I recommend creating a windows/ folder in our src/ folder, and where we can create a subfolder for each window, as such:

my-app

|- src/

|-- windows/

|--- main/

|---- main.controller.js

|---- main.html

|---- main.view.js

… where main.controller.js will contain the “server-side” logic of our application, and main.view.js will contain the “client-side” logic of our application.

The main.html file is simply an HTML5 webpage, so we can simply start it like this:

<html>

<head>

    <meta charset="utf-8">

    <title>Password Keychain</title>

</head>

<body>

    <h1>Password Keychain</h1>

</body>

</html>

At this point, our app should be ready to run. To test it, we can simply type the following in our terminal, at the root of the src folder:

$ electron .

We can automate this process by defining the start script of the package.son file.

Building a Password Keychain Desktop App

To build a password keychain application, we need: - A way to add, generate and save passwords. - A convenient way to copy and remove passwords.

Generating and Saving Passwords

A simple form will suffice to insert new passwords. For the sake of demonstrating communication between multiple windows in Electron, start by adding a second window in our application, which will display the “insert” form. 

Since we will open and close this window multiple times, we should wrap up the logic in a method so that we can simply call it when needed:

function createInsertWindow() {

    insertWindow = new BrowserWindow({

        width: 640,

        height: 480,

        show: false

    });

   

    insertWindow.loadUrl('file://' + __dirname + '/windows/insert/insert.html');

   

    insertWindow.on('closed',function() {

        insertWindow = null;

    });

}

Key points:

                 We will need to set the show property to false in the options object of the BrowserWindow constructor, in order to prevent the window from being open by default when the applications starts.

                 We will need to destroy the BrowserWindow instance whenever the window is firing a closed event.

Opening and Closing the “Insert” Window

The idea is to be able to trigger the “insert” window when the end user clicks a button in the “main” window. In order to do this, we will need to send a message from the main window to the Main Process to instruct it to open the insert window. We can achieve this using 

Electron’s IPC module. There are actually two variants of the IPC module:

                 One for the Main Process, allowing the app to subscribe to messages sent from windows.

                 One for the Renderer Process, allowing the app to send messages to the main process.

Although Electron’s communication channel is mostly uni-directional, it is possible to access the Main Process’ IPC module in a Renderer Process by making use of the remote module. 

Also, the Main Process can send a message back to the Renderer Process from which the event originated by using the Event.sender.send() method.

To use the IPC module, we just require it like any other NPM module in our Main Process script:

var ipc = require('ipc');

… and then bind to events with the on() method:

ipc.on('toggle-insert-view', function() {

    if(!insertWindow) {

        createInsertWindow();

    }

    return (!insertWindow.isClosed() && insertWindow.isVisible()) ? insertWindow.hide() : insertWindow.show();

});

Key Points:

                 We can name the event however we want, the example is just arbitrary.

                 Do not forget to check if the BrowserWindow instance is already created, if not then instantiate it.

                 The BrowserWindow instance has some useful methods:

                                 isClosed() returns a boolean, whether or not the window is currently in a closed state.

                                 isVisible(): returns a boolean, whether or not the window is currently visible.

                                 show() / hide(): convenience methods to show and hide the window.

Now we actually need to fire that event from the Renderer Process. We will create a new script file called main.view.js, and add it to our HTML page like we would with any normal script:

<script src="./main.view.js"></script>

Loading the script file via the HTML script tag loads this file in a client-side context. This means that, for example, global variables are available via window.. To load a script in a server-side context, we can use the require() method directly in our HTML page: require('./main.controller.js');.

Even though the script is loaded in client-side context, we can still access the IPC module for the Renderer Process in the same way that we can for the Main Process, and then send our event as such:

var ipc = require('ipc');

angular

    .module('Utils', [])

    .directive('toggleInsertView', function() {

        return function(scope, el) {

            el.bind('click', function(e) {

                e.preventDefault();

                ipc.send('toggle-insert-view');

            });

        };

    });

There is also a sendSync() method available, in case we need to send our events synchronously.

Now, all we have left to do to open the “insert” window is to create an HTML button with the matching Angular directive on it:

<div ng-controller="MainCtrl as vm">

    <button toggle-insert-view class="mdl-button">

        <i class="material-icons">add</i>

    </button>

</div>

And add that directive as a dependency of the main window’s Angular controller:

angular

    .module('MainWindow', ['Utils'])

    .controller('MainCtrl', function() {

        var vm = this;

    });

Generating Passwords

To keep things simple, we can just use the NPM uuid module to generate unique ID’s that will act as passwords for the purpose of this tutorial. We can install it like any other NPM module, require it in our ‘Utils’ script and then create a simple factory that will return a unique ID:

var uuid = require('uuid');

angular

    .module('Utils', [])

   

    ...

   

    .factory('Generator', function() {

        return {

            create: function() {

                return uuid.v4();

            }

        };

    })

Now, all we have left to do is create a button in the insert view, and attach a directive to it that will listen to click events on the button and call the create() method:

<button generate-password class="mdl-button">generate</button>

// in Utils.js

angular

    .module('Utils', [])

   

    ...

   

    .directive('generatePassword', ['Generator', function(Generator) {

        return function(scope, el) {

            el.bind('click', function(e) {

                e.preventDefault();

                if(!scope.vm.formData) scope.vm.formData = {};

                scope.vm.formData.password = Generator.create();

                scope.$apply();

            });

        };

    }])

Saving Passwords

At this point, we want to store our passwords. The data structure for our password entries is fairly simple:

{

    "id": String

    "description": String,

    "username": String,

    "password": String

}

So all we really need is some kind of in-memory database that can optionally sync to file for backup. For this purpose, Loki.js seems like the ideal candidate. It does exactly what we need for the purpose of this application, and offers on top of it the Dynamic Views feature, allowing us to do things similar to MongoDB’s Aggregation module.

Dynamic Views do not offer all the functionality that MongodDB’s Aggregation module does. Please refer to the documentation for more information.

Let’s start by creating a simple HTML form:

<div class="insert" ng-controller="InsertCtrl as vm">

    <form name="insertForm" no-validate>

        <fieldset ng-disabled="!vm.loaded">

            <div class="mdl-textfield">

                <input class="mdl-textfield__input" type="text" id="description" ng-model="vm.formData.description" required />

                <label class="mdl-textfield__label" for="description">Description...</label>

            </div>

            <div class="mdl-textfield">

                <input class="mdl-textfield__input" type="text" id="username" ng-model="vm.formData.username" />

                <label class="mdl-textfield__label" for="username">Username...</label>

            </div>

            <div class="mdl-textfield">

                <input class="mdl-textfield__input" type="password" id="password" ng-model="vm.formData.password" required />

                <label class="mdl-textfield__label" for="password">Password...</label>

            </div>

            <div class="">

                <button generate-password class="mdl-button">generate</button>

                <button toggle-insert-view class="mdl-button">cancel</button>

                <button save-password class="mdl-button" ng-disabled="insertForm.$invalid">save</button>

            </div>

        </fieldset>

    </form>

</div>

And now, let’s add the JavaScript logic to handle posting and saving of the form’s contents:

var loki = require('lokijs'),

    path = require('path');

angular

    .module('Utils', [])

   

    ...

   

    .service('Storage', ['$q', function($q) {

        this.db = new loki(path.resolve(__dirname, '../..', 'app.db'));

        this.collection = null;

        this.loaded = false;

       

        this.init = function() {

            var d = $q.defer();

           

            this.reload()

                .then(function() {

                    this.collection = this.db.getCollection('keychain');

                    d.resolve(this);

                }.bind(this))

                .catch(function(e) {

                    // create collection

                    this.db.addCollection('keychain');

                    // save and create file

                    this.db.saveDatabase();

                   

                    this.collection = this.db.getCollection('keychain');

                    d.resolve(this);

                }.bind(this));

               

                return d.promise;

        };

       

        this.addDoc = function(data) {

            var d = $q.defer();

           

            if(this.isLoaded() && this.getCollection()) {

                this.getCollection().insert(data);

                this.db.saveDatabase();

               

                d.resolve(this.getCollection());

            } else {

                d.reject(new Error('DB NOT READY'));

            }

           

            return d.promise;

        };

    })

   

    .directive('savePassword', ['Storage', function(Storage) {

        return function(scope, el) {

            el.bind('click', function(e) {

                e.preventDefault();

               

                if(scope.vm.formData) {

                    Storage

                        .addDoc(scope.vm.formData)

                        .then(function() {

                           // reset form & close insert window

                           scope.vm.formData = {};

                           ipc.send('toggle-insert-view');

                        });

                }

            });

        };

    }])

Key Points:

                 We first need to initialize the database. This process involves creating a new instance of the Loki Object, providing the path to the database file as an argument, looking up if that backup file exists, creating it if needed (including the ‘Keychain’ collection), and then loading the contents of this file in memory.

                 We can retrieve a specific collection in the database with the getCollection() method.

                 A collection object exposes several methods, including an insert() method, allowing us to add a new document to the collection.

                 To persist the database contents to file, the Loki object exposes a saveDatabase() method.

                 We will need to reset the form’s data and send an IPC event to tell the Main Process to close the window once the document is saved.

We now have a simple form allowing us to generate and save new passwords. Let’s go back to the main view to list these entries.

Listing Passwords

A few things need to happen here:

                 We need to be able to get all the documents in our collection.

                 We need to inform the main view whenever a new password is saved so it can refresh the view.

We can retrieve the list of documents by calling the getCollection() method on the Loki object. This method returns an object with a property called data, which is simply an array of all the documents in that collection:

this.getCollection = function() {

    this.collection = this.db.getCollection('keychain');

    return this.collection;

};

       

this.getDocs = function() {

    return (this.getCollection()) ? this.getCollection().data : null;

};

We can then call the getDocs() in our Angular controller and retrieve all the passwords stored in the database, after we initialize it:

angular

    .module('MainView', ['Utils'])

    .controller('MainCtrl', ['Storage', function(Storage) {

        var vm = this;

        vm.keychain = null;

       

        Storage

            .init()

            .then(function(db) {

                vm.keychain = db.getDocs();

            });

    });   

 

A bit of Angular templating, and we have a password list:

<tr ng-repeat="item in vm.keychain track by $index" class="item--{{$index}}">

    <td class="mdl-data-table__cell--non-numeric">{{item.description}}</td>

    <td>{{item.username || 'n/a'}}</td>

    <td>

        <span ng-repeat="n in [1,2,3,4,5,6]">•</span>

    </td>

    <td>

        <a href="#" copy-password="{{$index}}">copy</a>

        <a href="#" remove-password="{{item}}">remove</a>

    </td>

</tr>

A nice added feature would be to refresh the list of passwords after inserting a new one. 

For this, we can use Electron’s IPC module. As mentioned earlier, the Main Process’ IPC module can be called in a Renderer Process to turn it into a listener process, by using the remote module. 

Here is an example on how to implement it in main.view.js:

var remote = require('remote'),

    remoteIpc = remote.require('ipc');

angular

    .module('MainView', ['Utils'])

    .controller('MainCtrl', ['Storage', function(Storage) {

        var vm = this;

        vm.keychain = null;

       

        Storage

            .init()

            .then(function(db) {

                vm.keychain = db.getDocs();

               

                remoteIpc.on('update-main-view', function() {

                    Storage

                        .reload()

                        .then(function() {

                            vm.keychain = db.getDocs();

                        });

                });

            });

    }]);

Key Points:

                 We will need to use the remote module via its own require() method to require the remote IPC module from the Main Process.

                 We can then setup our Renderer Process as an event listener via the on() method, and bind callback functions to these events.

The insert view will then be in charge of dispatching this event whenever a new document is saved:

Storage

    .addDoc(scope.vm.formData)

    .then(function() {

        // refresh list in main view

        ipc.send('update-main-view');

        // reset form & close insert window

        scope.vm.formData = {};

        ipc.send('toggle-insert-view');

    });

Copying Passwords

It is usually not a good idea to display passwords in plain text. Instead, we are going to hide and provide a convenience button allowing the end user to copy the password directly for a specific entry.

Here again, Electron comes to our rescue by providing us with a clipboard module with easy methods to copy and paste not only text content, but also images and HTML code:

var clipboard = require('clipboard');

angular

    .module('Utils', [])

   

    ...

   

    .directive('copyPassword', [function() {

        return function(scope, el, attrs) {

            el.bind('click', function(e) {

                e.preventDefault();

                var text = (scope.vm.keychain[attrs.copyPassword]) ? scope.vm.keychain[attrs.copyPassword].password : '';

                // atom's clipboard module

                clipboard.clear();

                clipboard.writeText(text);

            });

        };

    }]);

Since the generated password will be a simple string, we can use the writeText() method to copy the password to the system’s clipboard. 

We can then update our main view HTML, and add the copy button with the copy-password directive on it, providing the index of the array of passwords:

<a href="#" copy-password="{{$index}}">copy</a>

Removing Passwords

Our end users might also like to be able to delete passwords, in case they become obsolete. To do this, all we need to do is call the remove() method on the keychain collection. We need to provide the entire doc to the ‘remove()’ method, as such:

this.removeDoc = function(doc) {

    return function() {

        var d = $q.defer();

       

        if(this.isLoaded() && this.getCollection()) {

            // remove the doc from the collection & persist changes

            this.getCollection().remove(doc);

            this.db.saveDatabase();

           

            // inform the insert view that the db content has changed

            ipc.send('reload-insert-view');

           

            d.resolve(true);

        } else {

            d.reject(new Error('DB NOT READY'));

        }

       

        return d.promise;

    }.bind(this);

};

Loki.js documentation states that we can also remove a doc by its id, but it does not seem to be working as expected.

Creating a Desktop Menu

Electron integrates seamlessly with our OS desktop environment to provide a “native” user experience look & feel to our apps. Therefore, Electron comes bundled with a Menu module, dedicated to creating complex desktop menu structures for our app.

The menu module is a vast topic and almost deserves a tutorial of its own. I strongly recommend you read through Electron’s Desktop Environment Integration tutorial to discover all the features of this module.

For the scope of this current tutorial, we will see how to create a custom menu, add a custom command to it, and implement the standard quit command.

Creating & Assigning a Custom Menu to Our App

Typically, the JavaScript logic for an Electron menu would belong in the main script file of our app, where our Main Process is defined. 

However, we can abstract it to a separate file, and access the Menu module via the remote module:

var remote = require('remote'),

    Menu = remote.require('menu');

To define a simple menu, we will need to use the buildFromTemplate() method:

var appMenu = Menu.buildFromTemplate([

    {

        label: 'Electron',

        submenu: [{

            label: 'Credits',

            click: function() {

                alert('Built with Electron & Loki.js.');

            }

        }]

    }

]);

The first item in the array is always used as the “default” menu item.

The value of the label property does not matter much for the default menu item. In dev mode it will always display Electron. We will see later how to assign a custom name to the default menu item during the build phase.

Finally, we need to assign this custom menu as the default menu for our app with the setApplicationMenu() method:

Menu.setApplicationMenu(appMenu);

Mapping Keyboard Shortcuts

Electron provides “accelerators”, a set of pre-defined strings that map to actual keyboard combinations, e.g.: Command+A or Ctrl+Shift+Z.

The Command accelerator does not work on Windows or Linux. For our password keychain application, we should add a File menu item, offering two commands:

                        Create Password: open the insert view with Cmd (or Ctrl) + N

                        Quit: quit the app altogether with Cmd (or Ctrl) + Q

...

{

    label: 'File',

    submenu: [

        {

            label: 'Create Password',

            accelerator: 'CmdOrCtrl+N',

            click: function() {

                ipc.send('toggle-insert-view');

            }

        },

        {

            type: 'separator' // to create a visual separator

        },

        {

            label: 'Quit',

            accelerator: 'CmdOrCtrl+Q',

            selector: 'terminate:' // OS X only!!!

        }

    ]

}

...

Key Points:

                        We can add a visual separator by adding an item to the array with the type property set to separator.

                        The CmdOrCtrl accelerator is compatible with both Mac and PC keyboards

                        The selector property is OSX-compatible only!

Styling Our App

You probably noticed throughout the various code examples references to class names starting with mdl-. For the purpose of this tutorial I opted to use the Material Design Lite UI framework, but feel free to use any UI framework of your choice.

Anything that we can do with HTML5 can be done in Electron; just keep in mind the growing size of the app’s binaries, and the resulting performance issues that may occur if you use too many third-party libraries.

Packaging Electron Apps for Distribution

You made an Electron app, it looks great, you wrote your e2e tests with Selenium and WebDriver, and you are ready to distribute it to the world!

But you still want to personalize it, give it a custom name other than the default “Electron”, and maybe also provide custom application icons for both Mac and PC platforms.

Building with Gulp

These days, there is a Gulp plugin for anything we can think of. All I had to do is type gulp electron in Google, and sure enough there is a gulp-electron plugin!

This plugin is fairly easy to use as long as the folder structure detailed at the beginning of this tutorial was maintained. If not, you might have to move things around a bit.

This plugin can be installed like any other Gulp plugin:

$ npm install gulp-electron --save-dev

And then we can define our Gulp task as such:

var gulp = require('gulp'),

    electron = require('gulp-electron'),

    info = require('./src/package.json');

gulp.task('electron', function() {

    gulp.src("")

    .pipe(electron({

        src: './src',

        packageJson: info,

        release: './dist',

        cache: './cache',

        version: 'v0.31.2',

        packaging: true,

        platforms: ['win32-ia32', 'darwin-x64'],

        platformResources: {

            darwin: {

                CFBundleDisplayName: info.name,

                CFBundleIdentifier: info.bundle,

                CFBundleName: info.name,

                CFBundleVersion: info.version

            },

            win: {

                "version-string": info.version,

                "file-version": info.version,

                "product-version": info.version

            }

        }

    }))

    .pipe(gulp.dest(""));

});

Key Points:

                        the src/ folder cannot be the same as the folder where the Gulpfile.js is, nor the same folder as the distribution folder.

                        We can define the platforms we wish to export to via the platforms array.

                        We should define a cache folder, where the Electron binaries will be download so they can be packaged with our app.

                        The contents of the app’s package.json file need to be passed to the gulp task via the packageJson property.

                        There is an optional packaging property, allowing us to also create zip archives of the generated apps.

                        For each platform, there is a different set of “platform resources” that can be defined.

Adding App Icons

One of the platformResources properties is the icon property, allowing us to define a custom icon for our app:

"icon": "keychain.ico"

OS X requires icons with the .icns file extension. There are multiple online tools allowing us to convert .png files into .ico and .icns for free.

Conclusion

In this article we have only scratched the surface of what Electron can actually do. Think of great apps like Atom or Slack as a source of inspiration where you can go with this tool.

I hope you found this tutorial useful, please feel free to leave your comments and share your experiences with Electron!

;;

Source: Originally published on the Toptal Engineering blog

Electron is a popular framework for building cross-platform desktop applications using web technologies such as HTML, CSS, and JavaScript. Electron uses Node.js and Chromium to provide a runtime environment for building desktop applications that can run on Windows, macOS, and Linux.

To build an Electron app, you need to have a good understanding of web technologies, particularly JavaScript and HTML. You will also need to learn how to use Node.js, which is the runtime environment that Electron is built on.

Here are the basic steps to build an Electron app:

Set up your development environment: You'll need to install Node.js and Electron on your machine, and set up a code editor such as Visual Studio Code.

Create your app: You can use HTML, CSS, and JavaScript to build the user interface of your app, just like you would for a web app.

Integrate with Node.js: You can use Node.js to perform file operations, access system resources, and interact with the operating system.

Package your app: Once your app is complete, you can use Electron's packaging tools to create an executable file for each platform you want to support.

Distribute your app: You can distribute your app through various channels, such as an app store or a website.

Electron provides a rich set of APIs for building desktop applications, including access to system resources such as the file system, the clipboard, and the network. With its ease of use and cross-platform capabilities, Electron is a great choice for building desktop applications that can run on multiple operating systems.