Giter VIP home page Giter VIP logo

open-event-organizer-android's Introduction

Open Event Organizer

Open Event Organizer Android App

Build Status Codacy Grade Codecov Coverage Appetize Preview Gitter Twitter Follow

Event management app for organizers using Open Event Platform

The core features of this Android Application are

Currently, the application is released in alpha phase and available here: Google Play and F-Droid.

Get it on Google Play Get it on F-Droid

Roadmap

Planned features & enhancements are:

  • Overview of tracks and sessions
  • Quick session re-scheduling
  • Push notifications for certain triggers

Communication

Please join our mailing list to discuss questions regarding the project: https://groups.google.com/forum/#!forum/open-event

Our chat channel is on gitter here: https://gitter.im/fossasia/open-event-orga-app

Screenshots

Development

Publishing

Each push to master branch automatically publishes the application to Play Store as an Alpha Release. Thus, on each merge into master, the versionCode and versionName MUST be changed accordingly in app/build.gradle

  • versionCode : Integer : To be monotonically incremented with each merge. Failure to do so will lead to publishing error, and thus is a crucial step before any merge
  • versionName : String : User visible version of the app. To be changed following symantic versioning

Libraries:

Android Development Setup

Please find info about the set up of the App in your development environment here.

Project Conventions

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:

Dependency Injection

We use Dagger 2 for DI, so please take a look at how it works. We did not create very complex graphs, component or scopes to keep it simple and easy to refactor. But, we do have certain guidelines as to what needs to be injected and how. Every object which is configurable or there is a possibility for it to be shared among objects, instances or lifecycles in future, must be injected through DI. The interface implementations which have obvious constructions are @Binded to their concrete classes and a general rule of thumb we follow is to have only one new keyword in the injectable construction (the @Provides method in Dagger). Meaning that all other dependencies that need to be instantiated during its creation must be passed as arguments and provided by the DI itself.

MVP

The project follows Model-View-Presenter design pattern and requires schematic interfaces for each component to be written first as contracts and then implemented.
All the interactions are done using interfaces only and concrete classes are only used when being injected into required positions. 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 contract is present in the View. This makes it easy to unit test and remove the dependence on Android APIs, thus making the need of instrumentation tests scarce
  • 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 and it is devoid of ANY Android related code, making it 100% unit testable. We have created wrapper around common Android APIs in form of models so that they can be mocked and presenter stays clean. 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. Lastly, presenter should always clean up after the view is detached to prevent memory leaks
  • 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.

Project Structure

