Forem: Jonathan P

How to make a cross-platform serverless video sharing app with Flutter, Firebase and Publitio

Jonathan P — Tue, 26 Nov 2019 00:00:00 +0000

What we're building

We'll see how to build a cross-platform mobile app that allows users to upload and share videos.

The stack

Flutter - A new cross-platform mobile app development framework by Google, using the Dart language.
Firebase - The serverless real time database, for storing and syncing video metadata between clients.
Publitio - The hosting platform we'll use for storing and delivering the videos.

Why Flutter

Flutter gives us a way of writing one code base for both iOS and Android, without having to duplicate the logic or the UI.
The advantage over solutions like Cordova is that it's optimized for mobile performance, giving native-like response. The advantage over the likes of React Native is that you can write the UI once, as it circumvents the OS native UI components entirely. Flutter also has a first rate development experience, including hot reload and debugging in VSCode, which is awesome.

Why Firebase

Keeping things serverless has huge benefits for the time of development and scalability of the app. We can focus on our app instead of server devops. Firebase let's us sync data between clients without server side code, including offline syncing features (which are quite hard to implement). Flutter also has a set of firebase plugins that make it play nicely with Flutter widgets, so we get realtime syncing of the client UI when another client changes the data.

Why Publitio

We'll use Publitio as our Media Asset Management API. Publitio will be responsible for hosting our files, delivering them to clients using it's CDN, thumbnail/cover image generation, transformations/cropping, and other video processing features.

By using an API for this, we can keep the app serverless (and therefore more easily scalable and maintainable), and not reinvent video processing in-house.

Let's start

First, make sure you have a working flutter environment set up, using Flutter's Getting Started.

Now let's create a new project named flutter_video_sharing. In terminal run:

flutter create --org com.learningsomethingnew.fluttervideo --project-name flutter_video_sharing -a kotlin -i swift flutter_video_sharing

To check the project has created successfully, run flutter doctor, and see if there are any issues.

Now run the basic project using flutter run for a little sanity check (you can use an emulator or a real device, Android or iOS).

This is a good time to init a git repository and make the first commit.

Taking a video

In order to take a video using the device camera, we'll use the Image Picker plugin for Flutter.

In pubspec.yaml dependencies section, add the line (change to latest version of the plugin):

image_picker: ^0.6.1+10

You might notice that there is also a Camera Plugin. I found this plugin to be quite unstable for now, and has serious video quality limitations on many android devices, as it supports only camera2 API.

iOS configuration

For iOS, we'll have to add a camera and mic usage description in ios/Runner/Info.plist:

<key>NSMicrophoneUsageDescription</key>
<string>Need access to mic</string>
<key>NSCameraUsageDescription</key>
<string>Need access to camera</string>

In order to test the camera on iOS you'll have to use a real device as the simulator doesn't have a camera

Using the plugin

In lib/main.dart edit _MyHomePageState class with the following code:

class _MyHomePageState extends State<MyHomePage> {
  List<String> _videos = <String>[];

  bool _imagePickerActive = false;

  void _takeVideo() async {
    if (_imagePickerActive) return;

    _imagePickerActive = true;
    final File videoFile =
        await ImagePicker.pickVideo(source: ImageSource.camera);
    _imagePickerActive = false;

    if (videoFile == null) return;

    setState(() {
      _videos.add(videoFile.path);
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
          child: ListView.builder(
              padding: const EdgeInsets.all(8),
              itemCount: _videos.length,
              itemBuilder: (BuildContext context, int index) {
                return Card(
                  child: Container(
                    padding: const EdgeInsets.all(8),
                    child: Center(child: Text(_videos[index])),
                  ),
                );
              })),
      floatingActionButton: FloatingActionButton(
        onPressed: _takeVideo,
        tooltip: 'Take Video',
        child: Icon(Icons.add),
      ),
    );
  }
}

What's going on here:

We're replacing the _incrementCounter method with _takeVideo, and also making it async. This is what happens when we click the Floating Action Button.
We're taking a video with await ImagePicker.pickVideo(source: ImageSource.camera);.
We're saving the video file paths in the _videos list in our widget's state. We call setState so that the widget will rebuild and the changes reflect in the UI.
In order to get some visual feedback, we replace the scaffold's main Column with a ListView using ListView.builder which will render our dynamic list efficiently.

Running at this stage will look like this:

Add Publitio

Create a free account at Publit.io, and get your credentials from the dashboard.

Note: The link above has my referral code. If my writing is valuable to you, you can support it by using this link. Of course, you can just create an account without me 😭

Add the package

Add the flutter_publitio plugin to your pubspec.yaml dependencies section:

dependencies:
    flutter_publitio: ^1.0.0

Create an env file

A good way to store app configuration is by using .env files, and loading them with flutter_dotenv, which in turn implements a guideline from The Twelve-Factor App. This file will contain our API key and secret, and therefore should not be committed to source-control.
So create an .env file in the project's root dir, and put your credentials in it:

PUBLITIO_KEY=12345abcd
PUBLITIO_SECRET=abc123

Now add flutter_dotenv as a dependency, and also add the .env file as an asset in pubspec.yaml:

dependencies:
  flutter_dotenv: ^2.0.3

  ...

flutter:
  assets:
    - .env

iOS configuration

For iOS, the keys are loaded from Info.plist. In order to keep our configuration in our environment and not commit it into our repository, we'll load the keys from an xcconfig file:

In XCode, open ios/Runner.xworkspace (this is the XCode project Flutter has generated), right click on Runner -> New File -> Other -> Configuration Settings File -> Config.xcconfig
In Config.xcconfig, add the keys like you did in the .env file:

PUBLITIO_KEY = 12345abcd
PUBLITIO_SECRET = abc123

Now we'll import this config file from ios/Flutter/Debug.xcconfig and ios/Flutter/Release.xcconfig by adding this line to the bottom of both of them:

#include "../Runner/Config.xcconfig"

Add Config.xcconfig to .gitignore so you don't have your keys in git

The last step is to add the config keys to ios/Runner/Info.plist:

<key>PublitioAPIKey</key>
<string>$(PUBLITIO_KEY)</string>
<key>PublitioAPISecret</key>
<string>$(PUBLITIO_SECRET)</string>

Android configuration

In Android, all we have to do is change minSdkVersion from 16 to 19 in android/app/build.gradle.

Is it just me or is everything always simpler with Android?

Upload the file

Now that we have publitio added, let's upload the file we got from ImagePicker.

In main.dart, in the _MyHomePageState class, we'll add a field keeping the status of the upload:

bool _uploading = false;

Now we'll override initState and call an async function configurePublitio that will load the API keys:

@override
void initState() {
  configurePublitio();
  super.initState();
}

static configurePublitio() async {
  await DotEnv().load('.env');
  await FlutterPublitio.configure(
      DotEnv().env['PUBLITIO_KEY'], DotEnv().env['PUBLITIO_SECRET']);
}

We'll add a function _uploadVideo that calls publitio API's uploadFile:

static _uploadVideo(videoFile) async {
  print('starting upload');
  final uploadOptions = {
    "privacy": "1",
    "option_download": "1",
    "option_transform": "1"
  };
  final response =
      await FlutterPublitio.uploadFile(videoFile.path, uploadOptions);
  return response;
}

We'll add the calling code to our _takeVideo function:

setState(() {
  _uploading = true;
});

try {
  final response = await _uploadVideo(videoFile);
  setState(() {
    _videos.add(response["url_preview"]);
  });
} on PlatformException catch (e) {
  print('${e.code}: ${e.message}');
  //result = 'Platform Exception: ${e.code} ${e.details}';
} finally {
  setState(() {
    _uploading = false;
  });
}

Notice that the response from publitio API will come as a key-value map, from which we're only saving the url_preview, which is the url for viewing the hosted video. We're saving that to our _videos collection, and returning _uploading to false after the upload is done.

And finally we'll change the floating action button to a spinner whenever _uploading is true:

floatingActionButton: FloatingActionButton(
  child: _uploading
      ? CircularProgressIndicator(
          valueColor: new AlwaysStoppedAnimation<Color>(Colors.white),
        )
      : Icon(Icons.add),
  onPressed: _takeVideo),

Add thumbnails

One of the things publitio makes easy is server-side video thumbnail extraction. You can use it's URL transformation features to get a thumbnail of any size, but for this we'll use the default thumbnail that is received in the upload response.

Now that we want every list item to have a url and a thumbnail, it makes sense to extract a simple POCO class for each video entry. Create a new file lib/video_info.dart:

class VideoInfo {
  String videoUrl;
  String thumbUrl;

  VideoInfo({this.videoUrl, this.thumbUrl});
}

We'll change the _videos collection from String to VideoInfo:

List<VideoInfo> _videos = <VideoInfo>[];

And after getting the upload response, we'll add a VideoInfo object with the url and the thumbnail url:

final response = await _uploadVideo(videoFile);
setState(() {
  _videos.add(VideoInfo(
      videoUrl: response["url_preview"],
      thumbUrl: response["url_thumbnail"]));
});

Finally we'll add the thumbnail display to the list builder item:

