PhoneGap Development Mistakes and How to Avoid Them
Custom Splash Screens
One of the first thing a user sees when they launch an application is the splash screen. By default if you use the PhoneGap Command Line Interface (CLI), it will auto generate a collection of default splash screens and icons, like this one.
It is a fairly straight forward process to replace this assets with your splash screen. You do need to make multiple variations to support the wide range of device screens and orientations.
The simplest method is to just overwrite the sample files with your assets. But you can just as easily go into the proper config.xml file and the changes there.
In fact, that was one of the driving reasons I created ConfiGAP for PhoneGap Build in order to assist that process.
I was also surprised that the application made it through the Apple App Store approval process. Yes it met the requirement to have a splash screen, but you would think the gatekeepers would have flagged it.
Holly Schinsky has a nice blog post outlining all the variations of Icons and Splash Screens as well.
Network Access
In another application, I decided to run a simple test. Would the app still function if my device is in Airplane Mode? The reason behind this test was that this app was a companion application to a major technology conference. If you have been to any tech conference you know that connectivity is always an issue. A great way to check your application for this type of use case is to enable Airplane Mode and see how it handles it. So, what happened in this case?
Well, the app launched, and then sat there trying to connect to some remote server, forever. After several minutes, I closed the app. If you make use of ANY network based data or services, you have to check that you have access to the network.
PhoneGap has the Connection API (also known as the Network Information API) which makes this very simple to do. First, this API can identify the type of network you are using. You can leverage this information to estimate the rough data speed you might get and handle the user experience accordingly. This API will call??? send Online/Offline events, so you can respond to the device losing its network access.
In the case of this app, it should have done a simple API call to see if the network was available for locking up the app in a failed attempt to access the schedule serve
Remote Assets
One of the challenges of mobile app development is the approval process for submission into some app stores. This can be at odds with with development time, especially of you are working toward a fixed date (like a conference). One solution is to display the content as an externally hosted web page and use the In App Browser plug-in. If you are not familiar with this Plug-In, it enables another webview to be opened so you can show additional HTML content.
The developers of this conference app chose to use this solution to display their conference maps. Of course this is the issue that I spoke of before regarding “what if there is no network?”, but the issue here is that In App Browser is not the nicest container for the content. The maps were shown, but with an URL address bar (filled with some long content management system type URL) and some unclear user interface controls. The screen no longer looked like the app that I was just using. Probably not the best user experience for a feature that will be fairly well used.
Instead, the developers should have leveraged the File API, allowing one to download and create local files on the mobile device. After properly checking for network status, they could have downloaded the latest maps onto the device, and referenced them locally in their application to create a better user experience.
Disabling the Web Bounce Effect
Another classic mistake when working with PhoneGap is remembering to disable the web bounce effect. If you are not familiar with this, when you scrolling your content in a web view, when the user reaches the top or bottom, the web view will indicate it has reached that point by bouncing or flashing. This is something that screams web app and really makes the app look poorly developed.
To stop this effect, you simply need to add a few elements to your config.xml file:
If you are using it for Android, then use
<preference name="disallowOverscroll" value="true" />
<preference name="webviewbounce" value="false" />
And for IOS, use like
<preference name="DisallowOverscroll" value="true" />
<preference name="webviewbounce" value="false" />
Reviewing on Device
One of the last things to look at is the actual text. I was amazed at how small the text appeared was in the app across multiple devices and it was really poor. I was wondering if the developers actually spent time looking and using their application on a mobile device, or did they just stay on their desktops and using emulators/simulators?
One fundamental rule of mobile development is you have to get it on-device. Now this can be slow and cumbersome (creating signing certificates, installing provisioning profiles, developer settings configured correctly), but the new PhoneGap Developer App can reduce that friction greatly. If you are not familiar with the new tool, it is a free app available for iOS, Android and Window Phone, which allows you to have your local PhoneGap application to run within this on-device shell application. It pretty sweet. Save your file, use the PhoneGap CLI, and run your app on-device as it would truly run. There is no excuse for not seeing your app on a device and ensuring it looks good.
Summary
Hopefully, you have added a few things to your checklist when developing your next PhoneGap application. The platform can do some amazing things, but it does require some extra attention to a few items to help make your apps shine. If you have other lessons learned, please feel to drop me a note.