Forem: Varun S

Creating a Status Page with Pure HTML, CSS, and JavaScript

Varun S — Sun, 10 Apr 2022 02:42:46 +0000

Running multiple local PHP web servers

Varun S — Sat, 17 Apr 2021 00:16:07 +0000

PHP is a both a front-end and back-end scripting language. If you've also used PHP for both ends of a full-stack application, you might relate to the frustration of looking for a free, high-quality local development tool for full-stack PHP developers.

With JavaScript, you can start a server directly in code, choose the port, and rewrite the urls without hassle, using Node's core http module.

Similarly, Java supports the feature through, for example, Sun's NET HttpServer package and C# as well.

But PHP is different from other languages. To start up the built-in web server, you use the following command:

php -S localhost:8000

Unfortunately, this creates only a very basic server that cannot rewrite files or interact with a database easily.

To resolve this, the recommended approach for hobbyists like myself is to use an Apache distribution:

XAMPP
WAMPServer
LAMP (Linux)

The above are all tech stacks with PHP, MySQL, and Apache. The Apache server will read the .htaccess file before serving a page, which means you can make more user-friendly URL names.

The Problem

And now comes a problem. You can only run one server at a time using Apache, so let's say you choose the front-end.

What do you do with the back-end? My initial reaction when trying this out myself was to use the PHP command for this.

This works, only partly. The REST API also uses url rewrites on the live server, and I want to make it as close as possible so I can minimize or even eliminate "development mode" conditionals.

The Solution

The solution is to use a router.php file. Here's an example:

<?php

chdir(__DIR__);
$filePath = realpath(ltrim($_SERVER["REQUEST_URI"], '/'));
if ($filePath && is_dir($filePath)){
    // attempt to find an index file
    foreach (['index.php', 'index.html'] as $indexFile){
        if ($filePath = realpath($filePath . DIRECTORY_SEPARATOR . $indexFile)){
            break;
        }
    }
}
if ($filePath && is_file($filePath)) {
    // 1. check that file is not outside of this directory for security
    // 2. check for circular reference to router.php
    // 3. don't serve dotfiles
    if (strpos($filePath, __DIR__ . DIRECTORY_SEPARATOR) === 0 &&
        $filePath != __DIR__ . DIRECTORY_SEPARATOR . 'router.php' &&
        substr(basename($filePath), 0, 1) != '.'
    ) {
        if (strtolower(substr($filePath, -4)) == '.php') {
            // php file; serve through interpreter
            include $filePath;
        } else {
            // asset file; serve from filesystem
            return false;
        }
    } else {
        // disallowed file
        header("HTTP/1.1 404 Not Found");
        echo "404 Not Found";
    }
} else {
    // rewrite to our index file
    include __DIR__ . DIRECTORY_SEPARATOR . 'index.php';
}

I then ran php -S localhost:8100 router.php in the root directory of my API.

Conclusion

And Voila! I was able to communicate between the front-end and back-end server without needing to deploy until I was ready!

Here is the StackOverflow question that helped to this solution: https://stackoverflow.com/questions/27381520/php-built-in-server-and-htaccess-mod-rewrites

I hope you found this post useful. Do you know any alternatives or easier ways to accomplish the same task? Leave a comment down below!

How I Wrote A Background Noise Remover from Start to Finish

Varun S — Wed, 31 Mar 2021 15:26:23 +0000

How do so many communication apps, like Signal and Telegram, get rid of all the static-y noise and background noise before the sound reaches the other people on the call?

These companies include noise removal in their software, and in a recent coding project, I wanted to do just that.

In this article, I will break down what I needed, how I made it, and the obstacles I faced along the way.

When I say ambient noise, background noise, or simply, noise, I am talking about sound that you do not want to hear in an audio file. This sound disrupts the signal, sound you do want to hear, in an audio file or incoming sound.

My plan was to somehow identify the noise so I could filter it out, then write the noise-removed-audio file to an "output" file once the program did its main functions so that I could compare and collect data.

Research

Researching this was hard. It took me a while, but I found a tutorial on the Kalman Filter. This explained all the background knowledge needed to understand the Kalman Filter, explained the Kalman Filter, and gave examples.

The Kalman Filter has two types: One-Dimensional and Multi-Dimensional. The Multi-Dimensional Kalman Filter involves linear algebra concepts that I had to learn. So, I started learning linear algebra concepts and buried myself in lengthy research papers on the covariance matrix and eigenvectors.

