The final release of Ionic 4 is a good incentive for migrating existing Ionic 2/3 applications to Ionic 4. The official documentation lists the required steps for creating a new Ionic 4 project and adding Android support to it. If you're using Cordova 8+, then the application will run fine. But if you're still using Cordova 7.1.0, you'll only be greeted by a white screen when the application starts.
Posts about Cordova
Cordova plugins can use variables for project specific values which must be entered when installing them. When these variables are used in Gradle build files for Android, a bug in Cordova 6.5.0 can cause the build to fail.
In a previous blogpost, I've described how to intercept console log output when the application is running on the device, so that it can later be exported using the standard sharing functionality. Although this is usually the most convenient approach for testers, it's an overkill during development. In such a scenario, it's more effective to look at the console output from the debugger.
After we upgraded the Cordova version on our build server from 6.5.0 to 7.1.0, we noticed a large increase in build time for our project. By looking at detailed build times, we could attribute all of it to a single command: cordova prepare.
Logging to browser console can be a useful tool for troubleshooting Ionic applications during development. Although all the logging is still done in test builds, the process of getting the log from the device is not tester-friendly. Without too much effort this experience can be improved a lot by adding an option to export the log directly from the application.
Ionic serve can be a very useful tool for tweaking the design of pages in Ionic applications. However, if your application is using native plugins, some of them might fail with Ionic serve.
Cordova config.xml file contains some information that might be different between the test and the production builds of your application, e.g. preference values or even the application id. This could be solved by having a separate branch in source control with these changes, but you could also modify the values just before you start the build on the build server.
Ionic framework (as well as Cordova, which it is based on) do a great job at abstracting away the details about the platform that the application is currently running on. There are ways to get that information from Cordova, but it's important to understand what exactly the values returned mean.
Cordova has well documented support for modifying the contents of AndroidManifest.xml file from a plugin by adding config-file and edit-config elements to its plugin.xml file. It's less obvious that these same configuration elements can also be used directly inside the application's config.xml.
In native Android applications, the version of build tools and SDK to build them with can be specified directly in the Gradle build script. In Cordova applications, the build file is automatically generated, therefore any manual changes to it will be overwritten. The question is, where do the values in the generated file come from.
Ionic Native makes it very convenient to use Cordova plugins from Ionic applications. Although Ionic Native provides an impressive collection of wrappers for many Cordova plugins, there are still Cordova plugins out there without a corresponding plugin. In such cases you will need to either use them directly without a wrapper or write your own wrapper. The latter option is much simpler than you might think.
Ionic has no built-in support for Firebase Cloud Messaging (FCM), which is now also Google's official push notification infrastructure for Android. However, since Ionic is based on Cordova, it's still easy to make it work with one of the available Cordova plugins.
I was convinced that it doesn't matter in what order plugins are added to a Cordova project. However, I recently encountered an issue with unexpected entries in iOS Info.plist file, which turned out to be caused by incorrect order of plugins in config.xml file.
I have finally updated Android SDK to the latest version, because I wanted Android Studio to stop informing me about available updates on every startup. Unfortunately several breaking changes have been introduced since the version I was using before, which altogether broke my regular flow of work.
Proguard is an optimizer and obfuscator for Java code. It can easily be enabled with only a few entries in the Gradle build script. In Cordova applications, the build script is regenerated on each build, therefore you'll need a plugin to add the required entries to it unless you want modify it by hand every time.
Although there's a lot of talk about Ionic 2 being suitable for creating progressive web applications (PWA), there's little guidance on how to actually configure a project to achieve this. In this post I am listing everything I changed in my project, to build a mobile web application (not yet progressive).