I’ve written a lot of Ionic Framework and Ionic 2 blog articles and have answered even more questions and troubleshooted more problems. When it comes to Ionic Framework, if I had to estimate, I’d say about 80% of the time the problems were related to the Ionic Service solution that the Ionic team offers.
I’ve written a post similar to this before on the topic of properly testing your Ionic Framework applications, but since it’s alarming how many people are still running into these issues I think it is worth bringing up again.
Now before going further I want to be clear that most of these issues are due to people not truly understanding how or why Ionic Serve works. Everyone I help assumes Ionic Serve is a magic fix solution to testing that works under all scenarios. This is not the case.
Let me start by stating the obvious. Ionic Framework is a platform for building mobile applications using web technologies. Just because you’re using web technologies doesn’t mean you’re building mobile apps that will work in a web browser. If you were building an iOS app using Objective-C or Swift would you test or expect your application to work in a web browser? How about if you were building an Android app using Java?
I’m trying to say don’t let the languages create confusion in what you’re trying to build.
Now you might come back at me saying that it is an inconvenience to test an iOS or Android app in the same fashion that you would a native app. Yes it is an inconvenience, but let me throw this example at you. Do you think Tesla Motors or Lamborghini tests its sports cars via a computer simulator or do you think they get behind the wheel and drive them? Wild guess is they drive them.
Here is the deal though. It really isn’t difficult or an inconvenience to test an Ionic Framework Android or iOS app legitimately. I wrote a tutorial on how to test Ionic Framework Android apps with ADB and Ionic Framework iOS apps with Safari console.
The sooner you get it in your head that Ionic Framework and Ionic 2 apps should not be tested with Ionic Serve, the better you’ll be in the long term.
Here is the technical on why Ionic Serve doesn’t work.
Most, not all, Apache Cordova plugins use native code whether it be Objective-C, Java, or both. Tell me the last time a web browser understood how to process these two language. None can to my knowledge.
Let me jump back a second. I said not all plugins use native code for a few reasons:
I must say the two things above are rarely the case.
There must be a trick to my madness right? How can I tell you’re using Ionic Serve? When people want my help troubleshooting, the first thing I ask for is the logs. Well I also ask for the things I list here, but the logs are what I care about the most. An example log can be seen as follows:
TypeError: Cannot read property 'toast' of undefined at Object.show (http://localhost:8100/js/ng-cordova.min.js:9:15751) at Scope.$scope.showToast (http://localhost:8100/js/app.js:23:23) at $parseFunctionCall (http://localhost:8100/lib/ionic/js/ionic.bundle.js:20124:18) at http://localhost:8100/lib/ionic/js/ionic.bundle.js:50863:9 at Scope.$eval (http://localhost:8100/lib/ionic/js/ionic.bundle.js:22178:28) at Scope.$apply (http://localhost:8100/lib/ionic/js/ionic.bundle.js:22276:23) at HTMLButtonElement.<anonymous> (http://localhost:8100/lib/ionic/js/ionic.bundle.js:50862:13) at HTMLButtonElement.eventHandler (http://localhost:8100/lib/ionic/js/ionic.bundle.js:10823:21) at triggerMouseEvent (http://localhost:8100/lib/ionic/js/ionic.bundle.js:2811:7) at tapClick (http://localhost:8100/lib/ionic/js/ionic.bundle.js:2800:3)
Yes I pulled this log out of my previous post. What I’m looking for when people send me their logs is localhost:8100. Neither Android or iOS natively operate on a web address so this is a clear indicator that someone is using Ionic Serve or similar.
So you’re saying you want to run
ionic serve, but test your application via your device or simulator? This is the equivalent of using live-reload which Ionic also has as a service. Don’t do this! Yes Apache Cordova’s cordova.js dependency will probably succeed at accessing the native device APIs, but it won’t do so correctly. For example, what if you’re using a plugin that depends on filesystem access. Since the application is serving via a web address and not its default filesystem method, such commands may not function correctly.
Take my example post on shipping an Ionic Framework application with a pre-filled SQLite database. For technical reasons that I’ve not had time to investigate, the migration from application bundle to local device storage has not been successful. In all scenarios, discontinuing the use of Ionic Serve and any live-reload functionality resolves the issue.
Don’t treat the filesystem stuff as an edge case to what I’m trying to convey. It is one of many examples on where Ionic Serve and live-reload functionality falls short.
Everyone I help who tells me they are using Ionic Serve, I tell them to re-evaluate their testing strategy and avoid this tool like the plague. Hybrid mobile apps, like native mobile apps, should not be tested via a web browser. These apps should be tested directly in a simulator or on a device only after they have first been compiled.
Don’t believe me on the things I said? Search my blog for some of my Ionic Framework and Ionic 2 posts. Look at the common requests for help that I receive, look at what people are using, and look at what the solutions are. Most of the solutions come from no longer using Ionic Serve.