child: new Container(
  padding: new EdgeInsets.all(10.0),
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.start,
    children: <Widget>[
      Stack(
        alignment: Alignment.center,
        children: <Widget>[
          Center(child: CircularProgressIndicator()),
          Center(
            child: ClipRRect(
              borderRadius: new BorderRadius.circular(8.0),
              child: FadeInImage.memoryNetwork(
                placeholder: kTransparentImage,
                image: _videos[index].thumbUrl,
              ),
            ),
          ),
        ],
      ),
      Padding(padding: EdgeInsets.only(top: 20.0)),
      ListTile(
        title: Text(_videos[index].videoUrl),
      ),
    ],
  ),

A few things here:

We're giving the thumbnail nice round borders using ClipRRect
We're displaying a CircularProgressIndicator that displays while the thumbnail is loading (it will be hidden by the image after loading)
For a nice fade effect, we're using kTransparentImage from the package transparent_image (which needs to be added to pubspec.yaml)

And now we have nice thumbnails in the list:

Play the video

Now that we have the list of videos, we want to play each video when tapping on the list card.

We'll use the Chewie plugin as our player. Chewie wraps the video_player plugin with native looking UI for playing, skipping, and full screening.
It also supports auto rotating the video according to device orientation.
What it can't do (odly), is figure out the aspect ratio of the video automatically. So we'll get that from the publitio result.

Note: Flutter's video_player package doesn't yet support caching, so replaying the video will cause it to re-download. This should be solved soon: https://github.com/flutter/flutter/issues/28094

So add to pubspec.yaml:

video_player: ^0.10.2+5
chewie: ^0.9.8+1

For iOS, we'll also need to add to the following to Info.plist to allow loading remote videos:

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSAllowsArbitraryLoads</key>
  <true/>
</dict>

Now we'll add a new widget that will hold chewie. Create a new file chewie_player.dart:

import 'package:chewie/chewie.dart';
import 'package:flutter/material.dart';
import 'package:video_player/video_player.dart';
import 'video_info.dart';

class ChewiePlayer extends StatefulWidget {
  final VideoInfo video;

  const ChewiePlayer({Key key, @required this.video}) : super(key: key);

  @override
  State<StatefulWidget> createState() => _ChewiePlayerState();
}

class _ChewiePlayerState extends State<ChewiePlayer> {
  ChewieController chewieCtrl;
  VideoPlayerController videoPlayerCtrl;

  @override
  void initState() {
    super.initState();
    videoPlayerCtrl = VideoPlayerController.network(widget.video.videoUrl);
    chewieCtrl = ChewieController(
      videoPlayerController: videoPlayerCtrl,
      autoPlay: true,
      autoInitialize: true,
      aspectRatio: widget.video.aspectRatio,
      placeholder: Center(
        child: Image.network(widget.video.coverUrl),
      ),
    );
  }

  @override
  void dispose() {
    if (chewieCtrl != null) chewieCtrl.dispose();
    if (videoPlayerCtrl != null) videoPlayerCtrl.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.black,
      body: Stack(
        children: <Widget>[
          Chewie(
            controller: chewieCtrl,
          ),
          Container(
            padding: EdgeInsets.all(30.0),
            child: IconButton(
              icon: Icon(Icons.close, color: Colors.white),
              onPressed: () => Navigator.pop(context),
            ),
          ),
        ],
      ),
    );
  }
}

A few things to note:

ChewiePlayer expects to get VideoInfo which is the video to be played.
The aspect ratio is initialized from the input VideoInfo. We'll add this field soon.
We show a placeholder image while the video is loading. We'll use publitio API to generate the cover image.
We have an IconButton that will close this widget by calling Navigator.pop(context)
We have to take care of disposing both the VideoPlayerController and the ChewieController by overriding the dispose() method

In video_info.dart we'll add the aspectRatio and coverUrl fields:

String coverUrl;
double aspectRatio;

And now in main.dart, we'll first import our new chewie_player:

import 'chewie_player.dart';

Add a calculation of aspectRatio:

  final response = await _uploadVideo(videoFile);
  final width = response["width"];
  final height = response["height"];
  final double aspectRatio = width / height;
    setState(() {
      _videos.add(VideoInfo(
          videoUrl: response["url_preview"],
        thumbUrl: response["url_thumbnail"]));
        thumbUrl: response["url_thumbnail"],
        aspectRatio: aspectRatio,
        coverUrl: getCoverUrl(response),
        ));
    });

Add a method to get the cover image from publitio API (this is just replacing the extension of the video to jpg - publitio does all the work):

static const PUBLITIO_PREFIX = "https://media.publit.io/file";

static getCoverUrl(response) {
  final publicId = response["public_id"];
  return "$PUBLITIO_PREFIX/$publicId.jpg";
}

And wrap our list item Card with a GestureDetector to respond to tapping on the card, and call Navigator.push that will route to our new ChewiePlayer widget:

return GestureDetector(
    onTap: () {
      Navigator.push(
        context,
        MaterialPageRoute(
          builder: (context) {
            return ChewiePlayer(
              video: _videos[index],
            );
          },
        ),
      );
    },
    child: Card(
      child: new Container(
        padding: new EdgeInsets.all(10.0),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: <Widget>[
            Stack(
              alignment: Alignment.center,
              children: <Widget>[
                Center(child: CircularProgressIndicator()),
                Center(
                  child: ClipRRect(
                    borderRadius: new BorderRadius.circular(8.0),
                    child: FadeInImage.memoryNetwork(
                      placeholder: kTransparentImage,
                      image: _videos[index].thumbUrl,
                    ),
                  ),
                ),
              ],
            ),
            Padding(padding: EdgeInsets.only(top: 20.0)),
            ListTile(
              title: Text(_videos[index].videoUrl),
            ),
          ],
        ),
      ),
    ),
  );

Add Firebase

Now that we can upload and playback videos, we want users of the app to view the videos other users posted. To do that (and keep the app serverless) we'll use Firebase.

Firebase Setup

First, setup Firebase as described here. This includes creating a firebase project, registering your mobile apps (Android and iOS) in the project, and configuring the credentials for both the Android and iOS projects. Then we'll add the Flutter packages firebase_core and cloud_firestore.

Cloud Firestore is the new version of the Firebase Realtime Database.
You'll probably need to set multiDexEnabled true in your build.gradle.

Save video info to Firebase

Instead of saving the video info to our own state, we'll save it to a new Firebase document in the videos collection:

final video = VideoInfo(
  videoUrl: response["url_preview"],
  thumbUrl: response["url_thumbnail"],
  coverUrl: getCoverUrl(response),
  aspectRatio: getAspectRatio(response),
);
await Firestore.instance.collection('videos').document().setData({
  "videoUrl": video.videoUrl,
  "thumbUrl": video.thumbUrl,
  "coverUrl": video.coverUrl,
  "aspectRatio": video.aspectRatio,
});

The document() method will create a new randomly named document inside the videos collection.

This is how the documents look in the Firebase Console:

Show video list from Firebase

Now in our initState method we'll want to start a Firebase query that will listen to the videos collection. Whenever the Firebase SDK triggers a change in the data, it will invoke the updateVideos method, which will update our _videos state (and Flutter will rebuild the UI):

@override
void initState() {
  configurePublitio();
  listenToVideos();
  super.initState();
}

listenToVideos() async {
  Firestore.instance.collection('videos').snapshots().listen(updateVideos);
}

void updateVideos(QuerySnapshot documentList) async {
  final newVideos = mapQueryToVideoInfo(documentList);
  setState(() {
    _videos = newVideos;
  });
}

static mapQueryToVideoInfo(QuerySnapshot documentList) {
  return documentList.documents.map((DocumentSnapshot ds) {
    return VideoInfo(
      videoUrl: ds.data["videoUrl"],
      thumbUrl: ds.data["thumbUrl"],
      coverUrl: ds.data["coverUrl"],
      aspectRatio: ds.data["aspectRatio"],
    );
  }).toList();
}

Now all the videos are shared!

Refactoring

Now that everything's working, it's a good time for some refactoring. This is a really small app, but still some obvious things stand out.
We have our data access and business logic all sitting in the same place - never a good idea. It's better to have our API/data access in separate modules, providing the business logic layer with the required services, while it can stay agnostic to (and Loosely Coupled from) the implementation details.

In order to keep this post short(ish) I won't include these changes here, but you can see them in the final code on GitHub

Future improvement: client side encoding

We can use FFMpeg to encode the video on the client before uploading.
This will save storage and make delivery faster, but will require a patient uploading user.
If you want to see how to do that, write a comment below.

Thanks for reading!
Full code can be found on GitHub.
If you have any questions, please leave a comment!

How to make an image uploading app with Vue, Quasar, Firebase Storage and Cordova - Part 2

Jonathan P — Sun, 13 Oct 2019 00:00:00 +0000

What we're building

We'll build a cross-platform mobile app for taking photos and uploading to firebase.

In Part 1, we saw how to take a picture and save it to Firebase Cloud Storage.
In this post we'll move the uploading to a separate thread via web worker, and use the blueimp library to generate a thumbnail locally and show it while uploading.

Web Workers

What is a web worker

Web Workers are a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface. (mozilla.org)

So we'll use a web worker to offload code that can potentially block our UI thread - in our case the Firebase Storage code - to another thread.

Configuring workerize-loader

We'll use workerize-loader to make using web workers a little easier (web workers interface is a little weird).

yarn add workerize-loader

We need to add some webpack configuration to tell webpack to use workerize-loader. In quasar.conf.js in the build section add:

extendWebpack(cfg) {
    cfg.module.rules.push({
        test: /\.worker\.js$/,
        loader: 'workerize-loader',
    })
},

