Skip to content

Instantly share code, notes, and snippets.

@justary27

justary27/gsoc2022_report.md

Last active March 17, 2024 18:12
Show Gist options
  • Save justary27/7f8e49a42d8ab9db895c4de82f4c419f to your computer and use it in GitHub Desktop.
Save justary27/7f8e49a42d8ab9db895c4de82f4c419f to your computer and use it in GitHub Desktop.
Download ZIP
My GSoC 2022 Completion Report
Raw
gsoc2022_report.md

GSoC 2022 Completion Report @OWASP

Table of Contents

Before you start...

All the project's code is at https://github.com/Bugheist/Flutter. I've described my contributions below.

Overview

Getting selected into GSoC as a contributor has been one of, if not the best moment of my life, and that too at OWASP, one of the best orgs in open-source security! To start with project details. My aim was to close all the 31 issues present on the repo as of May 20, 2022. To say, the least the issues encompassed re-developing a whole app, with much needed UI changes. Despite facing various challenges, I'm glad to say that I had overcome the no. 31 by this journey's end, proudly standing at 36 and also doin' various additional work!

Statistics

I don't want to bore you with long texts of my experience, so here are some stats of my work during GSoC!

  • Changes vs Days

    A graph showing the no. of changes made against the entire GSoC time period! Don't take the last phase as inactive, that was more dedicated towards, non-coding activites like adding-docs, writing blogs, etc. Btw, made the graph with matplotlib, if you wanna know.

  • Total changes

    A total count of changes done by me accounts to 29,307! This makes me the contributor with most changes added on the repo :). This equals to 2.25x the contributions of all other contributors combined! Well anyways, nothing to boast, everyone's contributions are important!

  • Commits

    All of the work was done in just 23 commits!

Documenting my Experience

GSoC is in all it's essence a once in a lifetime opportunity. Being fond of writing crazy experiences, naturally; I decided to document this blue moon experience. Writing needs a medium and what best could be than Medium itself! Below are the blog posts describing my journeys in much needed detail!

Pull Requests merged

You may be suprised if I say that all of my pull requests that I made have been merged into the main branch. But it's True! Below is a list of merged PRs along with brief description of each:

Issues closed

36 issues, it's long to say the least! Hold your horses and let's dive right in. (Click the arrow to begin!)

Fireworks Sideworks

Writing code is not the only part of GSoC. Being a contributor, in my opinion means also promoting the opensource culture, and adding to the product in ways other than code. To do this, I have contributed in terms of community interaction, added a README to the repo, more recently, I've added a detailed Contribution Guide for the BugHeist's Flutter repo, and most importantly designed the app's UI, you can say all of the UI was revamped.



Figma link: https://www.figma.com/file/NYD5WZzJywnO338lchnece/BugHeist?node-id=7%3A634

Improvements

While we write lots of code to add new features, we should also know that improving performance is also a important part. Below are some improvements I made along this 90 day journey!

