Development (Chapter 5)

Development

5.1. Splash Screen

5.2. User Management Functions

5.2.1 Login & Logout

5.2.2. Registration

5.2.3. Password reset

5.2.4. Change password

5.2.5. Edit user details

5.3. Mental questionnaire

5.4. Memory Card Game

5.5. Nintendo Wii Balance Board Connection

5.6. First Psychical Activity

5.7. Second Psychical Activity

5.8. Displaying the collected data in diagrams

5.9. Sharing the Results

5.10. External Sensors (Xiaomi Mi Band )

5.11. Third Psychical Activity

5.12. Fourth Psychical Activity

5.13. Recording data

5.14. Tips and Hints

 

The main goal of the project was developing a mobile phone application. Well-functioning, simple-to-use software was necessary for reaching the goal of project. The maximum abiding of the professional guidelines during the development was needed for implementing the planned functions. Waterfall method was used during the development with Prototyping method. So the functions are created one-by-one, following each other, and then the whole working function was tested on the development environment’s virtual devices and on compatible hardware too. The next function was developed after the flawless working of current one on all platforms.

 

Implementing of each main function and prototype testing lasted for one-one weeks, so every week a new copy with new version number was created and the new function implemented into the next function. This method made the version and source code evolution tracking safe.

 

The developing and testing of the application was summarized in this main chapter. The subchapters describe the main specifications and used guides of implemented functions step-by-step and also describe the experienced problems and their solutions.

5.1. Splash Screen

The users who downloaded and installed the application are welcomed by splash screen. The screen waits 4 seconds, then checks the user's login status in the SharedPreferences folder. A touch observing function was built-in for showing the welcome screen which means if the user touches the screen then the waiting time will be skipped. Depending on that status, it moves the user to the login or activity screen.

 

loggedIn = mSharedPreferences.getString("loggedIn", "false"); // Get user name

Log.e("Logged in, splash", "-" + loggedIn + "-");



if (loggedIn.equals("true")) {

Intent mainScreen = new Intent(this, MainActivity.class);
startActivity(mainScreen);
overridePendingTransition(R.anim.left, R.anim.right);
}
else {

Intent login = new Intent(this, LoginActivity.class);
startActivity(login);
overridePendingTransition(R.anim.left, R.anim.right);
}

5.2. User Management Functions

The first function of the application is user management. The use of the application requires registration, so the user information has to be stored and the application has to provide repeated entry. In the case of a forgotten password it has to give opportunity for the user to recover or change said password. Other than the password, the application also has to provide the ability to change other user information. In this subsection, these functions will be discussed. For development two, online support was used, Mybringback (2013) and Ray A. W. (2013).

5.2.1 Login & Logout

After the welcome screen the user (if said user is not already logged in) is moved to the LoginActivity page. Here they are able to provide their e-mail address and password to enter the program. Firstly, the program checks for the format of the e-mail and its existence, and then it checks the password. If the information provided is correct, then the information is transferred to the server, where the PHP coding checks it against the database and it sends a response to the program. Once the correct response arrives, the user is allowed entry into the software. All relevant personal information is temporarily on the SQLiteDatabase; therefore, a continuous internet connection is not necessary

 

The user has is able to log out at any time by using the icon on the ActionBar and menu. Upon exiting the program, relevant SharedPreferences values are moved across and the user data is deleted from the local database.

5.2.2. Registration

The new users have to set up an account before being able to use the application. The registration takes place on the RegisterActivity page, where all given information is checked to ensure that it is given in the right format and all required fields are completed. After the data has been covered, it is transferred to the external server. The program found there checks if the e-mail is already used, then the information is stored on the internal and external database. The password is Salted and Encrypted when stored. After registration, it shows all the information entered and enables the user to use the application.

5.2.3. Password reset

The application allows the user to reset a forgotten passwords by using the PasswordResetActivity. The user has to provide a registered e-mail, which, after the format of the e-mail was checked, is sent forward to the server. The server checks the existence of the e-mail address and then generates a new password, which is sent to the user in an e-mail. After this the user is able to enter the system with this new password.

5.2.4. Change password

The users who are logged in are able to change their registered password in the Settings menu that is found in the Action Bar, by using the ChangePasswordActivity option. This may be used, when a new password was provided to the user because of a forgotten password, and the user wishes to change the computer-generated password to one of their choosing that is easier to remember.

