FOSSASIA Summit 2020 Takes Places as Online and Offline Event

Due to the Corona crisis it is clear that events like the FOSSASIA Summit cannot be run in the usual way with large crowds. Therefore this year the FOSSASIA Summit will only be possible as a smaller gathering with social distancing in Singapore and online interactions from Thursday, March 19 – Saturday, March 21. 

Even with travel restrictions in place a number of speakers are in Singapore and expressed their wish sharing their knowledge and the FOSSASIA team is working hard to facilitate this in a safe space offline and online. Due to ongoing changes we will conduct the event with both unscheduled and scheduled sessions. The program will be updated continuously here.

The Lifelong Learning Institute, our host and co-organizer, adjusted the venue to ensure the safety and health of all. To participate on-premise you need to pass a screening test and follow directions for hygiene measures. The sign up is here

Singapore has an outstanding record seen internationally as a gold standard when it comes to cleanliness, hygiene and health. Additional measures in the LLI include providing entrance screening tests, social distancing, using open spaces, reducing the use of mics and mic disinfection, avoiding close group photos. Please find a list of measures here.

The events of our time show more than ever that we need to collaborate to solve the world’s problems such as climate change, global health issues, poverty and economic challenges. The FOSS/Open Source community has proven that we are able to overcome differences and work together across countries and cultures. It is important that we stay connected and continue our work be it offline or online. To connect virtually during the FOSSASIA Summit you can join us on these channels:

We will share more details about sessions in the upcoming days. Furthermore, we are planning additional online events at a later time this year. Let’s continue and build a better world through learning and sharing where-ever and however we can!

We would like to thank everyone who supported us throughout these challenges around the event – our speakers, friends, supporters, and partners like Google, Facebook, Arm, and Elastic.

We hope to stay connected. All the best and stay healthy!

FOSSASIA Presentations
FOSSASIA Videographers
Continue ReadingFOSSASIA Summit 2020 Takes Places as Online and Offline Event

Announcing the FOSSASIA Codeheat Winners 2019/20

We are very happy to announce our Grand Prize Winners and Finalist Winners of Codeheat 2019/2020.

Codeheat participants solved a stunning number of issues in FOSSASIA’s projects, reviewed pull requests, shared scrums, and wrote blog posts, but most importantly they encouraged and helped each other and collaborated across borders and cultures. More than 800 developers from 19 countries participated in the contest supported by more than 30 mentors. Over 2000 pull requests were merged. Thank you all for this amazing achievement!

With so many excellent developers participating it was extremely difficult to decide the Grand Prize and Finalist Winners of the contest. Our winners stand out in particular as they contributed to FOSSASIA projects on a continuously high level following our Best Practices.

Each of the Grand Prize Winners is awarded a travel grant to join us at the FOSSASIA Summit in Singapore in March where they receive the official Codeheat award, and meet with mentors and FOSSASIA developers. Other Finalist Winners will receive travel support vouchers to go to a Free and Open Source Software event of their choice.

Congratulations to our Grand Prize Winners, Finalist Winners, and all of the participants who spent the last few of months learning, sharing and contributing to Free and Open Source Projects. Well-done! We are truly impressed by your work, your progress and advancement. The winners are (in alphabetical order):

Grand Prize Winners

Kush Trivedi
Prateek Jain
Suneet Srivastava

Finalist Winners

A.Dilshaad
Dheeraj Kotwani
Nitin Kumar
Pulkit Kashyap
Robin Singh
Sundaram Dubey
Shantnu Kumar

About Codeheat

Codeheat is an online coding contest organized by FOSSASIA and OpnTec annually from September to February since 2016. Grand prize winners are invited to present their work at the FOSSASIA OpenTechSummit in Singapore every March and receive travel funding to attend. Mentors and the Codeheat jury choose three winners from the top 10 contributors according to code quality and relevance of commits for the project. The jury also takes other contributions like submitted scrum reports and technical blog posts into account. Other participants have the chance to win Tshirts, Swag and vouchers to attend Open Tech events in their region and get certificates of participation.

Thank you Mentors and Supporters

