Skip to main content

Cheqee: Or, How to Write and Publish a Mobile App In a Couple of Hours for Free for Anyone

For the first time in a long time I wanted to write a brand new little app, from scratch, just for fun. I was feeling the Joy of Coding coming back after a long hiatus. So, yay for me? Yay for me. The idea for a single-case app for the kinds of repeating chores of the day has been knocking around in my head, so I whipped out npx create-react-app and tinkered on my laptop while watching TV.

In about an hour and a half I made Cheqee, the Simple app for the things you do every day.


I was thrilled to be reminded of how quickly an entirely new application can be built from scratch and published as a PWA (Progressive Web App) and "installed" on any phone and used like any app by anyone around the world, so here's the things I accomplished in just a couple hours total and in this post all the pieces that went into making that happen so effortlessly:

  • Wrote a brand new app that does a simple job, built quickly but easy to expand and improve
  • Incorporated persistent data for a totally static web app without a server
  • Published the web app where anyone can use it
  • Made that same app installable on phones via browsers' "Add to Home" features
What made these four pieces possible and how did they all go?

Built a Brand New App from Scratch

React just makes building new things a breeze and, after building a lot of brand new things and maintaining lots of older projects with React now for a couple years, I think I've narrowed down the reason why: you can iterate fast with React.

"Iterate fast" means you can make lots of steps as you go, testing and sharing and getting feedback from yourself or others to fold back into an app you're building very quickly. The architecture of a new React app naturally carves boundaries that let you make changes fast and safe. Every application can break, but a React app is really stable when you make lots of small iterations fast. It is really rare that you have to make "giant commit" changes that require a lot of development while the app is basically broken and unusable until you get the new feature totally built out.

This was my first time using create-react-app but I'll definitely recommend it now. Prior, I had my own skeleton app I copied for new projects, but I like starting with an even tighter template and taking the work off me to keep that starting point updated as new React releases come out. I'll be using it in the future. Just running this was all I needed to create and start tinkering on a new React app:

npx create-react-app cheqee
cd cheqee
npm start

After that I just kept tinkering on Javascript until I had a prototype behaving how I liked, then I took a break and tinkered on CSS until it looked kind of decent.

So, React is just fantastic for building new things with loose specs or a vague idea. I only had a basic concept of Cheqee in mind when I started and I like how it turned out, both in code and in use.

Incorporated Persistent Data without a Back-end

Obviously tracking anything, which Cheqee is meant to do, isn't really helpful if the app can't remember anything. I don't need a back-end, or at least I don't want to need a back-end so I decided to implement some simple client-side storage, of which we have tons of options these days. The trick is how to connect a storage option to the React app and its state.

Here's a really simple trick to persist a simple app state:

class App extends Component {
  constructor() {
    super()
    let state
    let data = localStorage.getItem("data")
    if (!!data) state = JSON.parse(data)
    this.state = state || {
      taskLists: [],
    }
  }
  componentDidUpdate() {
    localStorage.setItem("data", JSON.stringify(this.state))
  }

Almost nothing to it! When the application starts up, it will look for a JSON string in local storage and try to parse it. If there isn't any data, it'll create a blank state. Every single time the state is updated it automatically becomes serialized.

The rest of the app doesn't care about storage at all. As long as the React state remains JSON-serializable the entire application's state is just magically persistent without any additional work and its all transparent to the user.

Easily Published and Distributed the App to Anyone

Now, I needed to actually put this thing somewhere. I decided it was time to try out the amazing Glitch service for more than just a very fancy pastebin, which is kind of how I always used it before.

It could not have been easier.

All I did was import my new app's Github repo into a project on Glitch, which I named for a good URL and didn't need any other changes. It automatically kicked off a build, ran the proper NPM script commands, and my app was running in just a few seconds and accessible on my phone.

It was honestly so easy that this part of the story is pretty boring.

Installable App without an App Store

Just being able to get at the app wasn't enough. I wanted it to "feel like an app" and I've been using PWAs for a while now, but haven't built one. (Although I've used many of the components and related bits in other projects)

Mainly that meant being able to "install" the app through the "Add to Home" option mobile browsers can give.



This didn't require anything more complicated than a simple manifest file, linked in my index.html file and detailing the application, its icon, and the "display" mode that tells it to act like a standalone app. Really straight forward in more of that "so dead-simple its exciting how boring it is" way.

{
  "short_name": "Cheqee",
  "name": "Simple app for the things you do every day",
  "icons": [
    {
      "src": "favicon.ico",
      "sizes": "64x64 32x32 24x24 16x16",
      "type": "image/x-icon"
    }
  ],
  "start_url": ".",
  "display": "standalone",
  "theme_color": "#000000",
  "background_color": "#ffffff",
  "scope": "https://cheqee.glitch.me/"
}

And... that was it.



Honestly its just mind-blowing how quickly you can go from a little idea to an app millions of people could use without any real barrier. Building software can get us jaded quickly and can teach us to really get frustrated at technology and computers and, well, at building software.

Don't be afraid to be excited about building software again!

Oh... and you can check out Cheqee if you want, but it only works on mobile (looks like trash on anything else) but you can gander at the repo if you want, too.

Comments

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this.


CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…

How To Care If BSD, MIT, or GPL Licenses Are Used

The two recent posts about some individuals' choice of GPL versus others' preference for BSD and MIT style licensing has caused a lot of debate and response. I've seen everything as an interesting combination of very important topics being taken far too seriously and far too personally. All involved need to take a few steps back.

For the uninitiated and as a clarifier for the initiated, we're dealing with (basically) three categories of licensing when someone releases software (and/or its code):
Closed Source. Easiest to explain, because you just get nothing.GPL. If you get the software, you get the source code, you get to change it, and anything you combine it with must be under the same terms.MIT and BSD. If you get the software, you might get the source code, you get to change it, and you have no obligations about anything else you combine it with.The situation gets stickier when we look at those combinations and the transitions between them.

Use GPL code with Closed S…

Using a React Context as a Dispatch Replacement

React Contexts are the pretty little bows of the React world.

Here's a really quick example of the kind of messy code you can cleanup by using contexts, without dragging in a larger dependency like Redux or even Flux. Starting backwards with a diff showing lines of code I was able to remove:


All the properties I was able to remove were just pass-through. The Carousel component didn't care about any of them, but it had to pass through these callbacks so the multiple TaskList components inside the carousel could invoke actions. They were removed from the Component class itself, too, since it no longer needed to pass them through.

Where did they all go?


My ActionContext removed all the need for these passthroughs by providing a single simple helper method, action(), that components rendered under it can access.


I really enjoy the pattern of passing a single callback through a context and removing what used to be lots of callback properties. Of course, I could be using a proper di…