Mark DuBois Weblog

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.

Last month, I spent some time investigating development of mobile applications with a focus on the Android market. Over the holidays, I finally had a chance to investigate development of mobile apps in the Blackberry market. These notes are a summary of my findings. Please note that I will not be including a section on iPhone development as I don’t have a Mac (and as far as I can tell, most IOS development tools assume one has a Mac). Since I have a Blackberry Torch and hope to have a PlayBook in the near future, I decided to focus on these devices.

First – emulators. As with Android emulators, one must have Java installed on your computer.There are separate simulators for both the Torch and PlayBook. One needs to obtain these from the RIM website. Frankly, I found the site a bit hard to navigate and found that it was easier to use a search engine to find the link to the appropriate download. I did find the documentation at RIM well thought out and thorough. For example, the documentation to create your first Adobe AIR application for the PlayBook is comprehensive and easily explains how to accomplish this on a step by step basis. As before, one needs to download the appropriate SDK and simulators and install it (for the Torch). The PlayBook simulator is provided as a VMWare install. Curiously, neither simulator seems to be able to run a browser within the environment. See the screen captures below for the Torch emulator as an example. As you note in the first screen apture, the browser is clearly listed. However, when you click on the browser (either right or left button), all you get is a Java exception. After multiple installs and some research, I have concluded that this feature simply doesn’t work.

If one click on the browser icon (lower right corner of above image), one gets the following screen. Yes, the only available choice is to “continue.”

Although the PlayBook has yet to be released, there is an emulator for  it as well. As mentioned above, this environment comes as a VMWare virtual machine. Since I already was using the VMWare Player for several other virtual environments, I did not have to take the extra step of downloading and installing this player. Of all the emulation environments, this was the quickest to set up and get working. It also seems to be the most limited. Note the screen capture below. Other than the ability to test AIR based applications, I don’t see any possibility to work with a browser (the choices are all that exist in each category).

The recommended approach to developing applications for the Playbook is to use either Flash Builder 4 (formerly known as Flex, comes with Creative Suite 5) or Flash Builder 4.5 (from Adobe Labs). The preferred approach is to use Flash Builder 4.5. Since I had attended several sessions on Flash Builder 4.5 (code name Burrito) at AdobeMAX, I already had the environment installed. I did learn that the  trial was good for 30 days only (yes, AdobeMAX was in October). I also learned that if one provides a valid serial number for Creative Suite Master Collection, one can obtain a valid serial number for Flash Builder 4.5 so I was up and running quickly.

One minor issue – I had installed Flash Builder 4.5 in a VirtualBox virtual machine (I prefer to install trial software in virtual environments as it iss easier to clean up if there are problems). Of course, I hadn’t realized that I would need VMWare for the PlayBook emulator. CCuriously, I am able to communicate between these virtual environments. I used the settings tab in the PlayBook emulator to identify the IP address (192.168…) below.

Within the VirtualBox virtual machine (Windows 7) where I installed Flash Builder 4.5, I was able to successfully ping the VMWare environment (even though the VirtualBox network is a 10.10… network). Frankly, I was amazed that these two environments actually seem to communicate with each other. I then was able to build the sample application in AIR and deploy it in the PlayBook emulator (just as per the instructions provided by RIM). The screen capture below shows the Flash Builder 4.5 run configuration.

So, I am now able to develop and test applications for the PlayBook. I believe I can also test applications for the Torch, but I have yet to test that capability.

Second – screen capture utilities. Since I have a Blackberry Torch phone, I also wanted the ability to take screen captures (as I can do with my Android devices). After a fair amount of investigation, I discovered that a number of sites which were recommended for various utilities were all defunct. This left the JL_cmder tool as the only viable option. One needs to first install the proper USB drivers (which are automatically installed when one installs the Blackberry desktop manager (link came on a small CD provided with the Torch itself). Next one needs to  install the JavaLoader Commander. This is a command line utility which allows one to take screen captures of the actual device (connected via a USB cable). Given that I plan to investigate mobile web applications over time, I really wanted this capability. One item that no one seemed to mention is that in order for this to actually work, one needs to do two things. first – regardless of what the instructions say, place the necessary files in a C:\Program Files\JL_Cmder folder (any other location seemed to cause problems on my laptop where I was testing this). Second, after placing the files there, reboot the machine. You will then be able to take direct screenshots of your device. I show two below – the default screen and a browser view of one of my HTML5 web forms.

View of one of my HTML5 form pages in the default browser on a Blackberry Torch.

Ok, I now have a viable environment so I can begin work on mobile applications. I can work with both Blackberry devices and Android devices. I hope readers have found this overview helpful.