Documentation
basic overview of content each screens in the app
shows also the transitions between screens (e.g. what happens if buttons are clicked)
(maybe not up to date)
and same thing as pdf, in case someone needs it: app_screens_2019-11-19.pdf
Basic overview of what components of the Openscale Project can be used for integrating a bluetooth scale into a digital health project.
The project is split into core ( = logic) and gui. Except for the MainActivity all classes and methods used are from the core folder. The Open Scale drivers (BluetoothBeurerSanitas.java and BluetoothCommunication.java) brought the biggest value to our project.
All the external libraries used are added to the build.gradle (Module:app) file. In the build.gradle(Project:android_app) file maven (a repository search engine) and jitpack (an Android package repository) are added so external dependencies can be imported.
External libraries used
- 'com.github.weliem:blessed-android:0.10' This is a library that makes working with BLE easy. The standard implementation of Androids BLE is tedious when it comes to threading. Blessed also provides higher abstraction so BLE connections can be handled with less code.
-
'com.jakewharton.timber:timber:4.7.1' This library makes debugging much easier. In Openscale this is used for every debug statement and replacing those with the default
Log.d("tag","msg")would be a hassle.
| Description | This Activity is used for discovering Bluetooth Devices and saving the selected device to be used in the App. |
|---|---|
| Primary author | Daniel Wagner |
| External libraries used | BLESSED |
| Development history |
Issue 87 A button to start the bluetooth scan was added. When starting a new BLE scan the Hashmap containing all the found devices is cleared. A new central (Welie Blessed library) object is created and a scan is started. During the creation of the central object the callback method bluetoothCentralCallback is passed as an argument. This callback calls the onDeviceFound method that populates the HashMap and ensure no device is added twice. This is done by comparing the address of the found device and the adresses of the already contained devices in the hashmap. If a device is not already in the hashmap the BluetoothFactory converts the scanned device into the class used for later interaction. If the scanned device name is not recognized by the BluetoothFactory null is saved as a value in the hash map. At the same time as the callback is happening a progress bar is set to visible. To animate the progress bar a seperate thread is started. This thread runs for 2 seconds. The progress bar fills up steadily during that time. To stop it gets interrupted and a InterruptedException is caught on purpose. When the thread is stopping the progress bar is removed from the screen and the stopBluetoothDiscovery method is called that stops the scan function of the central and lists all the recognized items that were populated in the HashMap. Issue 90 The hashmap was removed and a custom adapter was created in which address and name are saved in a seperate class. |
| Description | (use this as a template) |
|---|---|
| Primary author | your name |
| External libraries used | ... |
| Development history | ... |
Used library for round imageViews: https://github.com/hdodenhof/CircleImageView
Initial permission requests (user is asked at runtime):
- CALL_PHONE (dangerous): to allow the app to call a someone (previously stored number of nok, no access to the normal phone contacts) from the emergency screen
- READ_EXTERNAL_STORAGE (dangerous):
- WRITE_EXTERNAL_STORAGE (dangerous):
Additional permission requests (these permissions are requested in the activity that needs them)
- ACCESS_FINE_LOCATION (dangerous): we need that for bluetooth
- BLUETOOTH (normal): to connect paired bluetooth devices
- BLUETOOTH_ADMIN (normal): discover and pair bluetooth devices
Permissions are split in "normal permissions", "signature permissions" and "dangerous permissions" and for each of these cases the permission handling should differ.
If the app uses "dangerous" permissions, the user must explicitly grant them on runtime. Permissions are ranked as dangerous if they allow the app to use private data and resources from the user or if they could potentially affect the users stored data or other apps.
link to more detailed explanation
you can look up which permissions are dangerous here
Since most of the permissions needed for the app are ranked as dangerous, all of them are requested at runtime. The runtime permission checks include a detailed explanation for the user which tells the user in detail why this permission is required. The bluetooth permission is ranked as normal, but we want to inform the user about why the app needs bluetooth as well, so this one is requested on runtime too.
Each time the app starts permissions are checked and the requested if they are not granted. Permission checks and requests are performed in the Splash Screen (after the initial welcome screen). Permission requests are performed subsequently to give the user enough time to read through the explanation, the splash screen is held until the permission requests are completed, the app does not continue to run in the backgound while permissions are requested (which is not actually intended in Android). The app uses Broadcast receivers to do the permission handling consecutively, first permission is requested and the app waits for the result, then a broadcast is sent to mark that the request is completed and if such a broadcast is received the next permission request is triggered.
This picture describes the neccessary parts to save and synchronize data between the Android-Applications for Patients and NoK and the doctor's web interface:
The follwing table describes the single parts, mentioned within the picture. There are also mentioned some useful links regarding to the different parts for further research:
| Description | Client Server Communication |
|---|---|
| Primary author | Patrick Höfner |
| External libraries used | Django, Django REST, React, Room, Retrofit |
| MariaDB | Relational Database which provides a database-server to save and access the data which is generated and used by the applications |
| Django Backend | Connection to the database-server, which manages all required operations on the database caused by "GET" and "POST"-requests from client-site. |
| Django REST Framework | Provides an interface which defines the structure of "GET" and "POST" Requests to communicate with the django Backend. It also offers Serialization methods to convert "django models" (Database-Tables) into other formats like JSON for sending and using the data within client-applications. - https://medium.com/@hassanabid/developing-android-client-app-with-django-rest-framework-8d5961a49619 - https://dev.to/apcelent/how-to-create-rest-api-using-django-rest-framework-28em - https://simpleisbetterthancomplex.com/tutorial/2018/11/22/how-to-implement-token-authentication-using-django-rest-framework.html |
| React | Frontend-Framework to present data to the user and to manage user-interaction. |
| Retrofit | Retrofit is a type-safe REST client for Android, Java. The library provides a powerful framework for authenticating and interacting with APIs and sending network requests. This library makes downloading JSON or XML data from a web API fairly straightforward. Once the data is downloaded then it is parsed into a Plain Old Java Object (POJO) which must be defined for each "resource" in the response. - https://guides.codepath.com/android/consuming-apis-with-retrofit - https://medium.com/@thanasakis/restful-api-consuming-on-android-using-retrofit-and-architecture-components-livedata-room-and-59e3b064f94 - https://riptutorial.com/de/retrofit2 - https://futurestud.io/tutorials/retrofit-synchronous-and-asynchronous-requests |
| Sync Adapter | To synchronize the local- with the server-database we probably need an synch adapter, which manages the operations to synchronize the databases. Maybe the retrofit-libary offers an opportunity. More research required. - https://developer.android.com/training/sync-adapters - https://developer.android.com/training/sync-adapters/creating-sync-adapter |
| Room | Local "sqlite"-database which allows to save data on the android device. |