Generally, projects are created using package by layer approach where packages are names by layers like ui, activity, fragment, etc but it quickly becomes unscalable in large projects where large number of unrelated classes are crammed in one layer and it becomes difficult to navigate through them.
Instead, we follow package by feature, which at the cost of flatness of our project, provides us packages of isolated functioning related classes which are likely to be a complete self sufficient component of the application. Each package all related classes of view, presenter, their implementations like Activities and Fragments.
A notable exception to this is the common module and data classes like Models and Repositories as they are used in a cross component way.
Note: The interface contract for Presenter and View is present in contract package in each module`

Unit Testing

We have tight and almost complete coverage of unit tests for models and presenters and it was possible because we have focused on adding conditional unit tests with each functionality we have added. Each functionality was tested under various conditions making the tests self documenting about the functionality of app and saved us from various regressions that are caused after rapid development and refactoring of the application. Because we require the developer to write unit tests along with the code, we build up the confidence and credibility of the code base and remove the lag between functionality and test, making it hard for bugs to creep in between that period. Furthermore, if we let PRs merge without addition of unit tests, and the author of PR does not choose to write tests for it, it becomes difficult for someone else to just write tests for someone else's code and brings the coverage down and may cause regressions in future. We and everyone else wants to focus on creating the app better than to keep solving bugs and writing tests as we write code is the only solution.
So, please take a look at already written tests(they are fairly self-documenting) and try to write tests for each functionality you add.

Separation of concerns

Lastly, each class should only perform one task, do it well, and be unit tested for it. For example, if a presenter is doing more than it should, i.e., parsing dates or implementing search logic, better move it in its own class. There can be exceptions for this practice, but if the functionality can be generalised and reused, it should most definitely be transferred in its own class and unit tested.

Branch Policy

The following branches are present in the project:

  • development All development goes on in this branch. If you're making a contribution, you are supposed to make a pull request to development. PRs to development branch must pass a build check and a unit-test check on Circle CI.

  • master This contains shipped code. After significant features/bugfixes are accumulated on development, we make a version update and make a release.

    Please Note that :- Each push to master branch automatically publishes the application to Play Store as an Alpha Release. Thus, on each merge into master, the versionCode and versionName MUST be changed accordingly in app/build.gradle

    • versionCode : Integer : To be monotonically incremented with each merge. Failure to do so will lead to publishing error, and thus is a crucial step before any merge
    • versionName : String : User visible version of the app. To be changed following semantic versioning
  • apk This branch consists of multiple apk's which get generated by the Travis CI when the contributors branch is merged with the development branch and when the development is merged with the master branch. After every merge the previous APK's are deleted and new one's are created. The APK's are generated in accordance with the update-apk.sh script which is present in scripts folder.

PR Guidelines

Please help us follow the best practice to make it easy for the reviewer as well as the contributor. We want to focus on the code quality more than on managing pull request ethics.

  • Single commit per pull request
  • For writing commit messages please read the COMMITSTYLE carefully. Kindly adhere to the guidelines.
  • Follow uniform design practices. The design language must be consistent throughout the app.
  • The pull request will not get merged until and unless the commits are squashed. In case there are multiple commits on the PR, the commit author needs to squash them and not the maintainers cherrypicking and merging squashes.
  • If the PR is related to any front end change, please attach relevant screenshots in the pull request description.

License

This project is currently licensed under the GNU General Public License v3. A copy of LICENSE.md should be present along with the source code. To obtain the software under a different license, please contact FOSSASIA.

open-event-organizer-android's People

Contributors

991rajat avatar adityastic avatar akshaychd avatar anhanh11001 avatar betterclever avatar brijeshshah13 avatar codedsun avatar dependabot-preview[bot] avatar dependabot[bot] avatar dr0pdb avatar govinddixit avatar harshithdwivedi avatar hhimanshusahni avatar iamareebjamal avatar imgbot[bot] avatar kush-mish avatar lahirujayasekara avatar leeyh20 avatar mariobehling avatar masquerade0097 avatar mejariamol avatar mooocer avatar nikit19 avatar niranjan94 avatar rishabh-997 avatar rishabhk07 avatar rutvik-panchal avatar shridhargoel avatar sridharjajoo avatar yashishdua avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

open-event-organizer-android's Issues

Improperly cached Attendee List

The Attendee list is not cached according to event ID leading to display of wrong attendees for an Event when an app is offline.

I am fixing this. Needed for #49.

Relevant Screencast:
ezgif com-video-to-gif 2

Here Attendees for event betterclever-test-event are showing up in betterclever-test-event2. The list updates when internet is on.

Propose technology and set up basics

There were already some discussions about the choice of technology of this project, which could either be a web app or a native Android app. Please propose the most suitable choice of technology and set up the repository accordingly.

Two Loading Spinners on Pulled Refresh

On Dashboard Page and Attendees Page, two load spinners appear on pulled refresh.

Expected: Only load spinner of refresher should appear on pulled refresh

Upgrade to Ionic 2.0.x

This project right now is on Ionic 2 beta version. Please upgrade it to the latest stable release version of Ionic 2.

Page load time for Attendees List Page

Currently it takes more time to load attendees list page in case of large attendees.
For now we can try generating only list view items which fit in the viewport from the loaded attendees list on scroll. Will check if it decreases page loading time.
I will work on this.

Success of Checked-in Attendee unclear

Scanning the QR code of an attendee does not give me a clear success message. Has it been successful or not?

Expected: Show a screen "Success. Attendee [Name of Attendee] has been checked in."

Below that display a button "OK"

Convert orga app to Native android app

Hey i started converting orga app into native android app, here is the initial demo, all the functionality of the current orga app is present in it, here is the demo link & the repo of the app is here

rsz_screenshot_20170428-163743

rsz_screenshot_20170428-163800

rsz_1screenshot_20170428-163804

rsz_screenshot_20170428-164034

rsz_screenshot_20170428-164047

Upgrade to Ionic 3.0

Ionic Version 3 has been released based on Angular 4.0.
Project should be upgraded to include new features in platform like Lazy Loading which is now supported.

I am working on this.

Implement Login MVP

Part solving #92 - MVP Implementation

  • Use Retrofit instead of Volley ( Easy of Testing )
  • Use RxJava for Observable pattern rather than callbacks ( easy testing with pluggable schedulers and no need of callback captures), with additional feature of offloading tasks over Main Thread
  • Use Retrolambda to reduce anonymous inner classes and use lambda expressions itself

Proposed Architecture:

Package Style :

  • contract (Containing interfaces)
    • model ( Contains Repository pattern model too )
    • view
    • presenter
  • data
    • network ( Contains Retrofit implementation )
    • Model Implementation
  • ui
    • presenter
      • Login Presenter Implementation
    • activities
      • LoginActivity ( View Implementation )

Any suggestions are welcome

Implement Offline Check-in

If the app looses connection to the Internet during check-in, do the following

  • Give user a warning from the app (#30)
  • Allow user to continue to check in attendees offline
  • Sync all check-ins will automatically when your Internet connection is restored

Don't download obsolete packages

Some of the Android SDK downloaded are obsolete and not needed.
The travis log itself mentions this, so removing these will speed up the build process.

Installing Archives:
  Preparing to install archives
  Downloading Android Support Library, revision 23.2.1 (Obsolete)
  Installing Android Support Library, revision 23.2.1 (Obsolete)
    Installed Android Support Library, revision 23.2.1 (Obsolete)
  Done. 1 package installed.

Implement life cycle methods

Right now, all of the initialization is done in the constructor itself. It is better to move the initialization code to the lifecycle methods as the constructor cannot be "too heavy". Also the observables subscribed should be unsubscribed at appropriate lifecycle method.

MVP - Model View Presenter pattern Implementation

Currently the project is based on MVC (Model View Controller) pattern in which unit testing is difficult. Hence we will be implementing MVP pattern which facilitates unit testing.

Expected: Design MVP interface containing the required interfaces.

Only show email and password and a checkbox for server on start screen

The start screen currently gives three options to fill in:
Server, Email, Password.

Please only show Email and Password and below a small checkbox in smaller font

  • eventyay.com

If the user unticks the checkbox, it should be possible to enter an alternative deployment (just like now).

Loaded Event List hides while pulling refresh

On the Events Page, already loaded list hides when pulled refresh is called.

Expected: Already loaded list shouldn't be hidden while pulled refresh. Only it gets updated once refresh is done or shows previous list if refresh fails.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.