• WebView Strategy for Creating Mobile Apps

    30 May 2017

    Both Android and iPhone (iOS) development are separate beasts. For example, if you create an Android app, you must rewrite it as a port to iPhone. All that hard work x2. It isn’t ideal, but we do what we have to do to work around the limitations imposed on what we can develop.

    PhoneGap as a shortcut.

    PhoneGap will try to minimize the amount of platform-specific code you have to write by providing pre-packaged “boiler-plates”. PhoneGap intends on handling the mechanics of your WebView on different platforms. You can focus on developing web content to fill PhoneGap’s pre-written WebView.

    PhoneGap is great for pre-packaged functionality. However, it will make it more difficult for you to fine-tune the mechanics of your app… unless the mechanics, that you want, are already pre-packaged.

    If you are new to app development and you have never used PhoneGap, I recommend learning ios/android development first.

    Without adequate understanding, something that’s supposed to make life easier, only makes it more complicated.

    PhoneGap is great, if used well. However, if you are trying to use it because you want a shortcut from learning something new then you will probably end up having to take a lot of time to learn PhoneGap, instead. Then, you will also have to learn app development, anyway (when developing something that PhoneGap doesn’t do out of the box).

    Legends say that the “easy button” command exists for every language. It’s functionality is thus: Anything you want to happen will happen as long as it’s detailed by one or more vague sentences. Here is an example:

    ipconfig//:easy button:: "Make an app or something. Should haz sum birdz. Peepz like them som bird appz. Give up tha dollah$-dollah$"

    Before the discovery of the “easy button” command, people once resorted to spending time and effort on things.

    A simple app design

    Enough with the strategy. Let’s propose a simple WebView app, to provide context.

    app design
    app design
    app design
    app design
    app design

    Our app could have hundrends of different “screens”. However, there are only TWO different WebViews. WebView 1 displays all of OUR content. Our entire app is displayed through this primary WebView 1. Alternately, WebView 2 will display any external content that we want to “frame” into our app. For example, if we want to include an external link to something, we will use WebView 2 to display the external content.

    • Loading Screen (WebView 1) Even if your web files are hosted locally on the device, there will be a period of time when the first WebView must load the home screen. During this time, display some sort of loading indicator instead of just a white screen. The native device’s code must handle
      this loading indicator since your web files haven’t fully loaded yet.
    • Internet Connection Error (WebView 1) If your web files are hosted OUTSIDE of your app, then you will need to display an error message when your app cannot reach those external files. For example, if the user is in airplane mode, the device’s native code will need to display this message if the WebView cannot load your web files.
    • Home Screen (WebView 1) The first proper screen that appears when the app is done loading.
      Under the hood, this screen is made from a collection of Javascript, HTML, and CSS files (instead of having to use native device code to generate this content).
    • Sub Page (WebView 1) Just like the home screen, sub pages are just made up of HTML, CSS and Javascript. There is no need to get native device code involved in generating such content.
    • External Page (WebView 2) What if your app contains a link to an external webpage? When a user clicks on this link, you want the user to see the external content WITHOUT leaving your app. To do this, you can have a 2nd WebView that opens the external URL.


Comments closed on this post.