This Site & Me
I'm a technologist, mobile specialist, experienced software developer, author, public speaker & an SAP employee. My thoughts, ideas, rants, comments & most of the code you'll find here are my own. Feel free to use any of this, but be sure to identify the source.
Topics You'll Find Here
This site contains content on a bunch of different topics including Mobile, Mobile Development, IBM Lotus Domino and other topics that strike my fancy. I've written a couple of mobile development books, so mobile and mobile development tend to dominate.
Like What you See?
Like what you see here? Found something useful?
If you benefited from anything I've posted here, please think about buying one of my books or taking advantage of one or more of the ads on the page.
- Category: Stupid Developer Tricks
As look at the world around me, I’m surprised that in the world of the connected, mobile user, that companies are still not thinking of mobile-first users. There are millions or billions of mobile devices sold every year, but companies with public facing web sites still don’t seem to notice and I’m really surprised by that.
The local Charlotte BIG insurance company is Novant Health, and they’re usually pretty organized. I was in one of their facilities a while back and noticed that there was free Wi-Fi, so I decided to connect. After selecting the SSID and connecting to the network, I was presented with the confirmation page shown in Figure 1.
So, what’s happening here is that Novant Health recognized that they had a lot of mobile users within their facility and made a conscious decision to provide them with a little extra service (free Wi-Fi) but made no effort to make the confirmation page friendly to mobile devices. Sigh.
If you look at the page, their logo is pretty prominent, but below the fold as it were, so it’s not in the way too much. They probably should have used a smaller logo and put it at the top of the page where it is on every other web site they have.
Like I said, an almost unusable page.
What’s interesting is that it’s not that hard to make mobile friendly web pages out of something as simple as this small page. There are hundreds, literally hundreds, of HTML frameworks that could be used to automatically adjust the format of this page to accommodate any size browser and any type of device.
Taking the same page content, rendering it as a simple page with no fancy extra windows, just a logo, heading, content and a single button – would take no effort whatsoever. Just do the tiniest bit of research into HTML5 frameworks, pick one then mark up your text (using proprietary tags for some frameworks and simple CSS tags for others) and you’re all done. An extra 5 to 10 minutes of work and suddenly your web page works on any device.
For my books, I’ve recently been doing a lot of work with Adobe Topcoat and, as a CSS-only solution, it’s pretty easy to add the classes to your markup to make a mobile Beautiful page in no time. The same could be said for many other frameworks as well.
What I can’t understand is why these companies aren’t making the effort to do this. It’s Wi-Fi, they’re giving external users access to a wireless network. They have to know that the majority of users making use of this capability will be doing so from a smartphone or a tablet. There will be some laptops, but in general the majority of visitors won’t be bringing laptops with them.
I’m assuming they have some sort of tracking capability; that they can tell what systems are using their network – a little bit of checking would allow them to see what their audience looks like.
What’s interesting about this example is that it seems that they didn’t think to test the site on mobile devices, otherwise they would have seen how useless this page was. In my case, I was using a Samsung Galaxy S4 device – probably one of the most popular families of Android devices.
Developers – Know your audience and code accordingly. There is no need for fancy, small, scrollable windows on a smartphone device. Just wrap ALL of your page’s content in <p> tags and let the browser render it exactly as it sees best for the device real estate.
- Category: Miscellaneous
I had an idea a while back for a web application I wanted to create. I’d not worked much with Bootstrap (http://getbootstrap.com/) and wanted to have some experience with it, so I thought I’d play around with building the app I wanted using the framework.
The Bootstrap web site is pretty detailed, and I quickly found an application template I could use for my application. As I poked around, I noticed that the template allowed me to add a simple menu to my application and that worked for me. As I played around with it, I found that every single example I could find ANYWHERE for how to use the Bootstrap navbar (the menu) only showed how to create the menu, not anything about how to structure a the page sections within the application that would appear as you selected each menu item. I checked all of the Bootstrap web site, stack overflow and any other site I could find with examples, but there were none that showed a complete example of a complete Bootstrap web application that had a menu.
Yet another example of a software project where the documentation for things you don’t already know how to do assume that you already know how to do it. Sigh.
Let me show you what I created:
Anyway, I’ve posted the example code to GitHub at https://github.com/johnwargo/bootstrap-navbar-complete. The web application starts with the following code:
It defines the two navbars and mimics most of the examples found on Stack Overflow and the Bootstrap web site.
Next you create individual pages. First of all, you define a container using the following div:
Then, within the container, define separate divs for each ‘page’ of content:
The event listener first deselects the currently selected menu item then sets the current selected menu item to active. Next, in the container portion of the page, all of the divs in the container are hidden then the selected one is unhidden.
- Category: Mobile Development
I’ve been trying to build a sample application using Ionic, an HTML5 framework specifically designed for hybrid applications. I read the instructions, downloaded the code and initiated the command to create a new project.
What happened? Failure.
I posted my issue on their forum only to be told that my Cordova development environment must be old. I explained that it was all up to date and working perfectly for every other Cordova development I’ve ever done and what I got for my trouble was a link to a video that showed me how to install Ionic on Windows.
Sigh. Didn’t I just explain that I have a fully functioning Cordova development environment? Sigh again.
Anyway, I started looking around for a potential culprit. My Android dev tools were all up to date and so was my Cordova installation. I noticed that NodeJS was a little old, so I just installed the latest and greatest version of node.
When I tried the command again, I got the following…
I have the Ionic tools installed and the command runs. It downloads some stuff, then downloads some more stuff then sets about creating a project and adding some plugins to it. As you can see, it’s able to install two Cordova plugins (device and console), but where it fails is when it’s trying to install a proprietary Ionic plugin.
It tells me that there’s the potential that my Cordova is too old, but it’s already been able to install two Cordova plugins without any problems. What could it be about that Ionic plugin that suddenly breaks the Cordova CLI?
OK, so we know that my Cordova is up to date and we know that I can add plugins. I’m pretty sure this isn’t a problem with my Cordova implementation – I’ve created Cordova 30 apps or more with this configuration (and written three Cordova books using this config). So what’s the problem?
Well, the next thing the Ionic CLI tells me is that my Ionic CLI is out of date and that’s what prompted me to write this blog post.
As a developer, when should you check to see that your stuff needs updating? Do you do it before you perform any tasks or do you perform a bunch of tasks, fail, then check to see if there’s a new version of the tool(s)? That was a trick question because the answer to that question is ALLWAYS the first choice – check for application updates BEFORE your tools do anything.
That’s the only option that makes sense.
Why would you tell me I’m running an older version of a tool only AFTER I’ve tried to use it and failed? Whoever wrote that particular piece of code simply wasn’t paying attention.
OK, so I updated the Ionic CLI and ran the command again, only to receive the same error – apparently the Ionic CLI can install Cordova plugins, but not their own as shown below.
I’d ask for help again, but I’ve already done that and all I hear back is that I should check to make sure my development environment is up to date. Nobody seems to want to try to understand what’s happening here or suggest actual steps I can take to try to fix this.
It looks like my next book isn’t going to have a section in it about how to use Ionic with Cordova. Too bad.
- Category: Miscellaneous
Note: The original title for this post was supposed to be ‘How is the Chromium Embedded Framework Documentation like a Sketch from Monty Python’s Meaning of Life?’ but the title was just too long.
I was getting some exercise yesterday and came up with an idea for an app I wanted to write. The app needed to work for Windows as well as Macintosh, so I started thinking about how I’d do it. I’m a big Delphi developer, and the recent Delphi tools support Windows & Macintosh, but I imagine other folks would be interested in this thing, so doing it in something that required a commercial software license to maintain didn’t make sense.
Next I started thinking about whether I could do it as a Cordova application. Windows is a supported platform for Cordova, so that would work, but Macintosh support is only available pre-3.x. I could probably dig up some work in progress OS X support somewhere, but if it’s not part of the core, it didn’t make sense for me.
Then I started thinking about Adobe Brackets. This code editor worked on Windows, OS X and Linux, so they’d clearly picked an approach that worked on each. It’s written using web technologies, so that would work for the app I wanted to build.
I started digging into the Brackets code to see how they’d done it. A while back, a colleague convinced me that Brackets was written in PhoneGap, but in reading around on the blogs it quickly became clear that it was created using the Chromium Embedded Framework (https://code.google.com/p/chromiumembedded/).
So, I started digging around in the CEF documentation and found a bunch of information. There was an introduction page at https://code.google.com/p/chromiumembedded/, a tutorial at http://code.google.com/p/chromiumembedded/wiki/Tutorial and some general usage stuff at http://code.google.com/p/chromiumembedded/wiki/GeneralUsage. Nice! I love it when an open source project has actual guides (that’s one of the things I love about Apache Cordova).
I quickly read through all of that material and quickly discovered that after reading all of it, I still didn’t understand how it ‘worked.’ The materials talked about where to download the stuff and how to build it, but nothing about how to ‘use’ it. The tutorial and usage guides talked about threads, callbacks, plugins and all sorts of stuff, but nothing about how to actually ‘use’ it. It’s clear that after I downloaded all of these files, I had something I could run and use, but how did I actually make it do what I wanted it to do?
I scanned through the stuff again and still didn’t see it. I saw all sorts of source code and highly technical stuff, but not what I needed to know to make an application that did what I wanted to do.
Even the Brackets source didn’t help me as it’s just the source code for the app and there was some external process for building it into the actual platform-specific executables. Sigh again.
Finally, I started searching around again to find some post or article somewhere that told me what I needed to do to make this thing my own. I finally stumbled on an article from Intel at https://software.intel.com/en-us/html5/blogs/an-html5-project-with-chromium-embedded-framework. Here they told me exactly what I needed to do to make the CEF my own – open a configuration file and edit a particular variable to point it to the web application content you want to load.
Ah ha! That’s what I needed to know. All that other stuff about threads, plugins, callbacks and so on is interesting, and that’s information I’ll eventually need, but for now I simply need to understand how to get started. All those pages of content and somebody simply forgot to add the important part – how to specify what content is loaded into the browser container.
So, apparently, for each target platform, you have to specify the content you want loaded in the browser, then use the build process to package it all together into the executable you need. Tada!
The issue for me is that developers working on open source projects are so excited about the technical stuff that they skip the getting started stuff and jump to the ‘important’ stuff. So much of the ‘documentation’ out there is written, in my eyes, from the standpoint that you already know how to do this stuff. I’m not kidding, most every time I take a look at one of these projects, I struggle to get past all the unimportant stuff in order to be able to find the simple, everyday, what do I do with this thing.
That’s why I write my articles and books the way I do – I assume NOTHING and expect that if you’re brand new to a topic, what I’m providing will give you everything you need. If you’re already familiar with the topic, I expect that you’ll be able to scan the content in order to find interesting tidbits. If you read the reviews of my more recent books on Amazon, you’ll see that people seem to agree.
Developers, please listen to me. When you’re documenting your stuff, assume nothing. Let me decide what’s important and what’s important – just document everything STARTING AT THE BEGINNING.
Want to hear a little confession from me? I’ve honestly never manipulated an XML document programmatically. Yep, that’s true. Want to know why? Because I could never figure out how to do so. When I first tried to do it in Delphi, there were some tools to help me do it, but no matter how hard I tried, I simply couldn’t find any documentation or example anywhere that showed me how to actually use the tools. The tool documentation clearly explained to me what methods and properties were available, but nowhere could I find anything that showed me how to create an object, assign it to some XML then retrieve properties from it. I’m sorry, but I’ve been a professional software developer for more than 30 years, but sometimes you simply have to show me how things work. I no longer have the patience to hack away at something for hours to figure it out.
Back when I was doing Java development on BlackBerry, I was trying to figure out how to use KSOAP (http://kobjects.org/ksoap2/index.html) to allow an application to consume XML-based web services. Like I said earlier, the docs explained the methods and properties, but never, nowhere, anywhere did it show me how to use any of it in a sentence. I wasn’t a heavy duty Java developer (never have been) so I simply didn’t have the background I need to be able to understand how to use this thing.
Again, I could have figured it out, but I had a wife, kids and some books to write, I simply didn’t have the bandwidth to plug through it in order to sort it out myself.
I’ll say it again: When you’re documenting your stuff, assume nothing. Let me decide what’s important and what’s important – just document everything STARTING AT THE BEGINNING.
JavaDocs can be…useful and interesting, but where’s the sample code? A simple requirement for each and every API, object, property & method is a code sample that shows the target developer how to use the thingie in a sentence. I know that would be boring for the experienced folks, but just don’t look at that stuff. For folks however who are not experienced with the particular technology, someone who knows just a little Java, lay it all out for them so they can use the stuff.
OK, on to the Monty Python Reference. So, how is the Chromium Embedded Framework Documentation like a Sketch from Monty Python’s Meaning of Life? The story I just told reminded me of the Sex education sketch (https://www.youtube.com/watch?v=PqI-28meTZ8) from the Monty Python Meaning of Life Movie. I’m not going to try to explain it here, watch the video to see what I’m talking about (warning, it is clearly a very adult topic), but what made me think about the video was the teacher’s comment about ‘why not start her off with a kiss?’
When creating documentation for open source projects, start with the simple, give the background beginning users need, before leaping off to the technical details that the more experienced developers need. Both approaches are needed.
Start us all off with a simple kiss before doing anything else.
- Category: Mobile Development
Whenever I publish a book with my publisher, they always pick one chapter and post it online for anyone to read. Picking the right chapter has always been a challenge for me because I want them to publish a chapter that’s interesting enough to make you want to buy the book while at the same time not being so good that you get everything you need and don’t buy the book.
Get it? Please buy my books. I write them because I like to write and think I have a special skill when it comes to describing technical topics, but at the end of the day I like the extra income. Buy my books, please?
Anyway, today, my publisher, Addison-Wesley/Pearson Education, published a chapter from my latest book. The book is called Apache Cordova API Cookbook, and they selected Chapter 1: An Introduction to Apache Cordova (http://www.informit.com/articles/article.aspx?p=2235541).
The publisher usually consults with me on which chapter to publish – they typically ask me which one or ones I would suggest then go off and pick one then put it online. This time they simply picked one and went with it, so I didn’t have any say in what happened here.
As the book is all about the Cordova APIs, so they could either have picked one of the API chapters or picked the only generic chapter: chapter 1. The chapter introduces you to the concept of Apache Cordova, what it does, how it works and what it’s used for. The book is targeted to mobile developers who have at least a little exposure to Apache Cordova, so this chapter is for those people who skipped the requirements and bought the book anyway – I had to give them a quick intro so they’d be able to understand the remainder of the book. It’s a good chapter and should give you a good teaser of what kind of stuff you’ll find in the rest of the book. If you like it, please buy the book. If you’re just getting started with Apache Cordova or Adobe PhoneGap development, you may want to take a look at the companion book: Apache Cordova 3 Programming (www.corodvaprogramming.com).
- Category: Mobile Development
Print copies of Apache Cordova API Cookbook arrived on Friday; my expectation is that they will be available for shipment from Amazon.com and other retailers by the end of next week.
This book, along with my Apache Cordova 3 Programming, provide 600 pages of coverage for Apache Cordova. These two books give mobile developers everything they need to be able to write cross-platform mobile applications using Apache Cordova or Adobe PhoneGap.