Debugging Web Apps on Android’s Mobile Browser – Part 2

In addition to the suggestions listed in Part 1, I forgot to mention one more tool. There is a lesser known browser that can be quite handy for debugging: Firefox mobile. This relatively unknown sibling of the full-blown desktop browser actually has a fairly nice, built in debugger. The one major caveat is that it doesn’t work as well as the native browser for HTML5, CSS3 and some JavaScript, but it may be just the tool you need for some quick debugging, on-the-fly. Besides it fits in your pocket along with your other mobile apps, and you don’t need Logcat.

Step 1 – place your finger in the middle of the screen and drag it to the left. Click the gears icon at the bottom right of the screen.

Step 2 – In the upper right hand corner of the next screen, click the bug icon

Step 3 – Scroll down the datagrid to view errors.

Debugging Web Apps on Android’s Mobile Browser

For some unknown reason, Google did not include a debugger in their native browser, at least for versions up to v2.3.x. I don’t have a phone that supports a version greater than that, yet, so I can’t speak about the latest releases. Unfortunately this can be a huge productivity killer. The good news is there is a solution – you can debug the native Android browser using what’s called the DDMS, or Dalvik Debug Monitor Server, and the ADB, or Android Debug Bridge. I can also tell you this works great.

Yes, it’s true that JavaScript development forces you to have an armada’s worth of tools, tricks, libraries, phones and browsers. This is just another hammer to place into your growing toolkit. Debugging via ADB was good news for me since I do native Android development and I already have the software installed when I installed the full Android SDK. If you don’t do native development then it’s a real pain.

But, if you want to do your best to deliver bug free apps, then your best bet is to install at least ADB. I believe, but I’m not 100% certain, that you can this without having to install Eclipse along with the entire Android SDK. Yes, I agree that installing the entire SDK would seem entirely ridiculous and complete overkill for mobile web development, especially if you are not using Eclipse as your primary IDE. I’m aware that in the past I’d seen a few stand-alone versions of this floating around for both Windows and Linux. I’m not even remotely certain about Mac’s. If you do know something about this, then I encourage you to please post a comment.

How to use ADB. My suggestion, once you’ve installed it, is to filter by the tag “console” if you are using Android v2.x and above.  Instructions on how to do filtering can be found in the ADB link below and scroll towards the very bottom of the page.

Caveat: You will have to install the Android USB device driver on your machine in order for ADB to work.  And, you will also have to have a USB cable that will connect your device to your dev machine. The drivers are different for every device. I’ve included a link to Google’s device drivers below. On a related note, for several of my Motorola Androids I had to go directly to the Motorola website to find a device driver that finally worked.

Another Possibility – Adobe Shadow! You should also be aware of a very cool development from Adobe called Shadow. As of today, I believe you can still download it for free from Adobe labs. I mention this last because, well…I haven’t tried it out. However, my good friend Kevin Hoyt, from Adobe, says it’s very, very promising. And, it’s supported on both Mac and Windows. As I write this I’m thinking that I really do need to download it and test drive it. If you have tried it, then post your thoughts…don’t by shy!

References:

Adobe Shadow + sneak peak video

Google’s ADB

Android Device Drivers

Google’s Guidelines for Web app developers

Figuring out Date Time Zones in Adobe Flex/Actionscript

I was really frustrated the past few weeks when a major clock component of an app kept failing when viewed from different time zones. It was always supposed to show Antarctica time and only that. I searched and searched for definitive examples on the web, but never found what I needed.

At the heart of this is the ActionScript Date Class. It’s unfortunately a very poor implementation. I expected to simply have a property where you give the Class a timezone offset and presto you magically get the time for that location of the world. Silly me. In addition the documentation is incorrect in that the getTime() method does NOT in fact report the time in UTC. And, to make things even more fun, the getTimeZoneOffset() method returns minutes rather than milliseconds.

However, after enough iterations I was finally able to cobble together what seems to be a graceful solution. The trick is to use the getTime() method. Then add the time zone offset in milliseconds. This, in theory, gives you UTC time. Then add or subtract the number of hours in milliseconds for your fixed clock. Oh, and I also used the DateTimeFormatter to beautify everything up. Here’s the code to hopefully save someone else a bunch of additional coding:

var df:DateTimeFormatter = new DateTimeFormatter();
df.useUTC = false;
df.timeStyle = "short";
df.dateStyle = "medium";
var d:Date = new Date();

var millisecondsPerThreeHours:int = 1000 * 60 * 60 * 3; //using a -3 hour UTC offset
var timeZoneOffsetMilliSeconds:Number = d.getTimezoneOffset() * 60 * 1000;

d.setTime(d.getTime() + timeZoneOffsetMilliSeconds - millisecondsPerThreeHours);

var antarcticaTime2:String = d.toString();
antarcticaTimeTextArea.text = df.format(antarcticaTime2);

Adobe Flex Mobile Styles – Easily change the color of a Button

Have a mobile app using a default spark Button <s:Button /> and you simply want to change the background color? Wait just a second before you start creating a full-blown skin! It’s actually very simple – change the chromeColor. This info is buried way down near the bottom of the online reference doc. This also applies to ActionBar, ButtonBar, CheckBox, HSlider, and RadioButton.

