Thinking about Mobile: MediaQuery-CrossPlatform-Native

James Ardery
5 min readMay 9, 2021

In my last blog post I talked about the first hackathon I had participated in where I helped build the backend of a web app focused on showing the user local seasonal produce based on the current month and current location. The group has decided to continue to work on the app and address some of the issues we did not have time to address in the week long hackathon. From a backend perspective we do plan to implement an entirely new model relationship that would make our database far more dynamic and rich with current information from farms we want to partner with for version 2. From a frontend perspective the biggest hurdle was to make the web app responsive depending on the device it was being accessed on.

The front end team began tackling the responsiveness problem of the web app with the media query tool. The media query tool is used for styling web apps across 3 different types of devices.

  1. Screen Device: desktop or phone addresses the responsiveness based on screen size
  2. Print Device: styling applied to a printed version of the webpage
  3. Speech Device: Text to speech screen reader (Chromevox)

We were only concerned with the screen device because we were trying to have the website look good on both mobile devices as well as tablets. The media query sets parameters that must be met for styling code to be applied.

The above styling will only be applied when the screen width is below 600px. A screen width under 600px is common across mobile devices. That being said you can be far more specific and styled based on a given device. Android and iPhones can different screen sizes as well as having to accommodate for both portrait and landscape modes (when the device is rotated). Each mode can have specific styling applied. E readers and nooks have smaller screens than say an Amazon Fire tablet. Your laptop screen vs your gigantic 8k external monitors. As you can tell the amount of styling is almost limitless which is a daunting thing to account for when you are considering mobile styling.

So as the project grows from version 1 to version 2 I started to think about what would be needed to truly make this app mobile. The front end is built using the React framework. React is a great framework for building web apps but to build mobile apps we would need to rebuild the entire front end for a specific mobile device environment(Android vs iOS). So what is the biggest difference between a website/web app and a mobile app?

Websites and web apps run in the browser. The CSS, HTML, javascript is all served up via the browser. A mobile app on the other hand is run on the actual mobile device. So why would someone want to build and app that runs on the mobile device? Well if the application relies on native device technology like GPS location, cameras, or QR scanners then you would want to build a mobile app which will be more effective than a mobile website. Another reason for building mobile would be if the app would require access to media on a given device, like uploading picture or youtube videos. Also another big reason to build mobile is when you want or need your app to work offline. Angry Birds would be a terrible app if it stopped working when my train was stuck underground between stations.

So what are the downsides to mobile? Well writing apps for a specific mobile platform is one major hurdle. iOS and Android have different build specs and app-stores so mobile apps would have to be built to those specifications. Building a native app for an Apple device running iOS is often built using Objective C and Swift. Native builds for Android on the other hand are often in Java. The huge amount of work a company has to undertake building a website in one language, an iOS app in another, and finally and Android in a third requires a large dev staff and large budget. As a result we are seeing far more apps being built with cross-platform frameworks like ReactNative and Flutter vs truly native builds. However there are downsides to cross-platform frameworks. They are going to be less efficient than a native built app. They are also far more problematic when trying to build in offline features. Often times cross-platform frameworks are far more buggy or simply do not work with native device technology like cameras.

So if cross platform frameworks are slower more prone to bugs, lack offline features and native device technology why would they be used? They are often used to build very simple apps like games and content distribution apps. Also cross-platform require a much smaller dev staff and and smaller build budget. Those costs can be offset if the application crashes frequently, has lots of bugs, and creates a poor user experience. So it is very important to weigh all of these pros and cons when thinking about what your app requires from a user experience and build complexity. I have come to realize that mobile is far more complicated that media queries and css styling :)

--

--

James Ardery

Budding Software Engineer trying to find the tie that binds 🤔