I eventually found that the only concepts needed for the Kalman Filter with regards to linear algebra were matrices, vectors, and their operations. I also found a helpful video on the covariance matrix that explained what the research papers were describing, in 10 minutes.

In addition, I learned the Java Sound API on Oracle's official programming guide so that I could use Java to apply the Kalman Filter to sound. Unfortunately, the Java Sound API did not provide the low-level functions that I needed. The only useful function was the byte data, which is binary data that represents the sound, of the audio file. I then had to use Linear Pulse Code Modulation to determine the sound wave, and then apply the Kalman Filter from there.

Kalman Filter

The Kalman Filter is an estimation algorithm that lets you find the value of an object that you may never know for sure, called a "hidden state" but get very close to it by measuring the object and going through a series of equations that lets you converge to the true value.

For example, if you want to use the Kalman Filter to find the weight of a bronze Trojan horse, its hidden state might be 200kg (because of all the men inside) and your final state estimate, which is what you get when you put your measurement through a bunch of equations, is 198.4 kg.

In the Kalman Filter, every time you measure, you update your state estimate using an equation. Then, you predict the next state estimate, which you calculate after your next measurement.

The Kalman Filter uses the prediction-correction mechanism.

The Kalman Filter follows the "measure, update, predict" cycle.

How it Works

Going back to the Trojan Horse example, let's say you set your initial guess to 100kg. The sole purpose of the initial guess is to get the cycle started.

In addition, you need to set your initial guess for the estimate uncertainty. In other words, use a number between 0 and 1 representing how uncertain you are about 100kg being the hidden state.

Then, you finish the "0th" iteration of the Measure, Update, Predict cycle. These initial guesses are the "estimates," so now you need to make the prediction. Because you don't have a measurement yet, the predictions are the same as the estimate, and they are going to be used in the 1st iteration.

You put the Trojan Horse on a scale and you see "195kg." This is your measurement
Calculate the Kalman Gain. As this factor increases, the measurement is given more weight and as it decreases, the measurement is given less weight and the estimate is given more weight, as shown below.

Kalman Gain Equation

The Kalman Gain uses the estimate uncertainty and the measurement uncertainty in its calculation. The measurement uncertainty is a constant value between 0 and 1 that you set in the beginning.

Now, plugging in the prediction from the 0th iteration (the previous state prediction) - 100kg - and your current measurement - 195kg - into the State Update Equation, you get your state estimate.

State Update Equation

Next, you update the estimate uncertainty with another equation, the Covariance Update Equation.
Finally, you predict the next estimate and the next estimate uncertainty using the final 2 equations in the Kalman Filter algorithm.

And that's the cycle for the One Dimensional Kalman Filter. You can make it even simpler by ignoring the uncertainty. You now make another measurement and keep cycling through until you've made all the measurements you would like.

When you graph the estimate and hidden state as the y values and the iteration # as the x-value, you'll see the estimate converge to the true value.

Implementing the Kalman Filter

The kalmanfilter package was the first module I worked on after experiment a little bit with the Java Sound API (and mostly failing). Because I love to code, I didn't even implement the Kalman Filter first. I implemented simpler filters that also follow the "measure, update, predict" cycle: AlphaFilter, AlphaBetaFilter, and AlphaBetaGammaFilter.

Following test-driven development, I tested these with the values in the examples from the same site that taught me the filters themselves: kalmanfilter.net. I made the right decision testing, for I immediately faced lots of failing tests because of lots of bugs.

In addition to giving me testing experience, of which I have very little, implementing similar and simpler filters helped me hammer out the bugs that would likely have appeared in the Kalman Filter had I started with that. Starting off simpler let me focus on the more complicated bugs when I finally got to the more complicated filters.

Linear Pulse Code Modulation and Sound Manipulation

Sound files use a format called Linear Pulse Code Modulation to represent sound as numbers. At a specified sample rate, the bytes of data are specific amplitudes, and together they make sine waves, which is how sound is represented.

At first, I thought that the byte data itself were the samples that could be directly converted to sine waves. When the audio file was corrupted and produced unintelligible noise.

More than two months into my project, I discovered an algorithm on Stack Overflow that let me abstract the [bitwise operations], the intermediate step between the byte data and the sine waves which I knew how to manipulate.