chainWebpack (chain, { isServer, isClient }) {
    chain.output.globalObject('self')
}

This tells webpack to load the file worker.js using workerize-loader.

Moving code to the worker

Let's add the file src/services/worker.js and move our uploading code into it:

import cloudStorage from './cloud-storage'

export async function uploadPicture(imageData) {
    let storageId = new Date().getTime().toString();

    let downloadURL = await cloudStorage.uploadBase64(
        imageData,
        storageId
    );

    return {
        storageId,
        downloadURL,
    }
}

export function initFB() {
    cloudStorage.initialize();
}

export async function deletePic(storageId) {
    await cloudStorage.deleteFromStorage(storageId)
}

We've also added a deletePic call which we'll see later in cloudStorage.js.

Adding simple state management

We'll want to create an instance of the worker and save it in the app's state. We don't have state management yet, so let's add a simple state management pattern using a store.js file:

import worker from "workerize-loader!./worker.js";

var store = {
    debug: true,
    state: {
        pics: [],
        uploading: false
    },
    initWorker() {
        this.state.workerInstance = worker();
        this.state.workerInstance.initFB();
    },
    async loadPictures() {
        if (this.debug) console.log("loadPictures triggered")
        let picsJson = await localStorage.getItem("pics");
        if (!picsJson) this.state.pics = [];
        else this.state.pics = JSON.parse(picsJson);
        this.state.pics = this.state.pics.filter(pic => !pic.uploading)
    },
    async addPic(pic) {
        if (this.debug) console.log("addPic triggered with", pic)

        pic.failed = false;
        this.state.pics.splice(0, 0, pic);
        localStorage.setItem("pics", JSON.stringify(this.state.pics));
    },
    async deletePic(idx) {
        if (this.debug) console.log("deletePic triggered with", idx)

        this.state.pics[idx].uploading = true;

        if (this.state.pics[idx].storageId) {
            await this.state.workerInstance.deletePic(this.state.pics[idx].storageId)
        }
        this.state.pics.splice(idx, 1);
        localStorage.setItem("pics", JSON.stringify(this.state.pics));
    },
    async updatePicUploaded(oldPic, newPic) {
        if (this.debug) console.log("updatePicUploaded triggered with", oldPic, newPic)

        oldPic.uploading = false
        oldPic.url = newPic.downloadURL
        oldPic.storageId = newPic.storageId
        oldPic.width = newPic.width
        oldPic.height = newPic.height

        localStorage.setItem("pics", JSON.stringify(this.state.pics));
    },
    async updatePicFailed(pic) {
        if (this.debug) console.log("updatePicFailed triggered with", pic)

        pic.failed = true
    },
}

export default {
    ...store
}

A few things going on here:

We're importing our worker using the prefix workerize-loader! which tells webpack to use the loader we configured earlier.
We moved the pics collection to the state object from Index.vue.
We exposed the method initWorker which initializes the worker instance.
We added some CRUD methods for persisting the pics collection in localStorage: addPic, loadPictures and delete.
updatePicUploaded and updatePicFailed changes the loading property of the picture. We'll use this to show the spinner.

Generating thumbnails

We're going to generate a thumbnail (on the client) to show while the image is uploading. We'll use the blueimp library for this:

yarn add blueimp-load-image

Let's add another service for manipulating images: src/services/image-ops.js:

import loadImage from 'blueimp-load-image'

const base64JpegPrefix = "data:image/jpeg;base64,";

function removeBase64Prefix(base64Str) {
    return base64Str.substr(base64Str.indexOf(",") + 1);
}

function addBase64Prefix(imageData) {
    return base64JpegPrefix + imageData
}

async function generateThumbnail(imageData, maxWidth) {
    return new Promise(async resolve => {
        let url = base64JpegPrefix + imageData
        let res = await fetch(url)
        let blob = await res.blob()

        loadImage(
            blob,
            (canvas) => {
                let dataURL = canvas.toDataURL('image/jpeg');
                resolve(removeBase64Prefix(dataURL));
            }, {
                maxWidth: maxWidth,
                canvas: true
            }
        );
    });
}


export default {
    removeBase64Prefix,
    generateThumbnail,
    addBase64Prefix,
};

Notice we've moved the removeBase64Prefix and addBase64Prefix methods here.
The generateThumbnail function takes imageData - a base64 string, uses the fetch API, converts it to a blob, and then uses blueimp's loadImage to change it's size to maxWidth.
We're loading maxWidth from a new config file we've added to make things tidy - src/services/config.js:

export default {
    photos: {
        maxWidth: 1000,
        thumbnailMaxWidth: 30
    }
}

Adding the image-uploader service

We'll extract all the image uploading flow to a service to keep our UI component clean. Add the file src/services/image-uploader.js:

import store from "./store";
import cordovaCamera from "./cordova-camera";
import imageOps from "./image-ops";
import config from "./config";


async function uploadImageFromCamera() {
    let base64 = await cordovaCamera.getBase64FromCamera();

    let imageData = imageOps.removeBase64Prefix(base64);

    let thumbnailImageData = await imageOps.generateThumbnail(
        imageData,
        config.photos.thumbnailMaxWidth
    );

    let localPic = {
        url: imageOps.addBase64Prefix(thumbnailImageData),
        uploading: true
    };
    store.addPic(localPic);

    let uploadedPic = await store.state.workerInstance.uploadPicture(
        imageData
    );
    store.updatePicUploaded(localPic, uploadedPic);
}

export default {
    uploadImageFromCamera
}

What we're doing in the uploadImageFromCamera method is: getting base64 from the cordova camera -> generating thumbnails using our imageOps -> generating a new pic object in our state with uploading=true -> uploading the picture to Firebase using the web worker -> updating the pic's uploading state property when uploading is finished.

Putting it together

Now we've added all these services, we need to call them from our components.

In App.vue, we'll use the mounted lifecycle hook to initialize the worker and load the saved picture urls from the saved state:

<template>
  <div id="q-app">
    <router-view />
  </div>
</template>

<script>
import store from "./services/store.js";

export default {
  name: "App",
  async mounted() {
    store.initWorker();
    store.loadPictures();
  }
};
</script>

<style>
</style>

Finally, we'll add the interface for viewing all this in Index.vue:

<template>
  <q-page class>
    <div class="q-pa-md">
      <div class="row justify-center q-ma-md" v-for="(pic, idx) in pics" :key="idx">
        <div class="col">
          <q-card v-if="pic">
            <q-img spinner-color="white" :src="pic.url">
              <div class="spinner-container" v-if="pic.uploading && !pic.failed">
                <q-spinner color="white" size="4em" />
              </div>
              <div class="spinner-container" v-if="pic.failed">
                <q-icon name="cloud_off" style="font-size: 48px;"></q-icon>
              </div>
            </q-img>
            <q-card-actions align="around">
              <q-btn flat round color="red" icon="favorite" @click="notifyNotImplemented()" />
              <q-btn flat round color="teal" icon="bookmark" @click="notifyNotImplemented()" />
              <q-btn
                flat
                round
                color="primary"
                icon="delete"
                @click="deletePic(idx)"
                :disable="pic.uploading"
              />
            </q-card-actions>
          </q-card>
        </div>
      </div>
    </div>
  </q-page>
</template>

<style scoped>
.spinner-container {
  display: flex;
  align-items: center;
  justify-content: center;
  width: 100%;
  height: 100%;
}

</style>

<script>
import store from "../services/store";
import { EventBus } from "../services/event-bus";
import imageUploader from "../services/image-uploader";

export default {
  name: "PageIndex",
  data() {
    return {
      state: store.state
    };
  },
  mounted() {
    EventBus.$off("takePicture");
    EventBus.$on("takePicture", this.uploadImageFromCamera);
  },
  computed: {
    pics() {
      return this.state.pics;
    }
  },
  methods: {
    notifyNotImplemented() {
      this.$q.notify({ message: "Not implemented yet :/" });
    },
    async deletePic(idx) {
      try {
        await store.deletePic(idx);
        this.$q.notify({ message: "Picture deleted." });
      } catch (err) {
        console.error(err);
        this.$q.notify({ message: "Delete failed. Check log." });
      }
    },
    async uploadImageFromCamera() {
      try {
        imageUploader.uploadImageFromCamera();
      } catch (err) {
        console.error("Uploading failed");
        console.dir(err);
        store.updatePicFailed(localPic);
        this.$q.notify({ message: "Uploading failed. Check log." });
      }
    }
  }
};
</script>

What's going on here:

We've added a q-spinner to show when the uploading property of the picture is true.
We're calling imageUploader.uploadImageFromCamera when clicking on the photo button, which handles our uploading.
We've added some actions to the q-card of the picture (only delete is implemented for now)

Final app

That's it! We have an image uploading app that shows a blurred thumbnails with a spinner, a little like WhatsApp's image upload.
Running all this using quasar dev -m android/ios will show the final result:

Further improvements

Some ideas for improving this app further would be:

Offload thumbnail creation to another web worker
Handle long lists of images with a virtual list component like this one
Add a carousel / gallery component for viewing images full-size
Add a retry mechanism for failed uploads
Use firebase auth - so that users can only delete their own photos

Source code

The full code is on GutHub here: vue-firebase-image-upload.

Enjoy :)

