Given that I have spent some time setting up a couple of development environments for mobile web applications, I thought it appropriate to step back and observe the overall process. These are just my thoughts. I would be most interested in comments from readers regarding these thoughts.
First and foremost – this process reminds me of the Wild Wild West days of the WWW (circa, 1994 or 1995), only worse. Not only are there multiple ways to do everything, there are no emerging standards. Yes, many of the emulators are Java based. That is where the similarities end. There are a dizzying amount of different screen resolutions (one must give some thought to these if one wants to have a reasonable visitor experience). Of course, I haven’t even begun to fully investigate the other end of the screen environment (for example Google TV). You might be amazed to see what my website looks like on a 54 inch high def display (perhaps amazed is not the work I should have used). I long for the days when we only had to worry about PCs and Macs and 800 x 600 vs 1024 x 768. Today, I suspect there are hundreds (if not thousands) of different resolutions. Luckily, I have access to tools like Adobe Device Central CS5 to help me better understand the settings. Also, thankfully, many of the browsers are based on the WebKit rendering engine. Of course, every browser has its own nuances.
Second – this process is complex and will be daunting for many. Here are some of the technologies/ skills I have needed to employ in setting up development environments for Android and Blackberry devices. Obviously, Apple and Objective C are out of my present scope since I don’t have a Mac. These technologies/ skills are listed in no particular order – I just want to provide an overview of what one presently encounters.
- Ability to locate, download and install current Java Development Environment.
- Ability to locate, download and install Eclipse.
- Ability to locate and install Eclipse plugins.
- Ability to locate and install various developer SDK (software developer kit) environments – each unique for the platform in question.
- Ability to work with Adobe AIR.
- Ability to work with Flash Builder 4.5.
- Knowledge of HTML, CSS, and JavaScript.
- Ability to debug applications when they don’t work right the first time.
- Ability to debug development environments.
- Ability to work with VMWare virtual environments.
- Knowledge of networking to identify what to connect where.
- Ability to work at the command line in Windows.
- Although I did this because of personal reasons – ability to install and work with VirtualBox
- Keeping the focus on draining the swamp while one is up to their … in alligators.
I have probably forgotten a few items on the above list, but it should make everyone pause and consider what it will actually take to teach all this in a college class. Yes, it would be easier to focus on a single device, but there is still a tremendous amount of setup involved. Ok, I could do all that and present everyone with a customized virtual environment, but where is the fun in that?
Perhaps the following anecdote will help one better understand the complexity of developing applications in this environment (and why tools like AIR are so attractive – since they can yield remarkably consistent results across these environments). I obtained a bit of mobile jQuery code used to develop a small application at AdobeMAX in October, 2010. The code worked great in Safari on the desktop (Windows 7). I then deployed it on a web server and began looking at it in various browser environments. What is interesting about this little snippet of code is that is takes advantage of the HTML5 local storage capabilities (using SQLite). Essentially, it is just a laundry list stored locally. However, unless it works, the point of the application is lost. I tried this out on a few different browsers (yes, there are many others). By the way, these are the most current versions of each of the following browsers.
- Safari (desktop) – works like a champ
- Chrome (desktop) – works like a champ
- Firefox (desktop) – save button doesn’t work
- Opera (desktop) – works like a champ
- Android – default browser – unable to create database error
- Android – Dolphin browser – works sporadically (depends on version of browser)
- Android – Opera Mini browser – save button does not work
- Android – Skyfire browser – everything appears to work, nothing saved locally
- Android – Firefox browser – application freezes when save clicked
- Blackberry – default browser – works like a champ
- Google TV – default browser (Chrome) – works, but selection lists don’t behave (although data can be stored). Ok, I know this last one is not mobile, but since I happen to have one, I had to test.
That is just a small sample of the browsers one may encounter. Note that the results are all over the map. Nothing works consistently. I realize HTML5 is still emerging. However, if someone wants to take advantage of a given feature today for a business application, they can’t count on any sort of reliable environment (unless they test in all likely combinations their clients will use – and this likely measures in the hundreds of devices/ browsers). Obviously, tools like Adobe AIR provide a more consistent approach across platforms today. These applications will function similarly. One just needs to create the appropriate installation file. However, one must still identify the deployment platform for the application (whether Android or Blackberry or what ever). Welcome to our new view of the WWW (and welcome back to 1995). Clearly, we need to emphasize web standards today more than ever as we teach in this brave new world. And don’t forget to test, test, and test some more in all the possible combinations a visitor might use.
Loading ...