Code improvements

  • Example 1: Removing hard to undertsand and performance code This was painful to say the least, it was hard to understand how the the code was working not for other contributors only, but for me too :( More over, the code didn't worked, best course? Ofcourse, I replaced it with an efficient working one! This was the case for the "Authentication System"

    • Earlier The problem? A single widget simply handling way too much, and too many custom model classes which was simply not needed.

      class LoginFresh extends StatefulWidget {
    /// color main login
    final Color backgroundColor;

    ///color of card where are the login icons
    final Color cardColor;

    /// color of text in login
    final Color textColor;

    /// url logo main in login
    final String pathLogo;

    ///button when you want to avoid the login and go to the application content
    final bool isExploreApp;

    ///function when you want to avoid the login and go to the application content
    final Function functionExploreApp;

    ///widget to put a footer in your login
    final bool isFooter;

    /// custom widget footer
    final Widget widgetFooter;

    /// list type login import in login
    final List<LoginFreshTypeLoginModel> typeLoginModel;

    /// is signUp in login
    final bool isSignUp;

    ///widget signUp
    final Widget widgetSignUp;

    //model of key words used in login
    final LoginFreshWords keyWord;
    ...
  }
    • Present Solution? Separated the state management, broke the widget into many components, to make it more understandable.

       // Login Widget
   class LoginForm extends ConsumerStatefulWidget {
    final Size size;
    const LoginForm({
      Key? key,
      required this.size,
    }) : super(key: key);

    @override
    ConsumerState<ConsumerStatefulWidget> createState() => _LoginFormState();
  }

  class _LoginFormState extends ConsumerState<LoginForm> {
    Future<void> login(
      String username,
      String password,
      BuildContext parentContext,
    ) async {
      await ref.read(authStateNotifier.notifier).userLogin(
        {
          "username": username,
          "password": password,
        },
        parentContext,
      );
    }
  ...
      // State Management
  /// The provider which exposes the state management for user authentication.
  final authStateNotifier =
      StateNotifierProvider<AuthNotifier, AsyncValue<AuthState>>((ref) {
    return AuthNotifier(ref.read);
  });

  class AuthNotifier extends StateNotifier<AsyncValue<AuthState>> {
    Future<void> userLogin(Map<String, String?> userCreds, BuildContext parentContext) async {
      ...
    }
    ...
  }

  • Example 2: Preventing repeated API calls Ealier implementations of API fetching and displaying it in the UI all had used Future builder, inefficient to say the least! I switched it up to Consumers and Providers from Riverpod, the results are almost 4x better. Also it gives a more fine grain control over UI changes.

    • Earlier The problem? Everytime you switch back to the page having a future builder, it re-requests data from the backend. Have this for just 5 to 6 sceens, the requests can shoot up to 50+ easily, on just a single user session. This is obviously not wanted.

      // Using to fetch list of issues from backend
  child: FutureBuilder(
      future: _getObj,
      builder: (context, snapshot) {
        ...
      },
  );
    • Present Using a combination of providers and consumers we can reduce the number to ~12. This is much better and preferred too! Also it improves app performance.

      /// A Riverpod Consumer Widget
  child: issueState!.when(
    data: (List<Issue>? issueList){
      if (issueList!.isEmpty) return ...;
      else return ListView.builder(...);
    },
    error: (Object error, StackTrace? stackTrace) {
      return Center(
        child: Text(
          'Something went wrong!',
        ),
      );
    },
    loading: () {
      return Center(
        child: CircularProgressIndicator(),
      );
    }
  ),
      /// The provider which exposes the state management
  /// for issues in the issue list.
  final issueListProvider =
      StateNotifierProvider<IssueListProvider, AsyncValue<List<Issue>?>?>((ref) {
    return IssueListProvider(ref.read);
  });

  class IssueListProvider extends StateNotifier<AsyncValue<List<Issue>?>?> {

    ...

    Future<void> _retrieveIssueList() async {
      try {
        final IssueData? issueData = await IssueApiClient.getAllIssues(
          IssueEndPoints.issues,
        );
        nxtUrl = issueData!.nextQuery;
        state = AsyncValue.data(issueData.issueList);
      } catch (e) {
        AsyncValue.error(e);
      }
    }
  }

Design improvements

As I have said earlier multiple times, I redesigned the entire thing, to make the app look sleek and modern, this part was new to me as I haven't done much UI design on an industrial scale before, but it worked out well as everyone liked it! I'm sharing comparisons between my screens and previous ones.

Screen Name Old Design New Screen
 Issue 
 Report Bug 
 Leaderboard 
 User profile 

Challenges faced

This journey hasn't been a drive on a highway, but one in the hills. A lot of challenges popped up here and there, yet I'm glad I was able to overcome all of them! The biggest challenge I would consider was UI designing as I was completely new to the field, it's funny and sad at the same time when it takes a day just to decide the color scheme and fonts for the app :) Another one of my challenges were to create fully functional app-screens, this arose cause of the fact that there were limited APIs available to work with, so I had to extract the maximum info I can get from them and create a good user experience form it.

What have I learnt?

There's a learning in every challenge

Tho I know flutter very well imo. There's always something you can learn. Some of my learnings was how to create a working search bar, work with a lazy loading list, and creating and auth system with riverpod. Other that, I surely learnt UI designing very well!

Future Scope

Tho I've solved various issues and made the app launch ready on app and play stores, much can be done from here. First of one the reward system on reporting an issue, or integration of payments into the app for subscriptions and sponsoring the project. This was dropped out from my proposal later, so can be worked upon in future. Also there's a scope of making more APIs whcich provide easy access to the site data. New screens and features are always a possibility!

A Thanks to my Mentors

Of course you need someone who can guide you when you stray off the right path. Not acknowledging their contributions will be blasphemy! So yes, I would like to thanks my mentors @Sparsh1212, @ankit2001, and @fredfalcon for constantly helping me throughout this journey of mine. Without your guidance, every turn could have taken me on a worthless adventure!

Conclusion

This has been a great eventful journey full of ups and downs, it was a great feeling to be a part of something as big as the likes of Google Summer of Code, almost a once in a lifetime opportunity! I look forward to keep contributing to the world of open source! Open source FTW :)

- Aryan Ranjan

Made with ❤️ by 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment