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: https://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);
    }
});

10 Tips and Tricks for Running Live Demos on a Mobile Phone

Here’s my short list of some things to consider when you demo your company’s mobile apps to a live audience. I’ve accumulated this list over the last several years as the team I’m on does a lot of showing off apps on iOS, Android and Windows Phone. We’ve also seen quite a few demos from customers and at industry conferences.

While most of these tips apply to personal demos where you have the phone in your hand while standing in a tradeshow booth, I’m actually talking about projecting demos on a big screen in front of a live audience, or during an internet video conference call with screen sharing.

  1. Screen brightness. Adjust the screen brightness so that the screen is not too dark and not washed out, and temporarily disable screen brightness auto-dimming. Auto-dimming is where the phones background light gets dimmed usually around ten to fifteen seconds before the screen auto-locks.
  2. Turn off auto-lock. Temporarily disable your auto-screen lock (if your company policy permits it). There’s nothing more aggravating than talking about something for a few minutes and then when you turn your attention back to the phone you have to re-enter your unlock code. I’ve also seen this happen to people on the screen behind them and they didn’t notice but the audience could see it.
  3. Silence the phone. For demos that don’t need sound, which is probably most demos, turn your phone’s sound all the way to “off”. Most phones beep, tweedle and pop as various things happen in the background, so spare your audience by making your phone silent.
  4. A/C Power. Plug your phone into a power outlet. While this may seem obvious, I’ve seen a phone die during a major industry conference plenary session.
  5. Shutdown extra apps. Shut off any unnecessary apps that will consume memory and CPU. You want your demo to run as fast as possible.
  6. Remove unnecessary icons. Clean any non-professional app icons from the navigation screens you will be showing live. On a few rare occasions I’ve seen some fairly disturbing icons that had no place in a professional presentation.
  7. Verify the type of demo camera. Ask ahead what kind of demo camera the conference has for mobile phones, one of the most common ones is called an ELMO. These are devices where you set your phone below it and it has a camera that points downward at the phone and connects to a projector through a switch. So, when you go to show off your app you turn a switch that connects the ELMO (or similar device) to the projector. Some of these are terrible and some are great. I use an IPEVO Point 2 for some demos because it’s portable and I trust it.
  8. Test demo camera. Test your demo camera well before your presentation. You may need some help from the conference’s audio visual team. Make sure your phone in focus, check if you can see the application details, look to see if the background colors aren’t too white and washed out, etc.
  9. Cache local data. Cache your data when possible. If you plan on connecting to remote data sources, consider moving that data onto a local SQLite database on your phone.
  10. Check internet connection. Check your internet connection beforehand. Conference are notorious for having limited cell and wireless coverage. My recommendation is always create a movie backup of your most important demo points. Yep, I’m 100% serious. With an IPEVO Point 2, for example, you can project the camera image in a desktop app and use software such as Camtasia Studio, which also offers a free trial, to create a movie with audio too. Also, a note to phone developers here, it’s a best practice to check if your app has an internet connection and to let your users know if the connection goes away, for example: https://www.andygup.net/?p=155.

So you want to build a mobile app? Not all mobile apps are created equally

Most smartphones users I know ditch apps pretty quickly if they don’t work or end up being clunky. So, if your company is considering offering mobile apps to your customers you should be aware of a few things.

Buy a Smartphone. If you don’t already have a smartphone then you should go out and buy one. Then download a number of apps that interest you and try them out and see what you like and what you don’t like. For example, if you do the shopping for your family you might consider trying out a bar code scanner app that lets you compare pricing. Some scanner apps may work faster than others. If you don’t own a smartphone then you won’t be able to understand what a good app is.

Likes and Dislikes. Pay close attention to what you like and don’t like about a particular app. Here are a few questions to take note of:

  • Was it easy to use?
  • Did it hang and/or crash?
  • Did it perform its tasks gracefully?
  • Did it do what you expected?
  • Was it visually appealing?

Become Tech Savvy. Become a bit more tech savvy about things that the phone is doing behind the scene. There are apps that do this for both Android and iPhone that help you monitor what’s going one. Things to look out for:

  • Apps that keep running even after you think you shut them off. These will run the battery down faster.
  • Apps that consume more and more memory over time. Using more memory equals more battery usage and shorter time between charges.
  • Apps that seem to slow your phone down when they run. These apps may be using more CPU than necessary resulting in greater battery usage.
  • Apps that connect to the internet frequently costing you extra data charges. There are apps that let you monitor how much data your phone uses and some apps can help pinpoint which apps use the most data.

Which Phones to Support? Understand what devices to support. If you are building an application for internal use, then you have an easier decision since you hopefully have some control over which devices are being used and how often their software gets updated. If you work in retail, your users may have Androids, Blackberries, iPhones, iPads, Kindle’s, Nook’s and possibly other tablets that get updated whenever and however the customer dictates. My advice is do some research and pick one that is used the most and work on that first.

Release Early and Iterate Often. Technology changes so quickly these days that if your app takes more than 3 – 6 months to build, then the technology will change underneath you. In other words, you might be releasing an application that doesn’t work perfectly with the latest phone operating systems or browsers that your customers are using. When that happens, it will cost you even more time and money to fix the problem and the problem will repeat itself. Be sure to take into account the speed at which technology will change once you begin your software development process.

Go Native, Go Web Browser, or Both? Last, it’s important to understand that there are two common types of mobile applications. Native apps are downloaded from an app store and installed directly on the phone, the other is a web app that runs in the phones web browser. My advice is to research and understand your target market. What do your competitors use? What do your customers prefer? What are the trends in your industry?

If you go with native apps, you’ll need to understand which phones to support and how often you will be updating the app. If you choose web apps you’ll need to know which browsers to support. Also take into consideration which skill sets your development team has and understand if they can tackle the project or if you need outside help.

Update, Update, Update. No matter what you decide, you can’t just deploy an app and think you’re done. If you want to keep your customers happy, you’re going to have to keep updating the app until the product line is discontinued or replaced. And, you have to update it often enough to stay on top of the latest technologies. New smartphone models are being released all the time and they all may have different screen sizes and screen resolutions. An app that looks good at one screen size may look horrible on a tablet or iPad. These things have to be accounted for. And, the smartphones operating system software may be updated three or more times per year offering new functionality and fixing bugs. If your customers download a broken app, or if they see the app that hasn’t been updated in a while and something stops working they may not be your customers for much longer. This is especially true for retail apps where customers make split second decisions whether to stay or walk away and try something else.

Conclusion. I hope you find this list useful and at least give you some ideas to think about before you dive head first into bringing a new mobile application into the world. It can be fun, be there is a lot of hard work involved. But, if you plan it right you’ll be successful and learn alot in the process!