Posted Jan 20, 2015 by Gregg Milligan
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.
Normally, when a user views web pages, they use a browser. However, a WebView replaces a “browser.” Instead of allowing users to change web pages, the WebView only displays pages related to your app.
Mechanically, your app is a bunch of web pages. However, aesthetically, it appears to be a normal app. This is the WebView strategy.
With the WebView strategy, you can store the bulk of your app code on the device OR you can just host your code as a website page. Either way, there are benefits and drawbacks to both storage locations. Choose where to store your app code files based on your unique needs. This post applies to both methods equally, so whatever you choose, this article still applies to you:
Web app packaged with the phone app:
Web app stored in a central location:
Disclaimer: This list of pros and cons are not all inclusive. For example, you should also consider what should happen if your centralized host crashes. Instead of having devices trying to access a broken server, you could design a backup procedure where devices fall back to locally cached data. But such additional considerations are beyond the scope of this article. Let’s just keep things simple for now. Where should your app live? This is up to you.
If you plan on writing your app for BOTH platforms, then you will have to work with the unique mechanics of the WebView in two different “worlds“.
Note: 80% vs 20% are very rough approximations for the ratio of WebView versus platform-specific development time. Percentages can vary for different projects and depending on what you would like to accomplish.
Only platform-specific code may be able to handle these things:
This is a job for Objective-C, IOS / Java, Android…
Sooner or later you will probably have to get your hands dirty with some platform-specific code or configuration.
If you are NOT interested in taking the time to setup your WebView in two different platforms, then you should check out 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.
Enough with the strategy. Let’s propose a simple WebView app, to provide context.
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.
We’ve covered the app strategy and a basic design plan for a simple app. Next, let’s discuss real, device-specific (Android/iOS) code you can use to actually make this amazing app…