5.2.5. Edit user details

Similar to ChangePassword, the users are able to change their personal information. This function can also be accessed at any time in the menu of EditUserActivty page. The only information that can be changed, is that which was provided by the user. The automatically-generated information and password cannot be changed in this way. Any modifications to the information are checked to ensure that everything was completed, and using the correct format, then it is stored on an external server. If the information was transferred successfully then the information will be inserted into the local database.

5.3. Mental questionnaire

The second main function of the application was the measurement of the user's mental status. For these measurements, the sensors found in a mobile device are unsuitable. These can only be collected under laboratory conditions and, within the boundaries of the application, this was not possible. Questionnaires were left as a second option.

Questionnaires can have a simple structure too, but the creation of a credible questionnaire can also be a complex task. The questionnaires that are created for professionals, or general questionnaires, are always created by researchers or by people with deep knowledge in the subject. Therefore, the questionnaire chosen to be used in the application were provided by people who had worked in university education for a long time and these have been used for many years, TOPS (Test of Performance Strategies) Thomas, Murphy, &Hardy (1999). The sponsor of the project has given access to a 32-question questionnaire, which measures the user’s mental status in eight different subjects. Out of the 32 questions, with values from 1 to 5, the users have to provide a value (Appendices, Section E).

 

The subjects included are:

  • Goal-setting
  • Automaticity
  • Emotional control
  • Imagery
  • Activation
  • Self-talk
  • Relaxation
  • Attentional control

These questions were integrated into the application, by using AlertDialogBoxes for relevant questions written by Keerthy (2011). The answers are stored temporarily in an Array. There is a way to interrupt the questions, and as a response to answering the last question the data is saved in the database. The questionnaire includes a Scoring Key, which is used at points reached in a specific subject. The answer key has been encoded into the application.

private void scoreCounting() {

    // Scoring key    

    goalSetting = answer[1] + answer[9] + answer[14] + answer[18];

    automaticity = answer[5] + answer[20] + answer[23] + answer[29];

    emotionalControl = ((answer[8]*-1)+6) + ((answer[17]*-1)+6) + ((answer[21]*-1)+6) + answer[25];

    imagery = answer[2] + answer[11] + answer[27] + answer[31];

    activation = answer[3] + ((answer[10]*-1)+6) + answer[15] + ((answer[24]*-1)+6);

    selfTalk = answer[4] + answer[12] + answer[19] + answer[28];

    relaxation = answer[0] + answer[6] + answer[13] + answer[22];

    attentionalControl = answer[7] + ((answer[16]*-1)+6) + answer[26] + answer[30];

 

As noticed, some of the points earned for a question use inverted values. This is calculated by using (x*-1)+6 formula. The achieved score is saved on both the internal storage and the external server database. Alongside the score, the user's unique identification code and the date and time when the questionnaire was completed, are also saved. The date and the time depends on the values set up on the mobile device, and is not based on the server's internal clock, to avoid the time zone difference.

 

After the user has completed the mental questionnaire, they have an option to do the physical tests.

5.4. Memory Card Game

In accordance with the plans, the questionnaire measuring the mental state was originally supposed to be followed by tasks measuring the physical state. However, the sponsor recommended placing a simple card game between the two in order to test the memory of the user.


The task is to find the pairs in a simple card game from 20 cards, where only two cards can be turned over at each try. The pairs that have been found are disappearing from the scope of the game. The game counts the number of tries, and the aim is to find all the pairs in as few attempts as possible. The basis of the game's coding was provided by a free program.

 

Source: http://www.java2s.com/Open-Source/Android_Free_Code/Game/Download_Free_code_Memory_Game.htm

Accessed: 05 February 2016

 

From the codes downloaded from the source, only used were thosed that fit the programme, and any detected mistakes were corrected -- e.g. the cards needed to be adjusted to the size of the screen. The screen components were changed to own images and in order to save more space the icons of Action Bar were used as pictures of the cards. Considering the guidelines and directives of AndroidDeveloper, animations were also built into the game. A 'Shake' animation makes the game scope even more spectacular while for the disappearance of the cards a 'Size Down' effect was used.


At the rating, the number of attempts (for finding the cars) are subtracted from the 100 points, and this final result will be stored among the variables of SharedPreferences.

 

5.5. Nintendo Wii Balance Board Connection

The project planned to use the Nintendo Wii Balance Board to measure physical state. After devoting many hours on research and coding, it was found that the currently-used mobile devices are not able to connect to Wii controllers, as the A2DP profile used is not compatible with 4.2.2 version of Android operating system (Android Issue 39633, 2012).

This was replaced by CyanogenMod 10 or newer version devices, but due to the minimal number of applications on the device, it does not justify developing the project in this direction. The intended function is not feasible due to the reasons mentioned above; therefore the search to develop other solutions has become necessary.

5.6. First Psychical Activity

During the first task that was aimed at measuring the initial physical state, the subtle coordination of fingers and the concentration ability of the users were tested. The task was to keep a circle moving persistently faster above the aim scope for 30 seconds. The movement of the circle can be controlled by the subtle moving of the device held horizontally.


The construction was made in accordance with the instructions of "Tilt Ball Walkthrough" tutorial (mikew67, 2012). This was a good base for understanding the logical operation, though it contained several mistakes and inaccuracies that needed to be fixed, e.g. the determination of the size of the circle or the redefinition of the moving circle disappearing from the screen.

 


In the course of programming, the built-in Accelerometer sensor helped in the execution of control, since this sensor can be found in almost any of the devices. The movement and the speed of the circle was calculated within the fluctuation-observing function of the sensor.

 

if (mySensor.getType() == Sensor.TYPE_ACCELEROMETER) {

// Set circle speed, based on phone tilt (ignore Z axis)


mCircleSpeed .x = -event.values[0] * mSpeed;
mCircleSpeed .y = event.values[1] * mSpeed;

}

The visualization of the circle and the aim graphics are handled by a timer. Within stipulated periods of time, it verifies the location and speed of the circle, and modifies them using the values received from the sensor. In order to make the game more difficult, the speed of the circle constantly increases until it can barely be held above the aim scope. Throughout the test, the variation of the device's orientation was turned off and was fixed solely in "Portrait" mode. To avoid the device turning into stand-by mode, ‘WAKE_LOCK’ service was also turned off during the test.

setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);

