How would you rate your smartphones internet connection?

Not including WiFi, what I really want to know is over the period of an average day how happy are you with your 3G and/or 4G smartphone or tablet’s internet connection? Do you ever have moments where web pages are slow to download? Has an app ever taken forever to install, or a tweet or facebook picture upload failed?

Costs and geography aside, could you turn off your WiFi completely and generally have a decent connection at your home? At work? At the airport? At the supermarket?

It’s interesting to note that some really big company’s think that internet on mobile devices isn’t as great as it could be. Have you heard of Amazon Silk or Opera Turbo where they incorporate data compression to try and speed things up to overcome limitations of mobile browsers? I’ve even heard that Google is now working on something similar. Are these just attempts to work around current limitations of cellular 3G and 4G? Most likely, yes.

I’d give my general usage internet connection in my home area a 7 rating on a scale from 0 (no internet) to 10 (always incredible). By home area I mean the geographic location where I spend 98% of my time between home, work, shopping and visiting friends. When not developing apps on my phone, it’s primarily used for email, social media and occasional web browsing. Tethering is a different story. For tethering when I travel I’d give it a 4 rating overall. Tethering uses the bandwidth a lot more strenuously than my home area use case. And because of that it exposes any weaknesses in the internet connectivity a lot sooner and makes them much more noticeable. The typical situation I want to avoid when I travel is having to pay for a hotel internet connection. Besides, hotel internet connections in the U.S. are almost always awful in terms of download speeds, especially if you are in a hotel during a large conference.

If you are wondering if there’s anything you can do about bad cellular internet the answer is YES. First, call your provider and explain the situation in as much detail as possible. Simply calling up and saying “my internet connection is terrible” isn’t going to help. But telling them the geographic location, time of day, frequency of the problem, etc. will help immensely. And, you can always follow-up if the problem persists. Sometimes the problems are equipment malfunctions, sometimes cell towers need to be upgraded. Other times it could be the terrain, buildings and heavy foliage. All of these can degrade signals. As you can see there are many reasons why your smartphone internet could be less than desirable.

If you consistently see internet outages and other major problems and you can’t get a solid answer from your provider then you can also contact the FCC or file a public comment.

References:

FCC Online Complaint form

FCC 3G and 4G Wireless

Amazon Silk

Opera Turbo

6 reasons why your smartphone battery doesn’t last

I’ve surprised many people when I tell them my Android lasts less than 8 hours under heavy use. And, I’ve lost track of how many times I’ve asked someone how long their smartphone lasts and they really don’t know. The most common response goes something like this “…not sure because I plug it in whenever I get a chance.” Some of my friends even carry separate rechargeable backup battery packs to augment their limited battery life. As soon as their battery gets down to around a quarter tank they plug in the mega backup.

As a developer who builds apps for smartphones, I’ve spent quite a bit of time becoming very familiar with many of the configurable aspects of my various phones all the while using it intensively in build/debug cycles. And, I’ve put some thought into categorizing the different types of battery power usage of which some are less obvious than others. So here goes:

  1. Screen brightness. I turn it all the way down, but this does make reading the screen outside in bright daylight nearly impossible. The fact is the brighter the screen , the more pull on the battery.  On all my phones, the screen is the biggest gas hog.
  2. Number of applications loaded into memory.  Very few of us pay attention to how many applications are loaded/running versus completely shut down.  The more running apps the phone has to manage the more battery is drawn.
  3. Cellular signal strength. If your phone has a weak signal it will boost its own radio to try and compensate.  Cell phone signals are not constant and they ebb and flow all the time. On the down side when signals are weak, the phone will expend additional power to try and keep you connected. Sure, use wireless (wifi) were possible, but when wifi isn’t available you have to rely on good old cellular. It’s commonly understood that 4G draws the most power, 3G draw less and wifi draws the least.
  4. Duty-cycle for using apps. What I mean by this is how much time you use apps during the time period between charges.  If you spend 2 solid hours of app play time between 8 hour charge cycles then that means a duty cycle of 25% (2 divided by 8). The lower the duty cycle the less power is drawn assuming an idling phone with no apps installed is the baseline for minimal power usage.
  5. Number of applications that continuously connect to the internet.  This includes Twitter, facebook, FourSquare, email, etc. Secretly these apps can be very talkative in the background and you might not even know it. Every time they ask the mother ship for an update it draws power to make the request over the internet and then process the results.
  6. Talk-time. Everyone knows that talk time uses battery power, so this is obvious compared to items 1 – 5. On a smartphone you are usually doing other things in addition to talk time. In the days of feature phones, such as the original Motorola Razr, the only thing you could do with those was talk, talk, talk and intermix that with some limited texting. At least for me, over the period of 8 hours I’ve spent much more time (or duty cycle) using apps, such as email, as compared to making phone calls.