How to make an image uploading app with Vue, Quasar, Firebase Storage and Cordova - Part 1

Jonathan P — Thu, 10 Oct 2019 00:00:00 +0000

What we're building

We'll build a cross-platform mobile app for taking photos and uploading to firebase.

In Part 1, we'll take a picture and save it to Firebase Cloud Storage, and then show it in our app.
In Part 2, we'll offload the uploading work, and use the blueimp library to generate a thumbnail locally and show it while uploading.

The stack

Vue JS - Component framework
Cordova - Cross platform mobile framework
Quasar - UI framework (and CLI)
Firebase Cloud Storage - For storing the photos
Web Workers - For offloading the uploading to a separate thread

Scaffolding

We'll use Quasar CLI to initialize a new project, and run the cordova mode (android or ios) to see the app running on your connected device.

quasar create vue-firebase-image-upload
cd vue-firebase-image-upload
quasar dev -m android

You'll have to add https: true in the devServer section of quasar.conf.js if running on android > 9

You should get a basic working version that looks like this:

This is a good time to make your first commit.

For more details on how to install and setup quasar, see this post

Taking a picture and getting base64

The way to store images in Firebase Cloud Storage is by saving the base-64 string of the image, using Firebase's putString method.
Notice that you have to remove the base64 prefix from the string before uploading, or Firebase will reject the string.
To begin, we'll add a button that takes a picture using Cordova's camera plugin, and print the base64 string.

Adding plugins

First, add cordova camera plugin and file plugin:

cd src-cordova
cordova plugin add cordova-plugin-file
cordova plugin add cordova-plugin-camera

Taking the picture

In order to take a picture, we'll add some code in a new service file src/services/cordova-camera.js:

async function getCameraFileObject() {
  return new Promise((resolve, reject) => {

    let camera = navigator.camera;

    const options = {
      quality: 50,
      destinationType: camera.DestinationType.FILE_URI,
      encodingType: camera.EncodingType.JPG,
      mediaType: camera.MediaType.PICTURE,
      saveToPhotoAlbum: true,
      correctOrientation: true
    };

    camera.getPicture(imageURI => {
      window.resolveLocalFileSystemURL(imageURI,
        function (fileEntry) {
          fileEntry.file(
            function (fileObject) {
              resolve(fileObject)
            },
            function (err) {
              console.error(err);
              reject(err);
            }
          );
        },
        function () { }
      );
    },
      console.error,
      options
    );
  })

}

async function getBase64FromFileObject(fileObject) {
  return new Promise((resolve, reject) => {
    var reader = new FileReader()
    reader.onloadend = function (evt) {
      var image = new Image()
      image.onload = function (e) {
        resolve(evt.target.result)
      }
      image.src = evt.target.result
    }
    reader.readAsDataURL(fileObject)
  })
}

async function getBase64FromCamera() {
  let fileObject = await getCameraFileObject();
  let base64 = await getBase64FromFileObject(fileObject);
  return base64;
}

export default {
  getBase64FromCamera
}

This service is doing several steps:

Takes a picture using Cordova's camera plugin. This returns an image URI.
Gets a file entry using Cordova's file plugin, with resolveLocalFileSystemURL function.
Gets a File object using the file method.
Uses FileReader to get the base64 representation of the file.

Now let's add a simple event bus. Add the file src/services/event-bus.js with content:

import Vue from 'vue';
export const EventBus = new Vue();

Now in src/layouts/MyLayout.vue, we'll add a button in the toolbar for taking a picture, and use our event bus to send the handling to Index.vue:

<template>
  ...

  <q-btn flat dense round @click="takePicture">
    <q-icon name="camera" />
  </q-btn>

  ...
</template>

<script>
  import { EventBus } from "../services/event-bus.js";

  export default {
    ...

    methods: {
      takePicture() {
        EventBus.$emit('takePicture')
      }
    }
  }
  </script>

Finally we'll catch the takePicture event in our main component: Index.vue, call the cordova-camera.js service function and print the base64 result (which we'll later upload to firebase):

In Index.vue file in the <script> section:

  import { EventBus } from "../services/event-bus";
  import cordovaCamera from "../services/cordova-camera";

  export default {
    name: "PageIndex",
    mounted() {
      EventBus.$off("takePicture");
      EventBus.$on("takePicture", this.uploadImageFromCamera);
    },
    methods: {
      async uploadImageFromCamera() {
        let base64 = await cordovaCamera.getBase64FromCamera();
        console.log("base64", base64)
      }
    }
  };

Running with quasar dev -m android, and looking at the chrome dev tools, we can see the base64 output as a long string printed in the console:

Adding firebase

Web SDK or native SDK?

When using Firebase in a Cordova app, you can choose between using the Web SDK and a cordova plugin the wraps the Native SDKs. The state of the current Firebase cordova plugins seems a little unstable to me, not fully supporting Firebase Cloud Storage yet. And with the ability to offload work to a web worker, we can use the full-featured official Web SDK, and not take the performance hit.
Add the firebase sdk using yarn:

yarn add firebase

Firebase setup

Follow the instructions in the Firebase Cloud Storage setup page.
After the setup you should have a firebase project with Storage enabled. We'll save the settings in a separate file: firebase-config.js (this file won't be committed to our repo). The contents should look something like this:

export default {
    firebase: {
        apiKey: '<your-api-key>',
        authDomain: '<your-auth-domain>',
        databaseURL: '<your-database-url>',
        storageBucket: '<your-storage-bucket-url>'
    }
}

Uploading the image

Now that we have Firebase settings in place, we'll add another service for handling Firebase app initialization and uploading.
Add the file src/services/cloud-storage.js with content:

import * as firebase from "firebase/app";
import 'firebase/storage';
import firebaseConfig from './firebase-config';

async function uploadBase64(imageData, storageId) {
    return new Promise((resolve, reject) => {
        let uploadTask = firebase.storage().ref().child(storageId).putString(imageData, "base64");
        uploadTask.on(
            "state_changed",
            function (snapshot) {},
            function (error) {
                reject(error)
            },
            function () {
                uploadTask.snapshot.ref
                    .getDownloadURL()
                    .then(function (downloadURL) {
                        console.log("Uploaded a blob or file!");
                        console.log("got downloadURL: ", downloadURL);
                        resolve(downloadURL);
                    });
            }
        );
    });
}

function initialize() {
    firebase.initializeApp(firebaseConfig.firebase) 
}

export default {
    uploadBase64,
    initialize
}

The uploadBase64 function uploads imageData (the base64 string) using the putString method, under the Firebase child of storageId. You can have any ID you want, here I've chosen to use the unix datetime number as the child ID. After the uploading is done, we return the image URL using getDownloadURL function of the uploading task.

In our main App.vue file we'll call the initialize function when the app is mounted:

import cloudStorage from './services/cloud-storage'
export default {
    name: 'App',
    mounted() {
      cloudStorage.initialize();
    }
}

Finally we'll call the uploading function from Index.vue. This is now the content of Index.vue:

<template>
  <q-page>
    <div class="row justify-center q-ma-md" v-for="(pic, idx) in pics" :key="idx">
      <div class="col">
        <q-card>
          <q-img spinner-color="white" :src="pic" />
        </q-card>
      </div>
    </div>
  </q-page>
</template>

<script>
import { EventBus } from "../services/event-bus";
import cordovaCamera from "../services/cordova-camera";
import cloudStorage from "../services/cloud-storage";

export default {
  name: "PageIndex",
  data() {
    return {
      pics: []
    };
  },
  mounted() {
    EventBus.$off("takePicture");
    EventBus.$on("takePicture", this.uploadImageFromCamera);
  },
  methods: {
    removeBase64Prefix(base64Str) {
      return base64Str.substr(base64Str.indexOf(",") + 1);
    },

    async uploadImageFromCamera() {
      const base64 = await cordovaCamera.getBase64FromCamera();
      const imageData = this.removeBase64Prefix(base64);
      const storageId = new Date().getTime().toString();
      const uploadedPic = await cloudStorage.uploadBase64(imageData, storageId);
      this.pics.push(uploadedPic);
    }
  }
};
</script>

We've added the pics array to our component's data, containing URLs of all the pictures we uploaded. We've added a v-for that will show each picture in a quasar q-img component inside a q-card component.
We've also changes uploadImageFromCamera to take a picture, get the base64 string (stripping the prefix so Firebase won't freak out), calculated the storageId using the current datetime, and called the uploading function. After it's uploaded, we add the resulting URL to the pics array.

And we can now see the uploaded image:

The full code is on GitHub.

In the next part of the series we'll move tasks to a web worker, add a loading spinner, and save the URLs in local storage. Stay tuned!

How do you create charts / diagrams for your blog posts?

Jonathan P — Mon, 09 Sep 2019 17:40:09 +0000

Anyone know of a good library / site for creating sleek looking diagrams for technical blog posts?

