March 2017 update

Lots of new stuff in the app recently!

version 2.0

We finally released v2.0 of the app, after one and a half years in v1.x! ūüôā It felt appropriate, given that the app has changed considerably from the early version 1s, and has diverged quite a bit from the original legacy app.

Beta testing

With over 2000 active installs, we decided that we should migrate to using a beta version for testing new releases, rather than pushing directly to production and hoping for the best. Opt in at

Notification if picture is a duplicate 

As requested on the Commons village pump, we implemented a check to see if the exact same image already exists in the Commons database, in order to prevent unintentional duplicate uploads. This was done by checking for similar SHA1 hashcodes using this API


Updated licenses and added option to select them in upload screen

Users can now select their licenses directly from the upload screen instead of just via Settings! This has been implemented via a drop-down menu underneath the title and description fields. CC-BY-4.0 and CC-BY-SA-4.0 have also been added to the available licenses to choose from.

New and improved UI

The UI has received an update, and is now in line with Material design guidelines. Also, a light theme has been added, which is more suited for daytime use. This can be accessed via Settings as shown below.

Updated Google Play store listing

Our Google Play store listing has received an overhaul, with a new description and new screenshots that reflect the current state of the app.

New volunteers

We would like to welcome first-time contributors Aditi Bhatnagar, Veyndan Stuart, Vivek Maskara,¬†and Neslihan Turan on board! ūüôā Many of the recent improvements in the app have been thanks to them.

New volunteers are always welcome. Join us at

Prague pre-hackathon and Vienna hackathon

We will be sending a team to the Wikimedia Hackathon Vienna to work on improving the Nearby function of the app, and development will start during the Prague Pre-Hackathon that Wikimedia Czech Republic has kindly organized for us. More details in our discussion thread.

March 2017 update

IEG Update (October)

Things have been pretty crazy lately. I’ve been scheduled for dental surgery, and will likely be moving to Australia in a couple months’ time, with all the necessary preparations yet to be made! On the bright side, an exciting new development for the app – a few folks have expressed interest in coming together to work¬†on new features for the app during the¬†Vienna hackathon next year, so we’ve been trying to make that happen.

3 new features in the app:

Option to copy title and description from previous upload (#65). A button was added to allow users to use the same title and desc as the previous upload, to make it more convenient for people who upload several images of the same topic consecutively.


Suggest categories based on entered title (#43). In addition to suggestions for recent categories and nearby categories, we have added a new type of suggestion: title-based categories. A search is performed for categories matching the title that the user has entered for the image, via asynchronous queries to the Commons MediaWiki API. This is the same API call used for the category search tool.

An issue with this implementation is that it is subject to the same limitations as¬†the category search tool. For instance, it works well for simple titles such as “pancakes”. However, if someone titles their image “Nintendo sign at Tokyo branch in Taito”, it searches for that exact string instead of searching for “Nintendo”, “sign”, “Tokyo”, “branch” and “Taito”. This issue has been documented at #306. Solving it would likely require substantial language processing capabilities (splitting into words, extracting keywords, etc), so it will have to be left for future work.


Filter out year categories (#47).¬†Categories such as”X in 2006″ are very unlikely to be appropriate, so¬†we have filtered out categories containing 4-digit numbers¬†starting with ’19’ and ’20’ from all category suggestions. An exception is made for categories containing the current year or previous year. E.g. if a user searches for “Burning Man”, he¬†should¬†see a suggestion for ‘Burning Man 2015’ but not ‘Burning Man 2005′. The rationale for this design choice is that people are unlikely to store more than 2 years’ worth of pictures in their phone. So if someone has pictures of Burning Man on their phone, it is likely to be for the 2015 or 2016 event, not for 2005 etc.

We are open towards the possibility of use cases that we have not thought of, though, so please feel free to chime in in GitHub issue if you disagree with our rationale.

IEG Update (October)

List of bugs fixed (Phase 1)

This post contains a running list of bugs fixed and Google Play releases of the app, for Phase 1 (Fix existing bugs/crashes) of my IEG project.







List of bugs fixed (Phase 1)

A new chapter begins: IEG

My IEG proposal has been selected for this round! ūüôā I’ll be spending the next 6 months working on the ‘Upload to Commons’ Android app, and I’m absolutely psyched. It’s been announced on the official Wikimedia blog as well (woohoo!). I marvel at how it seems like not so long ago that I was downloading the GitHub client¬†for the first time and trying to figure out the whole collaborative open source thing… I wouldn’t be here if it weren’t for Outreachy and my two amazing mentors. Mentored internships are awesomesauce. Srsly. It’s never too late to do one.

In other news, the ‘Upload to Commons’ app is now known as the ‘Wikimedia Commons’ app! Yes, we’ve been authorized by Wikimedia Foundation to use their trademark Commons logo and name, contract has been signed and all that. There was a little snag with the app being suspended while we tried to get the contract to Google, but that should all be sorted now. Hopefully.

We also had our first new collaborator on our GitHub repo in a long time, and he’s done some really awesome stuff, including helping us migrate our project to Gradle (using Maven with outdated dependencies on Android Studio was a huuuuge pain in the butt). Welcome, Adam Jones!

Will probably try to update more often, with my IEG project starting and all. Stay tuned! ūüôā

A new chapter begins: IEG

Three cheers for Outreachy!

Outreachy’s goal is to encourage more people to get involved with FOSS – and I think they’ve succeeded in my case! I’ve always identified with the¬†ethos and ideology of FOSS, have always wanted to contribute, but was previously too intimidated to get involved. Plus, lets be honest – starting out is always one of the most difficult parts, starting out without a mentor is harder, and starting out without a mentor while simultaneously juggling a day job even more so.

While I can’t say that Outreachy inspired my interest in FOSS (I’ve always been interested), they’ve provided a clearer and easier¬†path to get involved by alleviating the other two issues – mentors and finances. Having the opportunity to get paid to work on FOSS full-time while being guided¬†by experienced FOSS contributors¬†has been absolutely fantastic, and has helped me get over the starting-out hump. Thank you, Marina and everyone else behind Outreachy. ūüôā

So…. what next?

I’m still unsure as to where I’ll go from here with regards to FOSS. Being able to continue working on FOSS (and with Wikimedia) as a job would be amazing. Wikimedia offers Individual Engagement Grants for people who want to undertake a project to improve various aspects of it, so I’ve submitted a proposal for the next IEG round. It’s a bit of a far-reaching goal – I’m not a long-time contributor and I haven’t received too many endorsements on my proposal yet – but it’s a goal all the same. ūüôā

Three cheers for Outreachy!

Guide: Applying to Wikimedia for Outreachy/GSoC

Applications for this round’s GSoC and Outreachy programmes are in full swing, with the associated flurry of activity. Yay, the community grows! ūüėÄ

I did my Outreachy project with Wikimedia, which turned out to be an excellent choice for me. IMO, working on a project that you actually use in your personal time is a huge advantage – you’re constantly motivated by seeing the improvements¬†you make being used by other people… and yourself.

That being said, I won’t lie, the application process for Wikimedia is a bit more complicated than that of some other organizations (albeit very¬†thoroughly¬†documented). There are several additional requirements, and if you are new to everything it might feel slightly overwhelming. But do not worry! This little guide is for you, from one newbie to another. ūüôā

(Disclaimer: This is a rough guide based on my personal experiences in the Dec ’15 – Mar ’16 Outreachy round, and do not reflect the views of Wikimedia Foundation. Also, there may¬†be differences with GSoC that I am not aware of, but AFAIK the two have an extremely similar application process. Also, this is not intended to be an exhaustive guide, but rather to highlight the Wikimedia-specific requirements that are not covered much in the GSoC/Outreachy guidelines.)

Getting started

Essential reading: Life of a successful project. You will be referring to this page multiple times during the process of your application and internship.

Phabricator is the lifeblood of technical collaboration in Wikimedia. Everything on Phabricator is a ‘task’ – the project task you pick, the proposal task you will make, the reports you will write later on. Tasks are associated with project boards which are essentially ‘groups’ of tasks – for instance, this is the GSoC 2016 board.

Finding a project and mentors

There are 2 main options for finding your project:

The “Featured project ideas” column on the GSoC or Outreachy project board contains the project tasks that are ready for you to choose – they have been approved by the community and have 2 mentors ready for it. This is the easier route.

Another option is to scour Possible-Tech-Projects¬†for projects that may or may not be ‘ready’ yet. This is a viable option but involves more effort and risk – you will also be responsible for finding your own 2 mentors (yes, 2 are usually required by Wikimedia, the lead mentor and a co-mentor). This is¬†the route I took, because there was a particular project that I really wanted to do that was not featured yet.

Complete your microtask

This step is similar with Outreachy or GSoC’s requirements and varies widely depending on the project you chose, so there isn’t much to elaborate on.

Drafting your proposal

GSoC/Outreachy has its own application template, but your Wikimedia proposal is a separate requirement. Create a Phabricator task – this will be your proposal task –¬†and follow the template stated.¬†Some of the questions will overlap with your GSoC/Outreachy application, copy/pasting between the two is¬†okay. Associate your proposal task with the project task.

As far as I know, only one intern can be accepted for one project. The selection process is described here, along with the criteria used for selection. From my observation, the thoroughness and quality of your proposal matters a lot, so it is worth putting some thought and time into a good proposal. You also need to have fulfilled programme-specific requirements, such as not having too heavy a university load during the 3 months of the internship for Outreachy.

By the application deadline, your proposal should be mostly complete and residing in the ‘Proposals Submitted’ column of your project board¬†and¬†you should have at least one microtask completed.


The mentors for each project task will select their preferred candidate and there will be a discussion with the organization admins to determine the selections. However, GSoC or Outreachy admins also have the right to reject applicants who do not fulfill various programme-specific requirements.

Community bonding period

Hooray, you got accepted! Congratulations. There will be a community bonding period during the week prior to the start of your internship; more on that here. The community bonding period is fairly time-consuming, so you would ideally not have full-time commitments during that week as well.


All the best folks!

Guide: Applying to Wikimedia for Outreachy/GSoC

Parcels (the Android variety)

Been reading up on Parcelable objects, as contains the nested class

public static class CategoryItem implements Parcelable {
        public String name;
        public boolean selected;

        public static Creator<CategoryItem> CREATOR = new Creator<CategoryItem>() {
            public CategoryItem createFromParcel(Parcel parcel) {
                return new CategoryItem(parcel);

            public CategoryItem[] newArray(int i) {
                return new CategoryItem[0];

        public CategoryItem(String name, boolean selected) {
   = name;
            this.selected = selected;

        public CategoryItem(Parcel in) {
            name = in.readString();
            selected = in.readInt() == 1;

        public int describeContents() {
            return 0;

        public void writeToParcel(Parcel parcel, int flags) {
            parcel.writeInt(selected ? 1 : 0);

I found myself unfamiliar with the Parcelable interface, but fortunately I found a helpful tutorial at which states:

Due to Android’s memory management scheme, you will often find yourself needing to communicate with different components of your application, system components, or other applications installed on the phone. Parcelable will help you pass data between these components.

Android uses Binder to facilitate such communication in a highly optimized way. The Binder communicates with Parcels, which is a message container. The Binder marshals the Parcel to be sent, sends and receives it, and then unmarshals it on the other side to reconstruct a copy of the original Parcel.

To allow for your class instances to be sent as a Parcel you must implement the Parcelable interface along with a static field called CREATOR, which itself requires a special constructor in your class.

The article also explains, in detail, the template used to create Parcels. An interesting point of note in the article is that there is a Parcelable plugin for IntelliJ that generates the template for this as well!

So it seems that the CategoryItem nested class in our app is basically a container to pass along the ‘name’ and ‘selected status’ vars to an Adapter that populates the ListView when displaying category suggestions that the user can tick to select, as so:


Also, just realized that the reason the boolean var ‘selected’ is handled so strangely in our writeToParcel() method is that apparently there is no simple way to write a boolean to a Parcel, hence the need for the workaround.

The other method of passing objects between components is using Serializable, which according to is about 10x slower.

Parcels (the Android variety)