Today in the #phonegap IRC channel, a frustrated developer showed me the cartoon below:
Sourced from: http://www.commitstrip.com/en/2014/08/18/the-dilemna-of-mobile-apps-development/
It’s funny, of course, and closer to the truth in some cases than some of us would like… but it’s still a massive over-simplification. It reminds me of my lightning talk: "PhoneGap doesn’t suck, YOU suck" and the great blog post by Brock Whitten (@sintaxi) that inspired it - "You half assed it. That is why your PhoneGap application sucks".
I can’t draw cool cartoons, so I can’t make a pretty rebuttal. However, I would posit that developing a PhoneGap app properly is more like following Google maps to a beautiful suburban home. Is it Neuschwanstein? Maybe not, though it depends greatly on what kind of app, and the developer(s) making it. There are certainly areas where hybrid app development shines, and some where it struggles. But, I would further suggest that a quick perusal of the various app stores would clearly show that merely being “native” does not instantly bestow taste in design, lightning speed, or the ability to make a useful and useable app that users actually enjoy. The castle on the left is probably as much of a fairy tale as it looks.
As the wise Eion Robb said in response to my wanting to write this post:
"the real argument is time [leads to] quality, regardless of language, platform, [or] technology. There are no shortcuts"
Some backstory: both iOS (as of iOS 7) and Android have app switchers that display a screenshot of your app. This is a lovely feature for most apps, but if your app displays sensitive information, this is a possible privacy risk.
The problem was that I was trying to do this using variations on the pause and resume events available in Cordova / PhoneGap. These events can be very handy, and I already use them for other purposes, but for this use case they don’t fire fast or early enough. The screenshots of my apps were getting taken before any DOM changes I might make in the pause event occured. I had basically given up on this thinking that a cross-platform plugin to do this would be way too big of a pain.
It came up again in conversation with SpiderOak’s “security guy” Tomâs Touceda, and I decided to take the plunge and see how hard it would be. I had grand plans of covering the screen with an all black native view or something. I knew how to do that in iOS, assuming I could hook into the native
applicationWillResignActive or similar. The issue was Android, of course. My native Android dev skills are way weaker than my Objective-C and iOS, particularly in the area of LayoutManagers and other view stuff.
Luckily, after about 15 minutes of ye olde Googling, I found FLAG_SECURE!
Well, between that and a recent Cordova dev email thread mentioning method swizzling (omg, that term… pfah!), I had a real idea for how to get started. I also found a great StackOverflow post that suggested just hiding the window.
I don’t like having to use plugins, but I really enjoy writing them, strangely. So a couple of hours later, I had a real working plugin on two platforms.
Have a look, raise an issue, or fork away here: https://github.com/devgeeks/PrivacyScreenPlugin.
Warning: this is a pretty log post.
A few months ago, I bought a ZTE Open Firefox OS device on eBay. It was the original Open, not the apparently much nicer Open C that is available now. I wanted to have a play with Firefox OS as not only was it entirely HTML5 based, but Apache Cordova was beginning to implement support for the fledgling OS. I was pretty interested in seeing how well it worked, and the phone itself was pretty cheap for an outright phone - less than $90AUD.
Now, first up, let’s make it clear that Mozilla is not targeting iOS or Android with Firefox OS. It is not intended to go head to head with those much more established mobile OS’s. Mozilla is instead interested in the market the other two have almost entirely ignored. Low priced and developing countries. A Firefox OS device is not intended to replace an iPhone or the latest Samsung Galaxy device. A Firefox OS phone is much more likely to replace a “feature phone” – a dumbphone, as it were. They seem to be looking to get smartphones into the hands of people that otherwise might not be able to afford them. This is another reason I was very interested in the platform.
I mention all that as the nicest possible way of saying that my ZTE Open was not a very high end or powerful device. In some ways, it’s even more low powered than my HTC Wildfire S – my slowest Android 2.3 test phone. In fact, in a lot of ways the two phones are very similar. Small screen, low powered CPU, etc.
As I kinda have a soft spot for the aforementioned HTC Wildfire S, I actually liked it quite a bit. After playing with it casually for a couple days I came to the conclusion that they were doing a pretty good job at what they were trying to do. The “apps” worked nicely, and the seamless integration with “hosted” apps - i.e.: actual served web apps like Facebook Mobile and Twitter Mobile - was a real joy. Only iOS really comes this close to making a web app feel like a “real” app - removing the location bar, etc. I resolved kinda halfheartedly to try and think of an app to make for it. I didn’t think I could port my current apps to it, but thought it would be fun to try to think of something more suitable.
This was all a while back when I first got the device. I came away basically feeling that I really thought Mozilla was onto something, and that if I ever found the time and an idea that might suit the power of the device I would try and make an app for it. I also kinda thought that if there ever was such a thing as a high-end Firefox OS device, that it might almost be possible to use it as a daily driver. I don’t actually use as many apps as you might think an app developer would. Email, Facebook, Twitter, SpiderOak and Encryptr - gotta eat your own dogfood, after all - and that’s about it. Of course there are plenty of other things I use rarely, but those main ones are my desert island needs from a smartphone. I thought that if I had a Firefox OS phone as powerful as my Nexus 4 - my main phone at the time - that I would certainly be willing to give it a go, just out of HTML5 solidarity if nothing else.
So fast forward to this week. I started thinking about my little orange phone again and even updated my Firefox OS simulator. Now that the Cordova CLI supports Firefox OS, I thought I’d see how hard it was to get a simple Hello World app up and running, at least on the simulator. Turns out it was so easy that it only took a couple seconds. I wanted more. Out of morbid curiosity I made a copy of my Encryptr app to really see how far I could push it. To my complete surprise, I ran the app up on the simulator and it actually mostly worked. All the primary functionality.. it worked. Wow.
My next problem was that the ZTE Open came with Firefox OS 1.0. My version of the Firefox OS simulator and App Manager needed at least version 1.2. This left me unable to even see how bad it was without upgrading. I couldn’t even run up a Hello World app. I needed to upgrade the ZTE Open. It didn’t go as smoothly as I would have hoped - at one point I even had it in an endless reboot loop - but I managed to get it updated to 1.2 with instructions on Mozilla’s site. Yay!
I think all this preamble is a dead giveaway for what happened next. I ran Encryptr on my little ZTE Open. It not only ran on the low end hardware, it actually ran better than it does on my iPhone 4. A lot better. It was actually useable. Could it be faster? Of course. but was my mind blown? Absolutely. No matter what else, I was impressed with Firefox OS at that point. I will also be fixing the last few issues, and around the same time as the Android release, I will be releasing Encryptr for Firefox OS.
At this point I am pretty fired up about Firefox OS. I remembered how I felt that if only it was on decent hardware, it would be even more amazing. I remembered that at one time it was possible to run Firefox OS on a Samsung Galaxy S2. Since I had an S2 lying around, I thought I would see if it had gotten any easier to do. It hadn’t, really.. but wait… what’s this? Instructions on how to install Firefox OS on a Google Nexus 4? O_o
My Nexus 4 is no longer my main phone, so it was a ripe target for being flashed with a new OS. After a little trepidation I went ahead and did it, and let me tell you, Firefox OS 1.4 on a Quad-core 1.5 GHz CPU with 2GB of RAM is a sight to behold. It’s pretty much everything I had thought it would be. I am not trying to switch to it as my daily driver yet or anything, but it’s only been flashed since this morning. Just going to have to keep playing with it and see, but either way, it’s still pretty damn cool.
Note: don’t flash a Nexus 4 with Firefox OS then use it as your test phone for development. It’s as bad or worse than only ever using the simulator. Actual Firefox OS devices in the wild will not have that much grunt. Use a device like the new ZTE Open C or one of the Geeksphone developer devices. Mozilla is pretty keen to get devices to developers that are serious about porting their apps, so have a look at see if maybe you can get in on the Phones for Apps program. However, if you want to use Firefox OS as a serious replacement for an iOS or Android device, a Nexus 4 makes a fantastic Firefox OS phone. I am looking forward to seeing where it takes me. This could be the start of a beautiful new friendship.
It turns out that Firefox OS still doesn’t have copy/paste clipboard functionality at all. It is planned for 2.0 due out around the middle of the year. Needless to say, this puts a dampener on my plans to release a password manager for the platform. I guess I’ll revisit it in a couple months. Until then, I have some ideas for other apps I want to release on Firefox OS
Appium talk at Melbourne Mobile -
Another set of slides, still no decent blog posts. *sigh*
Oh, well. Here is a short little talk I did about http://appium.io at the Melbourne Mobile Meetup for March.
I see a lot of confusion still about the difference and relationship between Cordova and PhoneGap.
TL;DR: If you don’t need to use the cloud build service at PhoneGap Build, just use the Cordova CLI tools, not the PhoneGap ones.
Lemme see if I can start with the penny tour.
In the beginning, there was PhoneGap. It was an amazing project by a little company called Nitobi in Canada. It was open source, and it was good.
Then the little company and the name PhoneGap was bought by Adobe. Adobe did not buy the actual PhoneGap codebase, just the people that worked on it, and the name. The actual open source project was donated to the Apache Software Foundation.
So now the open source project needed a new name. After a couple of false starts, eventually they came up with “Cordova” – the name of the street the Nitobi offices had originally been on in Vancouver.
For a bit over a year, “PhoneGap” was just the Adobe binary distribution of the Apache open source project “Cordova” – you could think of PhoneGap as Safari to Cordova’s WebKit.
Now, all of this has been better documented in a couple of other posts by smarter people. The problem lies in what’s happened since then.
In version 3.x of Cordova – and therefore PhoneGap – a shift was made towards heavy use of a Node-based command line interface (CLI). It handles everything from creation of the project, installing plugins, and finally building and even running the app. It’s awesome, by the way, and if you haven’t made the switch away from the shackles of IDEs like Xcode and Eclipse, I heartily encourage you to give it a try.
Anyway… at the PhoneGap Day US conference, back in July of 2013 in Portland, we released the 3.0.0 version of Cordova. At the same conference, a variation of the Cordova CLI was launched called the PhoneGap CLI. The first split in actual functionality between the two had finally arrived.
The PhoneGap CLI is a similar-but-different variation on the Cordova CLI. It does much of the same things and even uses the Cordova CLI under the hood. The biggest difference lies in its connection to Adobe’s cloud build service called PhoneGap Build. The PhoneGap CLI allows you to – from the command line – create and build apps using that service. You don’t need the SDKs for the various platforms installed on your machine.
However, aside from some small syntax differences – and a couple missing features, if I am to be honest – the use of PhoneGap Build is the only difference at the time of this article. So as I said in the TL;DR above, my advice is that if you don’t need to use the cloud build service at PhoneGap Build, just use the Cordova CLI tools, not the PhoneGap ones.
More importantly, whatever you do, do not “mix and match” in a single project. This will only make a big mess.
I hope that clears it up a bit… if not, please feel free to send me an email, or come and hit me up me in the #phonegap channel on Freenode IRC.
Crypton: Giving Privacy to the Internet -
I know I said no more slides till I actually post a real, well… post… but I spoke at the always awesome MelbJS tonight about Crypton and thought I’d better put these slides up with the others.
Actual blog posts with actual sentences and not just bullet points coming very very soon, though.
setting up a cordova build environment with grunt and jasmine by devgeeks -
I was working on a new actual post (as opposed to just posting slides like I have been lately) and realised that my grunt-init-cordova slides never made it onto the blog. I have just totally updated grunt-init-cordova (as part of writing the upcoming post) and there will be more about it there.
JS UI Framework Smackdown! - None of the Above -
Slides from my talk at the Melbourne Mobile meet up - August 20th, 2013.
So, I decided to advocate for “none of the above”
SpiderOak: The road to a performant open source mobile app -
Slides from my PhoneGap Day US talk about SpiderOak