How to ask questions to solve a setup or development problem as a Newcomer in Open Source

We see a lot of new users coming up and asking questions, which is great. But a lot of people ask “Can I ask a question?” which leads to an unnecessary indirection that “Yes, you can”. Or they say “Can anyone help me?”, “I’m having a problem” without mentioning their problem or even if they mention the problem “I cannot setup the project. It throws an error”, then they don’t mention the error. This leads to a loop of repeated question answers.

  • Please ask the question in the message itself
  • Mention what is the problem
  • Mention what you tried
  • Mention what failed
  • Mention the error with the exact error message/screenshot of the failure

To save both your and maintainer’s time in solving your issue.
Please read this: https://jvns.ca/blog/good-questions/

Also, respect time zones, people’s personal space, and time and realize that most people help others voluntarily. They are in different timezone than you and may take hours before replying. Use public channels so that even others may answer your questions, don’t spam and be patient, they may reply in their own time when they feel comfortable.

And also answer other’s questions if you know the solution.

“Now that you’ve read all the issues and pull requests, start to watch for questions that you can answer. It won’t take too long before you notice that someone is asking a question that’s been answered before, or that’s answered in the docs that you just read. Answer the questions you know how to answer.”

Andre Arko.net

Please join us to ask your question or answer a question of contributor on our channel at https://gitter.im/fossasia/fossasia

Continue Reading How to ask questions to solve a setup or development problem as a Newcomer in Open Source

Let’s Collaborate on Open Solutions at FOSSASIA

The FOSSASIA Summit 2020 in March already feels like an eternity away. With support from many contributors and sponsors we were able to pull off the event despite all the challenges. Thank you!

It has been impossible for FOSS contributors and Open Source companies since to organize in-person events, meet developers or collaborate on projects face to face.

There is not just a pandemic crisis happening right now, we see a violent political crisis in many regions of the world and also the climate crisis continues to affect people everywhere. These crises show more than ever that – just like in the FOSS community – we need everyone to collaborate on a global scale and to solve problems together with an open on all layers approach.

Below is some information on solutions we are working on at FOSSASIA and how we can team up in the Codeheat coding contest.

Let’s make Virtual Events Use Only FOSS/Open Source!

Currently we are integrating our hosted open source event solution with online video tools such as Jitsi or Big Blue Button. Right now many organizers depend on proprietary tools to run virtual events. Let’s change that. Check out the latest features of Open Event on eventyay.com, have a look at some of the upcoming events and sign up!

Let’s Develop Together and Share our Knowledge in Codeheat

We are running more and more activities online and we are adapting our annual coding contest Codeheat. We support participants by providing “Ask Me Anything” online support sessions, giving out more prizes every two months and extending the overall time of the contest until June 2021. Please join now at codeheat.org or contact us if your company would like to sponsor the program.

Let’s Make Science Truly Open Again with Pocket Science Lab

At FOSSASIA we believe it is only possible to solve our global issues by giving everyone access to open knowledge and tools. For this reason we are working on the miniaturization of science tools by developing the open hardware Pocket Science Lab.

Our goal is to create a science measurement device that is easy to handle, easy to transport, and easy to use. And of course it must fulfill the promise of science to provide every aspect of science openly starting with the hardware and software that collects data.

The PSLab can be connected to a smartphone and extend its capabilities. It enables everyone to collect data through sensors, control robots and to exchange data easily. Currently we are in the final steps of prototyping the next version which will come with an SD Card, on board real time clock, optional WiFi, Bluetooth, or Lora extensions, sleeping mode for datalogging and much more.

To learn more please download and test the project and start contributing to the repositories. Our weekly open hardware meetings take place every Saturday.
 

Continue Reading Let’s Collaborate on Open Solutions at FOSSASIA

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 Reading FOSSASIA 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 Reading Announcing 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 Reading FOSSASIA Confirms Annual Summit Takes Place from March 19-21 + DevSprints on March 22 at Lifelong Learning Institute in Singapore
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 Reading Introducing 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 Reading Making 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 Reading Adding 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 Reading Addition 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 Reading Making an About Section for Badge Magic Android App