Category: Android

A whole new world for app developers – it’s raining cats and browsers!

Holy smokes – how do we support all these different browser types and versions? I’ve been thinking about this for a while, but after attending the AdobeMAX conference this week I got to talk with other developers facing the same issues.  The web app world used to fairly simple: develop for the one or two major browsers running on desktop computers and you were done. We still grumbled a lot and had cross-browser problems that at the time were really annoying. And now we have to deal with not only desktop computers and laptops, but there are also dozens of different mobile browsers and hundreds of new tablet style devices. To make things even more interesting the pace at which new versions of browsers and mobile operating systems are being released is at an unprecedented (and perhaps unsustainable) rate.

What to do, what to do, what to do?  Well if we step back and look at this holistically, there are a few things to consider that can help lay the ground work for building apps in these crazy times. That will help you make better technical business decisions.

For web apps:

  1. What browsers and browser versions your customers are using? How often do you analyze this? If you don’t use a monitoring/analytics tool for this you can always download a free tool to analyze your web server logs. I’ve used Google Analytics in past, but there are plenty of other choices.
  2. What percentages of your visitors are using a particular browser version? Break down your stats again by the browser version. If you still have a large percentage of customers using IE 6 then you might want to consider continuing to support it.
  3. What percentage of your customers use mobile versus non-mobile?
  4. What percentage of customers are from your country? If most of your customers from outside your country then you’ll also have to include localization code.
  5. What type of device is each web site visitor using? Mobile devices can have vastly different screen resolutions and sizes.
  6. Which browsers represent visitors/customers that make you the most money? This is a very important number to know and getting this information can be a bit more involved than the other questions. If you mess up support for these group(s) you’ll really cause yourself business problems.

For native apps:

  1. Have you reviewed your marketplace stats page? One example is the Android Market offers application stats such as platform versions, devices, countries of origin, languages, etc.

What if you haven’t launched your app or website yet? If this is the case, then check out some of public tracking sites for hints. Some good places to start looking are: w3schools and Wikipedia which lets you drill down into different browser versions.  For mobile apps, most IDEs let you set up various layout scenarios that relate to rough categories of dpi (dots per inch). For example, here is an article from Adobe on Flex mobile development and handling different mobile device screen resolutions.

How do I interpret this information? In general, you want to have support for browsers and operating systems that the majority of your customers use. One example is in the retail/consumer industry you absolutely have to support what your customers use. If the vast majority of your customers use Internet Explorer then you will need to support IE or you will lose customers and money. If the vast majority of your visitors use Android, but your biggest spenders use iPhones then take that into your development considerations. If your website or application performs poorly for a small percentage of very high-spending customers then it could cost you your business. If you are lucky enough to have commercial customers consuming an internal-only application, or if you have an ultra-niche audience that only uses a single browser or smart phone operating system then you already have your answer. You build to suit their needs.

Any further advice? Test, test, test and then test some more on real devices and different versions of browsers. Emulators and simulators are not an adequate substitute for real-world checking. If you are a small shop, enlist family, friends and neighbors to test. Have them check out our app or website for a few minutes while they relax in the evening. You can also buy after market handsets on eBay and other places, just be careful that if a deal is too good to be true you probably shouldn’t purchase it. The reality is there are so many devices nowadays that you simply can’t test them all. So, pay special attention to feedback in your market place listing or on your forums.

Fastest Android Wall Charger?

I accidentally discovered that the fastest charger for my Motorola Atrix so far is actually a Barnes & Noble Nook charger. I’m blogging about this because the charging time of Atrix is a major point of contention, and it drives me crazy.

My Atrix takes forever to charge with the Original Equipment (OEM) factory charger. For the record, I’ve never been impressed with Micro-USB chargers. If the battery is around 30% – 40% when first plugged into the charger, it takes up to 5 – 6 hours to reach a full charge. This is painfully long especially in comparison to my retired Google Ion that always seemed to get fully charged in less than an hour. Often-times I walk-around with a half-charged phone because every time I pull it off the charger to go to a meeting, it has only charged a fraction of a percentage more than it had an hour earlier.

I’ve tried a number of different chargers including ones from my HTC EVO. Then at a recent out-of-town trip, I lost my factory charger and decided that since the Nook charger had the same type of USB plug, same voltage and amperage rating that I’d give it a try. At the time that seemed better than running out and buying a new one at the AT&T store. What happened next really surprised me. The Atrix charged from 50% to 100% in about two hours. In general, this charger consistently charged my phone faster.

Now before you blast me about slow chargers are the best way to go, keep in mind this was just an experiment and this post comes with a large amount of CAVEAT EMPTOR:

  • WARNING – Motorola ONLY recommends using approved chargers with their phones, so if you mess up your battery or phone don’t blame me. Furthermore, if you run out and purchase a Nook charger there is no gaurantee it will perform the same.

If you’ve had any better/different experiences with other charges please post a comment.

Reference:

Barnes & Nobel Nook Charger – Model No. BNRP5-850, Output: 5v @ 0.85A

Debugging Flex-AIR apps on iPhone and iPad

Debugging iPad or iPhone apps that you built with FlashBuilder has a number of extra steps that you don’t need when developing with Android. This is especially true if you use Windows as your primary operating system. The good news is that once you’ve done it once or twice it should be fairly straight forward. So here are a few hints to get you going.

Step 0. If you are building on Windows make sure to install the latest version of iTunes. Then check that your iPad or iPhone can be synched with iTunes. If you use a mac you’ve most likely already done this step (in your sleep a hundred times).

Step 1. Make sure you have a certificate and provisioning file. This must be configured under FlashBuilder Project > Properties > Flex Build Packaging. IMPORTANT: If the certificate and provisioning file are not set up or are not valid you will not be able to compile your project. If you don’t know what this is or how to do it, additional info can be found here in a great blog post by Holly Schinsky (@devgirlFL).

Step 2. Set up a Debug Configuration. If you don’t know where that is, select the pulldown next to the bug icon on the FlashBuilder toolbar and then choose Debug Configuration, or go to Run > Debug Configurations. Choose Apple iOS as your Target Platform. Be sure to select the On Device Packaging Method > Fast! If you don’t do this and you choose the Standard option it will take five or more minutes to compile the build each time you hit debug, and that can become a huge time waster really fast. One advantage of using the Standard option is it will perform more like the final release build. In comparison, the Fast version won’t be as performant. So, for the vast majority of your debugging you should probably use Fast, and when you want to test a final build then you might want to choose Standard. When you are ready select the Debug button.

Step 3.  You will then see a popup window with six important instructions. Once you have completed Steps one and two, select the Show package in Explorer link.

Step 4. Drag the .ipa file from your file browser window into the iTunes Library > Apps area.

Step 5. Select the Sync button on the bottom right hand corner of iTunes. You should see Sync In Progress screen on your device. Let the operation complete. When it’s finished you should see a message in the message box at the top of iTunes that says the sync was successful. If there was an error it will also show up in the message box at the top of the iTumes application window.

Step 6. Launch the application on your iPad or iPhone. You should get a popup window titled Flash Debugger that asks for the IP address or hostname.  Important:  your iPad or iPhone and your development machine need to be on the same wireless LAN, if they aren’t then this step won’t work. If you don’t have a wireless LAN handy you can always log both machines into a MiFi or some other type of mobile hotspot. Then enter the IP address of your development machine. On a windows machine you can easily get that in a DOS prompt using the command ipconfig. Hit OK.

The Final Result. If all goes well the app will launch and you will start to see debugging output in FlashBuilder.