And these worked like a charm! Increase the a value (amplitude) and its louder, increase the product inside the Math.sin() and the pitch goes higher. I could then combine float (a data type for decimal numbers) samples together to add sine or sound waves.

And when I added an amplitude and its negative, I got the expected silence. This is called destructive interference - when you add a sound sine wave and the inverse sine wave together. In mathematical terms, you got a horizontal line, and in sound terms, that's complete silence.

Modeling Matrices and Vectors

The multidimensional Kalman Filter uses matrices, which are rectangular arrays of numbers, and vectors, which are single-dimensional arrays of numbers. I had the most fun building this because I was working with a concept that I had already been introduced to in school, and I was using Java syntax that I was familiar with.

I created a Matrix class that held a two dimensional array for the matrix and a Vector class that extends the Matrix class and held a one dimensional array.

Following test-driven development, I first made a Matrix test class and VectorTest class.

For the matrix addition test, I called my Matrix#add() method on the first matrix passing in the second matrix. I then checked if the sum matrix was the correct value by creating a third Matrix object.

@Test
public void testMatrixAddition() {
    Matrix addend = new Matrix(new double[][] { { 1, 2, 3 }, { 4, 5, 6 } });
    Matrix augend = new Matrix(new double[][] { { 10, 14, -8 }, { 3, 1, 5 } });

    Matrix sum = addend.plus(augend);

    assertArrayEquals(new double[][] { { 11, 16, -5 }, { 7, 6, 11 } }, sum.getMatrixElements());
}



public Matrix plus(Matrix augend) {
    if (!(getRows() == augend.getRows() && getColumns() == augend.getColumns()))
        throw new IllegalArgumentException("Cannot add matrices of different dimensions");
     Matrix toReturn = new Matrix(new double[getRows()][getColumns()]);

    for (int i = 0; i < getRows(); i++) {
        for (int j = 0; j < getColumns(); j++) {
            toReturn.set(i, j, matrixElements[i][j] + augend.getMatrixElements()[i][j]);
        }
    }

    return toReturn;
}

After implementing Matrix#add, I continued for the subtraction, multiplication, inverse (which was so complicated I ended up extracting into its own class), and transpose operations, each time testing before implementing. I also included various methods concerning properties of the matrix, such as

getDeterminant()
isSquare()
isIdentityMatrix()
isInverse(Matrix inverse)

Finally, I implemented static factory methods for generic matrix types, which right now is only for the identity matrix, which is where 1's span the major diagonal and everything else in the matrix is a zero, and it is a square matrix. For example, the 3x3 identity matrix is [[1,0,0],[0,1,0],[0,0,1]]

Results

When I got rid of all Math.random()s, NullPointerExceptions and UnsupportedOperationExceptions, which stopped my program from fully running, I found no change in the audio file.

Conclusion

Ambient Noise Remover was a huge challenge, and I have not successfully removed background noise, yet. I, however, learned so much from the experience, from sound engineering to linear algebra to Java APIs.

Here is the link to the code (open source!): https://github.com/Ambient-Noise-Remover

It is also available as a JAR file, just make sure you have installed the Java JDK before downloading my program!

If you'd like to learn the Kalman Filter in detail, I suggest the tutorial website (https://kalmanfilter.net), as it explains everything very simply.

Thanks for reading my article! Do you have a project that involves a complex math topic, such as linear algebra? Leave a link to it in the comments!

How I Documented, Encrypted, and Tested My First REST API

Varun S — Mon, 11 Jan 2021 02:30:19 +0000

I added a lot more to my REST API than just the JSON responses. Borum Jot was the first project I tried seriously unit testing my code, encrypting the data, and documenting my back-end. In this article, I will discuss cybersecurity, software testing, and documentation of my REST API.

Encryption

I encrypted my data using defuse/php-encryption. This library, claiming to be secure, unlike other libraries, did the encryption and decryption for me. To encrypt and decrypt, I needed my own key, which I generated by running

$ composer require defuse/php-encryption
$ vendor/bin/generate-defuse-key

Composer is a package manager for PHP applications. The key is 256 bits long and can be stored either in a file (unsecure), or in the environmental variables. Vercel has a built-in way of storing environmental variables, and was the best place, without extra tools, for me to store the key.

Truthfully, I stored the key in a text file in the etc folder in the root directory because I didn't realize I could store it in the $_ENV at the time. This is highly insecure, so I am going to move this into a secure environmental variable soon

Then, at each request that updated or created data that I wanted to encrypt - task and note details - I loaded the key and called the encryption function. Similarly, for each request that fetched data that I encrypted, I loaded the key and decrypted before sending the response. This way, the front-ends never had to worry about encryption or decryption because I wrote everything on the backend, once.

Documentation

To document my APIs, I got inspiration from the Stack Exchange API documentation. I used NextJS to make a static documentation site for the entire Borum ecosystem, including Borum Jot. Then, for each page, I specified the request method, request headers, query string, request body (for POST, PUT, and DELETE requests), and response body.

Here is a given page of my developer documentation website, which is live, hosted by Vercel, and open-source on GitHub:

A sample Borum Jot endpoint API reference on my Borum Dev Documentation site

Because I am fluent in JavaScript, I did not have any trouble setting up the documentation site. I have a JSON file with data on each endpoint that I update whenever I update the Borum Jot REST API.

I suggest including the following as a bare minimum when documenting REST or other Web API's:

Request Headers
Request Query String
Request Method
Request Body
Response Body

Testing

I used PHPUnit, a PHP unit-testing framework, and GuzzleHttp, a PHP HTTP client, to unit test my application. GuzzleHttp acts as a client to the REST API server, making requests and asserting information about the responses.

namespace BorumJot\Tests;

use PHPUnit\Framework\TestCase;
use GuzzleHttp\Client;

class LoginTest extends TestCase {
    private $http;

    public function setUp() : void {
        $this->http = new Client(["base_uri" => "https://api.jot.bforborum.com/api/v1/"]);
    }

    public function testPost() {
        $response = $this->http->post('login');

        $this->assertEquals(200, $response->getStatusCode());

        $contentType = $response->getHeaders()["Content-Type"][0];
        $this->assertEquals("application/json; charset=UTF-8", $contentType);
    }
}

The TestCase is a superclass in PHPUnit that indicates that the class contains test cases. The setUp() method is called by PHPUnit before each test. GuzzleHttp's Client class's "request-method methods" (like .get() and .post()) provide information on the response, such as the headers and status code as shown above.

Setting Up Unit Testing

First I had to run composer install phpunit/phpunit guzzlehttp/guzzle to install the PHPUnit and GuzzleHttp packages.

I added the following to composer.json into the top-level object.

"scripts": {
   "test": "phpunit tests"
}

This will substitute phpunit tests for composer test. It is a common practice to substitute the unit testing framework command for the package manager's command to have one command prefix to rule them all. However, this is not necessary, for you could simply run phpunit tests.

The last step is to configure phpunit to find the folder with all the unit tests. I put mine in the root directory and called it tests, but you can call it and place it anywhere you would like, except maybe in auto-generated folders.

<?xml version="1.0" encoding="UTF-8"?>
<phpunit bootstrap="vendor/autoload.php">
    <testsuites>
        <testsuite name="Borum Jot REST API Test Suite">
            <directory suffix=".php">./tests/</directory>
        </testsuite>
    </testsuites>
</phpunit>

Replace ./tests/ with the path to the folder with the unit tests. The test suite is an arbitrary name you give to a group of tests to identify it.

And that's how I documented, tested, and encrypted the data of my first REST API. Have you ever documented your own API? What tools did you use? Share your own projects down below!

How I Wrote My First Web API

Varun S — Wed, 16 Dec 2020 13:14:31 +0000

As part of my Borum Jot project, I made a Web API for all my front-end platforms to create, retrieve, update, and delete (CRUD) data on the database. In this article, I'll discuss what exactly an API is and how I made my own Web API.

There are two main kinds of APIs.

One is a software and its documentation, and this is used very liberally. For example, the old JavaScript library jQuery has a documentation so developers know how to use it. This documentation web site is referred to as the jQuery API. Other examples are documentations for programming languages, frameworks, or even ecosystems. It is usually specified in the URL, even if it's not directly on the page.

Thanks to @mankms on Twitter, I learned that a Web API refers to sets of pages to which clients make network requests, and they return back data, possibly querying a database, in a specific structure. I like to think of a Web API as part of a filtration system:

