2014-08-13

The project-based environment

I've been tweaking the environment for my work, mostly programming, for years. I don't use any fancy IDE or desktop environment. Some of my co-workers use Citrix Client and this is actually recommended by our IT department. But, considering the just acceptable performance of connecting to remote sever, I am much more inclined to use terminal and switch to Citrix if I need to use any GUI application.

It is common that a company need to maintain several versions of a product for years and programmers need to port changes to different branches. Sometimes, a programmer need to run same experiment on different version to observe behavior or performance differences. It would be much safer if these runs are separated by different terminals even at the same machine.

The workspace-based flow is probably the most suitable one I've found. My configuration is pretty simple but effective. It's based on screen/tmux/emacs and submitted on GitHub. 

Check it out on Workspace-based configuration


2012-02-04

Implement an AppWidget for BozaAlarm - Part I: Limitation

Today, I released BozaAlarm v4.10 to the Android Market. What's new in this version is the simple AppWidget to display the next enabled alarm.


Here, I'd like to talk about how I implemented this simple widget. Before I go too far, you probably need to take a look at least these two topics,

  1. AppWidgetProvider
  2. App Widget Design Guidelines
Just as I said before, there are some limitations in App Widget design and understand these should save you some time.

Basically, the Launcher process hosts AppWidgetHostView for each App Widget and talk with your process through RPC calls. You can image there are many RPC (binder) calls between Launcher and your process. That's why you will use RemoteViews to package your update actions in your process and apply them on the App Widget on the Launcher side. In fact, the RemoteViews is implemented as Command pattern in software terminology.

Now, you can imagine why AppWidget design is so restricted.

Moreover, because it's always unsafe to load classes from other process in a process, you're not allowed to use custom classes in your widget layout. Only built-in widget classes can be used in your layout xml file and only methods tagged by RemotableMethod in these classes are allowed.

Experiment the Tips for reducing APK file size

I came across this article: Tips for reducing APK file size at SonyEricsson Developer blog. Among them, the one I am aware of is the PNG file optimization. So, I took some time to experiment it.

First, I downloaded the GUI wrapper of command-line optimizer ImageOptim and optimize the PNG files at res/ directory. According to the result, it reduce total file size from 748K bytes to 700K bytes.

Second, I recompile the release binary of my application. But, the size of APK file remains the same as the one w/o PNG optimization.

Hmm. I repeated this process some times to make sure I didn't miss some important steps. While I was wondering, I noticed some messages spewed out during compilation like,
  [crunch] Processing image to cache: /Users/yenliangl/Work/Android/bozaalarm-android/res/drawable-hdpi/handler_app.png => /Users/yenliangl/Work/Android/bozaalarm-android/bin/res/drawable-hdpi/handler_app.png
Looks like PNG optimization has been included in the standard Android tool v14??

This should confirm my guess. From official site of Android tool, it says that in revision 14, aapt optimizes PNG during compilation.

png processing in aapt.
When aapt packages the resources, its main goal is to compile the XML to binary format and to create a resource table with all the resource values (string, color, ids, etc...). Additionally, it processes the png files to optimize them (for instance, pre-processing of 9-patches).
Because the aapt process is not incremental, this means every build goes through all png files and processes them always. For large projects with numerous (and/or large) png this process could take a long time.
Revision 14 now processes the png files outside of the aapt packaging step and caches them. Only modified png files are re-processed.