Monday, July 01, 2013

Ultimate Stopwatch version 6.0.4


Fresh from being used to demo Android Studio at Google I/O, the Ultimate Stopwatch version 6.0.4 is rolling out with a couple more tweaks and bug fixes. This has also given me the opportunity to try the Google Play staged rollout feature.

First up, overdraw has been reduced again, this time by removing the background drawable for the window. 

    UltimateStopwatchActivity.onCreate(){
        getWindow().setBackgroundDrawable(null);
    }

Resulting in an almost totally green/blue layout, the only remaining red section is in the overlap of the minute and second hands. The screen was already drawing in a fraction of the time needed to maintain 60fps, so at this point it is really just optimizing for the sake of optimizing. Removing the window background had the side effect of a lap time screen without a background at all, leaving a hole in the UI and some freaky results. That was quickly resolved by setting a background color on that view.


I've gone one step further in an experimental version, which results in 0 overdraw for most of the app, but there are still a few margins left with no background color, so it needs a little more work and testing.

Another minor change in 6.0.4 was in the animation timing code. The animation runnable was already using postInvalidateOnAnimation() for JB+ devices, an optimization to cause redraws to happen on the next display frame:

    if(JELLYBEAN_OR_ABOVE) postInvalidateOnAnimation();
    else invalidate();


However, +ChrisBanes pointed out that there is a version of this in ViewCompat. ViewCompat is a backwards compatible helper provided in the Support Library for accessing View features introduced after API level 4. So, the custom view animation runnable now looks like this:


    //Stopwatch animation runnable
    private final Runnable animator = new Runnable() {
        @Override
        public void run() {
            updateWatchState(false);

            if(mIsRunning)
            {
                invalidate();
                removeCallbacks(this);
                ViewCompat.postOnAnimation(StopwatchCustomView.this, this);
            }
        }
    };

Which is more pleasing to the eye, easier to understand for devs reading the code and would benefit from any future advances in ViewCompat.

There are also a couple of other bug fixes in this release:

Issue #42: Fixed - Hands don't reset on Stopwatch when hand animations turned off.
Issue #47: Fixed - Ticking sounds go wrong during onPause onResume cycle.

As always the full source code to Ultimate Stopwatch is available at https://code.google.com/p/android-ultimatestopwatch

Saturday, February 23, 2013

Custom Paint Job: Accelerating the Ultimate Stopwatch

(Edit - 1st July 2013: Animator runnable updated again and one more layer of overdraw removed, details in new blog post)

Creating a custom Android view in 2013 isn't exactly breaking new ground, but the time was long overdue to relegate the old SurfaceView to history and move on; a task I was looking forward to but had kept putting off. Anyway, +Marie Schweiz's great new Ultimate Stopwatch designs deserved a hardware accelerated home.

The Android Developers training class breaks down the job of developing a Custom view into a few simple steps:
  1. Subclass a View
  2. Implement custom drawing
  3. Make the view interactive
In practice, when it came to the animations I also grabbed a couple of hints from Anders Ericsson's post at JayWay, as the mental model is also slightly different and I'd seen his related talk at Droidcon London 2012. In the SurfaceView I had a thread constantly looping to call the update/draw methods, however in a custom view it will redraw each time you call invalidate(). So, instead of a looping thread I can just call invalidate() after each cycle completes to start the next paint. This is done by posting a runnable to the View's message queue, I'm aiming for 15ms update cycles for just over 60fps.

    private Runnable animator = new Runnable() {
        @Override
        public void run() {
            updateWatchTime();
            invalidate();

            if (mIsRunning) postDelayed(this, 15);
        }
    };
The onDraw() methods from my SurfaceView and Custom view are identical, so just a copy and paste job there. The onTouch() and Activity communications handler also remained untouched. So in the end the Custom view is considerably simpler as there is no surface creation/destruction to worry about or separate thread to maintain.

A really nice feature of a Custom view is the ability to configure your own XML attributes. Previously I had to instantiate the SurfaceView and pass in details on whether it should represent the Stopwatch or Countdown view, with a Custom view I can add the following into attrs.xml

    <resources>
        <declare-styleable name="StopwatchCustomView">
            <attr name="watchType" format="enum">
                <enum name="stopwatch" value="1"/>
                <enum name="countdown" value="0"/>
            </attr>
        </declare-styleable>
    </resources>


Then by adding the name space xmlns:custom="http://schemas.android.com/apk/res-auto" in my layout, I can use the attribute custom:watchType="stopwatch" in the layout file and retrieve it in the code during instantiation. Being able to configure the custom view in XML can really simplify code and make the source easier to understand. Here is the code to retrieve the value:


    TypedArray a = context.getTheme().obtainStyledAttributes(
         attrs,
         R.styleable.StopwatchCustomView,
         0, 0);
    try{
        isStopwatch = a.getBoolean(R.styleable.StopwatchCustomView_watchType,true);
    }finally{
        a.recycle();
    }

That's it. The view is hardware accelerated where available and due to some optimizations the refresh rate has also increased when h/w acceleration is absent.

Some small improvements were gained by refactoring, but the main increases were delivered using the 'Show GPU overdraw' feature of Android's Developer Options, which is now available as I'm using the GPU to draw. It's immediately clear that before optimization there's excessive overdraw, highlighted by the red areas. This was almost entirely down to background colours being set on layers that weren't visible; the ViewPager, the layout of the custom view and also in the onDraw() of the Custom View. Eliminating these unseen, but still drawn, background colours reduced the graphics load and improved performance.