This concept is called information hiding, and it is important for simplicity and security. But before I could begin hiding information, I had to obtain information. I began by choosing a language.

Choosing a Language and Content Type

I used PHP, a back-end language, for my API. A back-end language sits on the server and accesses data.

I used JSON, or JavaScript Object Notation, for the content type. It is used to represent data in nested objects. In my API, I sent JSON that looked like this:

{
    "statusCode": 200,
    "data": [
        {
            "id": "10",
            "title": "Go to Grocery Store",
            "body": "Go to this grocery store",
            "user_id": "115",
            "completed": "1",
            "time_updated": "1038829292",
            "parent_id": "0",
            "priority": "0",
            "source": "task"
        }
    ]
}

Once the client receives the above response and parses the JSON, it can retrieve the value of any property, such as statusCode.

Host Configuration and File Structure

I now knew I was writing in PHP to make a Web API that sends JSON to a client (the front-end). Surprisingly, where I hosted was very important at this point. I deployed on Vercel, a hosting platform. Although Vercel is designed for JavaScript and React-type projects, the vercel-php runtime allows developers to host backend PHP projects on a secure domain (as opposed to directly on the domain registrar, which may require configuring GitHub, paying for an SSL certificate, etc.).

Because I was deploying on Vercel, I needed to store all the endpoints in the api directory and configure the now.json file. The now.json file tells vercel-php which files were serverless functions. These serverless functions served as the API endpoints that sent the response data in JSON format.

Vercel Function Logs

In addition, I've seen APIs specify their version (e.g. v1). So far, this was my file structure (note the composer.json is for including PHP libraries)

api/
    v1/
       ?
now.json
composer.json

What would go inside the v1 subdirectory?

Writing my First Endpoint

Finally, I could begin writing the code (the fun part!).

In its simplest form, a Web API is one PHP file that returns the JSON, such as one of the examples above, on every request.

<?php 

header("HTTP/1.1 200 OK");
header("Content-Type: application/json; charset=UTF-8");