Hopefully this takes some of the mystery away from short battery life. We all wish batteries could last days, but we unconsciously create situations within our phones that draws down the battery much faster than expected. And, their are situations beyond our control. such as low cell signal strength, that draw extra power.

7 Critical Things to Know When Building Any Mobile App

This blog post builds on concepts proposed in an earlier post about not all mobile apps being created equally. If you are a developer who is in the process of migrating to mobile this post is for you. It’s intended to raise awareness of important items to consider in your requirements. My goal is to help you identify some of the major gotchas early on in the development process and improve your chances for success.

There are many more details to learn on the topics I’ve described below. The good news is that in the last few years the amount of deeply helpful documentation has expanded considerably. Where possible I’ve tried to include links related to each topic.

Touch-based Workflows. Recent research has shown that people use their smartphones more often than web apps, and they spend roughly 80% of their time on social media and games. Because of this and the fact that smartphones today are touch driven and not mouse driven, you have to take that into account in your user interface design. Touch implies many things including gestures and multi-touch. You can toss your old conceptions of user interface design based on desktops and tablets, and check out Android’s recommendations as well as Apple’s. My strong recommendation is to hire a UX designer to help you through building a user interface.

Mutliple form factors come with various screen sizes and densities. Long gone are the days of building for just three main browser types. Now you have to take into consideration iPhones, iPads, tablets, numerous different style androids as well as desktop and laptops. Android defines the following screen sizes and, as you can see, this is quite varied and smaller than a typical laptop or desktop. Those typically run 1024 x 768 or greater.

  • xlarge screens are at least 960dp x 720dp
  • large screens are at least 640dp x 480dp
  • normal screens are at least 470dp x 320dp
  • small screens are at least 426dp x 320dp

This is important to know because an app that looks good on an iPad may not look good, or display correctly, on the four inch display of a Motorola Atrix at 960 x 540. A button that looks correctly sized on one smartphone may look too big on another. A whopping 84% of all Android screens are what Android defines as normal size (>=  470dp x 320dp) and between either medium dpi (~160dpi) or high dpi (~240dpi). But, you still have to take into consideration other densities. I also recommend taking a look at new HTML5 browser-based technologies to help with addressing this problem, such as CSS media queries.

Inconsistent Internet. It’s a best practice to check if internet connections exist and gracefully handle HTTP requests when the internet is down, as I blogged about here.  Depending on your application and needs, you should also monitor whether or not a wireless connection can be made and then allow the application to switch to wireless where possible. Wireless also has the advantage of using less battery power.

Slower Connections. And, on a related note, you can’t always depend on 4G connections having consistent maximum download speeds. Over the course of a user session, the connection speed will vary widely and you should plan for that. I’ve been trying to find some stats on mobile internet quality world-wide, if they are out there they are hard to find. But, we’ve all experience spotty mobile internet coverage. Take this into account if you are transferring large amounts of data between your servers and your app. You should also consider detecting when the user is in an area of greater bandwidth and use that to download more data less often. Use loosely coupled and event driven architectures. Test app load times on various devices and around town and away from your office.

Less CPU Horsepower. While the latest generation of four core phones are certainly the most powerful phones yet. In general, applications and web pages will run slower on phones than they do on your development machine running a desktop browser. Take older generation phones into account because they are usually significantly slower than the newer phones. There are a few workarounds in HTML5 to help with this, in that done correctly they can offload rendering to the hardware. In native applications be aware of memory leaks because, remember, more memory usage means less battery life and applications that can run slower over time.

Support across multiple operating system versions. Remember on Android that the vast majority of users are still running v2.2 – v2.3.7 even though v4.x is currently shipping. You’ll have to do some research on your target market and find out what versions and type of phones they are using. You can’t support everything, but you can make educated guesses. Apple, on the other hand, has a significantly more limited selection of phones and tablets that you have to support, and they do a great job helping you support those.

There are some solutions that help with building cross-platform mobile apps, to go into more detail will take another blog post. Here’s a few: Adobe Flex, PhoneGap and Titanium. Keep in mind that the future of Flex, as a development platform, is being called into question after Adobe open sourced everything but the browser and desktop runtimes to the Apache Foundation. PhoneGap and Titanium offer what is now being called “hybrid” solutions where you can build an application in JavaScript, for example, and then compile that code for native deployments on Android and iOS.

