The main feature of this app is to support Wikipedia education assignments, edit-a-thons, and other editing projects. It provides data and course management features for groups of editors — instructors, students, and others — who are working on Wikipedia, Wikidata, and other Wikimedia wikis. Users log in with their Wikipedia accounts (through OAuth) and allow the Dashboard to make edits on their behalf. The Dashboard automates many of the standard elements of organizing and participating in a Wikipedia classroom assignment, edit-a-thon, or other wiki contribution campaign.
This project is a part of WikiEdu Dashboard
![login page](https://github.com/WikiEducationFoundation/apps-android-wikiedudashboard/blob/master/screenshots/6.jpg) | ![login page](https://github.com/WikiEducationFoundation/apps-android-wikiedudashboard/blob/master/screenshots/4.jpg) | ![login page](https://github.com/WikiEducationFoundation/apps-android-wikiedudashboard/blob/master/screenshots/1.jpg) |
![login page](https://github.com/WikiEducationFoundation/apps-android-wikiedudashboard/blob/master/screenshots/3.jpg) | ![login page](https://github.com/WikiEducationFoundation/apps-android-wikiedudashboard/blob/master/screenshots/2.jpg) | ![login page](https://github.com/WikiEducationFoundation/apps-android-wikiedudashboard/blob/master/screenshots/5.jpg) |
Please find info about the set up of the Android app in your development environment here.
There are certain conventions we follow in the project, we recommend that you become familiar with these so that the development process is uniform for everyone:
The project follows Model-View-Presenter design pattern and requires schematic interfaces for each component to be written first in interfaces and then implemented.
All the interactions are done using interfaces only. This means any model, view or presenter will only be referenced by its interface. We do so it is easy to mock and test them and there is no discrepancy in the callable methods of the concrete class and the interface.
We realize that MVP is opinionated and there is no strict boundary between the responsibility of each component, but we recommend following this style:
View
is passive and dumb, there is no logic to be exercised in View, only the ability to show data provided by the presenter through interface is present in the View. Presenter
is responsible for most of the business logic, manipulation of data and organising it for the view to present. All logic for the app is present here. The responsibility of presenter includes the fetching of data from external source, observing changes and providing the view with the latest data. It also needs to handle all View interactions that require any logic, such as UI triggers causing complex interactions. Notable exception for this is launching of an Activity on click of a button. There is no logic required in the action and is completely dependent on Android APIs. Model
has the responsibility to hold the data, load it intelligently from appropriate source, be it disk or network, monitor the changes and notify presenter about those, be self sufficient; meaning to update data accordingly as needed without any external trigger (saving the data in disk after updating from network and providing the saved data from next time on), but be configurable (presenter may be able to ask for fresh data from network). The presenter should not worry about the data loading and syncing conditions (like network connectivity, failed update, scheduling jobs, etc) as it is the job of model itself.This software is open source, licensed under the MIT License.