I recently needed to create a tablet application. The immediate need was for iPad, but with a potential for wanting to think about Android tablets and IPhone and Android phones in the future. The potential for wanting to make something cross-platform had me thinking about Xamarin and Cordova from the start, but it was only a potential and I didn’t want to think about something YAGNI. The obvious choice was to use Swift and focus on getting the application delivered. There was something else, though, that really made me think about using Cordova: my client for this project has a team of PHP developers who don’t know Swift, Objective-C, .NET, or Java. They know HTML and JavaScript, though. Creating an application using JavaScript meant I could do a reasonable handoff upon delivery of the initial version of useful software and create a situation where I would not be a dependency in the future. This is a diversion from what I want to talk about in this post, but an important side-point: your job as a contract worker/consultant is not to give yourself a dependent client who will need you in the future – it is to give them something of value and to make them self-sufficient and stronger for the future. If you do that, your value will be clear and business will come to you and you don’t need to worry about trying to make yourself indispensable. It’s better to be valuable than indispensable.
The skills of the team in place for my client were the clear differentiator in why I decided I needed to look really closely at Cordova before deciding on my approach for the project. Ultimately, it was the winner and I proceeded with it. I have had a mostly pleasurable and rewarding experience with writing code using Cordova and have found that it works really well. Using the Visual Studio Tools for Cordova in Visual Studio 2015 was great as long as I didn’t need to test on real devices. The workflow there became painfully, unbearably, and unworkably slow when I was engaging device hardware and needed to see how things were working on a real device. Even using an emulator, though, is painfully slow if your project is configured to build for iOS. This is because of Apple’s licensing that requires using OS X for building iOS applications. Initially, my choice to have started with Visual Studio placed barriers in the path of being able to bypass Visual Studio because it set up files in a way that were not friendly with using the Cordova command line tools and XCode. Fortunately, the latest updates to the Visual Studio Tools for Cordova fixed this problem and had an upgrade path the updated project structures and such that made this work nicely. After upgrading, I was able to clone my repository on my Mac and use Bash to build and execute my application seamlessly and switch back and forth between using Windows for the things I could reasonably do there, and Mac for the majority of my work. All in all, I approve the Visual Studio Tools for Cordova and find it worth using. In retrospect, though, I may have been better off just starting from the command line in OS X and not using Visual Studio and Windows at all. If I have another iOS project, that will be my route, despite my preference for Windows. Apple has successfully put too many barriers in the way of using anything other than OS X, unfortunately.
Developing my first application using Cordova was a suboptimal experience, as you might expect, but I learned some things along the way. Here are some of my lessons:
- Building for iOS using Windows and Visual Studio requires communication with a Mac – what has been done by Microsoft using the XCode command line tools to create a remote agent to be able to code on Windows and with a build that goes over the network to a Mac (which, in my case was on the same machine with Windows running in VMWare Fusion inside the OS X running on the machine) is cool, clever, and works, but it’s too slow to use for real development, especially when you’re dealing with something focused real hardware with the need to test extensively on the device (in my case, camera interaction being the heart of the functionality).
- Testing on a device can work nicely with using a remote URL for your development machine for the index.html in the Cordova application and LiveReload. Gonzalo Ayuso has a fantastic post about how to do this. His post uses Ionic, which I didn’t (though maybe I should have – it appears a lot of folks writing Cordova applications are using it). My modifications to what he did to do this without ionic are below. LiveReload is awesome and you should be using it for web development as well. It is more fully featured on OS X than on Windows, but works on Windows as well.
- iFunbox is really useful for being able to view and manipulate and clear state if you are using local storage in your iOS application from your development machine on OS X and gets rid of the need for some of interacting with your target device via touch. It’s an enhancement to your workflow.
- There are very useful plugins for Cordova and they work really well. It’s easy to add them (especially using the Visual Studio Tools for Cordova). I especially like how they can be added using a GitHub repository location. The modularity of Cordova, using the plugin architecture is nice and makes it easy to just grab what you need. I used plugins for file system access, and for capturing photos and videos from the camera.
To use LiveReload, as illustrated in Gonzalo’s post, without using Ionic, I just wound up using the HTTP server built into cordova. From the Cordova application directory, I just issued:
cordova serve
This command opens an HTTP server and shows the port it was using. It then serves all the platforms you have set up in the application on paths under that root server path. For example, if cordova serve is using port 8000, your index.html in the ios output of your application will be at: http://localhost:8000/ios/www/index.html (localhost won’t work from your iOS device, so you’ll want to use the IP address of your Mac on your LAN).
With this in place, you can modify your config.xml to point to (fox example):
<content src=http://192.168.1.1:8000/ios/www/index.html />
I also needed to create a task, using Gulp, to copy changes I made in my repository working files to the ios output directory. With that done, every change I would make on my development machine would reflect on the iPad and make for a really nice testing experience.