Now we have a wondrous, hardware accelerated Custom view we're in a much better position to add some final flourishes to improve the application. Later I'll write about some custom animations I've added, as suggested by +Nick Butcher to not only improve the perceived quality but also the usability.

The Ultimate Stopwatch and Timer is open source at android-ultimatestopwatch.googlecode.com, designed by +Marie Schweiz and makes use of the awesome ActionBarSherlock by Jake Wharton.

Friday, January 06, 2012

Ultimate Stopwatch & Timer finally updated!

Finally after almost a year of good intent, the updated version of Ultimate Stopwatch & Timer for Android has just gone live, v5.0.0. It'll be making its way through the interweb caches to an Android Market near you soon.

Thank you so much +Marie Schweiz (http://marie-schweiz.de/) for your awesome designs!

Updates:
- New clean design
- Action Bar on all versions (using ActionBarCompat)
- Touch feedback on all elements
- Light face for stopwatch, Dark face for countdown
- Lap Times separated out
- Built for Android 4.0 with support for versions 2.0+
- Portrait / Landscape layouts for all sceen sizes including QVGA and Tablets

Big fixes:
- Sporadic countdown alarm notifications fixed
- Galaxy Tab time appearance fixed
- QVGA layouts fixed
- Other minor issues resolved

Source available at http://android-ultimatestopwatch.googlecode.com
Comments and questions to the post on Google+ please so I can respond https://plus.google.com/u/0/115995639636688350464/posts/KhqUhC1ezB4

Monday, December 19, 2011

Android 4.0 ADB Backup / Restore

Android 4.0 ADB Backup/Restore
I switch phones quite a bit and the cloud is immensely useful for that, almost all of my #Android apps restore and most of the data is up there, even my wifi settings and wallpaper get reinstalled. But games are still lagging behind on this, they rarely keep their settings in the cloud or give a backup/restore option.

I really didn't want to lose my 'World of Goo' progress so I've just used adb backup/restore to pull it off one ICS device and push it onto another. Worked a treat.

The command lines I used:
> adb backup -f worldofgoo.bak com.twodboy.worldofgoofull
and a little dialog appears on the phone screen to confirm the backup and offer the chance to enter a password to protect.

> adb restore worldofgoo.bak
and another little dialog appears to confirm the restore

et voila, done. Other options on adb backup allow for full user data backups (-all), just type adb to see all options.


adb backup [-f ] [-apk|-noapk] [-shared|-noshared] [-all] [-system|-nosystem] []
- write an archive of the device's data to .
If no -f option is supplied then the data is written
to "backup.ab" in the current directory.
(-apk|-noapk enable/disable backup of the .apks themselves
in the archive; the default is noapk.)
(-shared|-noshared enable/disable backup of the device's
shared storage / SD card contents; the default is noshared.)
(-all means to back up all installed applications)
(-system|-nosystem toggles whether -all automatically includes
system applications; the default is to include system apps)
( is the list of applications to be backed up. If
the -all or -shared flags are passed, then the package
list is optional. Applications explicitly given on the
command line will be included even if -nosystem would
ordinarily cause them to be omitted.)

adb restore - restore device contents from the backup archive

Saturday, July 23, 2011

ViewPager example from PAUG

During a recent session at the Paris Android User Group (hi PAUG!) we did a live coding of a ViewPager example, it took around 5 minutes. What is a ViewPager? It is a tasty new class smothered in awesome sauce on a bed of rocking adapters, seriously I think I may use at least one in every Android app I make from now on. It was released as part of the updated Compatibility Package.

White on green was a great choice, right? very.... visible.

If you search for 'android view pager' you'll see many questions on how to implement smooth, finger tracking, horizontal view paging in Android, so it seems appropriate the solution is called ViewPager. ViewPager was launched at the end of last week as part of the updated Compatibility package and supports Android 1.6+.

Some of you may have been aware of the Workspace example open sourced with the I/O Sched app. An important difference between ViewPager and Workspace is that ViewPager pulls its views from an adapter, so like with a ListView as the items are slid off the screen they can be recycled and/or brought back in on the right side of the screen. The sample code for ViewPager shows this being done with a FragmentPagerAdapter, where each view is a fragment, giving you an amazing amount of control over your application.

In this example we are just sliding TextViews on and off the screen, here is the complete guide:

1) Download the update from Android SDK & AVD manager: Available Packages -> Android Repository -> Android Compatibility Package, revision 3. It will be installed in \extras\android\compatibility\v4

2) Create a new Android Project (I'm using Eclipse) and include the library. Properties -> Java Build Path -> Libraries -> Add External JARs -> android-support-v4.jar, it is in the install directory.
Update: As Thomas says if you're using the latest ADT you can now just right-click on your project -> Android Tools -> Add Compatibility Library

3) Your should now be able to use ViewPager in your Activity

4) If you use ViewPager in an xml layout, be sure to use the full reference, e.g.

<android.support.v4.view.ViewPager
android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="@+id/awesomepager"/>


5) Create a PagerAdapter to serve up your Views to the ViewPager. The key methods to implement are getCount(), instantiateItem(), destroyItem() and isViewFromObject() here are my implementations along with some JavaDoc from the source.

Note: It is up to the developer to add the views they are creating in instantiateItem() to the collection being passed in. The converse applies to destroyItem(), you must remove the item from the collection. The collection in this example is the ViewPager that is using the PagerAdapter.

The complete project source is at http://code.google.com/p/viewpagerexample/

A more professional and complete example can be found in the Compatibility Package samples (in the install directory), where a FragmentPagerAdapter implementation is provided. Using fragments inside a ViewPager can provide much better structure to an application as each view has its own FragmentActivity.