Wu-Man's Blog

A Deep Dive into Open Source Android Development

2013-01-14T12:44:00.003+08:00

Over the past month I have given talks at three different occasions, all centered around the same topic: open source Android development. The speech is split up into two parts:

An overview of a long list of popular open source libraries and tools available for Android application development;
A walk through of the process of releasing your own open source library.

Android application development can be non-trivial if compatibility across platform versions is a requirement. Without building on the shoulders of other giants, it is extremely difficult to develop an Android application with great quality. The first half of the speech aims to introduce popular tools and libraries that can help facilitate the development of good Android applications.

Furthermore, it is always great to contribute back to the open source community by releasing your own library as open source projects. The second half of the talk aims to help developers do exactly that. It walks you through the entire process step-by-step and hopefully convinces you that releasing an open source library is both easy and worthwhile.

I have made the slides available on both SlideShare and SpeakerDeck. Feel free to also check out a recorded video of the presentation at Taipei GTUG.

AndroidImageLoader: Loading Images Asynchronously on Android

2012-10-31T10:57:00.000+08:00

Almost every Android application has a need to bind remote images to a View on screen. A very common usage is to load a bunch of remote images, cache them for later reuse, and finally bind them to each view in a scrolling AdapterView.

Making this process efficient and memory-leak-free, however, is not exactly trivial. There are at least these performance considerations:

All the IO activities need to be done in a background thread to avoid blocking the main thread.
Images that fail to be loaded (usually due to network disconnection or missing resource) should be remembered so that unnecessary retrying requests are not repeated.
Loading requests should be executed in a LIFO manner to improve perceived response time.
Loaded images should be cached at least in memory so that future requests for the same image can be loaded faster.
Asynchronously binding images to an AdapterView can be tricky. Calling BaseAdapter.notifyDataSetChanged() upon callback can be a very expensive operation.

On the other hand, a major memory consideration is to avoid memory leaks.

Since image loading must be done in an asynchronous manner, views holding a strong reference to Context inevitably have to be kept and referenced by the image loader itself. This can best be prevented by using a WeakReference.
Loaded images are to be kept in cache, which can potentially cause a memory leak if Drawables are cached rather than Bitmaps.

To address these issues, I have forked the Image Loader component of the libs-for-android project to create the AndroidImageLoader library.

The AndroidImageLoader is an Android library that helps to load images asynchronously. Like its upstream libs-for-android project, it executes image requests in a thread pool and provides caching support. The following features of libs-for-android are kept:

Images are downloaded and saved to cache via a pool of background threads.
Supports preloading of off-screen images into a memory cache.
Supports prefetching of images into a disk cache.
HttpUrlConnection is used for loading images, which respects cache control.
Custom URLStreamHandlerFactory is supported for creating connections to special URLs such as content:// URIs.
Supports Bitmap transformations by accepting a ContentHandler for loading images.

The AndroidImageLoader improves libs-for-android in the following ways:

In addition to memory cache, the library also supports second level disk caching. Caching support in AndroidImageLoader is now made to depend on the TwoLevelLruCache library, which in turn depends on the more widely used LruCache and DiskLruCache.
Image requests are now placed into a LIFO task queue, which makes more sense in most scrolling scenarios.
The API for view binding is now in a separate ViewBinder class. Applications can use the ImageViewBinder class to bind to ImageViews or extend the AbstractViewBinder class for custom views. Also, ImageViews within an AdapterView no longer require a different kind of binding.
OutOfMemoryErrors are automatically detected and caught. When memory is running low, the cache size is automatically decreased to give back more memory to the system.
Prefetching can now be supported out of the box via the SinkContentHandler and the HttpResponseCache library.

The library is open source and hosted on GitHub. It is well documented and has samples that illustrate the use of the exposed API. Feel free to try it out.

TwoLevelLruCache: Standing on the Shoulder of Two Giants

2012-10-20T01:14:00.000+08:00

Android application development is made easier by people who continue to create and share useful libraries.

A few days ago I discovered a port of the DiskLruCache from the Android ICS platform. The class is a delegate backing store for the HttpResponseCache, which in turn supports caching for HttpUrlConnection responses. The DiskLruCache was released with ICS but was not accessible as a public API due to its many dependencies on other hidden parts of the platform. Jake Wharton, the amazing guy who released a number of libraries to help ~~combat fragmentation~~ support backward compatibility on Android, ported the DiskLruCache class and made it a standalone library. The standalone DiskLruCache library has proven great for at least two things:

The library has helped another great port of the HttpResponseCache to make use of advanced disk caching. This means that apps targeting pre-ICS devices can now also enjoy the improved feature.
What I am even more impressed by the library is that Jake has also ported its rigorous unit testing.

Looking at these role models I can't help but want to reciprocate. It is only right to contribute back since I myself have benefited so much from open source projects too. With that in mind, I have isolated a part of my apps into a standalone library and am releasing it as an open source project on GitHub.

The TwoLevelLruCache is a two-level LRU cache composed of a smaller, first level LruCache in memory and a larger, second level DiskLruCache. It is designed to increase the capacity of the cache without also dramatically increasing the memory footprint of an app.

The project is at a very early stage. I will continue to update it with unit tests, documentation, samples, and improvements and bug fixes. Try it out and send your feedback my way.

Happy coding. :)

Caveat in Declaring a Click Handler in Android Layout XMLs

2012-10-18T14:21:00.001+08:00

Today I came across a post on the Square blog written by Jesse Wilson, pointing out an unexpected error that might arise from declaring a View.OnClickListener in the Android layout XML files. The Square team worked around this problem by always declaring click handlers in code rather than XML.

This reminds me of my own experience in running into problems with click handler declaration in XML, but for a different root cause. In production release we often obfuscate our code using proguard. If the proguard configuration is not written properly, there is a chance that click handler methods get renamed by proguard. Those obfuscated method names are not recognized by XML declarations and can cause problems at run time.

Fortunately this problem should now be resolved because Google is providing a base configuration file for proguard, which includes the following lines:

 -keepclassmembers class * extends android.app.Activity {
    public void *(android.view.View);                                                                                                                                  
 }

Introducing JReadability: Making Web Content Easy-to-Read

2012-10-03T15:21:00.000+08:00

Reading content on the web is becoming quite a pain. Instead of the main text that are of real interest to us, we are often sidetracked by complex layouts, fancy effects, and annoying ads. Hence services like Evernote Clearly, Readability, and Full-Text RSS are extremely useful and becoming popular.

Being able to extract content from a web page is particularly useful for mobile settings, where both network bandwidth and screen real-estate are scarce. With this motivation and inspired by arc90's readability.js project and Keyvan Minoukadeh's php port, I have ported the readability.js project to Java so that it can be used as a library on Android. I have named this JReadability and made it open source on GitHub.

JReadability is released under the Apache License, Version 2.0. Feel free to fork and improve it.

One-Liner URLDecoder

2012-09-04T14:39:00.001+08:00

I found a useful one-liner URLDecoder on commandlinefu.com:

perl -pe 's/%([0-9a-f]{2})/sprintf("%s", pack("H2",$1))/eig'

Haven't found a good plugin for vim yet though.

A Programmer's vim Settings

2012-08-22T19:44:00.000+08:00

For years I have been a programmer who is not fond of IDEs. For almost everything that I can, I use the vim editor in the terminal. This habit continued even when I switched from Ubuntu to Mac. One of the greatest things about using vim as an editor is that I can program whenever and wherever I want, as long as I have a shell.

Additionally, what makes vim super powerful is the huge number of plugins that augment the editor. I spent some time to organize my vim settings using the pathogen.vim plugin. I am sharing my settings as a project on github.

A screenshot of my vim

The project comes pre-installed a number of plugins that I use regularly, including one of my favorites the ZenCoding plugin. I'd appreciate if you share with me more cool plugins.

Hack to Enable the Google Play Movies & TV App Outside of US

2012-07-24T01:48:00.000+08:00

If you live or travel outside of the US you may notice that Google actively disables the Google Play Movies & TV app as soon as it finds out that the device is physically located outside of the US. I personally find it annoying because I can no longer watch movies I purchased in the US when I'm in Taiwan. So I spent some time to reverse engineer the app and understand how it is doing the check. I then came up with a little hack to get my app back up running. Here are the steps:

Make sure the phone is rooted.
Use the Market Unlocker or the Market Enabler to fake a US carrier. This should allow your Android Market to purchase or rent movies.
adb shell pm enable com.google.android.videos. This should allow your Google Play Movies & TV app to appear again in the launcher.
sqlite3 /data/data/com.google.android.gsf/databases/gservices.db
UPDATE main SET value='us' WHERE name='device_country';
Force stop Google Play Services and Google Play Movies & TV and restart the movies app. Voila! You should now be able to download or stream your purchased movies.

[UPDATE 2012/8/22]

Please note that in addition to the above hacks, you still need to use a US proxy to playback or download movies.

Taiwanese News Reader for Android

2012-06-18T15:48:00.001+08:00

At least two Android tablets have been given to me as gifts from Google: the Samsung Galaxy Tab 10.1 from Google I/O 2011 and the HTC Flyer from the Taipei Android Developer Lab. Rumor also has it that another Nexus tablet featuring Jelly Bean will be given out at Google I/O 2012. If that rumor is real, which I think is highly likely, I will have in total 3 free tablets from Google.

When I received the second tablet at the ADL event, I promised to write at least one app designed for tablets as a token of appreciation for Google's generosity. So in addition to what I am already doing at work, I have written in my free time a simple news reader app to demonstrate how a single APK can be written to support devices of all platform versions and all physical sizes.

The Taiwanese-targeting app aggregates news content from several mainstream Taiwanese news media and provides a unified reading experience. Several highlighted features include:

It supports Android devices of all sizes. It is optimized for best layout and resolution on even large size tablets.
A ListView-like home widget is provided so that real time news can be easily browsed right from the home screen.
Users can pick and reorder news categories for a more customized reading experience.
Full-fledged sharing integration using the new ShareActionProvider API is included to allow for easy sharing of news articles.

Some screenshots are included here to give you a better idea of what it looks like:

Check it out at the Android Play Market today and be sure to let me know your suggestions!

My Minor Frustrations with Android (Sometimes)

2012-06-07T01:55:00.000+08:00

The first announcement of the Android platform by Google was an exciting one. It was the first mobile platform that was somewhat open at every layer of the stack. It brought a lot of opportunities for hardware manufacturers as well as software developers.

Everything was great. In particular, as a software developer I was finally given the chance to really reach out to my users and make a side profit (albeit little) out of my apps. I also finally saw some slim hope (compared to none before) that perhaps one day I could become a millionaire by publishing a surprisingly popular mobile app. Call me naive and all, but hey it doesn't hurt to dream.

Yet everything was great, only for a while. My frustration with developing apps on Android grows each day. Here is why.

Differences Across Devices

Some people call this fragmentation. I don't like that word so much though. In fact, I see the huge variety of devices an opportunity to reach out to more users and for more use cases. I am completely accepting of the idea that there should be many different devices having different capabilities.

When challenged with this question, some folks at Google will subtly respond by basically saying that they have designed their APIs and written guidelines to help developers write apps that work on all devices with different capabilities. In other words, if you are having a problem, it's most likely your fault for not following the guidelines and writing the app correctly.

While that is certainly the case for many, if not most, cases, there are still discrepancies in devices implementing those APIs. A quick example would be how cameras made by different device manufacturers return their EXIF information differently. If you were a developer wanting to make an app that makes use of the camera for the first time, you would have a hard time dealing with the correction of photo orientations based on the EXIF. It's because they are not consistent across devices! Somehow that was overlooked in the CTS. Another example is how the default theme can be drastically different from one device to another (though should be fixed in ICS), which leads to my next point.

Backward Compatibility with Older Platforms

Android has a very rapid iteration cycle. About every 6 months a new major version is out and there are huge API differences between them. Each jump from Eclair to Froyo, from Froyo to Gingerbread, from Gingerbread to Honeycomb (OMG don't even let me get started on the Honeycomb which was totally half-baked), and from Honeycomb to Ice Cream Sandwich was a pain. For each new Android version, new theme attributes (many of which were supposed to be there in the first place) and new APIs are introduced. It takes a lot of effort to make a decision on where the trade-off should be at: make use of new APIs for new features and cleaner code, or stick with old APIs to maintain backward compatibility with all old devices. Sometimes you even wonder if it was worth it to stick a piece of ugly workaround into your otherwise clean code just for the sake of having a new feature on an old device. The truth is that the market share for Eclair is still significant enough for most serious apps to maintain backward compatibility with at least Eclair. That was more than 2 years ago!

A great thing that Google introduced was the support library, which packages implementations for many important features introduced in new versions of Android into a library so that they can be used on older devices. They have failed to include one of the most important APIs in the library though: the ActionBar. Thanks to Jake Wharton, the ActionBarSherlock library adds the ActionBar API into the support library. It works quite well but there are still a couple of real shortcomings:

If you use a ViewPager to swipe between different fragments and you want those fragments to show different action items, you are out of luck.
If you want to enable batch contextual actions in ListView or GridView, you're also out of luck because it is not yet supported by the ActionBarSherlock library.

In a nutshell, as a developer I spend about 80% of my time on not the design or innovation for my app, but on efforts towards backward compatibility. That is real pain.

Having said all that, I should still say that I love Android. It has done way more good than bad. In fact, I should commend Google for answering questions on StackOverflow and improving the platform at a rapid pace. Keep up with the good work Google! But before that could somebody please take a look at this in-app billing problem that I ran into today (seems like a bug with the recent introduction of subscriptions)? Thanks a lot.

[UPDATE 2012/06/20]

Apparently the in-app billing problem is now resolved.

[UPDATE 2012/09/11]

The issue with random disappearance of action items is seemingly resolved with the workaround mentioned in comment 8 of the issue report.

Bypassing the Thunk

2012-02-15T13:35:00.001+08:00

One of the best things about reading open source code is that it allows you to learn from other developers. I have recently experienced this first hand when I read the source code for the Android TextView. Due to my recent work on inline rich text editing for Android, I read most of the source code for the TextView class to study how it works.

While I was reading the source code, I came across a comment for a method called spanChange().

    /**
     * Not private so it can be called from an inner class without going
     * through a thunk.
     */
    void spanChange(Spanned buf, Object what, int oldStart, int newStart, int oldEnd, int newEnd) {
         // spanChange content
    }

The spanChange() method is an outer class (TextView) method that is called by an inner class instance.

    private class ChangeWatcher implements TextWatcher, SpanWatcher {

        public void onSpanChanged(Spannable buf,
                                  Object what, int s, int e, int st, int en) {
            TextView.this.spanChange(buf, what, s, st, e, en);
        }

    }

The term "thunk" was new to me but it appears that the change of access modifier for the outer method is intentional to improve performance. So I quickly became curious and decided to dig a little deeper.

It turns out that "thunk" in this context refers to a compiler-generated wrapper function to invoke an outer class method from an inner class. I had always known about the existence of such wrapper functions generated by the compiler, but never knew there was a conventional term for it.

To better understand the performance impacts of such wrapper functions, I wrote some test code to observe how the compiler behaves differently.

Here is my test code:

public class OuterClass {

 private final InnerClass mInner;

 public OuterClass() {
  super();
  mInner = new InnerClass();
 }

 public void start(int loops) {
  for (int i = 0; i < loops; i++) {
   mInner.callOuterFunctionDirect();
  }
  for (int i = 0; i < loops; i++) {
   mInner.callOuterFunctionThunk();
  }
  mInner.dump();
 }

 void outerDirectMethod() {
  System.out.println("Direct outer method");
 }

 private void outerPrivateMethod() {
  System.out.println("Private outer method");
 }

 private class InnerClass {

  private TimingLogger mLoggerDirect;
  private TimingLogger mLoggerThunk;
  private int mCountDirect;
  private int mCountThunk;

  public InnerClass() {
   super();
  }

  public void dump() {
   mLoggerDirect.dumpToLog();
   mLoggerThunk.dumpToLog();
  }

  public void callOuterFunctionDirect() {
   if (mLoggerDirect == null) {
    mLoggerDirect = new TimingLogger("test",
      "callOuterFunctionDirect");
   }
   OuterClass.this.outerDirectMethod();
   mLoggerDirect.addSplit("Count: #" + (++mCountDirect));
  }

  public void callOuterFunctionThunk() {
   if (mLoggerThunk == null) {
    mLoggerThunk = new TimingLogger("test",
      "callOuterFunctionThunk");
   }
   OuterClass.this.outerPrivateMethod();
   mLoggerThunk.addSplit("Count: #" + (++mCountThunk));
  }

 }

}

The compiler compiles the invocation of the outer method differently. If the access modifier was not private, then the outer method is a virtual function which can be invoked directly:

    invoke-virtual {v0}, Lcom/test/application/OuterClass;->outerDirectMethod()V

On the other hand, if the access modifier was private, then the compiler automatically generates a thunk and invokes the outer method indirectly via the thunk:

    #calls: Lcom/test/application/OuterClass;->outerPrivateMethod()V
    invoke-static {v0}, Lcom/test/application/OuterClass;->access$0(Lcom/test/application/OuterClass;)V

The access$0 method is the thunk:

.method static synthetic access$0(Lcom/test/application/OuterClass;)V
    .locals 0
    .parameter

    .prologue
    .line 5
    invoke-direct {p0}, Lcom/test/application/OuterClass;->outerPrivateMethod()V

    return-void
.end method

Invocation of the outer method through the thunk requires extra overhead in the call stack. My code does not test the memory footprint of the call stack, but it does compare the execution performance of the two different ways of outer method invocation. My test results show that on an average of 10 test runs of 10K loops, the thunk does degrade performance:

Direct: 11354ms
Thunk: 16485ms

Just thought this was kind of interesting. I love open source. :)

Memory Leaks Discovered in the Vpon Android SDK

2012-02-08T12:13:00.001+08:00

Most mobile developers in Taiwan are familiar with the name Vpon. It is the de facto mobile ad platform to choose (instead of AdMob) if your app targets Taiwan and/or mainland China. Unfortunately the quality of their Android SDK and support can be appalling.

A little more than a month ago I had discovered at least 3 places in their Android SDK that introduce serious memory leaks. We contacted their support team, listing instances where the memory leaks were taking place (well all the ones that I found anyway). FWIW, the root causes had been identified and a fix would be simple. We asked for an immediate fix, but unfortunately as of today no actions nor responses have been taken/heard.

As such I am reporting my findings in this blog post.

I first found the memory leaks in my Android app Roguso. In this app there is a ListView of posts that, when clicked, a corresponding details page will show up. The page holding the ListView is implemented as TimelinesActivity, and the details sub-pages are implemented as PlurkResponsesActivity. The PlurkResponsesActivity is written so that it is reused for different posts in the ListView. That's a fairly typical pattern.

We placed an ad on both the list page and the details page:

Roguso ListView page (TimelinesActivity)

Roguso detail page (PlurkResponsesActivity)

We soon discovered that after several page clicks the app was losing free memory quickly! Checking the MAT (Eclipse Memory Analyzer) we found that the PlurkResponsesActivity was not being reused and had several instances.

Looking at strong-referenced paths to GC roots on one of the PlurkResponsesActivity instances we identified several memory leaks caused by the Vpon ad:

After some reverse engineering on the Vpon Android SDK, I found at least 3 places in their code that introduced the memory leaks:

There is a static variable in the LocationUtils class that holds a long-living strong reference to Context.
There is a static variable in AdManager class that holds a long-living strong reference to Context.
A Runnable with obfuscated class name com.vpon.adon.android.b was being executed repeatedly and endlessly by the main thread Handler. The Runnable itself holds a strong reference to AdView, which causes a memory leak to its associated Context.

I'm pretty sure that there are more than 3 places introducing the memory leaks though. These are just obvious findings that I discovered fairly quickly.

A quick workaround to this problem is to not show an ad on every page of your app. In Roguso's case, we removed ads on all sub-pages and used the singleTask launch mode on the main page. That should significantly reduce the occurrences of memory leaks.

Nevertheless, we urge Vpon to patch their Android SDK soon.

LruCache with SoftReference on Android

2012-01-28T14:57:00.001+08:00

The use of cache is commonly important in Android programming, where the target devices are often limited in terms of capabilities. A cache improves performance by storing frequently accessed objects in memory so that they don't need to spend the extra overhead to be prepared or fetched again. On Android we often use a cache to store data loaded from a SQLite database or Bitmaps that can be reused across different ListView items.

Sometimes it is inevitable that we store in cache objects that themselves contain a strong reference to a Context. For instance, we often store Drawable objects in a cache to improve performance, but these Drawable objects also hold a strong reference to an associated Context. If the cache itself somehow outlives the Context (which is often the case if the cache is being used for multiple instances of an Activity), then we will have a memory leak.

Another problem with cache is that it often takes up a large area of memory. When the system is running low on memory, cache should usually be one of the best candidates for garbage collection.