echo json_encode(["english" => "Hello world!", "french" => "Bonjour!", "german" => "Guten tag!"];

?>

Notice the header function calls, establishing the server response headers. The 200 OK is an HTTP Status Code that tells the client that everything ran okay and it can now access the data. The json_encode turns a PHP Associative Array into JSON format. The API deploys through Vercel and has the following as its now.json file:

{
  "functions": {
    "api/v1/*.php": {
      "runtime": "vercel-php@0.3.1"
    },
  },
  "routes": [ 
   { "src": "/v1/greeting", "dest": "/v1/greeting.php" }
  ]
}

The functions object specifies the directories that have API endpoints and will always have the same runtime property. The routes array contains paths at the location of dest that rewrite the url to src. In the above example, /v1/greeting.php simply becomes /v1/greeting.

Helper Classes and Added Complexity

The second level of complexity was to interact with the database. I created a separate folder called include and put it in the api directory in case I wanted to have a v2. Remember, putting everything in one file still makes it an API, but I put database handling in a separate class to make my code DRY and modular. When I have more than one response object (such as a GET and POST request to the same endpoint, or multiple endpoints), I could call code I had already written. My modified file structure looked like this:

api/
    include/
       Config.php
       SimpleRest.php
       DBHandler.php  
    v1/
       greeting.php
now.json
composer.json

I copied the SimpleRest code from another site, expanding to fit to my API.

For every response from this point, I had only to call SimpleRest::setHttpHeaders(200) or another status code, replacing multiple header() calls with one method call of my own class.

Database Interaction

First and foremost is a Config.php file for database interaction. I used the mysqli_connect() call to connect with my database credentials to the MySQL database I host on GoDaddy. Next, I stored the PHP Connection object inside an instance variable named $conn in the DBHandler class in the constructor.

For every database-querying function, I wrote an instance method in the DBHandler class. Once my database, app, and API got larger, I expanded this into its own folder and namespace, but for now, I could keep everything in one class.

For instance, I wrote the createNewUser() method for a POST request to the register.php endpoint. Below is the code of this method.

public function createNewUser($firstname, $lastname, $email, $password) {
        if ($this->newUserValid($email)) {
            $query = "INSERT INTO firstborumdatabase.users 
                (first_name, last_name, email, pass, registration_date) 
                VALUES ('$firstname', '$lastname', '$email', SHA2('$password', 512), NOW())
            ";
            $newBorumUserResult = $this->executeQuery($query);
            if (mysqli_affected_rows($dbc) == 1) { # Query ran okay
                $accountId = $this->executeQuery("SELECT id FROM firstborumdatabase.users ORDER BY registration_date DESC LIMIT 1");
                $accountId = mysqli_fetch_array($accountId, MYSQLI_BOTH);
                $apikey = $this->generateApiKey();

                // If the generated api key is taken, keep generating until a unique one is found
                while ($this->apiKeyExistsInDatabase($apikey) != true) {
                    $apikey = $this->generateApiKey();
                }

                // Insert the newly created Borum user into the Borum Jot `users` table
                $newBorumJotUserResult = $this->executeQuery("INSERT INTO users (borum_user_id, time_created, api_key) VALUES ($accountId, NOW(), '$apikey')");
                if (mysqli_affected_rows($dbc) == 1) { # Query ran okay
                    return [
                        "ok" => true,
                        "statusCode" => 200
                    ];
                }
            }             
            return [
                "error" => [
                    "message" => "The user could not be validated at this time"
                ],
                "statusCode" => 500
            ];
        } else {
            return [
                "error" => [
                    "message" => "User with that email already exists on Borum"
                ],
                "statusCode" => 500
            ];
        }
    }

And in the endpoint file, I would call it and my helper methods inside of one case of a switch statement that checks the request method:

case 'POST':
        SimpleRest::handlePostParameterValidation("name");

        $newnoteres = $handler->createNote($_POST['name']);

        SimpleRest::setHttpHeaders($newnoteres["statusCode"]);
        echo json_encode($newnoteres);
break;

The $handler variable instantiates a new DBHandler object (or a subclass of that). I put a statusCode property in each JSON response so I could easily set the status code header.

And that's what I did for every new response that I needed to create - I made a new method that queried the database in a DBHandler class. If you know how to use PHP with MySQL, and you followed everything described above, you're ready to make your own Web API!

Don't I have to document it? What about unit tests? Stay tuned for Part 2, where I'll be covering all of this and more!

How I wrote my first full-stack Android app

Varun S — Sun, 29 Nov 2020 21:47:49 +0000

In the span of 4 months, I planned out a mobile app idea, self-taught myself the Android framework, wrote my first REST API, and released my finished Android app on the Google Play Store. I learned a lot along the way, so I thought I'd share what I learned.

The app I made was a to-do app combined with a note-taking app. Users would be able to filter out and in their notes and tasks as they please, and maybe I'd even allow them to convert a task to a note, and vice versa.

This project had 5 major components: Preparation, Front-end, Back-end, Unit Testing, and Play Store Releasing. Below are all the things that helped me make my app.

Preparation

Even though I did not know a line of Android code, I knew that one could write an Android app in Java. I knew a lot of languages, but didn't know the frameworks for many of them, rendering my knowledge of most of them useless. Learning Android was a chance for me to make Java a useful language for me by getting into mobile app development.

I used TutorialsPoint to learn XML and Java within the Android framework. In addition to taking notes, I coded along with the tutorial to make one giant app that didn't really do anything, but demonstrated everything I learned.

Meanwhile, I was looking for a good wireframing desktop app. Wireframing is a set of sketches for an app that shows the structure and the layout. I was starting to focus on user interface more in my projects, and I had started employing more software development skills. I read up on how to plan a mobile app, and after sketching a few screens in my paper notebook, I found Pencil. It was lightweight, but some other developers said they prefer lightweight software for wireframing, so I went with it. It's also free of charge, another criterion for which I was searching.

My low-fidelity wireframe on paper of Borum Jot

The benefit of going through multiple stages before beginning coding, is, especially for a brand new platform, I could make the critical design choices here so that I could focus on functionality when I finally got to coding.

Pencil was what I considered my high-fidelity, or "hi-fi", wireframe. I actually drew almost every screen, but I didn't focus on the color theme. I just wanted to figure out how and where I would lay out the features.

Next, I moved on to my mockup. I knew that this was still a personal project that only so many people would look at, so I chose the same software for mockup as I did for prototype: Adobe XD. Adobe XD is a powerful free Windows app for making mockups and prototypes. The thing is, it has a learning curve. After watching tutorials, I was well on my way to...

And for the prototype, I wired the "artboards" together in Adobe XD. The rectangles were perfectly aligned, the colors were exactly how I planned it to look, and the prototype functioned to the good extent that a dataless software could.

After two months of planning and learning, I was ready to begin my app.

Front End

I started with the XML, of course. The XML layout files were the markup, meaning they didn't really use logic. I made one activity (that's what Android calls a screen) a day, and in around 2 weeks, I had nearly imitated my mockup (except for a lot of the details within, for example, the task screen).

Next, I worked on implementing navigation between the activities using Java. I didn't worry about any data fetching, just on UI, including styles and logic. And for almost every non-lifecycle Java method I wrote, I attached a multiline comment to it.

%[https://gist.github.com/Borumer/d76ef92e042f62507e7de5250ffad27d]

In even less time, I had successfully mocked a lot of my mockup with actual code.

Back End

This was my first time, or so I thought, separating the back end from the front end. I wondered what voodoo magic developers used to create a REST API and an "external API endpoint" and I wanted to make one myself.

However, it turns out I had already made full-stack web apps before, just not technically REST APIs. I knew PHP and a REST API is simply a set of pages written in a backend language, like PHP, that give either XML, HTML (rare), or JSON output and return the standard HTTP status codes. If one knows how to use PHP to query a database, he or she can make a REST API.

The key part here is REST, which stands for Representational State Transfer, is an architectural style. No extra classes are required, except those that help the developer give output and set HTTP headers. I created a class called RestService that had a static method for setting the header with a status code, and setting the Content-Type to application/json. With classes that queried the database, classes that helped with validation and header sending, and the PHP pages that instantiated and invoked all of their methods, called the API endpoints, I effectively created a REST API.

API Deployment

I went back and forth between writing new backend code and writing new frontend code for the remaining two months, except for one hiccup. I used Vercel, a great freemium hosting platform, for hosting my API and GoDaddy for the domain. Vercel uses Amazon Web Services to deploy its site, and Amazon Web Services used dynamic, or constantly changing, IP addresses. In order to fetch data from the database I created on my GoDaddy hosting account, I needed to whitelist the IP Address of the API that I made. This created a problem because there was no specific IP for Vercel's servers. After calls for help, I ended up (very insecurely, but without any other viable option) whitelisting ALL addresses with %.%.%.% to resolve the issue.

Unit Testing

As I mentioned earlier, I wanted to employ techniques used by professional software developers. One of these was software development testing. I had done a course on EdX that covered how to write unit tests, so I wanted to make this a norm for my programming projects.

Android Studio, the IDE I used for making the front end of the project, has as part of every Android project a folder for testing. The Android framework starts with Mockito and JUnit for unit testing. I wrote a few unit tests for my simpler modules (such as the purely Java ones) and didn't bother with the Context and interface-based ones. Here's an example that tested if my LoginValidation returned the correct string based on whether the email and password matched correctly.

public void loginCredentialValidation_isCorrect() {
    LoginValidation loginValidation = new LoginValidation(mMockContext, "armageddon@gmail.com","pass");
    String resultWithInvalidCredentials = loginValidation.validate();
    assertEquals(resultWithInvalidCredentials, LoginValidation.SUCCESS);
}

Although I didn't test everything, and certainly not on par with all testing principles, I did introduce myself nicely to the skill. If you're also new to unit testing, I would suggest postponing writing tests until you know the language and the framework really well. Although this doesn't comply with Test-Driven Development, writing code not only in a new framework (Mockito and JUnit), for a new framework (Android), for a new purpose (software testing) can be very overwhelming if you're already new to the technologies themselves.

Google Play Releases

A Google Play Developer Account (which has a one-time $25 fee) gave me access to the Google Play Console, which let me upload my Android app as a .aab file (Android App Bundle), which makes my code understandable by the Android operating system. I released for every feature that I added and utilized the different forms of testing.

Conclusion

I hope this guide was helpful for anyone wanting to build their own mobile app. Even if you're using Kotlin instead of Java, or JSON instead of XML, most things mentioned stay the same. Have you made a mobile app before? Was your journey similar to mine? Leave a comment down below!

The app is public and available for download: https://play.google.com/store/apps/details?id=com.boruminc.borumjot.android
I would greatly appreciate if you checked my app out!

Originally published on HashNode at https://varuns.hashnode.dev/my-first-full-stack-android-app