Our mentors and many project developers, the heart and soul of Codeheat, are the reason the contest thrives. Mentors volunteer their time to help participants become open source contributors. Mentors spend hundreds of hours during answering questions, reviewing submitted code, and welcoming the new developers to project. Codeheat would not be possible without their patience and tireless efforts. Learn more about this year’s mentors on the Codeheat website.

Certificate of Participation

Participating developers, mentors and the FOSSASIA admin team learnt so much and it was an amazing and enriching experience and we believe the learnings are the main take-away of the program. We hope to see everyone continuing their contributions, sharing what they have learnt with others and to seize the opportunity to develop their code profile with FOSSASIA. We want to work together with the Open Tech community to improve people’s lives and create a better world for all. As a participating developer or mentor, you will receive your certificate over the upcoming weeks. Thank you!

More Links

Continue ReadingAnnouncing the FOSSASIA Codeheat Winners 2019/20

FOSSASIA Confirms Annual Summit Takes Place from March 19-21 + DevSprints on March 22 at Lifelong Learning Institute in Singapore

We are glad to announce that the annual FOSSASIA Summit will take place from 19-21 March and the DevSprints on March 22, 2020 at the Lifelong Learning Institute (LLI) in Singapore after official meetings confirming that relevant measures are put in place to ensure the health and safety after the Covid-19 crisis.

Singapore has been widely praised in the International community for preventing the spread of the virus, a Harvard study hails the country as a gold standard for case detection. 

The FOSSASIA organization and LLI are following all recommendations of the Ministry of Health and taking necessary measures throughout the event. These include among others: Carrying out temperature screening for all attendees, providing health information on each day, adding prominent notices at entrances about hygiene measures, that are put in place throughout the venue, offering excellent bathroom and hand washing facilities, providing free disinfectants, increasing the frequency of cleaning of commonly used areas and more. 

Everyone can help to prevent the spread by following hygiene measures and regularly washing hands. The FAQ of the ministry of health is a good starting point to learn more about the virus and how Singapore is stopping its spreading.

The FOSSASIA Summit program will be online next week. We are happy that we are able to run the event with the help of the Lifelong Learning Institute and we cannot wait to see you in Singapore! 

Global issues, pollution, the threat of climate change, new illnesses, lack of education and poverty show more than ever that it is vital that we all work together to save the planet. Only through open collaboration and sharing can we solve the problems of the world. We need to meet and share our experiences. Events like the FOSSASIA Summit are an important platform. Rest assured we are taking all necessary steps to ensure the continued health and safety of all participants at the event.

More information on the FOSSASIA Summit 2020 is here.

Please check out a list of confirmed speakers and sessions.

Communities interested in running a DevSprint on Sunday, March 22 can still register here.

See you in Singapore!

Continue ReadingFOSSASIA Confirms Annual Summit Takes Place from March 19-21 + DevSprints on March 22 at Lifelong Learning Institute in Singapore
Read more about the article Introducing MVVM (Model-View-ViewModel) Architecture in Phimpme Android App
Introducing MVVM in Phimpme

Introducing MVVM (Model-View-ViewModel) Architecture in Phimpme Android App

Phimpme Android App an image editor app that aims to replace proprietary photographing and image apps on smartphones. It offers features such as taking photos, adding filters, editing images and uploading them to social networks. The app was using MVP(Model-View-Presenter) architecture and is now being ported to MVVM(Model-View-ViewModel) architecture.

Advantages of MVVM over MVP?

  1. The view model is lifecycle aware and only updates the UI based on the lifecycle of the activity/fragment.
  2. Separation of concerns – Not all the code under one single activity
  3. Loose coupling – Activity depends on ViewModel and ViewModel depends on the Repository and not the other way around.

MVVM?

  1. Model – Model represents the data and business logic of the app. The repository can be seen as a model in an MVVM architecture which contains login to fetch the data from an API or a remote API
  2. ViewModel – The view model creates a reference with Model/Repository and gets the data for the UI. It delivers the data to UI via observers of LiveData and also the ViewModel is lifecycle aware and respects the lifecycle of the activity such as screen rotations that don’t cause the ViewModel to be created again.
  3. View – The Activity/Fragment is the view where the data is shown to the user, the View creates a reference to the ViewModel via ViewModel provider class. Hence it listens to the ViewModel callbacks via LiveData.

