Name: susi_android
Owner: FOSSASIA
Description: SUSI.AI Android App https://play.google.com/apps/testing/ai.susi
Created: 2016-09-21 08:56:16.0
Updated: 2018-01-18 08:29:02.0
Pushed: 2018-01-13 18:58:29.0
Size: 41383
Language: Kotlin
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
| Branch Name | Status | |————-|——–| | Master || | Development ||
The main feature of the app is to provide a conversational interface to provide intelligent answers using the loklak/AskSusi infrastructure. The app also offers login functionalities to connect to other services and stored personal data. Additionally, the application uses data provided by the user's phone to improve Susi answers. Geolocation information, for example, helps to offer better answers related to questions about “things nearby”.
Planned features & enhancements are:
Please join our mailing list to discuss questions regarding the project: https://groups.google.com/forum/#!forum/susiai
Our chat channel is on gitter here: https://gitter.im/fossasia/susi_android
A native Android app using both Java and Kotlin for writing code. The answers for user queries comes from SUSI Server which further uses skills defined in SUSI Skill Data.
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 as contracts 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 contract is present in the View. This makes it easy to unit test and remove the dependence on Android APIs, thus making the need for instrumentation tests scarcePresenter
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 leaksModel
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.Around 50% of the App is written in Kotlin. Kotlin is a very similar language to Java but with much more advantages then Java. It is easy to adapt and learn. So, you need not worry if you don't have prior experience with it. Follow these docs for syntax reference. The latest Android Canary Version has in built support for Kotlin but if you don't have the Canary version, you can add Kotlin Plugin in your Android Studio. Follow this link to see how to do that.
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 a 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 helper
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*
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 to this practice, but if the functionality can be generalised and reused, it should most definitely be transferred in its own class and unit tested.
First time contributors can read ContributionHelp.md file for help regarding creating issues and sending pull requests.
We have the following branches
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
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.
Go to AndroidManifest.xml
Replace the fabric_api_key with the Real Fabric API Key
Add:
Open the app/fabric.properties: Replace the fabric_api_key with your actual Fabric API Secret.
Open MainApplication.java, a) After adding the API KEYS and API Secret Uncomment the line: Fabric.with(this, new Crashlytics())
b) Add imports :
import com.crashlytics.android.Crashlytics;
import io.fabric.sdk.android.Fabric;
Uncomment the line in the app/gradle Line: apply plugin: 'io.fabric'
If you are a tester and want to test the app, you have two ways to do that:
This project is currently licensed under the Apache License Version 2.0. A copy of LICENSE.md should be present along with the source code. To obtain the software under a different license, please contact FOSSASIA.