- Android App for Susi
- Contributions Best Practices
- For Developers: Adding Fabric API KEY
- For Testers: Testing the App
Android App for Susi¶
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:
- Hotword Detection training
- Full Screen Voice interaction
- Feedback for skills.
- Displaying SUSI skills
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
Android App Development Set up¶
Please find info about the set up of the Android app in your development environment here.
Libraries used and their documentation¶
There is certain conventions we follow in the project, we recommend that you become familiar with these so that the development process is uniform for everyone:
Viewis 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
Presenteris 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
Modelhas 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.
Use of Kotlin¶
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.
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.
helpermodule and data classes like Models and Repositories as they are used in a cross component way.
contractpackage in each module`*
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.
Contributions Best Practices¶
We have the following branches
- 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 gh-pages must pass a build check and a unit-test check on Travis.
- master This contains shipped code. After significant features/bugfixes are accumulated on development, we make a version update, and make a release.
- apk This branch contains two apk’s, that are automatically generated on merged pull request a) debug apk and b) release apk.
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.
Join the development¶
- Before you join development, please set up the project on your local machine, run it and go through the application completely. Press on any button you can find and see where it leads to. Explore. (Don’t worry ... Nothing will happen to the app or to you due to the exploring :wink: Only thing that will happen is, you’ll be more familiar with what is where and might even get some cool ideas on how to improve various aspects of the app.)
- If you would like to work on an issue, drop in a comment at the issue. If it is already assigned to someone, but there is no sign of any work being done, please free to drop in a comment so that the issue can be assigned to you if the previous assignee has dropped it entirely.
For Developers: Adding Fabric API KEY¶
- Go to AndroidFest.xmlReplace the fabric_api_key with the Real Fabric API KeyAdd:
- 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/gradleLine: apply plugin: ‘io.fabric’
For Testers: Testing the App¶
If you are a tester and want to test the app, you have two ways to do that:
- Installing APK on your device: You can get debug APK as well as Release APK in apk branch of the repository. After each PR merge, both the APKs are automatically updated. So, just download the APK you want and install it on your device. The APKs will be always be latest one.
- Testing on `appetize.io <https://appetize.io/app/mbpprq4xj92c119j7nxdhttjm0>`__: If you don’t want to download the APKs, you can simply go on this link and use the App on an online simulator. You will always find latest version of App on that link because it is updated after each PR merge.