Android has a native implementation of cache called LruCache, which uses the LRU replacement policy. It was introduced in Honeycomb. If backward compatibility is needed, there is a Support Library version too. However, if used inappropriately, it is possible that we run into the aforementioned problems.

I have rewritten the LruCache so that it uses SoftReference on all of its cache entries. I call it the LruSoftCache. The great thing about the LruSoftCache is that it uses SoftReference on all of its cache entries, which means that cache entries don't get held on forever and hence will not be leaked. The only drawback is that the cache size can now only be measured in the number of entries. You can find the source code here on GitHub.

Improving Android Application Performance and Enabling Inline Rich-Text Editing on Android

2011-12-30T16:59:00.001+08:00

The month of December is kind of crazy for me. I had two speeches and two products for launch, not mentioning the heavy workload in my day job.

The first talk was about sharing tips and tricks on improving Android app performance. It was given at the Department of Computer Science & Information Engineering of National Taiwan University, where I graduated from. So there were some sentimental moments there LOL. You can find my slides here on SlideShare.

The second talk was about sharing ways of enabling your Android app to use inline rich-text editing. It was given at the Open Source Apps on Mobile forum held in Academia Sinica. Thanks to my OSSF friends who invited me to speak there. You can find the slides for this talk here on SlideShare as well. The video recording of this talk is now available on YouTube.

I'll be speaking again on the same topic (rich-text editing) at the Taipei Google Technology User Group gathering in January, but hopefully with more demos. Be sure to check it out!

UPDATE [January 28, 2012]

The rich text speech at GTUG was held on January 18. I used my app Roguso as an example to demonstrate how rich text can be implemented on Android. The slides are available for download on SlideShare. The speech was also video recorded and can be watched on YouTube as Part 1 and Part 2.

Customizing the ActionMode Bar on Honeycomb Devices

2011-12-30T16:38:00.000+08:00

The ActionBar API provided by Google on Honeycomb or later devices has great features, but can be a pain to use if your app needs to ensure compatibility. A recommended way to maintain compatibility while using most of the great features provided by the ActionBar API would be to use the ActionBarSherlock library. The library is a fork of the Android Support Package (aka. Android Compatibility Library) so in addition to the ActionBar API, you can also use other useful features such as Fragments, Loaders, etc.

Anyway I was looking for ways to customize the style of the title and subtitle of the ActionMode bar, but realized that the attribute android:actionModeStyle wasn't provided until Ice Cream Sandwich. That means you can't customize this easily in your theme/style XML files like you could with the ActionBar.

I wrote a little hack and tested it on my Galaxy Tab 10.1 to be working. You basically add the following piece of code in beginning of your onPrepareActionMode() before proceeding:

if (UIUtils.isHoneycomb(true) && !UIUtils.isICS(true)) {
    /*
     * Honeycomb devices do not allow style customization of
     * the action mode title/subtitle. We hack this by code.
     */

    final int contextId = getResources().getIdentifier(
            "action_context_bar", "id", "android");
    final int titleId = getResources().getIdentifier(
            "action_bar_title", "id", "android");
    final int subtitleId = getResources().getIdentifier(
            "action_bar_subtitle", "id", "android");

    if (contextId != 0 && titleId != 0 && subtitleId != 0) {
        try {
            ViewGroup decorView = (ViewGroup) getActivity()
                    .getWindow().getDecorView();
            ActionBarContextView abContext = (ActionBarContextView) decorView
                    .findViewById(contextId);
            TextView titleView = (TextView) abContext
                    .findViewById(titleId);
            TextView subtitleView = (TextView) abContext
                    .findViewById(subtitleId);

            if (titleView != null) {
                titleView.setTextAppearance(getActivity(),
                        R.style.ActionModeTitleStyle);
            }
            if (subtitleView != null) {
                subtitleView.setTextAppearance(
                        getActivity(),
                        R.style.ActionModeSubtitleStyle);
            }
        } catch (Exception e) {
            // If this is a custom device with customized
            // layouts, then forget it
        }
    }

}

Obviously you will need to set the styles accordingly in your application. UIUtils is just my own helper class to determine the device's API version.

Horizontal View/Fragment Paging in the Android Compatibility Package

2011-07-26T02:24:00.010+08:00

A while ago I published source code for a ViewGroup which pages horizontally in between multiple child views in an efficient manner using the Adapter. I called it the AdapterWorkspace, which extends the AdapterViewAnimator class in the Honeycomb release. Most readers probably did not benefit from this, as the source code for AdapterViewAnimator (as well as source code in general for all Honeycomb releases from 3.0 to 3.2) remains closed.

Fortunately, revision 3 of the Android Compatibility Package has included classes that function the exact same way. Better yet, the source code is available!

The following two classes work the same way as my AdapterWorkspace:

ViewPager: A ViewGroup that manages the layout for the child views, which the user can swipe between.
PagerAdapter: An adapter that populates the ViewPager with the views that represent each page.

The Android Compatibility Package goes even farther to provide support for Fragments! (Hey that was what I wanted to do next too!)

FragmentPagerAdapter: An extension of PagerAdapter for flipping between fragments.
FragmentStatePagerAdapter: An extension of PagerAdapter for flipping between fragments that uses the library's support for Fragment.SavedState.

Be sure to check out the sample code here.

Why Google chose to make these APIs available only in the support library puzzles me. Nevertheless, I'm thankful that they are making the source code available to all.

COSCUP2011: Summary of Enhancements to the Google I/O 2011 App

2011-07-21T01:31:00.008+08:00

For some weird reason I feel compelled to summarize what I have added to and/or modified in the original iosched project to arrive at my current COSCUP2011 project.

Parsing

The parser in the original iosched project dealt with data that came in the form of XML spreadsheets. The COSCUP API, however, came in the form of JSON, which are themselves transcoded directly from Google Spreadsheets. It is then obvious that most of my work is to rewrite the parsers to handle the different format.

Sync

The spreadsheets for the iosched project have a sync hash/timestamp for each row/record. This makes the app much more efficient during its periodic sync. It is able to decide which spreadsheets and also which records within those spreadsheets should be reparsed and used to replace old data stored in the local cache. However, the COSCUP API does not offer such convenience. So I had to rewrite this part of the app to make sure each sync will keep the local cache consistent with remote data.

As a side effect of the less efficient sync, ANR (Application Not Responding) errors start to appear each time a sync is in progress. This is caused by the fact that each operation on the local database (and there are many of them during each sync) will trigger a foreground ContentObserver change. This wasn't noticeable in the iosched project because the sync was often much shorter. To remedy the problem, I made changes in the provider to notifyChange only in the last operation of a sync. This took care of the ANR problem, which would otherwise be quite annoying to the user.

I also fixed a bug in the initial launch of the app. The iosched project invoked triggerRefresh() at the end of each onCreate() call of HomeActivity, which could be premature at times. The DetachableResultReceiver in the SyncStatusUpdaterFragment may not have been instantiated when the triggerRefresh() call is made.

One last change I made was to disable the refresh button when a sync is already in progress.

Schedule conflicts

The iosched project could not handle time block conflicts properly. This is perhaps best illustrated with the following picture.

