FOSSASIA

In this Blog-Post, I will show how I made email-id case insensitive so that the open-event-server won’t allow multiple accounts with a single handle.

Previously, email ID was stored in the open-event-server database as raw string, i.e., case sensitive, so if a user entered the email with upper case alphabets, he/she needs to enter the same way during Auth, which could have lead to creation of multiple accounts with one email id and so is a major bug.  

Migration updation:

First, we need to handle the cases on the production database where people have made multiple accounts with a single handle because of this bug. For this, we need to write a complex SQL query, so let’s just make a new migration instead of updating the models.

def upgrade():  
      op.execute("UPDATE users SET deleted_at = current_timestamp, _email =      
   concat(_email, '_') where _email not in (SELECT DISTINCT ON (upper(_email)) _email 
   FROM users);", execution_options=None)

The nested query will return the list of all Emails which are not distinct on upper(_email). In simple words, the following query says: “Get the _email from users table where upper(_email) is distinct”. We want to delete the emails which are not returned in this query. For that, we set “deleted_at = current_timestamp” for those row. 

Make ‘_email’ column case insensitive:

We need to change the column data type to something that treats email as case-insensitive. That’s where “citext” comes into play. But we will still get an error on applying citext to “_email” column.

Any guesses why?

Remember we just updated “deleted_at” column of duplicate _email rows. So there still exists duplicate entries of emails in case we treat them case-insensitive, which defies the “_email” column rule to have unique entries defined in “user” Model. As it’s never a good idea to delete entries on the production database, we add a “_” to distinguish those email ids. 

Now the following lines will change the column type of “_email” to citext.

op.execute("create extension citext;", execution_options=None)

Now, we need  to write the opposite logic in case someone downgrades from the migration.

def downgrade():
    op.execute("alter table users alter column _email type     text;",execution_options=None)
    op.execute("UPDATE users SET deleted_at = null, _email = left(_email, length(_email)-1)        
    where right(_email, 1) = '_';",execution_options=None)
    op.execute("drop extension citext;",execution_options=None)

This will solve our bug, and won’t allow multiple accounts from the same handle.

Resources:

Issue: fossasia/open-event-server#5643
Pull Request : fossasia/open-event-server#5728
Documentation | Postgresql: https://www.postgresql.org/docs/current/sql-select.html#SQL-DISTINCT
Documentation | Citext: https://www.postgresql.org/docs/9.1/citext.html 

Whenever an application is created, it needs an “About Section” for people to know about who built the app. But a lot of about sections forget to give credit to the open-source libraries they use among other things. This blog post will describe how to create a good about section for an open-source android app, by making an example of the about section made in Badge Magic Android.

The about section is composed of multiple card views, each card view representing one section. The first card view contains the app icon along with some basic details of what the app does. Mention is made of the developers of the app by providing a link to the contributor’s page of the application. This is a really important part in order to give credit to the contributors of the app who helped build it. 

The proceeding section is another card view that gives additional information about the app. Here a link is provided to the GitHub repo of the app in order to help new contributors join and also help users report any issues they face with the app. Here, links to social media pages of the application such as Twitter, Facebook, etc can also be provided.

Then comes the last section, the one which generally gets missed out. Being an Open source application, the license of the application and the open-source libraries used should also be given credit. In this section, this is what is done. The license has been provided, which in this case is the Apache License 2.0. Then come the open-source dependencies. Since a lot of these are used in most open source apps, all cannot be mentioned in the card view itself. Here we use a special type of dialog, LisenceDialog to show all the dependencies the licenses used by these dependencies. To make use of the licenseDialog, just add the following line to the gradle of the app:

implementation ‘de.psdev.licensesdialog:licensesdialog:2.0.0’

Once this is done, dependencies can be added to the dialog in the form of notices. Each notice contains the name of the dependency, the link to where it is hosted and the license it uses. There is already a collection of all licenses provided included in the licencesDialog dependency and it just has to be called. For example, if the moshi dependency has to be shown in the dialog, it’s notice is added as follows:

Here are a couple of screenshots of how the About Section of Bade Magic looks like:

References:  

Licenses Dialog:   https://github.com/PSDev/LicensesDialog

Card view based layout: https://developer.android.com/guide/topics/ui/layout/cardview

Link to the pr in badge magic which added this feature: https://github.com/fossasia/badge-magic-android/pull/265

Tags:

Android, kotlin, badge magic, about, documentation, best practices, card view, license, open-source libraries, internship

How to manage your repository size and prevent it from getting too large? Sometimes the size of a repository can get too large. This was the case with the Phimp.me and PSLabs Android repositories, which kept the history of apk files for testing in the Git history.

Did you ever notice that your repository size keeps increasing? Like your application size might be small, but the size of the repository is too large? 

This can happen because of a large commit history. Whatever changes that are made to your repo are stored as history. This process of maintaining the history isn’t bad, but it does increase the size of the repo unnecessarily. This might create a problem for contributors who will have to download the bloated repo, while the actual size of the application might be quite small. Due to an enormous amount of contributions to the Phimp.me and PSLab  the repository, their size increased too much. The Phimp.me repo grew to a staggering 600+mb, while the application is just around 20mb. This creates problems for new contributors because to work on an application that is just 20mb, they have to spend more than half a GB of data. Not only new contributors but sometimes existing contributors might also have to clone the repo again and to do so they would have to waste a lot of time and data. Therefore, a repo must be maintained in such a way that the size is not much bigger than the application on which the work is to be done. 

To get the repo size back under control, we used a tool called bfg repo cleaner. The advantage of using this tool is that the commit history does not get erased, and all contributors get credit for the changes they made.

So the first step to do is to find the files in the git history which are causing the repo size to be increased. This can be done using a handy command given below: 

This command will give all the files comprising the git history in an order such that the files towards the last will the ones with the largest size. Here, you can see which large files are bloating the repo size. The files that are not being used any longer or are refreshed every time a change is made in the repo can be safely deleted. 

For example, let’s take Phimp.me into consideration. 

The files which were causing the increase in size were the redundant apk files, gradle files and old screenshots of the app that used to be in the readme but were not in use anymore. Using the above command, we got all these files and deleted them using bfg. 

You can download the bfg.jar file from here. Once this is done, to delete files and folders using bfg, the commands needed are:

To make your work easier, you can maintain bfg as an alias for java -jar bfg.jar.

Using this command deletes the required files. Once that is done, force push the changes to your repo. 

That’s it. This way you can easily maintain the size of your repo and keep deleting the extra files that cause a rrepo to bloat without erasing the commit history. 

Here is the link to the entire discussion of the issue on the Phimp.me project where you might find several other insights into the process especially while doing it for repos with android apps.

After doing the entire process, the size of Phimp.me was brought down to 27mb from 600mb. 

Resources

• 1) https://rtyley.github.io/bfg-repo-cleaner/
• 2) https://github.com/fossasia/phimpme-android/issues/2820

Tags: Android, Java, Phimpme, PSLabs Android, Repo size, git, history, repo cleaner, bfg, commit history