Battery Life. Ah, battery life is last but certainly not least. Be aware of how battery intensive your application is and try to minimize battery consumption as much as possible. The Android online docs have a number of highly information articles on this subject. Smaller app footprint in memory means less battery consumption. Heavy CPU usage means more battery usage. Minimize GPS usage through smart algorithms to help preserve battery life.  Switch to 802.11 wireless connections where possible, since this requires less battery power than 3G and significantly less power than 4G.

So, there you go. I hope these suggestions help. If you have more suggestions based on your own experience please post a comment!

References:

Android Gestures

Android Optimize Battery Life

Android Screen Sizes and Densities

CSS media queries

Android UI Design

Android Model for Best GPS Performance

iOS User Experience

HTML5 Hardware Acceleration

Event-based Architectures for Adobe Flex

Auto-resize Dojo Mobile Charts on Orientation Change

The best I can tell, Dojo’s dojox.mobile.Charts2D do not auto-resize on their own when the phone’s orientation changes. I posted a question on how to get around this on the Dojo Community Forum and never got an answer. So, I had to cobble together my own solution.

I have to point out that the functionality I built by hand is inherent in Flex and Silverlight, and you wouldn’t even bat an eyelash thinking about this. So, from a productivity standpoint I spent about double and maybe even triple the time I should have needed in order to sort through why things weren’t working as they should, and to build my own best practice for handling it. 

I do consider what I built as a hack, so caveat emptor. It should at least give you a good starting point to improve on what I’ve already done. There are some important things to note.

  • Here’s a sample demonstrating the functionality: http://andygup.net/samples/realestate/
  • Dojo does not provide any State properties on the View. So, I had to build that.
  • Dojo does not provide any way to bind a dijit to a mobile View. In other words, this enables the Chart to take action automatically when something happens in the View. Check…yep, I bolted that in.
  • Dojo, as far as I know, does not provide a way to detect when the phone’s orientation changes. So you have to listen for that at the window object level. I’m fairly certain that the pattern I used is not completely reliable across all platforms, but it’s what I had to work with. So, I built that too.
  • I also had to detect if there was no orientation change prior to a View transition. This was so that I didn’t unnecessarily redraw the chart and make it appear to flicker. This check was important because my chart is in a secondary View. There seems to be a bug in charts redraw() function in that the chart may self destruct if you try to redraw it from a different View.
  • There’s a bug in the Android native browser that passes the previous orientation event object to the listener. You actually have to set an event timer so that you retrieve the final, and most recent, orientation event object.
Here’s how you initialize the chart. In this case, I’m using a pieChart. This snippet also includes the html markup:
pieChart = new com.agup.PieChart("chart1","statsView").pieChart;

<div id="chart1ParentDiv" dojoType="dojox.mobile.RoundRect">
        <div id="chart1" style="width:100%; height: 350px;"></div>
</div>

Here’s the PieChart Class that I built to encapsulate the functionality I described above:

dojo.declare("com.agup.PieChart",null,{
    pieChart:null,
    orientationChanged:null,
    constructor:function(chartDiv,chartView){
        this.pieChart = this._createChart(chartDiv);
        this.orientationChanged = false;
        if(chartView)this._setTransitionListener(chartView);
        if(chartView)this._setOrientationListener();
    },
    _createChart:function(chartDiv){
        //create the chart
        //Had problems with using just HTML markup, so creating it here and piping to DIV
        var pieChart = new dojox.charting.Chart2D(chartDiv);
        //set the theme
        pieChart.setTheme(dojox.charting.themes.PlotKit.blue);
        //add plot
        pieChart.addPlot("default", {
            type: "Pie",
            radius: 100,
            fontColor: "black",
            labelOffset: "-20"
        });

        pieChart.isVisible = false; //NOTE: this is a new public property that we inject

        return pieChart;
    },
    _setTransitionListener:function(/* DIV of dojox.mobile.View where chart resides - typeof String  */view){
        var test = dijit.byId(view);
        var pieChart = this.pieChart;
        dojo.connect(test, "onAfterTransitionIn",null,
                dojo.hitch(this,function(){
                    pieChart.isVisible = true;
                    if(pieChart != null && this.orientationChanged == true)var time = setTimeout(function(){pieChart.resize()},700);
                })
        );

        dojo.connect(test, "onAfterTransitionOut",null,
                function(){
                    pieChart.isVisible = false;
                }
        );
    },
    _setOrientationListener:function(){
        var supportsOrientationChange = "onorientationchange" in window,
                orientationEvent = supportsOrientationChange ? "orientationchange" : "resize";

        window.addEventListener(orientationEvent,
            dojo.hitch(this,function(){
                var pieChart = this.pieChart;
                var orientationChanged = this.orientationChanged;
                if(pieChart != null && pieChart.isVisible == false){
                    orientationChanged = true;
                }
                if(pieChart != null && pieChart.isVisible == true){
                    orientationChanged = false;
                    var time = setTimeout(function(){pieChart.resize()},700);
                }
        }), false);
    }
});