Notice that the two conflicted breakout sessions blocks in the 5pm-6pm time slot overlap. If they had the same end times, the block drawn in the bottom can never be clicked. So I rewrote this part of the code to take care of conflicted blocks and the end result can be seen in the 3:30pm-4:30pm slot:

Sponsors

Instead of showing sandbox vendors, I rewrote this part of the app to support a listing of conference sponsors. These sponsors are organized in different levels according to the amount of their sponsorship to the conference.

Vote for my app

Thanks to original author and Google engineer Jeff Sharkey's great work, I was able to make these changes in 5 nights (averaging about 2 hours per night after work). What I love most about the experience is that I witnessed first hand how an open source project could foster more interesting projects; in this case, it's most adequate that the forked project is to be used by participants in an open source conference!

If you like what I have done, please support by voting for my app here and contributing with your patches here.

Quick Sharing of Google I/O Sessions at Taipei GTUG

2011-07-19T00:32:00.008+08:00

A few weeks ago the Google Technology User Group in Taipei held a gathering for all the Google I/O fans who could not make it to San Francisco. Speakers who signed up were asked to condense an hour-long Google I/O 2011 session of their choice into a 10-minute sharing. Yes I agree with you that participants of this gathering are all pretty lazy. :p

Anyway I signed up to share two particular sessions:

Android Protips: Advanced Topics for Expert Android App Developers by Reto Meier
Memory Management for Android Apps by Patrick Dubroy

It was an interesting challenge for me coz condensing these sessions were almost impossible. Nevertheless you can check out the slides here and here. Video recordings of my sharings can be found here and here on YouTube.

Oh and I received this Chrome cartoon book as a token of appreciation.

Mobile Device App Contest for COSCUP 2011

2011-07-18T23:01:00.029+08:00

COSCUP 是開放原碼社群中一年一度的大拜拜，每年都有來自各地的英雄好漢搶著報名。在今年的活動中，最大的樂趣除了認識朋友~~和旁觀報名網站被DDoS搞掛~~外，就是主辦單位第一次嘗試提供議程的API，並舉辦了一場各大行動平台上的應用程式競賽。

由於我平常的工作就是Android程式開發，再加上已經有一個很棒的開放原碼專案可以提供分支，讓我很快把程式雛型寫好，所以自然地就參加了。主辦單位希望參賽者寫一份圖文說明的文章，所以我只好寫這篇~~交差了事~~囉～

懶得讀完整篇介紹文章的朋友可以直接到 Android Market 上下載。此外，這個應用程式是完全開放原始碼的，讀者可以自行到這個網頁去參與此專案的開發。

首頁簡介

首頁上提供了六個選項，讓使用者可以選擇不同方式瀏覽主辦單位發布的官方訊息。左下角提供了即時倒數，讓使用者在活動開始前可以一起興奮地參與倒數。活動期間，這個區塊會改為顯示當下正在進行的議程，並提供快速連結方便使用者瀏覽。

此外，右下角的 Realtime Stream 選項，會展示出噗浪上所有提到 #coscup 這個關鍵字的討論串，方便使用者掌握最即時的討論。

議程瀏覽

議程主要可由兩種不同方式瀏覽：Schedule 和 Sessions。Schedule 選項以時間排序，並用日曆方式顯示每個時段有哪些講題。點選某個時段區塊後，就會跳出該區段的所有講題，再進而查詢某講題的詳細資訊。

另一種查詢議程的方式是 Sessions，也就是 by tracks。依據議程主題與類型，將講題分門別類列出。使用者點選某一軌主題後，就會詳列出該主題的所有議題。這對只有單一主題興趣的使用者來說應該是較為方便的瀏覽方式。

議程標記

通常我們在參加研討會時，總會有幾個講題是我們極為確認一定要參加的。也有另一種情況是我們在同一時段有兩個講題都想參加，但還沒辦法決定到底要參加哪一個講題，想要晚點再來決定。不管是哪一種情況，如果能把這些講題都先標記起來，就可以方便之後快速瀏覽。所以這個應用程式也提供了標記的功能，方便使用者快速回顧所有曾被標記星號的議題。

搜尋議程

有時候我們會想快速搜尋和某個關鍵字相關的所有議程。例如，或許我們會突然想知道今年 COSCUP 的鑽石贊助商之一的 HTC 有些什麼講題，就可以按下搜尋按鈕，然後輸入 HTC，就可以查詢到所有和 HTC 這個關鍵字有相關的講題。

贊助商瀏覽

COSCUP 是免費的活動，因此每年都需要廠商的大力贊助。使用者可以依照贊助層級來瀏覽每個贊助廠商的官方資訊。

官方部落格公告

Bulletin 這個選項可以方便使用者瀏覽官方部落格的文章，若議程進行間主辦單位有新的訊息發布，這就是很好得知的一個管道。

大尺寸平板支援

最後，就是大尺寸平板的支援囉。附上一些擷圖給沒有平板的使用者看看囉～

地圖功能

最後沒有介紹的地圖功能，因為我的 Photoshop 功力沒有很好，所以需要一點時間製作。後續會再補上這個功能的，請各位大大見諒。

結語

雖然工作很繁忙，可是心裡還是有不少想對這個應用程式增加的功能。活動前希望還能利用一些空閒的時間來做進去！有興趣的大大可以先到 Android Market 上下載。所有的程式碼都開放在這個空間。

UPDATE [7/21]:

我把我的貢獻的部份整理在這篇新的文章中。

Secret Modes in Samsung Galaxy Tab 10.1 Limited I/O Edition

2011-06-18T01:36:00.012+08:00

I have a Samsung Galaxy Tab 10.1 Limited Edition, which was given to me and 5500 other attendees of Google I/O 2011. I was playing with it today and found out the key sequences to get into some of the secret modes, though I have no idea what some of these modes are for.

Safe Mode

Press the Power button to start the device as normal.
As soon as you see the Samsung Galaxy Tab 10.1 logo during boot up, press and hold the volume down (left) button.
After the Samsung logo comes up, you should feel a vibrate. You can then release all the keys and wait for the boot to complete.

As you can see, you should see the words "Safe mode" on the bottom left of the screen. The only thing that's different from this mode to normal start up is that all the apps that I downloaded from the Android Market are gone. The launcher will show only the apps that came bundled with the device.

Upload Mode

Press and hold the power button to boot the device.
As soon as you see the Samsung Galaxy Tab 10.1 logo, press and hold the volume down button (along with the power button).
As soon as the logo disappears, release all the buttons.

You should then see the following on the top left corner of the screen, indicating that the device is in Upload mode, which I have no idea what it is for.

Bootloader (Fastboot Mode and ODIN3 Download Mode)

Press and hold the volume down key.
Press and hold the power button.
The device will then boot into the following screen.

As you can see there are two options for you to choose from. You use the volume down (left) key to change your selection and the volume up (right) key to confirm your selection. The USB icon on the left will make you go into Fastboot mode. The Downloading icon on the right will make you go into ODIN3 Download mode. Now Fastboot mode is obvious; it allows you to do all your fastboot commands if the bootloader is unlocked. I don't know what the Download mode does though.

Super Cute DogFan (お父さん扇風機) Ported on Android

2011-06-16T16:39:00.010+08:00

