The Moust videoplayer plugin allows the app to play videos within the app in fullscreen mode.
Unfortunately, the video does not play according to its own proportional size, nor is it confined to the proportion of the div it’s in. It breaks out to fit in the device window. We are given two different options for scaling the video. The following were the results when viewing a 320x200px video in my Nexus 7:
SCALE_TO_FIT_WITH_CROPPING As noted, this doesn’t show the whole video. In landscape, the top/bottom are cropped. In portrait, the left/right sides are cropped. No pinch-to-reduce functionality included.
SCALE_TO_FIT (default) This will stretch/squeeze the video to fit the device’s screen, whether horizontal or vertical orientation.
It makes the most sense to use this player when you want to play back the videos in the same mobile device you shot them with; then they would play back in perfect proportion. If you want your videos to play back reliably across Android devices in their own proportion, I recommend trying Crosswalk. Continue reading
Why consider using Crosswalk? Android devices have different implementations of the webview, in which our PhoneGap and Cordova apps appear. Vendors have made their own tweaks of the webview, causing our code to render inconsistently. So our CSS and scripts will play differently across devices or not at all.
For instance, the HTML5 <video> tag won’t work across all Android browsers:
controls preload="auto" width="320" height="240">
<source src="video/myvideo-h264.mp4" type="video/mp4">
I'm sorry; your device browser doesn't support HTML5 video in MP4 with H.264.
But it will work in the Chromium webview provided by Crosswalk. By adding the Chromium webview to our app, we will have a unified Android playing field for our app. Continue reading
I updated the following pages several times over the last few weeks. I realize that subscribers are alerted only when new posts are made, not when pages are updated, so this post is to alert you to several important edits.
I made updates to conform the processes more closely to Cordova 5.0.0, explain how I do icons and screens with iOS reliably, and described my process for creating screengrabs more thoroughly (for iOS), among other edits.
More information was added to the bottom of the adb logcat after its first release:
A more descriptive title would be, “Using ADB logcat outside of ADT, Eclipse, or Android Studio to debug your Android app installation errors.” Did you try to install the app in your Android device, but got the annoying “Unfortunately, [app name] has stopped”? If so, then you need to run ADB logcat to find out why. Logcat allows us to read the logs that are automatically running in the background when we run the program. So when the app quits suddenly, we can read the messages along the way and pinpoint when it went south. Here are the steps to implement logcat. Continue reading
Here’s a cheat sheet for creating a Cordova app from start to finish. No details on this page; they’re all covered elsewhere on my site. My environment for this is a PC machine with Windows 7 Pro, and this is building an Android project. I’m not using Eclipse or Android Studio — they are not needed. Continue reading
I’ve decided to ditch Eclipse in favor of the NetBeans IDE. Since we can create signed apks with the Cordova CLI, Eclipse is no longer needed. There are several good replacements if you want a code editor. NetBeans, like several other code-creation editors, offers much more than a text editor can provide. Here is why I am enjoying NetBeans (NB) with Cordova. These are just a few of the features I’ve found handy when using NB. (If you have a coding IDE you favor other than NB, please talk about it in the comments section.) NB works on the PC and Mac. Continue reading
I decided to try npm (nodejs) and see how it could streamline my workflow. If you’ve been using Cordova or PhoneGap, you probably already have npm installed – you used npm to install either one in the first place. But it can do so much more.