- Category: Miscellaneous
It seems like I'm becoming more of an app guy lately. It was an interesting realization for me as it's surprising that I've been in mobile for 10 years, but just now seem to be getting into apps.
Of course, spending some time thinking about it, it's not surprising.
My entry into mobile was through BlackBerry; I was a Technical Manager, Applications – meaning that I helped customers understand how they could build apps for the BlackBerry platform. I was a developer supporting developers and, at the time, not much was available for consumers, it was all enterprise apps. Since enterprise required having access to back-end enterprise data, and I didn't use any enterprise apps at the time, not much was available to me.
Next I headed over to BoxTone (now part of Good Technologies) and was focusing on BlackBerry server performance and BlackBerry device performance. Not many apps for me to rely upon. That and I was a BlackBerry guy as the world abandoned BlackBerry, so even less interest in apps.
At AT&T, I was part of a sales team selling mobile application platforms. These were Mobile Enterprise Application Platforms (MEAP) and Mobile Consumer Application Platforms (MCAP) which was all eventually renamed to Mobile Application Development Platforms (MADP). In my focus on platforms, I knew how to build apps for the Antenna, Pyxis (now Verivo) and Kony platforms, but was so busy with development stuff, that I really didn't use a lot of apps. That and working for a carrier, I was constantly switching phones; switching between BlackBerry, Android, iOS and Windows phones – there was really no way for me to use a big app catalog with my device in flux.
At this point, I started using and writing about Apache Cordova and Adobe PhoneGap and therefore had a ton of sample hybrid apps on my devices, but none of them helped me much in my day to day activities.
Next was SAP and I was fortunate enough to be a product manager for part of a mobile development SDK and again focused on helping enterprises build their mobile apps. For a while, I stayed on BlackBerry, but eventually switched to Android. I started using more and more Android apps, but ultimately I stopped traveling so had less need for apps as I moved around.
During my transition from SAP, I started having trouble with my Android phone, so I activated a Windows Phone device that Microsoft was kind enough to give me as I worked on my last book. I struggled a bit with the device since some of the apps I found to be critical (like the Sonos app and the Amazon Echo app) weren't available on Windows Phone. Time to switch back to Android.
I'm getting ready to make a BIG career change and because the company I'll be working with supports a bring your own device (BYOD) environment, I had to buy my very first smartphone (the first one I ever paid for) and my second iPad. I've been reading some books lately on mobile apps and I started researching more apps and loading them on my device. I think the quality and quantity of apps available to consumers is great. I think the separate app for each activity or relationship is a flawed approach, but I'm enjoying getting all of these apps and making them a part of my daily routine.
Already, I'm finding myself spending more and more time with the following apps:
- Sonos: controlling the music that surrounds me
- Pandora: when I want to listen to music when I only have my tablet or smartphone near
- Zinio: Unfortunately, a few of the publications I read are ONLY available in electronic format; I HATE that.
- Flipboard: I LOVE flipboard, that's how I get all my news now
- Banking and Credit card apps: direct deposit is way overdue.
- Google Drive and apps
I used to hate the zinio app, but it's gotten better although it's still flawed in a great many ways, at least it works most of the time (which is an improvement).
There's a bunch more, but you see my point. So many aspects of my day are enhanced through the information provided by these apps. Notice that I'm not playing games – too much other stuff to do.
- Category: Mobile Development
My latest book, Apache Cordova 4 Programming (www.cordova4programming.com), is now available in stores. This is my 7th book overall and my 4th book on Apache Cordova/Adobe PhoneGap.
The book is written for mobile developers who want to learn about Apache Cordova 4. If you’re brand new to Cordova, then this book will be just what you need to get started. If you’re experienced with an older version of Cordova, this book can act as a refresher plus will show you in detail how to use all of the new stuff that’s in Cordova 4. You will need to have at least some experience with mobile development to directly benefit from this book. The target audience could be existing web developers who want to get into mobile development, but much of the needed native mobile development background just isn’t in here. Sorry!
What you’ll find in the book:
- Lots of detailed information about Apache Cordova, what it does, how it works and how to use the available tools and APIs
- Lots of examples and code; for even more code, be sure to check out my Apache Cordova API Cookbook (www.cordovacookbook.com)
What you won’t find in this book:
- Mobile web development and mobile development topics; this is a book about Apache Cordova, not mobile development
- Expressions or phrases in languages other than English (I hate it when authors include expressions from Latin or French)
- Obscure references to pop- culture topics (although there is an overt reference to Douglas Adams’ Hitchhiker’s Guide to the Galaxy and one obscure reference to Monty Python)
- Pictures of my children or my pets
This book is not a book for experienced Cordova 4 developers – if you consider yourself an experienced Cordova 4 developer, then you probably should not buy this book.
Herein I tried to provide complete coverage of Apache Cordova 4; covering enough detail that readers will leave with a complete understanding of what Cordova is, what it does, how it works and how to use it for their mobile application projects. There’s a whole lot more to Cordova, many advance topics and more detailed coverage of the Cordova APIs which is covered in the Cordova documentation or in blogs.
This book started many years ago as a book called PhoneGap Essentials (www.phonegapessentials.com); the book was all about PhoneGap 2.0 and was published right about the time the project name changed to Apache Cordova. The book weighed in at about 300 pages long. The book’s first 150 pages covered the available tools and everything a developer needed to know to configure a development environment then create, write, build and test PhoneGap applications. The second half of the book provided a detailed deep dive into each of the (at the time) PhoneGap APIs. The cool part of this second half was that it included, for each API, at least one complete, functional sample application that demonstrated each aspect of the API. The framework’s documentation was pretty useful in demonstrating how the API worked overall, but PhoneGap Essentials provided much more thorough examples.
The book went on to become the bestselling book on the topic and it was used in university courses around the world. According to Amazon.com, people are still purchasing this book today.
With the release of Apache Cordova 3, I reworked the manuscript and published Apache Cordova 3 Programming (www.cordovaprogramming.com). This book also weighed in at 300 pages, but was essentially a rewrite of just the first half of PhoneGap Essentials with only cursory coverage of the Cordova APIs provided. This allowed me to go into much more details on the tools and development process.
Unfortunately, the book was only available as an ebook, so most readers didn’t even know it existed. This was exacerbated by Amazon’s refusal to link a printed book to an updated version in a different format; I could point people interested in the ebook version of PhoneGap Essentials to the ebook version of Apache Cordova 3 Programming, but I could not do the same for the printed version. The side effect of this was that people continued to buy PhoneGap Essentials even though it covered an older version of the framework.
In order to accommodate those readers who were more interested in the Cordova APIs, I reworked the second half of PhoneGap Essentials into another 300 pages called Apache Cordova API Cookbook (www.cordovacookbook.com). In this book, the complete example applications from PhoneGap Essentials were enhanced and expanded and all of the book’s content updated for the newer version of Cordova. I’d not covered some topics as well as I would have liked in the first book, so this update allowed me to really expand the coverage of some topics and include even more complete sample applications (32 I think it was).
Between Apache Cordova 3 Programming and Apache Cordova API Cookbook, I had written more than 600 pages of coverage of Apache Cordova 3. That’s more than twice the size of the original book and a lot of good information for developers.
With this book, I’ve updated Apache Cordova 3 Programming for Apache Cordova 4 plus included new content on a bunch of topics. In my previous books, I focused primarily on PhoneGap and Apache Cordova; I didn’t cover many third-party tools and left many mobile development topics uncovered as well. For this book, there were a bunch of additional tools available and some hybrid-focused HTML frameworks so I decided to cover as many of them as I could in the space available to me. Where this book’s predecessor was 300 pages, this one should top out at over 500 pages, so there’s a lot of really good information here for all types of Cordova developers. When bundled with Apache Cordova API Cookbook, you’ll have more than 800 pages of information about Apache Cordova.
Herein you’ll find most of the same topics as were covered in Apache Cordova 3 Programming, the only missing topic is coverage of the BlackBerry platform. I wrote the first book on BlackBerry development and had pretty much always carried a BlackBerry device, but between books BlackBerry experienced a dramatic drop in market share and I started carrying an Android device as my primary device. Additionally, in previous books I had the enthusiastic support of my former colleagues at BlackBerry, but when it came time to get feedback on the BlackBerry chapter in Apache Cordova 3 Programming, the development team stopped responding to my inquiries. Because of those two things I decided to drop support for BlackBerry from this book.
So, what new stuff have I added in this book? Coverage of:
- Plugman and the PhoneGap CLI
- Cordova’s support for Firefox OS and Ubuntu devices
- Automation (Grunt and Gulp) and Cordova CLI Hooks
- Microsoft’s hybrid toolkit for Visual Studio
- Third-party tools such as AppGyver, GapDebug, THym and more
- Third-party HTML frameworks such as Bootstrap, OpenUI5, Ionic, Onsen UI
There’s a lot more, but that’s just the highlights.
The one thing I cover in the book, but not in tremendous detail is how to build custom Cordova plugins. I cover the topic and show you how to create two complete plugins, but this isn’t a native mobile development book and that’s a native mobile development topic. I’ve learned from my readers that the material I do provide is enough to help a lot of people get started with plugins and create their own plugins; I’ll leave it up to another author to write a book dedicated to plugin development so it can get the attention it deserves.
- Category: Mobile Development
If you access web applications from a smartphone, you may be asked to provide an email address by the application. This will happen during a registration process, but email is also used as a user's user name, so you may find that you have to type an email in every time you log into a site.
One of the things that HTML5 gives mobile developers is a special input type for email addresses that simplifies email input for users. Unfortunately, most web developers haven't implemented this cool feature yet, and the result for end users is that every one of us has to work harder to input our email address in these applications.
To highlight how this works, I created a sample application that demonstrates the hard way then the easy way to accept email address input in a web application. You'll see screen shots of the application in operation later in the article. You can find the sample application on my GitHub account at https://github.com/johnwargo/email_input.
It seems that most web applications today use the default HTML text input field to capture email addresses:
When the user places the cursor into this field on a mobile device, he or she will see something like what is shown in Figure 1. The user can type anything they want into the input field using the default input keyboard provided by the mobile device.
As you can see from the figure, even though I'm trying to type in an email address, the browser doesn't know that and the @ symbol used in all email addresses is not readily accessible on the virtual keyboard displayed to the user. It's not too painful to press the ?123 key shown in the figure and select the @ symbol from the secondary keyboard, but it's extra work – extra work that every user who accesses the form will have to do every time they use the form.
With HTML5, there's a special email input field you can invoke using:
With this input type, the mobile browser automatically displays an email address-friendly keyboard as shown in Figure 2.
With this keyboard, the @ symbol is readily available and the user doesn't need to press any modifier keys to access it. Every single user who uses the form with this input tag has to use one less keypress to enter the email address.
This isn't an earth shattering reduction in keystrokes, but at least with this approach an attempt is made to simplify things for users. Developers should always look for ways to simplify things for their users and this is a great example.
It's not a lot of work to implement this, simply change the input type from text to email. Now, many of you may be asking yourself what the impact is for browsers that don't support the HTML5 input tags. Well, HTML5 as a draft has been around long enough that you'll be hard pressed to find a modern smartphone that doesn't support them. However, for those browsers, if the email type isn't supported, the browser will simply ignore the tag and render the default input field.
So, there's no impact on users if the tag isn't supported by the browser, but direct benefit to smartphone users if it is. There's no reason not to update all of your email input fields to use this input tag right away.
- Category: Miscellaneous
For those of you that follow me on Twitter or are connected with me on LinkedIn, you probably already know that I no longer work at SAP. This wasn't my idea, instead it was part of an office consolidation that SAP has undertaken. Since I worked in the development organization but wasn't working in an office with my team, my position was eliminated. I live in North Carolina but the people I worked with were in Dublin, CA and Walldorf, Germany so hence the source of the problem.
Fortunately for me, SAP made it pretty easy for me. They gave me some time to see if I could find another position with SAP (I didn't). Plus they did some other stuff (which I can't talk about) to help me in my transition. Overall, a stressful but not a very painful process. Bonus!
I really liked working at SAP. They treated me very well and I was very happy that I was able to work on software development tools (something that interested me greatly). I really enjoyed working with all of the smart people at SAP. As the Product Manager for what was essentially SAP's hybrid development SDK, I was in the unique position where my day job aligned with my hobby. As a writer about and contributor to the Apache Cordova project, owning some of the Cordova-based products from SAP was the perfect place for me.
When I joined SAP, I'd pretty much decided that I was going to stay there until I retired. It was a great job with a great company and I thought I could stay for the duration of my career. Unfortunately, being remote became a problem and I was unwilling to move to California (although I would have been interested in moving to Germany). Over the years, some opportunities presented themselves to me, but, because I wanted to stay at SAP, I didn't really consider them. Now that SAP forced the separation, it gave me some time to pursue some really good opportunities.
During this process, I confirmed that only a small percentage of people find jobs on Job Boards; most nowadays find jobs through their existing connections. Once I decided that I wasn't going to find a new position within SAP, I posted on LinkedIn that my position had been eliminated. It wasn't long before my inbox was filled with emails from my existing contact base offering to help me. I quickly updated my resume then responded to everyone. Before long, I'd been introduced to opportunities in about 10 companies and I began actively interviewing with many of them. Of course, nothing came of some of them, but I was able to begin actively working with 6 different companies on 11 different opportunities.
I only had a certain amount of time to find a job, so I set a deadline for myself and got to work. I was able to secure 2 job offers a few days past my deadline and had one more lined up, but not formally offered. Essentially, I had three opportunities to choose from. Unfortunately for me, I was really, really interested in all three of them. Sigh. I was hoping I'd have a choice to make (and I succeeded), but I wasn't expecting that I'd be solidly interested in all three of them. Sigh, the pressure increases.
For many years, I led custom development (consulting) and product development teams for different organizations. I really enjoyed leading teams. When I got into mobile, I obtained individual contributor roles and had those for the last 10 years or so. With this job…transition, I pursued some individual contributor roles, but also one where I'd be able to build and (someday) lead a team of technical people. At the end of the day, I had to choose between the three opportunities and I did.
I start my new job on Monday – and will tell you all about it once I start. Stay tuned.
Recent commentsView other comments
- Category: Stupid Developer Tricks
I'm constantly reminded of how web application designers don't pay attention to the impact their decisions have on their application users. I've written here before about this, but I think it's time to bring it up again.
When designing a form or dialog, it's important to remember that if you're asking users to make a selection when they first access the site, you should make sure to store that selection so that you don't ask them to make the selection every time. If it's something simple, something the user only needs to address once, most web designers allow the user to make the necessary choice, store the resulting decision and move on. The user's not asked again, so it really doesn't matter how challenging the initial form is if the user is only going to ever use it once.
On the other hand, some sites require that the user make a decision or selection every time they access a site or an area in a site. I don't have a problem with that, sometimes it's necessary and the user just has to deal with it. An example of this is shown in Figure 1.
Employees that migrated to PayFlex sometime in the past will need to be able to access their pre-PayFlex data as well as their PayFlex data. Makes sense to ask the user which way he or she wants to go, right?
In this case, PayFlex has implemented this incorrectly. Whenever you login to the site and try to access this area of the site, you have to make this selection. The problem is that after a while, you'll never need to go back to the old system as all of your current activity is being performed with the PayFlex stuff. OK.
The problem I have with this is that the developer who implemented this part of the application didn't make any effort to keep the user's previous selection. It's OK to ask me every time as there's no way for the site to know whether I want to access the old system or the new system. But, once I go down a particular path, it's likely that the next time I access the site I'll want to go the same way again. What they should have done is store the user's decision then preselect that option the next time the user comes into that portion of the site.
If going to the same place, all the user has to do is click the continue button (the previous choice will already be selected) and they're golden. If not going to the same place, then all the user has to do is select the other option and click continue to go down that path. By making this simple change, I eliminate, can potentially eliminate 50% of the selections the user has to make on this form. It's either one click or two clicks, but most of the time it will be only one click.
By not implementing this simple fix, this company is making every single user make a selection before clicking submit – EVERY TIME THEY ACCESS THE SITE. This is completely unnecessary and wastes your user's time. You should always be on a lookout for ways to eliminate unnecessary actions by your users.
- Category: Content Management Systems
Back in December, I set about migrating this site to a new hosting provider. Hackers had been having some fun with my site and I was having trouble blocking their efforts. Online advice said to whack the site and start over, so that's what I tried to do.
I setup a new hosting account then backed up my existing site. Next I tried to restore the existing CMS data into a new CMS installation (of the same CMS software, of course). The plan was to eliminate any old or nefarious application files and basically start from scratch by doing a new CMS installation with old data. Once everything was working, I planned on upgrading everything to the latest version of the CMS software.
I didn't spend a lot of time on this (over the last 5 months), but I did take a few vacation days to work on this. The result was that I failed miserably, I simply wasn't able to restore my CMS files into a new CMS installation. The biggest issue I faced is that when I brought up the new site, it 'worked' but when I tried to add my plugins back to the CMS, the legacy installations were still there and it became quite a mess.
I tried to manually whack the old plugin installation data (the new CMS didn't actually have the plugins anymore, but the database entries were still there) but that didn't work. The CMS wasn't capable of supporting what I was trying to do.
So, anyway, what I did was backup the site then restored it into the new hosting account. Everything worked (yippee). Next, I upgraded the CMS and almost everything worked. I poked around a bit and fixed the most glaring issues (for me) and completed the migration this evening.
The contact form isn't working right now – I had CAPTCHA problems with it on the old hosting account and now I just need to remember what I did to fix it. I'll work on it this week and will hopefully have things back up and running again. If you need to contact me, my email address is my first name and this site's domain.
- Category: Miscellaneous
As you can see, it's been a while since I posted to this site. Well...I started the migration to a new hosting provider on December 1st and spent a couple of days on it before taking a break for the holidays. I had a couple of lingering problems, so I spent the day today trying to get around them.
I pretty much did, but not other problems have arisen. Sigh - this has been really hard as it's next to impossible to migrate a Joomla! site the way I'm forced to do it here. I'd tell you that I'll write about my experiences doing this, but then I'd be telling lies.
Anyway, I'll keep hammering away at this and let you know when it's done. I have a stack of articles I want to write and post and can't wait to get back at that.
In the mean time, Apache Cordova 4 Programming is 'finished.' I've completed the manuscript and it's been through the editing process, now I'm waiting to see proofs before it goes off to the printer.