I was impressed by the charts on this blog post but wasn't able to find out what he's using (he didn't answer me on twitter :) )

How to make your Svelte 3 Cordova app work on old phones using Babel 7 and Rollup

Jonathan P — Thu, 22 Aug 2019 00:00:00 +0000

When working with a relatively new framework like svelte you come across issues that more "battle tested" frameworks have solved already.
One such issue is transpiling your code to work on older browsers. This is meaningful especially for a cordova app, because it runs in a system WebView, which version depends on various factors, and is not always updated.

I wrote more about WebView versions in the post: should you transpile your cordova app

What should be transpiled?

We're going to use babel of course, in order to transpile.

From the babel docs:

Babel is a toolchain that is mainly used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript in current and older browsers or environments.

But which code needs to be transpiled? We need to consider two levels of transpilation:

1. Our app's code

If you're using ES6 and above in your app (and you should), you need to transpile that. This includes you .svelte files and .js files.

2. Dependencies

Your dependencies are also code that's bundled along with your app. If they were published with ES6 syntax, then they'll cause your bundle.js to contain untranspiled code.
By the way, here is babel's take on external dependencies:

Ideally, you should only be transforming your source code, rather than running all of your external dependencies through Babel – hence the exclude: 'node_modules/**'
We encourage library authors not to distribute code that uses untranspiled ES6 features (other than modules) for this reason. Consumers of your library should not have to transpile your ES6 code, any more than they should have to transpile your CoffeeScript, ClojureScript or TypeScript.

Unfortunately, not all libraries abide by this rule.
One such library is axios:

Up until the 0.6.0 release ES6 Promise was being polyfilled using es6-promise. With this release, the polyfill has been removed, and you will need to supply it yourself if your environment needs it.

Another is svelte. According to this svelte GitHub issue, it's still a WIP to list exactly what needs transpiling / polyfills.

The solution

The following configuration has worked for me, successfully transpiling my cordova app.

1. Install dependencies

First let's install the required babel packages, and the rollup plugin.

npm i -D @babel/core @babel/preset-env rollup-plugin-babel core-js

2. Configure babel

Now add the following configuration to babel.config.js:

module.exports = function (api) {
    api.cache(true);
    const presets = [
        ["@babel/preset-env", {
            // "debug": true,
            useBuiltIns: "usage",
            corejs: 3, // or 2,
            targets: {
                browsers: "last 2 versions",
            }
        }]
    ];
    return {
        presets
    }
}

Notice the browsers: "last 2 versions" line. It's a feature of @babel/preset-env that makes it transpile to last 2 major versions of all browsers.
Also, the debug field can come in handy if you want to see exactly what files are being transpiled.

3. Configure rollup

Add the following babel section at the end of the plugins section of rollup.config.js, assuming you're using the same directory structure as in the svelte cordova template:

import svelte from 'rollup-plugin-svelte';
import resolve from 'rollup-plugin-node-resolve';
import commonjs from 'rollup-plugin-commonjs';
import livereload from 'rollup-plugin-livereload';
import replace from 'rollup-plugin-replace';
import babel from 'rollup-plugin-babel';


export default {
    ...
    plugins: [
        ...
        production && babel({
            exclude: [
                // 'node_modules/**',
                /\/core-js\//,
            ],
            extensions: ['.svelte', '.js', '.jsx', '.es6', '.es', '.mjs', '.ts']
        }),
    ]
};

Several things to notice here:

The line production && babel is a js trick to make the babel plugin not execute in dev mode. You can turn this on or off as you please, if you're testing how the transpiled code works, it might be handy to let it run in dev mode too.
The exclude section does not contain node_modules. We're transpiling our dependencies, because some of them are untranspiled. If this is not the case for you, you can ignore them, but you still need to transpile the svelte module itself.
The extensions section must contain the .svelte extension, or else your own app's code won't go through babel.
We are excluding core-js from transpilation, because of a circular reference issue with rollup-plugin-babel

Credits

I've used this post by simey.me as a basis for the configuration described here.

How (and why) to change your Android Cordova app's minSdkVersion

Jonathan P — Mon, 19 Aug 2019 00:00:00 +0000

TL;DR

For example, for setting minSdkVersion to 24, in config.xml add in the Android platform section:

<platform name="android">
    <preference name="android-minSdkVersion" value="24" />
    ...
</platform>

Make sure to remove and re-add the platform or it won't work!

cordova platform rm android
cordova platform add android

For considerations, and a way to test that it works, read on.

What is minSdkVersion

minSdkVersion is a property of the <uses-sdk> tag in the AndroidManifest.xml file. From the docs:

Google Play uses the attributes declared in your app manifest to filter your app from devices that do not meet it's platform version requirements.

So if you want your app to be available for download in the Play Store only for devices with Android Nougat (7.0) and above, you'd want to set <uses-sdk android:minSdkVersion="24">.

Why should I change the minSdkVersion

If you're building a production cordova app, most chances are you're using the latest JS / HTML / CSS in order to make your app smooth and pretty.
Thing is, many Android devices are still using an old OS version. Old OS versions == old WebView which won't support many of the new web features.

Some active users of my apps are still using Android 4.0 - ICS. The latest release of ICS was June 2012, 7 years ago! It's no longer supported by Google, and is almost guaranteed to have your new cordova app perform very badly (if it works at all). Bad performance / crashes == bad reviews. You don't want that.

The default minSdkVersion in cordova apps is currently API level 19 - Android 4.4 KitKat. Your cordova app might work on Android 4.4, but it probably won't work well. So you have two options:

Build your app so that it works on Android 4.4, which has a WebView with Chrome version 30 (ancient!)
This will include a lot of transpiling, debugging, and completely giving up on things like css grid, which just isn't supported on Chrome 30, and never will be. You can use modernizr to detect whether features are available, and provide a different version of the app according to features, but that makes for quite a lot of extra work.
Decide on a higher minimum version, and block all users with a lower version from downloading your app. In my new app I've decided to go for API Level 24 - Android 7 Nougat.

I've written more about the current market share of Android / iOS versions and the corresponding WebView browser versions in this post.

How to set minSdkVersion

You don't want to do anything directly in the Android project, as it will be overridden every time you build your cordova app! So setting android:minSdkVersion in AndroidManifest.xml is out of the question!

One of the main advantages of using cordova over React react-native is that you never have to edit the native project manually. You have only the cordova project, and the native versions are generated according to configuration. This makes your project update-able to new cordova versions, and doesn't require native adjustments for each new plugin / update you install.

According to the cordova docs, you can set this value

<platform name="android">
    <preference name="android-minSdkVersion" value="24" />
    ...
</platform>

Alas, if you add this to you config, generate an apk and upload to the store, you'll notice (maybe after a few negative reviews) that it didn't change the minSdkLevel!

After wasting some time on this I found a hint in this GitHub issue, saying you have to remove and re-add the platform for it to take effect.

So after changing config.xml, you must also remove and re-add the platform, for the changes to take effect in the generated Android project:

cordova platform rm android
cordova platform add android

Checking it worked

One way to see that it worked is in the Play Console, after uploading a new apk:

Preferably, you'd want a way to test your generated apk locally without having to bump version and upload to the store for every test.

It seems like there should be an easier way to do this, but it seems like the only option now is to de-compile the apk file. I use the open source apktool by Connor Tumbleson for this. You can get the latest version here.

After downloading, build your cordova app using cordova build android and run this in a shell:

java -jar <path-to-apktool.jar> d <path-to-cordova-project>/android/app/build/outputs/apk/debug/app-debug.apk

It will generate a folder named app-debug in the folder from which you ran the command. Go into that folder and open apktool.yml. You should see something like:

sdkInfo:
  minSdkVersion: '24'
  targetSdkVersion: '28'

That way you can be sure your changes are in effect before uploading to the store.

Should you transpile your cordova app?

Jonathan P — Thu, 15 Aug 2019 00:00:00 +0000

The following is based on a true story.

Just worst

You've finished your amazing cross-platform mobile app, you publish it on the stores, and then you get this review:

Hmm.. But it opens on my phone! So you take a closer look:

Oh right, we never checked it on an old phone. Darn. Let's try it on an Android 4.4 emulator:

So a quick search of some of the errors points to the problem. We used all the cool new ES6 syntax, but the WebView is too old to support ES6.

How likely is this to happen? What's the impact?

So your app that uses ES2015+ syntax doesn't work on old devices. But how old? And how many?

In order to assess the damage, we need some data. We're basically asking what's the adoption rate of new browsers within the system WebView components of Android and iOS. But what browser does the WebView actually run? This differs by the OS and the OS version, so let's look at both major mobile operating systems.

1. Android

The WebView cordova apps use in Android is the system WebView component. There have been two major changes in how the Android WebView works in recent years:

Since Android Lollipop, the WebView auto updates through the app store. So a device running Android 5.1 will support new ES features (as long as the user actually approves updates of the WebView app).
Starting from Android 7 (Nougat), Chrome and WebView are the same. That means the WebView cordova uses is the same version as the Chrome app, and there is no need to update a "System WebView" app.

If you're bored, check out some of the reviews of the "System WebView" app on the play store:

For Android versions below L, the WebView is part of the OS and won't update without updating the OS.
Looking at the market share numbers of Android versions, we see that we don't really need to worry about Android versions below L, as they make about ~3% of all devices:

If you still want to cater to this ~3%, or your app runs on specific proprietary devices that can't be upgraded, then you have two options:

Transpile all the way down to chrome version 30 (or lower if you need to support below Android 4.4)
Use the deprecated crosswalk plugin which ships the WebView within your apk. It's no longer maintained (because the changes mentioned above render it quite useless), and doesn't install at all if you use the new cordova CLI (version 9). If you really have to support old devices, I've managed to find one fork of the project that actually works with new cordova versions, but it will probably stop working with the next version :)

2. iOS

iOS 8 and Yosemite introduced the new WKWebView, which now deprecates the old UIWebView (read more about it in this very detailed post on nshipster). The new WKWebView runs the same JS engine as Safari, so that's basically the same change that Android 7 did with Chrome and the system WebView.

Notice though that in new cordova projects (version 9 currently), cordova still uses the old and deprecated UIWebView, so it's recommended to upgrade to WKWebView in new applications. More about this in this announcement by cordova

So if we're using WKWebView which was introduced in iOS 8, how many users are we losing? According to this, less that 2.3% (version 8 isn't even listed):

