RSS Feed
May 7

Introducing CallingProxy Pro – Automate Calls Like a Pro!

Posted on Tuesday, May 7, 2013 in User

It’s been a while since the last post. When I’m not running Wayne Enterprises (my day job), I have been mostly working on Gnucash for Android and CallingProxy Pro in the cave.

Today, I am announcing a brand new version of CallingProxy Pro for Android. The app enables you to automate call inputs by having call code presets which are automatically dialed for you either before, during or after your call.


In order to create your proxy numbers, all you need know is following

  • Commas (,) are for two-second pauses
  • Proxies must have an ‘N’ character (available on Android keypad) which will be replaced with the actual number you dial.
  • An example the proxy #33#N will dial #33#<number you called>.  
    Or if you want to dial a hotline and press 1 for English and 3 for tech support during the call, save the proxy as N,1,3.

CallingProxy Pro

New and improved features in the pro version include:

  • Support for infixes and suffixes in addition to prefixes
  • Download new proxies / Share your own proxies
  • Improved call log management
  • Contact searching support
  • New and Improved look using latest Android guidelines

You can download the app from the Google Play store

Feb 15

Help Your Users Localize your Android App

Posted on Friday, February 15, 2013 in Coding, User

In order to widen the reach of your app, it is necessary to localize it.This increases the desirability of the app with non-native speakers of your language.

Android comes with a resource framework which eases localization of strings in your application. Basically you provide a string resource file for each language with the strings represented by keys. Then in your code, you simply load the string by its key and Android takes care of using the correct string, based on the user’s device locale settings.

When you support only a few locales, it is ok to email the strings file back and forth for translation. However, as the number of supported locales grows, the emailing becomes more of a burden. Here I present some things I’ve learned through managing the 8+ different translations in Gnucash for Android.

Firstly, not all strings.xml files are created equal. Normally in your app, there are not only user interface strings, but also strings for many other non-user facing things like preference keys. These only need to be in the default res/values/strings.xml file since they are not meant to be translated. Android will still find the default strings irrespective of the user locale.

Doing this will also ease the work for your translators since they can simply translate everything in their strings.xml file without having to decide each time if it is a user-interface string or not.

Secondly, if your translators are developers themselves, then it is usually easy for them to send pull requests with translations. However, most of the time, the translators are just normal users of your app who are willing to help.

Asking them to clone/edit/push is a bit too much to ask. If your code is on GitHub, then you can easily have them issue pull requests without having to learn Git. You can do so as follows:

  1. Create the folder for the resource file and copy the strings.xml to the folder e.g. res/values-de/strings.xml for German (de) translations.
  2. Ask your translators to create a GitHub account and log in.
  3. Point your translators to the file which needs to be translated. Each language will have a slightly different link based on the locale code. For example, the German locale:
  4. If they are logged in, they should be able to see an “Edit” button at the top of the file. They can click this and then directly translate the strings in the browser. edit_strings
  5. When done, they can enter a description of their changes and click “Propose File Change” and the UI for creating a pull request comes up.


Then they click on “Send pull request” and you get the changes as a pull request which you can merge easily.


Your translators have basically accomplished cloning your project, creating a branch, editing and committing their changes, push their changes back upstream and issue a pull request. All without having to learn Git or opening a terminal. Usually there should be no conflicts in the merge since string translation usually comes after feature freeze.

There are some who decry the fact that GitHub basically wraps Git in such a way that it is unidentifiable. But I think there is an argument to be made for those who want to contribute to projects without having to learn technical nitty-gritty details (such as navigating the maze that is Git documentation).

Feb 7

Dear User, please push the “Report” button

Posted on Thursday, February 7, 2013 in Coding, User

One of the features provided by the Play Store on Android is the ability to report crashes to the developer when an app crashes. Whenever you are using an app which crashes, I know the tendency and easier thing to do is to dismiss the dialog and move on with your life. There are several reasons for this, some are too busy to report the error, others are worried about privacy, etc. That’s ok, but doesn’t really help anyone.

I want to shed some more light on what happens when you click that button. Android collects some information about the crash, things like the application version, your Android version, system state and the logs of the application just before it crashed and sends to the developer. You can also include a note if you wish (please do) describing what was happening when the crash occurred. This helps your developer to quickly fix this problem. Android also offers you the ability to review the information that will be sent before sending it.

As a developer, when you log in to the Google Play Developer console, you get to see a view like the one in the picture. There is little if any identifying information there, but the crash logs are invaluable for fixing bugs.


You might say instead of reporting, you could just file a new bug in the issue tracker. That’s also good, but often times, a bug is not easily reproducible on another device. In the case of Android, there are thousands of different devices out there and it is impossible to test for all. Including the crash report created by Android enables the developer to quickly  trace where the error is coming from on your device, even if he/she cannot reproduce it on his/her own device.

So dear User, the next time you think about dismissing the crash report, please think again. Sending that report will make life easier for the developer, and for you (as in the bug gets fixed faster) and everyone else.