pm = (PowerManager) getSystemService(this.POWER_SERVICE);
wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, "My tag");
wl .acquire(); // Acquire screen lock
 

The scores are received for holding the circle above the aim scope, from this the deviation is allowed only by the degree derived from the resolution of the screen. In the course of testing the task, it was perceived that the obtained scores depended chiefly on the quality of the sensor built in to the device, as well as its graphical and calculational efficiency. As a result, we get data that can be used for comparison only when the user is doing the recurring tests on the same device.

5.7. Second Psychical Activity

The second physical assessment was lifted from the system of EurofitFitness Test, that was recommended and also used by the sponsor. The name of this task is FlamingoBalance Test. During the execution of the task the balance of the user was tested, they had to stand on one foot for 60 seconds in a certain position.


For the original task a special tool is used, though since it is not available for everyone, the execution of the task and its rating had to be changed. The users have to put the mobile device in a place that can be easily reached. Prior to the test they have five seconds to take on the proper posture. A 60 seconds timer then starts. In case the users lose balance before the end of the given 60 seconds they have to stop the timer by touching the STOP button. The obtained scores are calculated from the remaining seconds on the basis of function.

 

mScore = (int) ((seconds % 60) * -1) + 60;

 

This means that the more time users can hold the determined position, the higher scores they gain. The maximum score is 60.

For the design of the timer a method written as a question in connection with a tutorial was used and built in to the programme (Nazul, 2014)


The graphical basis of the stop button was provided by a picture for free use that was downloaded from the following link and later transformed with Photoshop: https://pixabay.com/en/photos/stop%20button/?&per_page=150

Accessed: 19 January 2016


To avoid damage to the mobile device it is not recommended for users to have the device in their hands during the task since it can be damaged if balance is lost. Another option can be an external assister who can stop the timer.

 

During the development, a cheap fitness bracelet (Xiaomi Mi Band) was found with proper external sensors, which complies the needs. The data of the accelerometer sensors were read out via Bluetooth connection and this made the state examination possible. Also this gave a possibility to shut down the countdown clock by software. This possibility was built-in the application, but manual shutdown is available as well. If the countdown clock will not stop automatically due to instability of Bluetooth connection, the manual shutdown is still available.