As you can see, the problem is less severe with iOS than with Android. This is a perk of having the same company that makes the OS also make the hardware.

How to transpile

We can't talk about transpiling without talking about babel.
From the babel docs:

Babel is a toolchain that is mainly used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript in current and older browsers or environments.

It's a pretty cool project, which lets us use the newest language features before they get adopted into all browsers. But you'll notice that the babel configuration is non-trivial to say the least.

Luckily, most frameworks come pre-configured with babel these days, so if you generate a Vue CLI 3 app for example, it will come with a configuration of webpack to use babel.

If you're messing around with a newer / less known framework, try to find a sample project on github that has the babel configuration.

If you're using Svelte, you can check out my post on how to configure babel with rollup for a svelte cordova app here.

So, should I transpile my cordova app?

Yes you should. It's the same argument for why you want your web app to be transpiled (down to the last two versions of major browsers is a good standard, but it depends on your app's customers).

As a developer I always like to use the latest language features, and I can never be sure what my end customer's browser will support. I don't think it's a good idea to stay behind and just use the language features that are already widely supported. Language improvements make development faster and our code better. Luckily, you can use babel's preset-env and define your target browsers generically using a query to select browsers (ex: last 2 versions, > 5%, etc).

If babel ensures our code runs on the last two versions of all major browsers, and we know the vast majority of Android and iOS WebViews are updated automatically as part of the OS, then we're pretty much 99% covered.

Finally, here is a decision tree to help you decide:

What are good reasons to open source your project?

Jonathan P — Mon, 29 Jul 2019 08:24:34 +0000

I've been thinking about open sourcing some of my side projects, and was wondering how to approach this.

I don't think that open sourcing is necessarily a good way to gain traction, as it's not much easier to gain users on GitHub than on the web in general.

And it seems like you're giving up the chances of making profit from the product.

Has anyone faced a similar dilemma?
How do you decide?

How to build a SoundCloud-like audio player app with VueJS, Quasar and WaveSurfer

Jonathan P — Fri, 26 Jul 2019 00:00:00 +0000

What we're building

We'll use Quasar and WaveSurfer to build a SoundCloud like cross-platform mobile audio player app. We'll load a local audio file from the device using html file input, render a waveform and add controls to play the audio.

Quasar?

Quasar is a UI framework built on Vue.js. It seems more mobile-oriented than Vuetify, and also has an excellent CLI that works great for generating Cordova apps. You get debugging on actual device with hot reload out-of-the-box. This is a crucial part of an efficient dev process, and one of the determining factors for me when choosing a framework /stack.

More points that made me want to try it out:

Vibrant and active community (11K GitHub stars)
Great CLI
Beautiful UI components and grid system built in (I like to write as little CSS as possible)
Use the Vue ecosystem you know and love

Scaffolding

I assume you already have a working Cordova setup with android studio / xcode configured. Just follow quasar's tutorial

Let's start by installing the Quasar CLI. From your workspace terminal run:

npm install -g @quasar/cli

Then create a project:

quasar create quasar-wavesurfer-audio-player

Insert the following answers:

Project name: default
Project product name: change to "Cool Player"
Project Description: A soundcloud-like audio player using quasar and wavesurfer
Author: you
Features: we don't need any features
Cordova id: leave as is, unless you want to publish to the store(s)

Quasar CLI will install required packages. After it's done, enter the folder, and run quasar dev to see the basic layout:

cd quasar-wavesurfer-audio-player
quasar dev

A working version! This is a good time to init a git repo and make the first commit.

Adding the cordova mode

Now we have a Quasar app running in SPA mode. In order to turn it into a mobile app we can then publish to the app store, we need to add Quasar's cordova mode:

quasar mode add cordova

This Quasar CLI command adds an src-cordova folder, containing our Cordova project. Within this folder we can run any Cordova CLI command. Quasar will build our Vue code and put the assets in src-cordova/www folder.

Now we'll check if it's running on our device. This should be done as early as possible as a sanity check to see that the setup's working. I'll use android for this, but it works the same for iOS.

Make sure your device is connected by USB, and run:

quasar dev -m android

Note: Newer chrome versions block cleartext traffic by default, so Cordova's internal WebView will throw an ERR_CLEARTEXT_NOT_PERMITTED error. To solve this, uncomment https: true, under devServer section in quasar.conf.js

Note2: If you're building for iOS, it's recommended to upgrade from the deprecated UIWebView (that Cordova uses by default) to WKWebView using one of the methods described here

Now the CLI asks you which IP to serve on. Choose an IP that's accessible from your mobile device (they have to be on the same network). Quasar will create a Cordova app that's inner WebView loads from this IP, thereby giving us the ability to develop with hot reload on our device. This is a crucial feature for an efficient dev process.

We'll continue developing with quasar dev, while periodically testing on an actual device to see things are working.

If you're building an app you want to work on android and iOS, I recommend periodically running it on both platforms. They are never the same.

Quasar Project Structure

Now let's have a look at the project structure the CLI has created for us, for a quick overview of Quasar. Quasar CLI scaffolds a folder structure with the default layout MyLayout.vue inside the layouts folder. The layout is a Vue component that has all the Quasar UI elements including a navigation drawer, a toolbar and a main page. You can spot the Quasar components starting with q- e.g. q-layout, q-toolbar etc. These are all Vue components written by the Quasar team (similar to the v- components of Vuetify).

In order to use a Quasar UI component, you need to explicitly include them in quasar.conf.js, as we'll see later.

The main page is contained inside the <q-page-container> element in MyLayout.vue, which contains a <router-view /> - the same vue-router you know and love. The routes are saved in the pages folder.

The main page loaded by default is Index.vue under the pages folder, so we'll add our code there for this example.

Adding wavesurfer.js

WaveSurfer is an open source audio player that renders the audio wave onto an html5 canvas. Let's add it:

npm i wavesurfer.js

Now we'll import WaveSurfer into Index.vue, add a wavesurfer data member, and a method createWaveSurfer that will initialize it when the component is mounted. The wavesurfer object needs a container, which is the ID of the html element it will be rendered in.
So we'll also add a container div to the component's template. We'll load a demo mp3 file just for testing at this stage. This is how Index.vue looks like now:

<template>
  <div id="waveform"></div>
</template>

<script>
import WaveSurfer from "wavesurfer.js";

export default {
  name: 'PageIndex',
  data: () => ({
    wavesurfer: null,
  }),
  async mounted() {
    if (!this.wavesurfer) this.createWaveSurfer();
  },
  methods: {
    createWaveSurfer() {
      this.wavesurfer = WaveSurfer.create({
        container: "#waveform",
        barWidth: 3
      });
      this.wavesurfer.load(
        "https://ia902606.us.archive.org/35/items/shortpoetry_047_librivox/song_cjrg_teasdale_64kb.mp3"
      );
    }
  }
}
</script>

Running using quasar dev you should see the waveform rendered:

Loading a local audio file

We'll use html's <input type="file"> to load files from the local device. Let's add a file-loading button to our toolbar. In MyLayout.vue replace <div>Quasar v{{ $q.version }}</div> with a q-btn component:

<q-btn color="white" text-color="primary">
Load File
<input
    type="file"
    class="q-uploader__input overflow-hidden absolute-full"
    v-on:change="fileChosen"
    ref="fileInput"
    accept="audio/mpeg"
/>
</q-btn>

What we have here is a <q-btn> (Quasar button), containing a regular html <input> element, with type="file" (making it a file chooser) that will only accept audio files (accept="audio/mpeg").

Notice that browsers try to enforce file inputs to have one of the internet's ugliest designs, something like this:

While there is no official way to change the appearance of a file input, we'll "borrow" the css classes from Quasar's q-uploader component in order to make it appear more like a button, and less like a relic from the 90's. Clicking on this in a Cordova app will open the native device's file choosing interface.

In the methods section add a handler for receiving the file:

fileChosen(file) {
    // Chosen file passed as argument
}

Sending the file to the main page

As we have the file object received in the MyLayout component, but the wavesurfer object in the Index component, we'll use an event bus to communicate between them and send the file when it's selected. An event bus can easily be created by using another Vue object. Add a services folder with a new event-bus.js file, containing:

import Vue from 'vue';
export const EventBus = new Vue();

We'll import it in MyLayout.vue and emit an event whenever the file input value changes:

import { EventBus } from "../services/event-bus.js";

...

methods: {
    fileChosen(file) {
        EventBus.$emit("fileChosen", file);
    }
}

Now we'll want to catch the event in Index.vue's mounted handler:

import { EventBus } from "../services/event-bus.js";

...
mounted() {
    ...

    EventBus.$on("fileChosen", file => {
        this.loadFile(file);
    });
}

And finally we'll load the file using wavesurfer's loadBlob method:

loadFile(file) {
    if (file.target.files.length == 0) return;

    this.wavesurfer.loadBlob(file.target.files[0]);
}

Try loading a file from your device, and you should see it rendered:

Adding controls

Let's add some play/pause/skip buttons. In Index.vue add the following code to the template section:

<template>
  <q-page class>
    <div class="audio-container">
      <div class="row q-ma-md">
        <div class="col-12">
          <div id="waveform"></div>
        </div>
      </div>
    </div>
    <div class="controls row flex flex-center fixed-bottom q-pb-md q-pt-md shadow-10">
      <div class>
        <q-btn
          color="primary"
          flat
          round
          icon="fast_rewind"
          size="xl"
          @click="wavesurfer.skipBackward(1)"
        />
        <q-btn
          v-if="isPlaying"
          color="primary"
          round
          icon="pause"
          size="xl"
          @click="wavesurfer.playPause()"
        />
        <q-btn
          v-if="!isPlaying"
          color="primary"
          round
          icon="play_arrow"
          size="xl"
          @click="wavesurfer.playPause()"
        />
        <q-btn
          color="primary"
          flat
          round
          icon="fast_forward"
          size="xl"
          @click="wavesurfer.skipForward(1)"
        />
      </div>
    </div>
  </q-page>
</template>

And in the script section:

computed: {
    isPlaying() {
      if (!this.wavesurfer) return false;

      return this.wavesurfer.isPlaying();
    }
},

We've added some controls using Quasar's <q-btn> components inside a Quasar "row" div, which arranges them neatly using the positioning helpers flex, fixed-center, and fixed-bottom. q-pb-md/q-pt-md gives us some predefined margins. The @click handlers call wavesurfer's methods directly.

Notice how we're designing the UI declaratively using the template section, with Quasar's modifiers like round, flat and size. This saves us 99% of the css we'd have to write manually.

We've also added an isPlaying computed, which is a wrapper around wavesurfer's method, in order to decide whether to show a play or pause button. It should look like this:

Using wavesurfer hooks to add a loading spinner

Almost done! Now we'll add a spinner in order to give some feedback to the user when the file is loading. Wavesurfer exposes some hooks so we can handle various events. We'll use the error, loading and ready events.

In quasar.conf.js components section, add 'QCircularProgress' to the list.
Then in Index.vue, above the play button, add a q-circular-progress:

<q-circular-progress v-if="isLoading" size="72px" indeterminate color="primary" />

Change the play button to show only if we're not loading:

<q-btn v-if="!isPlaying && !isLoading"
...

Add the isLoading member to the data section:

isLoading: false

And in the createWaveSurfer() method, we'll hook into wavesurfer events:

this.wavesurfer.on("error", err => {
    console.error(err);
    this.isLoading = false;
    this.$q.notify({ message: err });
});

this.wavesurfer.on("loading", () => {
    this.isLoading = true;
});

this.wavesurfer.on("ready", () => {
    this.isLoading = false;
});

We've also added a Quasar notification (snackbar) whenever there's an error. This is made super easy in Quasar using this.$q.notify from anywhere in your code.

A little design

To finalize the design, we'll add a nice background image and some styling on the waveform.
I've used James Owen's picture as the background. Save the picture as audio.png under assets folder, and set it as our main div's background using following css:

.controls {
  background-color: white;
}
.audio-container {
  position: absolute;
  top: 0;
  left: 0;
  height: 100%;
  width: 100%;
  background: linear-gradient(rgba(0, 0, 0, 0.3), rgba(0, 0, 0, 0.3)),
    url("../assets/audio.jpg") no-repeat center;
  background-size: cover;
}

And some styling for the waveform using WaveSurfer options:

this.wavesurfer = WaveSurfer.create({
    container: "#waveform",
    hideScrollbar: true,
    waveColor: "white",
    progressColor: "hsla(200, 100%, 30%, 0.5)",
    cursorColor: "#fff",
    barWidth: 3
});

And that's it!

Summary

I've found Quasar to be a very rapid way of developing a well designed mobile / desktop / web app using Vue, with very little CSS. The CLI is also pretty awesome, and saves a lot of Cordova configuration headache.

WaveSurfer can be customized and has a lot of plugins. We've loaded local files for demonstration, but it can also fetch remote urls from your server.

Don't be an Update Junkie

Jonathan P — Wed, 17 Jul 2019 00:00:00 +0000

"The Update Loop"

Ever found yourself in an update loop? You check your email, refresh your twitter feed, check how many people read your blog post, check your website traffic, your instagram likes, the news updates, and then check your email again?

Recently I've noticed a negative correlation between the amount of focus and creativity I have, and the amount of updates I check for.
Checking for updates is a seductive form of distraction that is built on a need for new, external information.
Updates are addictive, and not by chance. Our brains are ill-equipped to handle them.

I've noticed that the more I slip into this update-checking loop, my mind is more diffused and restless. It's harder to get into the zone of deep focus.
Being in the zone is required for creative work, but it's also more fun than having diffused attention.
This is especially true if you work remotely / freelance, because you have more freedom.

Why we get hooked on updates - supernormal stimulus

While reading Atomic Habits I was introduced to the concept of "supernormal stimulus", which makes it very hard for our primate brains to resist certain aspects of the modern world.

A supernormal stimulus or superstimulus is an exaggerated version of a stimulus to which there is an existing response tendency, or any stimulus that elicits a response more strongly than the stimulus for which it evolved.

Source: Wikipedia

Junk food is a good example of this. Our brains evolved in a world where liking high-sugar foods like bananas (normal stimulus) increased your survival rate, because it was scarce. But now we have donuts with 100x more sugar and fat (supernormal stimulus). They're easy to access, and hard to resist.

Similarly, in hunter-gatherer tribes, being socially validated by your tribe's members (normal stimulus) was important for your survival.
Now you can post on social media, and get validated (or invalidated) by billions of people (supernormal stimulus). That's why it's addicting - getting an update on your social status on a huge scale is just too easy.

The same goes for our curiosity instinct. Instead of getting news from a traveler who came from the next town south, we can get instant updates on anything that happens anywhere in the world.
To add to the mix, we have the best engineers in the world engaged in an arms-race for capturing our attention, and machine learning algorithms that get better at figuring out which content is the most "engaging" (read: addictive).
Tristan Harris does a good job of explaining how out-gunned our brains are in this battle.

The damage

I think that the addiction to external updates is the real danger when talking about productivity and creativity. You get to a state where if you haven't had some external input for 5 minutes, you get agitated and restless. You check for updates, and then you're out of the zone. You become a polling algorithm that constantly polls the server (the internet) for updates.
Creativity requires focus and something coming from within yourself, which is blurred by constant input from outside.

How to stop

I'm not saying we should never get distracted, or do idle things. That's impossible, and probably unhealthy.
It's just becoming too easy to get distracted. And with the blessing of smartphones, it makes it 10 time easier still.

It's not practical be completely disconnected these days, but knowing how vulnerable our mind is, we have to set some limits.

Systems, not will-power

Update-checking is a habit like any other, and to fight it we need to use methods from habit theory.
In order to change a habit, don't rely on will-power. Rely on systems.
You need to create systems that make it less easy to do what you're prone to do.

Here are some ideas for systems you can put in place, that will protect you from yourself.

1. Turn off social notifications on your phone

Notifications like "someone liked your photo" or "someone mentioned you in a tweet" are hooks designed to get you into the app. Once in, you're prone to refresh your feed and get into an update loop.
You can still keep notifications for direct messages sent to you, with WhatsApp or Facebook Messenger.

2. Don't install social apps on your phone at all

This is more extreme, but makes it harder to check your feed 100 times a day. It also protects you from walking head on into traffic while checking your feed.

3. Don't log into your email on your phone

This way you can only access your email explicitly from your desktop. This limits the frequency you're able to do it. This will depend on your work place of course, sometimes you just have to be available via email.

4. Start your day pre-input

The idea of not checking your phone when you wake up is becoming almost eccentric. One of the biggest signs of addiction is doing the addictive behavior first thing in the morning. Try putting your phone into flight mode before you go to sleep, and not going out of flight mode until you do some creative thinking / writing / meditation. Starting your day with a mind clear of external input in the morning can be very powerful.

5. Use Pomodoro Technique 🍅

The Pomodoro Technique - basically cycles of 25 minutes of work, and 5 minutes break. This method is something I revert to every time I notice I'm getting too distracted. Update checking is allowed only during breaks, thereby giving you at least 25 minutes to get into deep focus.

6. Go cold turkey

Sometimes you just need to go cold turkey, and get completely off any kind of updates for a while. A silent retreat is a perfect setting for this, and I highly recommend trying it at least once. Until you experience it, it's hard to imagine how it's like to spend a week without any news from the outside world.

Summary

These are all way of making it less easy for us to slip into a behavior that's designed to be addictive: checking for updates. If you make it too easy, it's just impossible to resist.

Do you notice that checking for updates is becoming a habit and makes you less focused?
What are your methods of dealing with this?

Do you include hobbies in your CV?

Jonathan P — Tue, 16 Jul 2019 06:07:11 +0000

A friend asked for feedback on their CV, and I thought adding some hobbies is a good idea, as it gives a little more depth as a person.
He strongly disagreed, saying the proper place to mention hobbies is F2F only.

What do you think?
Do you include hobbies in your CV?

How to finish your side-project

Jonathan P — Mon, 15 Jul 2019 00:00:00 +0000

I've read some good posts about the importance of having side projects, and I agree, they are important. And fun.
I want to talk about finishing your side project.
Part of the reason I chose to work part-time is so I can have more time for my side projects.
I've started many projects. I've actually finished only a small fraction of them. Here's what I think made the difference.

Definitions

But first, some definitions.

PSP - Personal Side Project

Personal - you're doing it alone, or with a friend
Side project - you're not doing it full time, and if full time, not for a long time (if you're dedicating the next 5 years of your life to work on it, then it's not a side project, it's your startup.)

"Finishing"

For our purposes, finishing your PSP is shipping a working version out there (an MVP if you will) for people to use. In reality, a product is never really "finished". Apps constantly change and evolve. Your product might hit off and you'll decide to continue working on it for 10 years. Or you might release it and realize it's worthless. But for our purposes, finishing is getting it out there for people to start using.

The danger

Pop quiz: what's the biggest danger your PSP faces?

a. Being a bad product
b. Having bad design
c. Having 0 traction
d. Making you so much money you go insane

All real dangers no doubt, but I would argue that the real danger your side project faces is abandonment.
Why? Because you have limited time, energy and motivation.
No matter how enthusiastic you are about it now, your motivation is bound to wane. The more time it takes to finish, the more likely you are to abandon it.

The biggest danger your side project faces is abandonment

Why you should finish your project

But why should I finish it? Isn't it enough to revel in the joy of creation?
Sure, you'll learn a lot from everything you do, and might have a lot of fun in the process. But I've noticed that no matter how much fun I have developing, an unfinished project impinges on my psyche. Like an unrealized dream. Like that girl/guy you thought liked you, and you never made a move, and you'll never know if it could've worked.
But the main reason to finish a project is that it gives you more motivation to keep working on it. Circular argument? Perhaps... Let's see how that works.

Motivation and traction

I've noticed a recurring pattern in my motivation to work on something.

I get super excited about something, and start working on it.
Work on it for about a month, maybe two.
The project grows in complexity, I can't get the design right, progress slows. I get bored.
I get super excited about something else and I'm ready to switch. This is the stage I usually abandon the project, telling myself I'll get back to it later, but it rarely happens.

What breaks this pattern, and breathes new air into a project, is traction.
When you see your product out there and people using it, you get motivated. And for good reason. When people are using your product, you know it's viable, and you know it's worth your time to continue with it.
If not, you know you tried and can continue on wholeheartedly to other endeavors. Also, moving on at this stage doesn't kill your project, because it's out there, and can start gaining traction with time, while you work on something else.

You never know

Your project could reach more success than you think, or even become a source of income. You'll never know if you don't get it out there.
When making the language learning app Flamingo French, I thought it would be mildly successful. It wasn't.

But then we had the idea to test out some languages that don't actually exist, and the results were surprising:

I would never have guessed this when first starting the project.
The point is, you never know until you get it out there.

Better estimations - The 40% rule

Until you finish your project, you're likely to grossly underestimate the work required to actually finish it.
You think to yourself "it's basically done, just need some finishing touches". Those finishing touches can take more time than building it!

After I "finished" building my morning pages app Blurrish (built with electron and vue), I decided to upload it to Apple's app store. It was already working on mac, so I thought it would take a couple of hours to publish to the app store. It took me a week! (I had to re-write large parts of my code due to sandboxing and app signing problems). I could only have learned this by actually trying to publish the app to the store.

I will paraphrase David Goggins here:

Whenever you think the project is done, it's 40% done.

You learn this by experiencing it.

How to finish your side project

Now that we agree that we want to finish it, let's see how.
The most important part of finishing you project is choosing what not to do.
The best way to finish your project is by constraining it.

Eu-constraints

Constrain yourself so you don't strain yourself

Making a product is a form of creation. Whenever you're creating, you're bringing something into existence that wasn't there before. And when you do that, you need to choose from an infinite number of options. This is called the blank page problem in the writing world. And that's the hard part of creating.

Constraints are crucial.
Having a good set of constraints limits the infinite number of possibilities, and even makes you more creative.

Because we usually perceive constraints as negative, let's add the greek prefix "eu" (as in euphoria, not the European Union), to remind ourselves that they're good.

Source: wiktionary

Luckily, we have some constraints built-in to the definition of a PSP, and this is exactly what forces us to be creative.
I like naming things in order to remember their importance. And I also like acronyms. Enter SCRUF.

SCRUF - Simple, Cheap, Re-Using and Fast

The SCRUF method (never miss an opportunity to invent a new acronym) shows the most important constraints for a side project you'll finish:

1. Simple - become a "feature minimalist"

It's hard to build software. The bigger it is, the harder it is.
As developers we have a tendency to under-estimate the time it takes to build something.
NOT developing features you think you can develop is one of the hardest things for developers.
Take yourself by the scruff of your neck and learn to say no to features!
For every feature you add, coding it is just the tip of the iceberg. 90% of the time it will take is in the complexity it adds to the rest of the system, the bugs it will create, the UI problems, etc.
Practice feature minimalism and ruthlessly cut away any feature that's not essential.

2. Cheap - burn rate will kill your project

The greater the burn rate of each product you publish, the more likely you are to pull the plug on it prematurely.
Use free services, or services that will only start costing when your product is generating income.
I think 10-20$ per year burn rate is a good number to aim for. Basically only pay for the domain name (if you need it), and use free stuff for the rest. The goal is to have multiple projects, that can run long enough to see if they stick.
Maybe you think paying 20$ a month isn't a lot, but if you have 5-10 side projects running, it can add up.
Some suggestions for cost cutting:

No dedicated email server / GSuite. You can configure GMail to send and receive emails from you@yourdomain.com.
Use Netlify over Heroku for hosting your public facing website - SSL is free.
Domain - get the cheapest version - shouldn't cost more than 10-20$.
Start paying for upgrades and premiums only when you're making profit.

3. Re-Using - reinventing the wheel is a DRY violation

DRY - Don't Repeat Yourself, the most fundamental rule of programming. Maybe even the definition of programming.
Don't repeat your own logic, and don't repeat other people's work unnecessarily.

A few suggestions:

Make it cross-platform. Use cross-platform libraries like cordova, react native, or electron. Building and maintaining two separate code-bases for Android and IOS, or Mac+Windows+Linux is a huge waste of time (and a huge DRY violation).
Use a UI framework - instead of inventing css for UI components that many people have used before, use a UI framework. Unless a new amazing UI is a core feature of your product, it's better to spend time in other areas than css. Does your app really need that custom CSS you'll spend a week creating? Do your users really care?
Starter project - Spend time on finding a good starter project e.g. Vue project running in a Cordova app with Quasar UI Framework. This will save a ton of time in scaffolding and creating a good dev process.
- Test the components and performance of the stack and UI framework on your TARGET OS before choosing.

4. Fast

For me, the time constraint is huge, and it's a constraint you can easily let go of, because you're in charge of your own time.

I aim for a product I can ship in about one month - calendar time.
This is for first version, and is mainly in order to dictate the size of the project and what features your first version should have. It's OK (and beneficial) to change the idea a bit in order to fit the size of the project to this time frame.

Why calendar time? Because that's the determining factor in how motivated you'll stay. If you have 3 hours a day to work on it, you can do more. If you have 3 hours a week, you can do less. Choose the size of the project according to the time you have to work on it, and keep the total amount of calendar time constant. I've noticed that the time frame of a month works well, and obviously this will vary from person to person. Part of the benefit of making things on your own is that you learn to know your own process and how your motivation works.

A point about deadlines: I don't believe in setting arbitrary deadlines for yourself. This has never really worked for me. You can get into a habit of elimination by keeping a time frame in mind, but an arbitrary date seems redundant. It is a form of constraint though and it might work for you. Try it.

You need to be ruthless to be fast. Cut anything that's not 100% necessary for a useable first version. Good examples are:

Cut server side. Making your app serverless will not only save about 50% of dev time actually writing and debugging server code, but will also make your client code much simpler. I don't know if there is any data to support this, but I would estimate that you cut about 70% of the workload if you can make your project serverless (I don't mean serverless.com, but actually serverless. As in no servers at all). This won't always be possible, but remember that hard constraints make you be creative and might end up giving your product an edge over the competition.
Cut user management / login systems - Is having a user profile a core feature your app will fail without? If not, cut it. You can always add it later.
Cut unit tests. Yes, I just said that. Shoot me. Unit testing is not gospel, and in our case the overhead is not worth the benefit. (Unless your side project is a temperature-regulating app for nuclear reactors. Then please write unit tests.) As your project grows in complexity, and as your team size grows, you might want to add unit testing or another form of automatic testing, but for now, skip it. If SO can do with very few unit tests, so can your small, simple side project. Of course, if you have a super critical piece of code you can protect it from regressions or bugs with unit tests. I did that for user's journal encryption logic in Blurrish, because corrupting journal entries is unforgivable.

Summary - High level work process

Choose a project, using SCRUF to ensure it's "finishable". Don't multi-task here, one project at a time in phase 1.
Publish a first version. Get it out there.
Marketing, analysis, feedback - This can go on while starting the next project.
Maintain, expand, or discard - Is this project worth working more on? If so, great. If not, leave it and move on to more interesting things.
Repeat

Do you have side projects you've never finished?
How long does it usually take you to finish a side project?
Would love to hear feedback / thoughts :)