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

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro