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.
However, there is hope. There is a way to reuse 80% of our application code for BOTH iOS and Android development. The strategy to do this is to write your app using web technologies: CSS, HTML, and JavaScript, then configure a WebView (a container for web pages) in your native phone app to render your app pages (saving user preferences, dynamic content, graphics, etc…). HTML5, CSS, and JavaScript should be sufficient to do all of these things INSIDE the WebView of whatever device has WebView support.
A WebView app is composed primarily of Javascript, CSS, and HTML files. Basically, your app is one or more web pages. These web pages make up your frontend interface. The “WebView” is the window through which your device displays these web pages.
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:
Primary Benefits:
Primary Drawbacks:
Web app stored in a central location:
Primary Benefits:
Primary Drawbacks:
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.
Yes, the WebView is the window through which users access most of your app. Most of your app can be written in device-agnostic Javascript, CSS, and HTML. However, there is some device-specific code you will have to implement in order for the WebView to behave properly: eg, IOS WebViews are different from android WebViews so you have to write device-specific code for each different type of WebView.
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“.
What mechanics of your app cannot be written in web languages, like Javascript, HTML, and CSS? Here are some of the mechanics that I had to tackle (for each platform) when building a dual-platform WebView app.
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.
These are some examples of development considerations that may comprise the remaining 20% of development; stuff that Javascript, HTML, and CSS may not be able to handle in an app.
Only platform-specific code may be able to handle these things:
This is a job for Objective-C, IOS / Java, Android…
These are just some of the considerations that you may have to make, outside the confines of the WebView world; Not every mechanical requirement can be solved with Javascript, HTML, or CSS inside of your WebView.
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…
Post a comment
Comments (4)
juan posted
we are waiting for you to continue.. :)
Amit posted
can we capture the screen which is outside of the app means any screen using the screen shot plugin please help me. I have used same plugin but it will capture the only screens only inside the app
Ashley posted
I guess you could split the hosting of the app, have the majority of the code stored locally on the device so it can run without an internet connection and then some stored on a server for things like notifications on new updates for example.
Lee posted
The strategy looks like something I would want to adopt for my next project. The files will be too massive for me to package within the app anyway. Which leads me to a question I was hoping to find an answer to here... While my files are hosted on the web (It's a wordpress site) how can I keep the site from web visitors and make it available only to the app so people can't have access except via the app.