Yesterday I saw in @vgod's plurk this cute HTML5 page. It's a hilarious (apparently also very popular in Japan) dog fan that was released by SoftBank. You can check out the original CM on YouTube and its Wikipedia article to learn more.

I thought it was kind of cute and decided to port @vincicat's HTML5/CSS/JS version to Android. I will refine and add more features in later releases when I have more free time. For now you can check out the source code on my GitHub or download from the Android Market. Be warned though that I only tested with my Nexus One.

[Update 2002/06/28] I just updated the app to support sound effects. You can finally hear the infamous "ahahah~" noise when you turn the fan on.

Thank You Vancouver Canucks

2011-06-16T12:02:00.006+08:00

So the Stanley Cup final has ended and the Vancouver Canucks has lost Game 7. Many Canucks fans are upset about the final outcome, and I'm one of them. This blog post, however, is not about that. I wanted to spend some time to talk about how proud I am to be a Canucks fan.

The Vancouver Canucks has inspired me in many ways. Unlike many bandwagoners, I have actually been watching their games since day 1. I witnessed how this team has worked hard to get to where they are now. There have been ups and downs along this long journey (which will definitely be marked down in history and remembered by all), but it is their persistence to fight for their dream that has really brought the team together and made them grow. This fighting spirit has encouraged me to overcome my own setbacks on numerous occasions.

Another thing that makes me proud as a Canucks fan is that the team has really brought the city (and perhaps the nation) together. Enormous crowds gather both inside and outside of the arena to cheer for our favorite team. At a local sports bar in Taipei (where I live), many expats gather for the final game and sing the opening anthem together. If you were there you would be moved by it too.

So there you go. Thank you Canucks for a great season. You guys didn't win the cup, but you surely accomplished lots. I will continue to support and proudly shout "Go Canucks Go"!

Efficient Tweetdeck-styled Workspace using AdapterViewAnimator

2011-06-03T00:18:00.012+08:00

If you have ever used TweetDeck, you would grow to love its horizontal pager. It's actually a layout that is found common in many applications such as feedly, YouTube, and News & Weather, just to name a few. In fact, the stock Android launcher's home screen works the exact same way. It allows the user to horizontally swipe across the display to quickly switch in between screens. The layout in use there is called Workspace and the source code can be found here.

However, the Workspace layout actually has a fatal limitation. It requires you to inflate and add all of the child views to the Workspace layout beforehand. This is probably fine if you have only very limited number of child views. If you need to work with more than a handful child views, particularly if your child views are themselves hierarchically complex layouts, you might run into performance and memory problems. There are several overheads. The inflation of all the child views could block the UI thread. Secondly, all the child views are present in the Workspace hierarchy even though most of them are not drawn in the screen; that means you waste unnecessary tree traversals (and there are lots of them since you probably only need to traverse at most two branches of the tree at any given time).

I ran into this exact problem when I was working on a secret project, where I needed to provide the horizontal paging functionality to a fairly large number of complex child views. With the introduction of Honeycomb, fortunately there is a new layout called AdapterViewAnimator that comes handy. The concept is simple. It extends the AdapterView and allows you to switch (and animate) between views provided by an Adapter. One can extend the AdapterViewAnimator to have a customized layout that is functionally equivalent to the Workspace layout.

That's exactly what I did. A drawback is that my implementation needs to be placed in the same package namespace as the AdapterViewAnimator as some of the instance methods and fields are restricted to default access (which in my opinion is an extensibility hindrance found in many of the android.widget.* classes). I suppose when the source code for honeycomb (which I heard will not happen) or ice cream sandwich comes out, you can copy out the AdapterViewAnimator class to your own package and extend it then. But for now, here are my two cents. Btw, I call it AdapterWorkspace.

package com.wuman.widget;

import java.util.ArrayList;
import java.util.Map.Entry;

import android.content.Context;
import android.graphics.Canvas;
import android.graphics.Rect;
import android.util.AttributeSet;
import android.view.MotionEvent;
import android.view.VelocityTracker;
import android.view.View;
import android.view.ViewConfiguration;
import android.widget.Scroller;

public class AdapterWorkspace extends AdapterViewAnimator {

    private static final int INVALID_CHILD = -1;
    private static final int INVALID_POINTER = -1;

    private boolean mFirstLayout = true;
    private int mNextChild = INVALID_CHILD;
    private Scroller mScroller;
    private VelocityTracker mVelTracker;
    private float mTouchX;
    private float mLastMotionX;
    private float mLastMotionY;
    private int mMotionAction = MotionEvent.ACTION_DOWN;
    private boolean mAllowLongPress = true;
    private int mTouchSlop;
    private int mLayoutTouchSlop;
    private int mMaximumVelocity;
    private int mActivePointerId = INVALID_POINTER;

    public AdapterWorkspace(Context context) {
        super(context);
        initAdapterWorkspace();
    }

    public AdapterWorkspace(Context context, AttributeSet attrs) {
        super(context, attrs);
        initAdapterWorkspace();
    }

    private void initAdapterWorkspace() {
        configureViewAnimator(3, 1);
        setHapticFeedbackEnabled(false);
        setHorizontalFadingEdgeEnabled(false);
        mScroller = new Scroller(getContext());
        final ViewConfiguration vc = ViewConfiguration.get(getContext());
        mTouchSlop = vc.getScaledTouchSlop();
        mMaximumVelocity = vc.getScaledMaximumFlingVelocity();
        // min slop to switch touch handling owner to layout itself
        mLayoutTouchSlop = 50;
    }

    @Override
    public void addFocusables(ArrayList<View> views, int direction,
        int focusableMode) {
        getCurrentView().addFocusables(views, direction);
        if ( direction == FOCUS_LEFT ) {
            if ( mWhichChild > 0 ) {
                getViewAtRelativeIndex(mActiveOffset - 1).addFocusables(views,
                    direction);
            }
        } else if ( direction == FOCUS_RIGHT ) {
            if ( mWhichChild < getWindowSize() - 1 ) {
                getViewAtRelativeIndex(mActiveOffset + 1).addFocusables(views,
                    direction);
            }
        }
    }

    public boolean allowLongPress() {
        return mAllowLongPress;
    }

    @Override
    void transformViewForTransition(int fromIndex, int toIndex, View view,
        boolean animate) {
        // Do not animate as we are doing horizontal scrolls
    }

    @Override
    void showOnly(int childIndex, boolean animate) {
        super.showOnly(childIndex, animate);

        mNextChild = Math.max(0, Math.min(childIndex, getWindowSize() - 1));
        int screenDelta = Math.abs(mNextChild - mWhichChild);

        View focusedChild = getFocusedChild();
        if ( focusedChild != null && screenDelta != 0
            && focusedChild == getCurrentView() ) {
            focusedChild.clearFocus();
        }

        if ( mViewsMap.containsKey(mNextChild) ) {
            final int nextRelativeIndex = mNextChild - mCurrentWindowStart;

            int scrollOffset = nextRelativeIndex * getMeasuredWidth()
                - getScrollX();
            awakenScrollBars(screenDelta * 300);
            int duration;
            if ( screenDelta == 0 ) {
                duration = Math.abs(scrollOffset);
            } else {
                duration = screenDelta * 300;
            }

            if ( !mScroller.isFinished() ) {
                mScroller.abortAnimation();
            }

            mScroller.startScroll(getScrollX(), 0, scrollOffset, 0, duration);
        }

        invalidate();
    }

    @Override
    public void computeScroll() {
        if ( mScroller.computeScrollOffset() ) {
            scrollTo(mScroller.getCurrX(), mScroller.getCurrY());
            postInvalidate();
        } else if ( mNextChild != INVALID_CHILD ) {
            mWhichChild = modulo(mNextChild, getWindowSize());
            mNextChild = INVALID_CHILD;
        }
    }

    @Override
    public void setDisplayedChild(int whichChild) {
        if ( !mScroller.isFinished() ) {
            mScroller.abortAnimation();
        }
        super.setDisplayedChild(whichChild);
    }

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        super.onMeasure(widthMeasureSpec, heightMeasureSpec);

        if ( mFirstLayout ) {
            setHorizontalScrollBarEnabled(false);
            int widthOffset = getMeasuredWidth() * mActiveOffset;
            scrollTo(widthOffset, 0);
            setHorizontalScrollBarEnabled(true);
            mFirstLayout = false;
        }
    }

    @Override
    protected void onSizeChanged(int w, int h, int oldw, int oldh) {
        super.onSizeChanged(w, h, oldw, oldh);
        setDisplayedChild(mWhichChild);
    }

    @Override
    protected void onLayout(boolean changed, int left, int top, int right,
        int bottom) {
        checkForAndHandleDataChanged();

        final int currentWindowSize = mCurrentWindowEnd - mCurrentWindowStart
            + 1;

        for ( int i = 0; i < currentWindowSize; i++ ) {
            final int rangeIndex = modulo(mCurrentWindowStart + i,
                getWindowSize());
            final int relativeIndex = mCurrentWindowStart + i
                - mCurrentWindowStartUnbounded;

            if ( mViewsMap.containsKey(rangeIndex) && relativeIndex >= 0
                && relativeIndex <= getNumActiveViews() - 1 ) {

                final View child = getViewAtRelativeIndex(relativeIndex);

                final int childBottom = getPaddingTop()
                    + child.getMeasuredHeight();

                final int realLeft = getMeasuredWidth() * i + getPaddingLeft();

                child.layout(realLeft, getPaddingTop(),
                    realLeft + child.getMeasuredWidth(), childBottom);
            }
        }
    }

    @Override
    protected void dispatchDraw(Canvas canvas) {

        final boolean fastDraw = mMotionAction != MotionEvent.ACTION_UP
            && mNextChild == INVALID_CHILD;

        if ( fastDraw ) {
            drawChild(canvas, getCurrentView(), getDrawingTime());
        } else {
            long drawingTime = getDrawingTime();
            if ( mNextChild >= 0 && mNextChild < getWindowSize()
                && Math.abs(mWhichChild - mNextChild) == 1 ) {
                drawChild(canvas, getCurrentView(), drawingTime);
                drawChild(canvas, getViewAtRelativeIndex(mNextChild
                    - mWhichChild + mActiveOffset), drawingTime);
            } else {
                for ( ViewAndIndex vi : mViewsMap.values() ) {
                    drawChild(canvas, vi.view, drawingTime);
                }
            }
        }
    }

    @Override
    public boolean dispatchUnhandledMove(View focused, int direction) {
        if ( direction == FOCUS_LEFT ) {
            setDisplayedChild(mWhichChild - 1);
            return true;
        } else if ( direction == FOCUS_RIGHT ) {
            setDisplayedChild(mWhichChild + 1);
            return true;
        }
        return super.dispatchUnhandledMove(focused, direction);
    }

    @Override
    public void focusableViewAvailable(View v) {
        final View current = getCurrentView();
        View view = v;
        while ( view != this ) {
            if ( view == current ) {
                super.focusableViewAvailable(v);
                return;
            } else if ( view != this && view.getParent() != null
                && view.getParent() instanceof View ) {
                view = (View) view.getParent();
            } else {
                return;
            }
        }
    }

    @Override
    public void requestChildFocus(View child, View focused) {
        super.requestChildFocus(child, focused);

        if ( !isInTouchMode() ) {
            for ( Entry<Integer, ViewAndIndex> entry : mViewsMap.entrySet() ) {
                int index = entry.getKey();
                ViewAndIndex vi = entry.getValue();
                View view = vi.view;

                if ( child == view ) {
                    setDisplayedChild(index);
                    break;
                }
            }
        }
    }

    @Override
    public boolean requestChildRectangleOnScreen(View child, Rect rectangle,
        boolean immediate) {
        if ( !isInTouchMode() ) {
            for ( Entry<Integer, ViewAndIndex> entry : mViewsMap.entrySet() ) {
                int index = entry.getKey();
                ViewAndIndex vi = entry.getValue();
                View view = vi.view;

                if ( child == view
                    && ( index != mWhichChild || !mScroller.isFinished() ) ) {
                    setDisplayedChild(index);
                    break;
                }
            }
        }
        return false;
    }

    @Override
    protected boolean onRequestFocusInDescendants(int direction,
        Rect previouslyFocusedRect) {
        View screen;
        if ( mNextChild != INVALID_CHILD ) {
            screen = getViewAtRelativeIndex(mNextChild - mWhichChild
                + mActiveOffset);
        } else {
            screen = getCurrentView();
        }
        if ( screen != null ) {
            screen.requestFocus(direction, previouslyFocusedRect);
        }
        return false;
    }

    private void onSecondaryPointerUp(MotionEvent ev) {
        final int pointerIndex = ( ev.getAction() & MotionEvent.ACTION_POINTER_INDEX_MASK ) >> MotionEvent.ACTION_POINTER_INDEX_SHIFT;
        final int pointerId = ev.getPointerId(pointerIndex);
        if ( pointerId == mActivePointerId ) {
            final int newPointerIndex = pointerIndex == 0 ? 1 : 0;
            mTouchX = mLastMotionX = ev.getX(newPointerIndex);
            mLastMotionY = ev.getY(newPointerIndex);
            mActivePointerId = ev.getPointerId(newPointerIndex);
            if ( mVelTracker != null ) {
                mVelTracker.clear();
            }
        }
    }

    @Override
    public boolean onInterceptTouchEvent(MotionEvent ev) {
        int action = ev.getAction();
        if ( action == MotionEvent.ACTION_MOVE
            && mMotionAction != MotionEvent.ACTION_DOWN ) {
            return true;
        }

        switch ( action & MotionEvent.ACTION_MASK ) {
        case MotionEvent.ACTION_MOVE: {
            int pointerIndex = ev.findPointerIndex(mActivePointerId);
            float x = ev.getX(pointerIndex);
            float y = ev.getY(pointerIndex);
            int xDiff = (int) Math.abs(x - mLastMotionX);
            int yDiff = (int) Math.abs(y - mLastMotionY);

            if ( xDiff > mTouchSlop || yDiff > mTouchSlop ) {
                if ( xDiff > mLayoutTouchSlop ) {
                    mMotionAction = MotionEvent.ACTION_UP;
                    mLastMotionX = x;
                }
                if ( mAllowLongPress ) {
                    mAllowLongPress = false;
                    getCurrentView().cancelLongPress();
                }
            }
            break;
        }
        case MotionEvent.ACTION_DOWN: {
            mTouchX = mLastMotionX = ev.getX();
            mLastMotionY = ev.getY();
            mActivePointerId = ev.getPointerId(0);
            mAllowLongPress = true;
            if ( mScroller.isFinished() ) {
                mMotionAction = MotionEvent.ACTION_DOWN;
            } else {
                mMotionAction = MotionEvent.ACTION_UP;
            }
            break;
        }
        case MotionEvent.ACTION_UP:
        case MotionEvent.ACTION_CANCEL: {
            mMotionAction = MotionEvent.ACTION_DOWN;
            mAllowLongPress = false;
            mActivePointerId = INVALID_POINTER;
            break;
        }
        case MotionEvent.ACTION_POINTER_UP: {
            onSecondaryPointerUp(ev);
            break;
        }
        case MotionEvent.ACTION_OUTSIDE:
        case MotionEvent.ACTION_POINTER_DOWN:
        default: {
            break;
        }
        }

        return ( mMotionAction != MotionEvent.ACTION_DOWN );
    }

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        if ( mVelTracker == null ) {
            mVelTracker = VelocityTracker.obtain();
        }

        mVelTracker.addMovement(event);

        int action = event.getAction();

        switch ( action & MotionEvent.ACTION_MASK ) {
        case MotionEvent.ACTION_DOWN: {
            if ( !mScroller.isFinished() ) {
                mScroller.abortAnimation();
            }
            mTouchX = mLastMotionX = event.getX();
            mActivePointerId = event.getPointerId(0);
            break;
        }
        case MotionEvent.ACTION_MOVE: {
            if ( mMotionAction == MotionEvent.ACTION_UP ) {
                int pointerIndex = event.findPointerIndex(mActivePointerId);
                float x = event.getX(pointerIndex);
                int xDiff = (int) ( mLastMotionX - x );
                mLastMotionX = x;
                int scrollX = getScrollX();

                if ( xDiff < 0 ) {
                    if ( scrollX > 0 ) {
                        scrollBy(Math.max(-scrollX, xDiff), 0);
                    }
                } else if ( xDiff > 0 ) {
                    View lastChild;
                    if ( mCurrentWindowEnd == getWindowSize() - 1
                        && mViewsMap.containsKey(mCurrentWindowEnd)
                        && mViewsMap.get(mCurrentWindowEnd).index == mActiveOffset ) {
                        lastChild = getViewAtRelativeIndex(mActiveOffset);
                    } else {
                        lastChild = getViewAtRelativeIndex(mActiveOffset + 1);
                    }

                    scrollX = lastChild.getRight() - scrollX;
                    scrollX -= getWidth();
                    if ( scrollX > 0 ) {
                        scrollBy(Math.min(scrollX, xDiff), 0);
                    }
                } else {
                    awakenScrollBars();
                }
            }
            break;
        }
        case MotionEvent.ACTION_UP: {
            if ( mMotionAction == MotionEvent.ACTION_UP ) {
                int pointerIndex = event.findPointerIndex(mActivePointerId);
                float x = event.getX(pointerIndex);
                mVelTracker.computeCurrentVelocity(1000,
                    (float) mMaximumVelocity);
                int xVelocity = (int) mVelTracker.getXVelocity(mActivePointerId);
                boolean flingedEnough = ( Math.abs(mTouchX - x) > 100.0f );

                final int globalScrollX = mCurrentWindowStart * getWidth()
                    + getScrollX();

                int whichScreen = ( globalScrollX + getWidth() / 2 )
                    / getWidth();

                if ( flingedEnough && xVelocity > 500 && mWhichChild > 0 ) {
                    // Fling hard enough to move left.
                    // Don't fling across more than one screen at a time.
                    setDisplayedChild(Math.min(whichScreen, mWhichChild - 1));
                } else if ( flingedEnough && xVelocity < -500
                    && mWhichChild < getWindowSize() - 1 ) {
                    // Fling hard enough to move right
                    // Don't fling across more than one screen at a time.
                    setDisplayedChild(Math.max(whichScreen, mWhichChild + 1));
                } else {
                    setDisplayedChild( ( globalScrollX + getMeasuredWidth() / 2 )
                        / getMeasuredWidth());
                }

                if ( mVelTracker != null ) {
                    mVelTracker.recycle();
                    mVelTracker = null;
                }
            }
            mMotionAction = MotionEvent.ACTION_DOWN;
            mActivePointerId = INVALID_POINTER;
            break;
        }
        case MotionEvent.ACTION_CANCEL: {
            mMotionAction = MotionEvent.ACTION_DOWN;
            mActivePointerId = INVALID_POINTER;
            break;
        }
        case MotionEvent.ACTION_POINTER_UP: {
            onSecondaryPointerUp(event);
            break;
        }
        case MotionEvent.ACTION_OUTSIDE:
        case MotionEvent.ACTION_POINTER_DOWN:
        default: {
            break;
        }
        }

        return true;
    }

}

Controlling the LED Flashlight in Android

2011-05-03T18:14:00.004+08:00

Today my friend lzy asked me if I could help him by writing an Android app that controls the LED on Android devices. He needs this because he needs to do a demo of his customized LED driver to some vendor.

He needed an app that has 4 buttons: one that turns off the LED and the other three flashing the LED at different frequencies. It sounds like an easy task so I wrote it up quickly. The source code is released here.

The trick is to write to the file /sys/class/leds/flashlight/brightness.

Courage to Do What You Believe In

2011-04-29T15:48:00.006+08:00

Last night I was fortunate to have met a new friend at our weekly Hacking Thursday gathering. His name is Ben Lin.

He demoed his recent project called MacFlickr, which is a web client for browsing the popular photo service Flickr. What's special about his client is that the interface mimics that of a Mac desktop, but everything is chromed within the web browser and written in regular HTML/JavaScript. The interaction is so blazing fast that it can really fool you into thinking that you're in a native desktop environment if the browser is switched to full-screen mode. It wasn't until after he restored the browser window back to normal size had I realize that it was a web app! As a programmer I could immediately tell how much time and effort was spent on this project to make all the kinky details work elegantly like this.

That's not the end of the story though. He continued to share with us his background and how he came about ideas for this project. As a matter of fact he is not even a computer science major; he learned all about coding by himself simply because he had ideas that he wanted implemented but could not find programmers to help him materialize those ideas into a product. He started off by using OTS libraries to help him implement the UI effects. Iteration after iteration he would realize that some of these libraries don't always support 100% of what he needs, so he would go into the source code of these libraries to make major modifications that tailor to his own project needs. This is what we do on a daily basis as a free software programmer, but for someone without any programming background you can imagine how impressive that really is.

What I like the most about his story is that he quit an old, stable job to pursue his own entrepreneurial dream. His courage to do what he believes in and his determination to refine a product to near perfection are things that I will take home with and always remember. Thanks for the inspiration Ben!