Best Practices

This final page doesn't introduce anything new — it pulls together the most important habits from every lesson in this Cordova track into one capstone checklist. Treat it as a pre-launch review: before any Cordova project ships to a real user, walk down this list and confirm each item genuinely holds true for your codebase.

1. Always Wait for deviceready

Every plugin's JavaScript API only exists on the global scope after Cordova's native bridge has finished initializing, which the deviceready event signals. Calling a plugin method before that fires is the single most common Cordova bug of all.

document.addEventListener('deviceready', onDeviceReady, false);

function onDeviceReady() {
    // Safe: every installed plugin's JS API exists starting here
    navigator.geolocation.getCurrentPosition(onSuccess, onError);
}

• No plugin call (navigator.*, device.*, cordova.*) sits at the top level of a script that runs on page load
• Every entry point into plugin code is inside, or reachable only after, onDeviceReady

2. Only Install Plugins You Actually Use

Each plugin adds native code, app size, and startup overhead, as covered in the Plugins Overview lesson. Before depending on a community plugin, check that it's still maintained.

cordova plugin ls

• Every plugin listed by cordova plugin ls is one your app code genuinely calls somewhere
• Any community plugin's npm page has been checked for a recent publish date and open issues before you rely on it
• Plugins added for a cut feature, or "for later," have been removed with cordova plugin rm

3. Never Edit Generated Files Inside platforms/

As explained in Project Structure, the platforms/ folder is regenerated by Cordova tooling and can be wiped or rebuilt at any time. All of your real work — HTML, CSS, JavaScript, images — belongs in www/, never edited directly inside a platform's native project files.

# Correct place for your app code
www/js/app.js

# Never hand-edit this directly — it's regenerated from www/ on every build
platforms/android/app/src/main/assets/www/js/app.js

• Every edit you've made lives somewhere under www/
• platforms/ and plugins/ are listed in .gitignore, not committed as source

4. Design for Offline Gracefully

Mobile connectivity is unreliable by nature. Detect connection loss using the technique from Network Information, and cache what you reasonably can locally with the approach from Local Storage & Persistence, so a dropped connection degrades your app instead of breaking it outright.

document.addEventListener('offline', onOffline, false);

function onOffline() {
    // Fall back to cached data instead of a blank or broken screen
    showCachedFeed();
}

• The app checks connectivity state rather than assuming a network call will simply succeed
• Key data the user has already seen is cached locally and shown when offline
• A dropped connection shows a clear message, not a silently frozen or blank screen

5. Test on Real, Ideally Low-End, Devices

The browser platform and your own fast development phone both hide real device-specific bugs. Combine the remote-debugging techniques from Debugging Cordova Apps with the low-end device testing habit from Performance Tips before calling any feature done.

• Every feature has been exercised on a real Android/iOS device or emulator, not just the browser platform
• At least one older or budget-tier Android device has been used for a final pass, not only your primary phone

6. Back Up Your Android Signing Keystore

As covered in Production Build & Submission, losing your Android keystore means losing the ability to ever publish another update to that same Play Store listing. There is no recovery process.

keytool -genkey -v -keystore my-release-key.keystore -alias my-app-alias -keyalg RSA -keysize 2048 -validity 10000

• The keystore file exists in at least one secure backup location outside your development machine
• Both the keystore password and the key password are saved somewhere durable (a password manager or encrypted vault), not just remembered

7. Invest in a Polished, Native-Feeling UI

A UI that behaves like a native citizen — smooth transitions, platform-appropriate navigation, no obvious "browser" feel — matters for user experience and, as noted in the App Store review discussion in Production Build & Submission, for approval odds too. Build this with the framework choice from Using a UI Framework, or careful custom styling if you go without one.

• Navigation, transitions, and touch targets follow platform-appropriate conventions rather than looking like a plain website
• A UI framework (or a deliberately hand-styled equivalent) has been chosen rather than left as unstyled defaults

8. Keep Performance in Mind From the Start

Performance is far cheaper to build in than to retrofit. Revisit Performance Tips regularly as your app grows: minimize DOM churn, optimize images, and avoid unnecessary plugins from day one rather than after users start complaining.

/* Prefer compositor-friendly transforms over left/top animation from the start */
.panel { transform: translateX(0); transition: transform 0.3s ease; }

• DOM updates are batched rather than performed one element at a time in a loop
• Images are compressed and sized appropriately, not scaled down purely with CSS
• The installed plugin list has been reviewed for anything no longer used