What do you read for technical news?

It was just a few years ago that I regularly scanned a list of mainstream developer and IT rags on a weekly basis: ComputerWorld, Visual Studio Magazine, SD Times, JDJ, and the list goes. Then one day early last year the thought hit me and I was a bit stunned to realize that I’d stopped reading online magazines. The vast majority of my technical info was now coming from blogs, online help docs and dizzying amount of internet searches. So, what happened? I have some theories that I’ve been thinking over the last year, but I can’t really nail down anything for certain. So, it’s most likely a combination of these five concepts below.

Rapid Change. My first thought is that technology has been changing so rapidly that simply digesting the changes and understanding them takes a huge chunk of time. Huge. I’ve blogged about this a number of times. This trend cuts across the entire tech industry. The upside is that innovation happens overnight and fixes as well as new features come out quickly. The downside is it’s harder for everyone to stay on top of all the changes across updates to features, libraries, SDKs, smartphone operating systems and browsers.

Super busy. My second thought is:  in addition to staying on top the über release cycle of web and mobile technologies, I’ve been so busy with project work that I simply had to narrow the scope of what I was reading. It’s a balancing act and there’s only so much time in the day. Superfluous information seemed to just slow me down, or worse it felt like a distraction from the day’s objectives. And in today’s online environment there is such a huge flow of information. So, there has to be a way or mechanism for focusing and filtering the fire hose of inbound data.

Irrelevant Info. My third thought is that every time I try to go back and read mainstream rags that I find myself sifting through a bunch of stuff that isn’t relevant to my immediate or near-term needs. Like I mentioned above, a good portion of it often seemed to be superfluous. Don’t get me wrong: online magazines offer well written and well thought out information. But, I felt the extra information, or perhaps even information overload in some cases, slowed me down. If it takes time to sift through article after article looking for a specific topic, my inclination is to go back out to a search engine and narrow down my search parameters.

Online Search Engines. Search engines have done an excellent job of (rapidly) indexing online technical content. I don’t need to mention them by name because you know all the players. At work we’ve often joked about a pattern we call “coding by search engine.” The pattern goes something like this:  copy a class name or error message, paste it into the search bar and then skim through the results. If you have to go more than one page deep in the search results then stop and redo the search. Mostly gone are the days of sifting through reams of paper documentation or digging around in some esoteric corner of a vendors website. I don’t think most customers will stand for that anymore. I think more information is instantaneously available at our fingertips now than any other time in history. It is astonishing, really.

Forums. My final thought is the voice of the developer community has never been more important. Online forums, such as Stack Overflow, have become to be perceived as definitive sources on technical questions of all kinds and about all different sorts of programming languages. I’ve been in many conversations where, right or wrong, someone interjected with a comment about something learned on Stack Overflow, or similar sites. These sites are well indexed by search engines, the community can vote answers up or down, and many brilliant and knowledgeable players contribute their knowledge. These are excellent, speed-of-light resources that are freely available.

So, there you have it. This is my two cents of what I’m reading these days and why I think I changed what I read. Leave a comment or email me about how you get your technical info injection. I’m really curious to hear your experience.

* Clip art courtesy of Microsoft Office 2007.

The Largest Conference For Mapping and Geospatial Developers – Esri DevSummit 2012

I’ll be presenting at the Esri DevSummit next week so if you are attending please swing by my sessions and say “hi”. If you aren’t familiar with Esri or the conference, about 1400 developers and other technical experts converge on Palm Springs, California every Spring to learn all things technical about building commercial and enterprise geographic information systems. There will be everything from introductory Dojo workshops to deep dives into the heart of our APIs.

If you’re around here’s my schedule. I’d be very interested to hear about what you are working on:

Monday,  March 26

Getting Started with the ArcGIS Web APIs – 8:30am – 11:45am, Pasadena Room. I’ll be presenting the portion related to our ArcGIS API for JavaScript.

Gettings Started with Smartphone and Tablet ArcGIS Runtime SDKs – 1:15pm – 4:45pm, Pasadena Room. In this session, I’ll be presenting on our ArcGIS Runtime SDK for Android.

Wednesday, March 28

Flex the World – 10:30am, Demo Theater 2. I’ll be presenting with my esteemed colleague Sajit Thomas on Apache Flex.