Process for inclusion

  1. Add ViewModel and LiveData

    implementation "androidx.lifecycle:lifecycle-extensions:$rootProject.lifecycleVersion"

  2. Now create a class AccountViewModel – it will perform all the functioning that will drive the UI of the Account Activity. We will use LiveData for observing the data in the activity

    public class AccountViewModel extends ViewModel {
    private AccountRepository accountRepository

    = new AccountRepository();
    MutableLiveData<RealmQuery<AccountDatabase>>accountDetails = new MutableLiveData<>();//live data 

    }

  3. Create a class AccountRepository – Used to perform the DB related operations and the ViewModel will hold the instance of this repository.

    class AccountRepository {
    private Realm realm = Realm.getDefaultInstance();
    private DatabaseHelper databaseHelper = new DatabaseHelper(realm);// Fetches the details of all accounts present in database
    RealmQuery<AccountDatabase> fetchAllAccounts() {
    return databaseHelper.fetchAccountDetails();
     }
    }


  4. Now we will add the functionality in AccountViewModel to fetch accounts for the UI

    public class AccountViewModel extends ViewModel {
     final int RESULT_OK = 1;
    private AccountRepository accountRepository = new AccountRepository();
    MutableLiveData<Boolean> error = new MutableLiveData<>();
    MutableLiveData<RealmQuery<AccountDatabase>> accountDetails = new MutableLiveData<>();
    public AccountViewModel() {}
    // Used to fetch all the current logged in accounts
    void fetchAccountDetails() {
       RealmQuery<AccountDatabase> accountDetails = accountRepository.fetchAllAccounts();
    if (accountDetails.findAll().size() > 0) {
         this.accountDetails.postValue(accountDetails);
    } else {
     error.postValue(true);
    }
    }


  5. Now in the AccountActivity, we will have the reference of ViewModel and then observe the liveData error and accountDetails

    public class AccountActivity extends ThemedActivityimplements RecyclerItemClickListner.OnItemClickListener {

    private AccountViewModel accountViewModel;

    @Override
    public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    ButterKnife.bind(this);
    ActivitySwitchHelper.setContext(this);
    setSupportActionBar(toolbar);
    //fetching the viewmodel from ViewModelProviders
    accountViewModel = ViewModelProviders.of(this).get(AccountViewModel.class);
    initObserver();
    }

    private void initObserver() {
    accountViewModel.error.observe(this, value -> {
    if (value) {
     SnackBarHandler.create(coordinatorLayout, getString(no_account_signed_in)).show();
    showComplete();
    }
     });
    accountViewModel.accountDetails.observe(this, this::setUpAdapter);
    }


Hence, this completes the implementation of MVVM Architecture in the Phimpme app.

Resources 

  1. Guide to App Architecture – Android Developers Blog
  2. ViewModel Overview – Android Developers Blog
  3. LiveData Overview – Android Developers Blog

Link to the Issue: https://github.com/fossasia/phimpme-android/issues/2889
Link to the PR: https://github.com/fossasia/phimpme-android/pull/2890

Continue ReadingIntroducing MVVM (Model-View-ViewModel) Architecture in Phimpme Android App

Making Email IDs Case Insensitive

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 


Continue ReadingMaking Email IDs Case Insensitive

Adding an option to hide map in browse events.

Open Event provides filtering while browsing events. These filters are present in a sidebar which also consists of a map. In this blog, I will describe how I implemented the feature to toggle the visibility of the map present in sidebar for mobile devices.

About the issue

This issue was part of improvements decided for the browse events section. Earlier the map in sidebar was shown irrespective of the user’s device. It is essentially not required to always show the map in mobile device and is a better choice to provide user with an option to view or hide the map.

Sidebar as viewed from an android device before the fix was merged.

The Solution

A button is introduced in the mobile view which controls if the map should be visible or hidden. In the sidebar component (app/components/explore/side-bar.js), a variable “isMapVisible” which decides if the map should be visible (if it is true) or not (if it is false) at a particular instant. A new action “toggleMap” is written which changes the value of “isMapVisible” whenever the button is clicked.

isMapVisible = true;
@action
  toggleMap() {
    this.toggleProperty(‘isMapVisible’);
  }

In the handlebar file (app/templates/components/explore/side-bar.hbs), the map and associated text is changed as per the truthy or falsy value of the “isMapVisible” in the component.

<div class=”map item {{if (not isMapVisible) ‘mobile hidden’}}”>

{{#if device.isMobile}}
  <div class=”ui bottom attached button” role=”button” {{action ‘toggleMap’}}> {{if (not isMapVisible) ‘Show’ ‘Hide’}} Map </div>
{{/if}}

After making the changes, the sidebar looks as follows on the mobile devices

The above images are from an Android device.

Resources:

Issue: https://github.com/fossasia/open-event-frontend/issues/3122
Pull Request: https://github.com/fossasia/open-event-frontend/pull/3444

Ember Docs:https://guides.emberjs.com/v2.14.0/tutorial/simple-component/Toggle Component Tutorial: https://www.learnhowtoprogram.com/ember-js/ember-js/components-hide-show-image

Continue ReadingAdding an option to hide map in browse events.

Addition of new filters for event search

Open Event has an event search provided but it lacked two of the userful filters which will make searching for an event for a user easier than the current ecosystem. In this blog post, I describe how I implemented filtering of events on the basis of CFP status and Ticket Type.

About the issue

Addition of these two filters were subparts of improving the browse events page better. The browse events page currently functions in an optimal way but these improvements make it even better.

How the filters are added

For adding these two filters, it was required that the request sent to server to filter the event must contain ticket type and cfp so that the results from the server can be received. To achieve this, the frontend code needed the following changes:

  1. Passing of request variable into sidebar component present in app/templates/explore.hbs and addition of a clear filter for the same in the same file.e startDate=start_date endDate=end_date location=location ticket_type=ticket_type}
{{explore/side-bar model=model category=category sub_category=sub_category event_type=event_type startDate=start_date endDate=end_date location=location ticket_type=ticket_type}}
{{#if filters.ticket_type}}
  <div class=”ui mini label”>
    {{ticket_type}}
    <a role=”button” {{action ‘clearFilter’ ‘ticket_type’}}>
      <i class=”icon close”></i>
    </a>
  </div>
{{/if}}
  1. Adding UI for both the filters in app/templates/components/explore/side-bar.hbs. Accordion UI is used to achieve this.
  <div class=”item”>
    {{#ui-accordion}}
      <span class=”title”>
        <i class=”dropdown icon”></i>
        {{t ‘Ticket Type’ }}
      </span>
      <div class=”content menu”>
        <a href=”#”
          class=”link item {{if (eq ticket_type ‘free’) ‘active’}}”
          {{action ‘selectTicketType’ ‘free’}}>
          {{t ‘Free’}}
        </a>
        <a href=”#”
          class=”link item {{if (eq ticket_type ‘paid’) ‘active’}}”
          {{action ‘selectTicketType’ ‘paid’}}>
          {{t ‘Paid’}}
        </a>
      </div>
    {{/ui-accordion}}
  </div>
  1. Editing the routes (app/routes/explore.js) to make sure if the request has new filter parameter then it should be sent to server.
if (params.ticket_type) {
      filterOptions.push({
        name : ‘tickets’,
        op   : ‘any’,
        val  : {
          name : ‘type’,
          op   : ‘eq’,
          val  : params.ticket_type
        }
      });
    }
  1. Addition of new request parameter in the controller (app/controllers/explore.js)
queryParams  : [‘category’, ‘sub_category’, ‘event_type’, ‘start_date’, ‘end_date’, ‘location’, ‘ticket_type’],

ticket_type  : null,

if (filterType === ‘ticket_type’) {  this.set(‘ticket_type’, null);
}
  1. Editing the sidebar component to set the value of request parameter when the user interacts with the filter.
hideClearFilters: computed(‘category’, ‘sub_category’, ‘event_type’, ‘startDate’, ‘endDate’, ‘location’, ‘ticket_type’, function() {
    return !(this.category || this.sub_category || this.event_type || this.startDate || this.endDate || this.location || this.ticket_type !== null);
}),

selectTicketType(ticketType) {
  this.set(‘ticket_type’, ticketType === this.ticket_type ? null : ticketType);
},

this.set(‘ticket_type’, null);

Sidebar after the addition of filters.

Resources:

Issue: https://github.com/fossasia/open-event-frontend/issues/3098
Pull Requests:

Ticket Type: https://github.com/fossasia/open-event-frontend/pull/3158
CFS: https://github.com/fossasia/open-event-frontend/pull/3144

Specifying Query Params: https://guides.emberjs.com/release/routing/query-params/

UI Resources for the feature: https://semantic-org.github.io/Semantic-UI-Ember/#/modules/accordion

Continue ReadingAddition of new filters for event search

Making an About Section for Badge Magic Android App

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:

val notices = Notice()

notices.addNotice(
Notice(
context?.getString(R.string.moshi),

context?.getString(R.string.moshi_github_link),
context?.getString(R.string.moshi_copy),
ApacheSoftwareLicense20()
)
)

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

Continue ReadingMaking an About Section for Badge Magic Android App

Managing Repository Size of the Phimp.me Android App

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: 

git rev-list –objects –all | git cat-file –batch-check=’%(objecttype) %(objectname) %(objectsize) %(rest)’ | sed -n ‘s/^blob //p’ | sort –numeric-sort –key=2 | cut -c 1-12,41- | numfmt –field=2 –to=iec-i –suffix=B –padding=7 –round=nearest

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:

java -jar bfg.jar –delete-files <file name>java -jar bfg.jar –delete-folders <folder name>

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. 

git clone https://github.com/fossasia/phimpme-android
Cloning into ‘phimpme-android’…
remote: Enumerating objects: 6304, done.
remote: Counting objects: 100% (6304/6304), done.
remote: Compressing objects: 100% (4674/4674), done.
remote: Total 23695 (delta 4285), reused 3539 (delta 1622), pack-reused 17391
Receiving objects: 100% (23695/23695), 27.10 MiB | 6.19 MiB/s, done.
Resolving deltas: 100% (14248/14248), done.

Resources

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

Continue ReadingManaging Repository Size of the Phimp.me Android App

Fixing Notification Services Across EventYay

In this Blog-Post, I will show you, the fixing of multiple notification messages getting sent on multiple clicks or display of multiple messages for a single response.

What Caused the Problem?

In our Open Event Frontend, We are using Ember Notify Services to inject notification across the web app to show the notifications. Due to improper error handling on the client side sometimes we get multiple notification messages for a single click or for a single action. As shown in this picture.

How Did we Tackle It ?

Since the following issue was long pertaining, I solved the issue by adding a unique ID to each notification injected through the webapp. Since a unique ID was associated with each notification message, A single notification was getting displayed on each and every action irrespective of number of clicks or number of actions called. If an actions caused two notification to be simultaneously triggered, One of them on the basis of ID is suppressed so that a unique and understandable notification get shown.

Code Snippet:

Before the changes:

.then(() => {
          if (state === 'draft') {
            this.notify.success(this.l10n.t('Your event has been published successfully.'));
          } else {
            this.notify.success(this.l10n.t('Your event has been unpublished.'));
          }

After the changes:

this.notify.success(this.isNewInvite ? this.l10n.t('Role Invite sent successfully') : this.l10n.t('Role Invite updated successfully'), {
            id: 'man_role'
          });
        })
        .catch(() => {
          this.notify.error(this.l10n.t('Oops something went wrong. Please try again'), {
            id: 'man_role_error'
          });
        })

Pull Request : Open-Event-Frontend-3438

Issue : Open-Event-Frontend-3437

Tags :

OpenEvent, EventYay, Fossasia, Intern-2k19

Continue ReadingFixing Notification Services Across EventYay