Here’s one way to do it using CSS:

<fx:Style>
   @namespace s "library://ns.adobe.com/flex/spark";
   #shutdownButton
   {
      chromeColor: #FF0000;
   }
</fx:Style>

<s:Button id="shutdownButton" label="Shutdown?" click="shutdownButton_clickHandler(event)"/>	 

 Reference:

Basics of Mobile Skinning

The pace of technological change: Do Android’s really dream of electric sheep?*

Google’s Android v1.5 (Rev 1) was released in April 2009. In 2010, there were three major dot-X releases of the 2.x platform: v2.1, v2.3 and finally v2.3 in December 2010. According to Gartner in a February 2011 report, Android grew from 3.9% of the worldwide smartphone market, to almost 23% in the span of one year, from 2009 to 2010. That’s roughly 888% growth.

As a developer, I’m awed by the pace of change and the rate of adoption. I like being on the cutting, and now the consumer competition is furious for mindshare, and the mad push is on for developers to build applications that take advantage of the latest software and hardware technology. It’s a developers dream. Cool new toys, ever better functionality and hardware with new releases just six months away!

And while I like to simply pay attention to the technology and ignore everything else, I’ve been asked a number of questions recently by other developers who work in a variety of industries from around the world, and to which I have no answer. If you read this please share your thoughts:

  • How do we plan software development cycles around mobile phone system(s) that change dramatically every six months? We are talking about both hardware and software.
  • If I build an application now, will it still work on the next generation of hardware which will come out in one year or less?
  • Will applications that were built on the latest mobile OS still be backward compatible in one year?

What’s interesting is we have been faced with similar questions before when Adobe Flex, Microsoft Silverlight and even HTML 5 were announced. And, yes, they are changing the way we build applications and to a large extent changing what our users expect to experience. However, internet browsers have been around for a while, web development technologies in general aren’t exactly new, and all computers these days come with a pre-installed browser. But, all the sudden we could more quickly develop beautiful applications in days and weeks that used to take many months, or years. And, it’s been an eye-opener as far as our surfing experiences go.

Many commercial applications have never been more powerful with built-in charting and dynamic access to data with very graceful interfaces. These applications opened our eyes to what’s possible by letting us build applications independent of the machine they ran on. And, in a sense it was liberating. The idea of building one version of the software and then deploying it across many machines and devices became true. I, for one, touted that I no longer had to worry about esoteric items such as pointers and garbage collection. The browser took care of all that for the most part, even though it still had a few issues.

Maybe I celebrated too soon. What’s changing now is the pace of adoption which is in the form device that fits in your hand, and you can carry with you anywhere even when you hike, that accesses the internet, and that has similar functionality to a desktop/laptop system. Smart phone access is changing how people communicate: live, work and play. It’s becoming the primary connection to the internet in many parts of the world. It’s becoming a primary work tool while on the road.

We, as developers, are at the heart of this change and with a front row seat.

Our use cases are changing to accommodate people accessing our applications while they are standing in line ordering their morning coffee. We’re back to looking at native applications which don’t run in the browser and are subject to all sorts of interesting limitations and challenges. We are back to adapting code to different devices, limited battery life, testy internet connections, varying processor power, and dealing again with problems related to device drivers.

It’s funny that I caught myself thinking how nice it would be to have a software framework that would let me abstract away all these pesty problems that low-level code development entails: a sort of Flash Player environment for low-level code on a mobile phone. I mused about how easy it was to use FlashBuilder “Burrito” to convert my Adobe Flex applications directly to Android without having to deal with Java code (which works very nicely by the way). Or, do I build a rich functionality web app?

But, you know, I chuckled as soon as I had a requirement that asked for closer access to the smart phone hardware and operating system: things related to power management, and getting more information from the device GPS. Do I wait until the functionality I need is built into an abstraction library…or do I build a native application today? Which applications do I build for the web, and which application should be native?

These are all business question that many of you will also face. I’m certain it’s being asked thousands of times around the world. And ultimately, whatever the answer is… it will change the way we all do business.

*I pay full respect to Philip K. Dick’s 1968 science fiction novel, Do Androids Dream of Electric Sheep?, that served as the primary motivator for the movie Blade Runner which was first released in 1982.

Creating a Copy of a Default Spark Skin Class

Here’s five easy steps for creating a copy of a default Adobe Spark skin class in Flash Builder 4. There may be documentation on how to do this on the Adobe site, but I can never find it when the need arises. So, here goes:

Step 1:  In Flash Builder, make sure you are in the Flash perspective (upper right hand corner), and right click on any folder in your project. Choose New > MXML Skins

Step 2.  In the New MXML Skin window, fill in the package and name fields.

Step 3. Select “Browse” to choose your Host Component. Start typing the name of the component and choose the one that you need. Click Ok.

Step 4.  Check “Create as copy of”, and then use the drop down list to choose the skin you want. Click Finish.

 Step 5. Make sure you see the Adobe copyright in the skin’s MXML file. And that’s it, you are good to go!