=Google Summer of Code 2020=
=Commons-App Android=
=Implement Leaderboards=
**Proposal Document**
{F31718048}
==Proposal Summary==
#Personal Details
Name: Kshitij Bhardwaj
Github: [[ URL | kbhardwaj123 ]]
Email: kshitij256kencryption@gmail.com
Phone No: +91-9634843951
Location: India
Time Zone: India (UTC +5:30)
Slack: Kshitij Bhardwaj
LinkedIn: [[ https://www.linkedin.com/in/kshitij-bhardwaj-8508a5191/ | Kshitj Bhardwaj ]]
##Project Overview
At its core the Underlying Goal of This Project is to incorporate the concept
of Gamification into the Commons Android Application with the purpose of
leveraging User’s interest to increase their Wikimedia edit count. This
project aims to realise such kind of Gamification by establishing a
Leaderboards for the users wherein they will be ranked based on their edit
count via the Commons-App and not the Web portal.
The app already implements the level system which can be combined with
their ranks (indicative of their edits) and based on that we can award them
Rank Badges/Titles whose distribution algorithm has been proposed in
detail in this proposal later.
##Features
- Implement database schema which is entirely separate from the
existing edit counter as it includes counts made from the web portal.
The APIs which interact with this particular schema will have their
End-points served only to the Commons Android app.
- Leaderboards calculated from the above database schema will serve
their results via a single End-point which would accept the following
three parameters:
# Uploads/Nearby/Used ( as single integer viz. 0,1,2 )
# Weekly/Monthly/All (again as integer parameter)
# Username
- Entire Calculations will be accomplished on the server side and the
Android app’s leaderboard section will have the sole purpose of
displaying the results.
- The Leaderboards will be cached and stored on the server in a
database and will be refreshed at regular intervals.
- The leaderboard database includes only those users who have
explored the Achievements activity at least once.
- Server will perform complete re-calculation of leaderboard ranks at
regular interval of 1 hour, additionally for users who are really
intrigued in the leaderboards and check it more than 5 times a day (
on average which will be calculated on a per month basis ) will get
updated leaderboard after every 5 minutes interval.
- Implement Rank Badges and/or titles to motivate users to maintain
their pace of contributions so as to get a higher badge , apart from
that it will prevent users with ranks in orders of thousands to get
completely unmotivated as badge distribution will be much more
discrete in order of 10 or 20 badges/titles in total. The inspiration for
this feature has been from Competitive games like CS:GO, this
feature is highly effective in leveraging long term user interest.
## Feature Implementation
- The database schema will provide an end-point to the app which
consequently ensures that only the android app users enter the
leaderboard database. The Schema can be implemented as
mentioned in the model structure diagram sketched in the pdf file.
- The results will be served using a single API End-point as discussed
previously, the server side request flow will implement the following
pattern: (diagram in pdf file)
- How can this division of requests improve performance ?
The users who are check leaderboards quite often will be marked as
Active users, as a matter of fact only a fraction of the total user base
will be highly active so even if they are provided with the feature of
more frequently updated Leaderboards the server would not have
any extra load or request traffic
The Non-Active users would be provided with the leaderboards
which are refreshed once in an hour.
- How can Rank Calculation architecture be implemented ?
The API hosting server can run certain services for periodic rank
re-calculation, these services can be implemented using the
Advanced Python Scheduler ( APScheduler ) or we can also use
Cron Jobs( description ).
# Uploads Leaderboards:
The commons applications provides public logs of the users
which when displayed with conditions type=upload and with
tag filter=android app edit we only get the uploads made
by the android app as can be seen here .
The API would implement this as follows:
```
Use commonswiki_p;
Select count(*) as edits
From logging
Join change_tag on log_id = ct_log_id and
ct_tag_id=22
Where log_type='upload' and log_actor = ACTOR_ID;```
- Nearby Leaderboards:
These are counted when images are uploaded while in
Nearby section so they are automatically from the mobile
app.
- Images Used in articles Leaderboards:
These are calculated from the globalimageslinked table under
the GlobalUsage extension, to sum it up:
```
Use commonswiki_p;
Select count(distinct gil_to) from
globalimageslinked
Where gil_to in (Select log_title from logging
Where log_type='upload' log_actor=ACTOR_ID);
```
- How can Badge Distribution be implemented:
For badge distribution we combine user’s rank ( monthly/weekly
rank, could be based on uploads ) with their achievements so as to
incorporate long term (the level) and shortterm (weekly/monthly
rank) so we define a quantity x whose formula has been described
below and we find its standard deviation and the badges are
distributed as per the Badge distribution diagram(diagram in pdf) .
## UIX (designs)
{F31718100}
{F31718103}
The Design Screens shown above demonstrate the flow of the app in the leaderboards section, the last screen shows the user screen when the user has clicked on one of the leaderboard position holders, this first opens the commons gallery page of that particular user from where users can open any of the uploaded images (this is exactly what has been shown in the last screen, one of the gallery pictures )
## Crud Operations
An Overview of how the crud operations will work has been drawn below
For Evaluating uploads of Single user:
{F31718107}
The Leaderboards will be processed in two layers as shown above:
- Layer 1:
The uploads will be derived from joined logging and change_tag
tables now we will also have the timestamp in the combined result
records, in all the cases (Nearby/Uploads/Used). These results are
calculated on the basis of the logic discussed under the heading
Rank Calculation.
- Layer 2:
In all the three cases (Nearby/Uploads/Used) the final record list will
have timestamp (log_timestamp) now this timestamp will be used to
filter the leaderboard results as follows:
# Weekly: ``` If Current TimeStamp - Log TimeStamp <
WeekDuration```Where WeekDuration is the difference between two
timestamps with one week gap.
# Monthly: ``` : If Current TimeStamp - Log TimeStamp <
MonthDuration```
# All Time: No additional calculation required.
- Layer 3: Sort the results as per the upload numbers and then store
the rank into the particular case (for instance uploads/all) into the
field rank_uploads_all in the record of the corresponding user, inside
the table edits_commons_app.
The first two Layers will be repeated for every user and for all the (3*3) 9
cases we will store the corresponding fields of the edits_commons_app
table.
After the completion of all the three layers we will have a complete
leaderboard record of a particular user, this will be repeated for every user.
The Rank Badge calculation kicks in at this point, from the algorithm it
might seem like the process would be highly taxing for the server but
actually it's quite straight-forward. The 9 final ranks per record in the
edits_commons_app table leveraged into the standard deviation formula
mentioned in the Badge Calculation section.
## Project Timeline
**Community Bonding, 4th May - 1st June **
● Get to know the Community more,
and bond with mentors, admins
and developers.
● Get feedback if something in the
project needs amendment.
● Finalize the Database Schema and
APIs.
● Read more about RxJava,
APScheduler and other relevant
android technologies and
concepts.
● Get familiar with Commons
database schema and ideate on
how it will implement the new
tables proposed in the project
● Finalise a barebones
implementation of the ui using
viewpage and recyclerView in the
Achievements activity
● Deliverables:
○ Report on Community
Bonding period
** Phase - 1**
** Week 1**
Start UI implementation of primary
filters (nearby/used/uploads)with
mock data
● Implement basic view pager
● Get approval on database schema
changes and gather necessary
knowledge on how to implement it.
**Week 2**
Implement Capsule navigation bar
(primary filters)in leaderboards
view page.
● Get approval on MySql and
MariaDb script code changes
(script 1 and script 2)
● Create Pull Request for script
changes, iterate upon received
reviews
** Week 3**
Commence coding the python API
algorithms for Layer 1
filters(nearby/used/uploads)and
storing rank in the database.
● Discuss API code structures with
mentors.
● Create Pull Request on
commonsmisc repo with the Layer
1 implementation, iterate upon
received reviews.
**Week 4**
● Start Code implementation of
APScheduler services (responsible
for periodic updation of
leaderboards).
● Discuss Services code related
issues with the mentors.
● Create Pull Request for services on
commonsmisc and iterate upon
received reviews.
**Week 5**
Debug the database and Layer 1
API changes, ensure that they are
working in synchronization.
● Ensure only those who visit
achievements enter the database.
● Commence recycler view
implementation of leaderboards
● Get Approval on the final
Leaderboards design along with
code logic(upto this juncture).
**Week 6**
Implement RxJava Observable
pattern for the received user list.
● Discuss the final Observable
pattern code implementation of
leaderboards.
● Create a Pull Request for the work
done on a different(from master)
branch, amend as per the inputs
received.
**Week 7**
Debug the database-API(Layer
1)-Userlist chain.
● Start implementation of Layer 2 for
API to implement time filters.
**Week 8**
Complete Layer 2 implementation
along with the Rank Badge/Title
calculation.
● Synchronise services with the
updated APIs(Layer 1 + 2).
● Create Pull Request(not master),
iterate on inputs.
**Phase 3**
**Week 9**
Commence functional
implementation of the time filters
in the App.
● Debug combined implementation
of all filter combinations in the
application
**Week 10**
Finalise code structure the
commence implementation of
pagination to facilitate lazy loading.
● Iterate upon the reviews received
on the code changes so far and get
it merged with master.
**Week 11**
Finalise how avatars would be
stored(possibly local storage or
cache).
● Implement avatar display along
with Rank Badge display in the UI.
**Week 12**
Fix the bugs.
● Document as necessary and write
unit tests.
● Implement the Avatar change
feature.(if time permits)
## Additional Dileverables
Write blog posts on medium every alternate week.
● Write weekly report of accomplished tasks on the mailing list (or
something more relevant)
● Prepare and submit a presentation for this project.
## Motivation
Google Summer of Code is an excellent platform to get acquainted with the
open source community and their skillful mentors. It gives one a professional
work experience in their college years where they collaboratively build a
product for the welfare of the society. In this process, both the individual and
the community progress and flourish.
Contributing to Commons has been an enriching experience, the mentors and
the community have been really friendly and helpful in giving me constructive
criticism making me learn new stuff and improving my coding skills.
## Contributions
3422 - For v2.13, handle zoom in media detail view (merged)
❖ 3344 - TextUtils.isEmpty creates problems when unit testing
with Mockito (merged)
❖ 3378 - Ultimate achievement: Too many contributions
(merged)
❖ 3407 - Do not display pins at all when "Needs Photo" is
selected (merged)
❖ 3351 - Pending GCI task: Add java docs to methods which
have it missing (merged)
❖ 3326 - Make category search non case-sensitive (merged)
❖ 3366 - Adds a Test for Method A categories search (merged)
❖ 3332 - add javadocs to the file CategoryItem (merged)
❖ 3512 - Fix App Crashes on opening Contributions from
MainActivity (merged)
❖ 3505 - Media Detail design Overhaul (open)
❖ 3481 - Implement Progress Bar for Zoom Activity (open)
❖ 3513 - Image height remains zero for some time on bad
network (open)
❖ 3343 - TextUtils.isEmpty creates problems when unit testing
with Mockito (closed)
❖ 3436 - Switch to Material Card design for the Media Detail
Fragment (open)
❖ 3506 - Image View Height remains zero for some time on a
bad network (open)
❖ 3507 - App Crashes in MediaDetailsFragment with
ClassCastException (closed by PR 3512)
❖ 3414 - Handle zoom in media details view (closed by PR
3422 )
❖ 3355 - Do not display pins at all when "Needs Photo" is
selected? (closed by PR 3407)
❖ 3295 - Ultimate achievement: Too many contributions
(making our script time out) (closed by PR 3378)
❖ 3278 - Add java docs to methods which have it missing
(closed by PR 3351)
## About Me
Full Stack web and native app Developer, currently Hub-Coordinator at
Information Management Group (IMG), IIT Roorkee. During my first year at
college my workspace was confined to web development, during which I
worked on a few applications, for instance IMGSched (application for
scheduling meetings and sync to your google calendar), in my second year my
workspace expanded to Native app development and some major projects
listed in the following section.
My Projects:
● CMS :-
CMS is abbreviation for Content Management System which is
manages more than 6000 static pages of the official website of IIT
Roorkee, the use of a Content Management system is to make a
template for certain type of page (say news announcement page) so
that anyone without coding knowledge (say some staff member or
professor) can make changes to all those pages of that particular type
by just changing the base template and publish changes.
❖ Feature additions to the Institute CMS ( 10 commits )
❖ Role: Backend developer
❖ CMS handles the official website of IIT-R website
❖ It manages more than 6000 static pages on the website
❖ Tech Stack includes Yii 2.0, PostgreSQL, RabbitMq, Apache2
ㅡ
Project
Overview
● Placement Flutter :
At the Institute level it is imperative that the information flow is
smooth and fast, the official placement app aims to provide the
information regarding the placement and internship programs.
Additionally the app facilitates direct submission of their resume
directly to the companies, the app was migrated from native android
to flutter due to fast development times
❖ The official Placement app of IIT Roorkee
❖ Role: Full stack developer (81 commits)
❖ Currently under development (pre-alpha)
❖ For Security reasons it implements AES-256 encrypted tokens
for auth and resume handling
❖ Shows results for placement and internship seasons
❖ Facilitates submission of Resumes to companies
❖ Github Repo link: [[ https://github.com/IMGIITRoorkee/placement-flutter | Placement-flutter ]]
● Flutter Login Template:
An Open Source boilerplate application which is completely packed
with essentials for flutter development such as Stream Providers,
Implicit Routing and flutter hooks.
❖ Open Source Login Template
❖ Role: Repository creator and maintainer (22 commits)
❖ Includes Form validation
❖ Complete implementation of Routing and Data Streams
❖ Github Repo link: [[ https://github.com/IMGIITRoorkee/flutter-login-boilerplate | login-boilerplate]]