Unfortunately, other tasks of the Eurofit system are not able to be built-in to the application to do this; either special accessories or a great unbound territory would be needed. As a result, other simple and accepted tasks should be found for the remainder of the user tasks.

5.8. Displaying the collected data in diagrams

Due to problems with external sensors it was not possible to develop the preserved physical surveying tasks, so these needed to be skipped, and then the developing of the next function took place. This function was displaying the diagrams for simple review from the collected data.

 

GRAPH VIEW external library was used for the implementation. This external library was exactly developed for this function and free-to-use for everybody (Gehring, 2015). The library is well documented and contains examples but it is not flawless of course. After following the instructions and then integration the application quit with some error messages. Interpreting the error messages made possible to find a solution which provided flawless integration. For this, the inserted row from dependency must be removed and only the functions of .jar file which placed in lib folder needed to be imported to activity.

 

During the early stages of development the 8 mental category values were worked out with constant values with different colour lines for the visualization depending on the display resolution. Addition need was displaying the titles of lines. After these functions started working the values were changed to actual ones.

 

After working out the visualization, it needed to work out the loading of necessary informations from external database and then saving to internal database. The necessary PHP codes needed to be developed because only the last 5 values needed from the user’s data. It was implemented with

 

"SELECT * FROM mentalSurveys WHERE uid = '$uid' ORDER BY `mentalID` DESC LIMIT 5"

 

SQL command from DB_Functions.php file. Additional development needed for sending back the required data as an array and also the processing of the array in the application.

During the testing of developed function some defects came to light. In these cases where the user had no 5 previous test results, it caused shutdown of the application because the lack of necessary data for filling the diagrams. The codes needed to be rewritten because the program only tries to display the available data. Fixed numbered displaying had to be changed to piece number examiner loops. Furthermore an additional filter needed because the diagram displaying needs at least two data groups, if the user has only one earliest save data then the program informs the user about the data is sufficient for visualizing.

 

During the show for sponsors, a sponsor asked to display the time of particular collected data because those are important for the analysis. To fulfil this request, displaying of those data was added to the defined page.

 

After displaying the graph, a device was needed with external sensors which comply for the further development needs because this was the next step.

5.9. Sharing the Results

Another planned function was the sharing of results. The sharing can be done on two channels. The first option is sharing via e-mail. The second one is sharing via Facebook Messenger. Easiest way on both channels was transmitting as picture.

The graphical display of the results is already done, so the method of screenshot saving needed to be implemented. Already saved content can be later freely shared or used. The answer found on the Internet gave the base for saving screenshot from the mobile device.

 

Source: http://stackoverflow.com/questions/19214714/android-taking-the-screenshot-and-sharing-it

 

Only the method of screenshot saving was used from the available solution. The actual saving was done in a different way. First of all, the device checks the availability of externally connected memory unit. If it is available, it checks the existence of myGraphs folder, if there is no folder with this name, the program will create one. Bitmap is made from 90% of screen, which is named after the momentary millisecond of system time, guarantying the unique filename. The image file is saved in 100% quality JPEG compression for good quality. If the saving of image file is successful, the filename will be stored in SharedPreferences and then redirected to ShareActivity page, which provides possibility of sharing.

 

’Intent’ invitation was used for sharing via e-mail.

final Intent emailIntent = new Intent(android.content.Intent.ACTION_SEND);

emailIntent.setType("plain/text");

emailIntent.putExtra(android.content.Intent.EXTRA_EMAIL, email);

emailIntent.putExtra(android.content.Intent.EXTRA_TITLE, "MSMAS");

emailIntent.putExtra(android.content.Intent.EXTRA_SUBJECT, "My Graph");


// Put extras to email array

if (URI != null) {

    emailIntent.putExtra(Intent.EXTRA_STREAM, URI);

}

// Start email activity

this.startActivity(Intent.createChooser(emailIntent, "Sending email..."));

Facebook for developers (2015) Getting Started Android SDK was used for sharing via Facebook Messenger. The newest 4.8.2 version did not contain Android Studio support, so the older 4.1.0 version got integrated. For the integration, the modification of AdroidManifest.xml file and the ‘Project’s Dependencies’ were needed. The integration was already done with another module, so it was not hard to do it with this one. API key was not defined for the application, so the consignee will get an additional message which informs about the usage of demo version. If the application will publicized for real, generating an own key and replacing will be needed.

The implementation of planned services was done with the above described method, so a possibility opened for the realization of the next function.

5.10. External Sensors (Xiaomi Mi Band )

Because the original plan was unable to make with Nintendo Balance Board so a new external device was needed to survey the physical state. The research showed that smart watches and fitness bracelets used for this purpose nowadays.

 

Among the commercially available smart watches and bracelets the good quality ones are high priced and their software are closed sources. One of the main viewpoints was the cheapness and the device’s software is well known so it enables custom software developing. Unfortunately the mass produced Chinese devices are not comply these requirements. Another important viewpoint was the long battery life to avoid the frequent recharging.

 

Finally, a device which comply all the requirements was found. This device was the Xiaomi Mi Band bracelet. The British distributors are selling it around £12 price, which is acceptable. The memory map of the device is known, which means an external application can be developed for this bracelet. Battery life of the device is around 30 days which is also acceptable.

 

Disadvantages are the pairing and disconnecting only done with the device’s own software. Until the device was not disconnected from the connected one it will not be recognized by other devices. Additional disadvantage is that the factory made software only works with Android 4.4 and 5 versions so the connecting only can be done with devices that run these operating systems. The last disadvantage is the usage of BLE (Bluetooth Low Energy) standard and the support of only Bluetooth 4.0 version. These requirements heavily limited the number of usable devices but this solution looked the best one.

 

Inserting into the application and connection based on the information from the page called „Xiaomi Mi Band BLE Protocol reverse-engineering and API “(Gavrikov, 2014). Inserting of the SDK was a relatively easy task but the Bluetooth connection did not work, so a solution was needed for this problem. A system was worked out first for avoiding the error which reads out the list of paired Bluetooth devices from the machine and then shows all of them in a list, giving choice opportunity to users. During the test it was uncovered that only a few mobile devices can connect to the bracelet and will not be saved to paired devices so a new solution was needed.

 

Searching and connecting of BLE devices is not an easy task. From many available solutions only one was the really stable and viable. (BluetoothLeGatt, 2016). The devices were not present in the list of paired ones so a sample used for finding them. The disadvantage of the program is the function supported from API21 version so this is why the external SDK minimal system requirements must be changed which narrowed the number of usable mobile devices.

 

With the usage of the above mentioned guides the connection was built, and the necessary information were read out from the memory addresses of Xiaomi Mi Band. Finally, the values of odometer, battery information are available and the adjustments of sensor mode to accelerometer state and extract the values. These functions made available the solution of two further planned physical surveying tasks.

5.11. Third Psychical Activity

The already connected Mi Band gave possibility for the implementation of the third physical state surveying. A task was needed, which could be done in a small place and for short time, and also could be measured with the external sensor, so the 30 second long in-place-running was chosen.

 

The user has 30 seconds to reach the most possible number of steps during the in-place-running. Feet must leave the running surface, so real steps are needed.

 

Like the previous exercises, the user has 5 seconds of preparing time, and then a 30 seconds countdown clock shows the remaining seconds. The start and the end of the exercise are both indicated with vibration of bracelet. The spectacular graphical displaying was done with a circle shaped Progress Bar. During the last 10 seconds, the seconds are flashing, thus giving attention to the coming end.

 

The odometer, which is built in the bracelet, sometimes has a latency of transmitting the number of steps, so it will be displayed if the value is greater than zero. At the start of the exercise, the number of steps is stored in a variable. The program checks the difference between the already stored step number and the actual numbers in every second, and then displays it on the upper part of the screen to make the user faster. The final result is calculated in similar way, so the initial value will be extracted from final value. The actual number of steps will be saved to SharedPreferences value pairs, and then saved to local and external databases after completion of all tasks.

 

Timing problems of Bluetooth connections are committed to a third timed task, which delays the transmitting of necessary steps by seconds to avoid the data congestion and drop-outs. The first step disables the data transmitting. The second one switches the observing routine to odometer. The third one switches the sensor observing mode into default state. These steps are needed for extracting the proper data.

 

The code below is used for calculating the decimal value from hexadecimal stored value in the memory of bracelet.

 

info.steps = data[3] << 24 | (data[2] & 0xFF) << 16 | (data[1] & 0xFF) << 8 | (data[0] & 0xFF);

During the implementation of function a possibility was given to take advantage of last service of the bracelet, so it was fully used.

5.12. Fourth Psychical Activity

The same aspects were important at the creation of the fourth physical test, as in the previous tests. It means that a physical exercise should have been found that can be implemented in a small place, which is measurable and repeatable, and which can be used with the connected Mi Band fitness bracelet.

 

The sponsor suggested an exercise, in which the test subject is in a half squatting position, with the arms stretched out horizontally in front of the body, and tries to maintain the current position. This test measures the subject's muscle strength and endurance. This exercise is often implemented on the sport faculty of universities with a modification - the test subjects can have their backs against the wall as an easement in order to implement the exercise safer. Since this would mean the extension of test time, and in our case making the exercise easier is not an aspect as well, this option was not installed into our application.

 

Following the principle of continuity, this test was also modelled on the pattern of previous tests. An information page introduces the test as in the previous tests, where a figure displays the body position and a short description of the task. There are three buttons on the side, ‘CANCEL’, ‘START’, and ‘MANUAL’. Pressing the MANUAL button the detailed description of the exercise can be read in a pop-up window.

 

Pressing the START button the user will be redirected to the test page. Three consecutive exercise timer routines take care of the implementation. The first routine creates a Bluetooth connection with a shift per second, and then sets the functions of Mi Band to monitor the acceleration sensor. In the second routine, a 5 seconds countdown shows the time available for preparation. The third routine is a 3 minutes stopwatch, which measures the time spent in the pose. A circular Progress Bar makes the stopwatch more spectacular.

 

During the test, a STOP button is also seen on the screen, which can stop the test. During the test, the program monitors the displacement of the pose measured by the sensors of Mi Band, and if there is a major displacement, it automatically stops the test. After completing the test, the number of seconds spent in the pose will be recorded as score in the SharedPreferences storage.

 

After completing this test, the series of tests ends, and all necessary data is available, so the next step is saving the data.

5.13. Recording data

After completing the tests, all data is stored in the value pairs of SharedPreferences storage. The final scores are displayed on the ‘SAVE RESULTS’ summary page.

 

The results can be saved with the ‘SAVE’ button found on the page. After pressing the button, the program checks the Internet connection by opening the address http://www.google.com. If the connection works, the missing data for the saving will be collected. These are the user-specific identifier, given date, and right time. When all data is available, they are forwarded as a JSON object to the interpreting and processing file created on the external server. First the data of mental categories will be saved on the external server. If the saving was successful according to the feedback, the data will be recorded on the local MySQLite database as well. The same processes are repeated during the recording of results of the physical tests. In other words, the results are recorded on two separate database tables, mentalSurveys and physicalTests, as well as on the internal database with the same table names.

 

After the successful savings, the user is returned to the home page, where the previous results or suggestions for better results can be seen.

5.14. Tips and Hints

The last tasks of the development process were evaluation of data and giving suggestions. It was an important aspect that users can only access to their own data to protect personal data. As user base is very broad, data of different groups are not similar. In case of every users, only their own, previous test results were compared to the last result.

 

TipsActivity page created for this reason firstly checks operation of internet connection. Then, it queries the user’s last five mental test results from the database. Then, it is done with physical test results, too. Data are inserted into local array variables. The programme firstly counts average from value of arrays created by categories, and then it compares the last, saved result to the average. As only experiences from the developer’s test run were available in this phase of development, only these data could be used initially. A change of a category was assessed in proportion to average results by category.


Category name of test in question was provided by category in a scroll screen. Then, average scores and last score were displayed. Changes in case of 10% and 20% difference, either positive or negative direction, were detailed with structured sentences in a string.xml file stored in values folder. These sentences are just sentences identifying changes. Science-based recommendations for improvement of different abilities could not be carried out during the project. Therefore, this has to be implemented during the further development of the application.

 

Additional unanswered questions remained about analyses of extent of changes. This kind of changes are not specified with percentage or ratio in social science research, but a ’p’ (probability) value is used. Significant amount of data is required to be able to work out accurately. In general, useful, practicable conclusions can be drawn from returning, multiple data of 30-50 users.

 

As this function requires the deepest sports science research, it is expected that most of the development will be needed in this field. Current state is only suitable to illustrate data connection and processing of data downloaded from central server, and display text content depending on them.