Climbing Trainer

Mobile programming with android

Aleksi Olkkonen
Pekka Melgin

Project documentation
December 2015

Software engineering
ICT
 1

Content

1. Introduction.................................................................2

2. Objectives....................................................................3

3. Tools............................................................................ 3
1. Libraries.....................................................................................3

4. Use cases.....................................................................4

5. Mockups......................................................................5

6. Application architecture................................................5
1. Clean Architecture.....................................................................5
2. Presentation Layer.....................................................................6
3. Domain Layer............................................................................7
4. Data Layer.................................................................................7
5. UML diagrams............................................................................8

7. Product........................................................................9

8. Workload....................................................................11
 2

1. Introduction

This document is part of mobile programming with android course's

final project. This document describes the objectives of this project,
use cases, and also the structure of the application. Working group
consists of two party members, Aleksi Olkkonen and Pekka Melgin.
The objective of this final project is to know the basics of mobile
application programming with android using android apis and apply
them by creating an android app which could be later published to
google play store.

This documentation uses following domain specific terms related to

climbing:

Indoor climbing. Refers to the act of climbing in climbing

gyms. They have artificially made walls with climbing holds
that can be moved around and added as necessary. Indoor
climbing is useful for training strength and technique needed
in demanding outdoor climbing, in safe and controlled manner.

Grading, Grade. Gives the general difficulty of the route. There

are many different scales in which grades are presented, most
used of them are Hueco scale and Fontainebleau scale.

Route. Is a set of holds which defines the way that you climb
up.

Hangboard. It is a training tool specifically made for climbers

and increasing finger strength. They usually have varying
amounts of ledges and pockets with varying depths. Climber
hangs for desired time from the holds of hangboard.

Campus boards. It is a training tool for improving climbing

strength. Consists of wall with overhanging angle with evenly
 3

spaced rungs attached to it. Climber ascends and descends

the rungs using only hands.

2. Objectives

Objective of this project is to create android application to ease the

logging of climbing training(indoor climbing, hangboard training and
campus training). At the time of this project there were not any
particularly great apps for logging the training of climbing. Whilst
there were one or two good applications for logging hangboard
training, there weren't any which did all of the three aforementioned
functionalities. The intent of constructed application is to provide all
of the three functionalities in one application using modern design
language.

3. Tools

For this project the IDE used will be Android Studio 1.4.1 and
upwards.

1. Libraries

In order not to create all the wheels again, this project uses few first,
and third party libraries to ease the workload within the project
itself. These libraries mainly focus on the UI presentation of the
application. It enables us to create modern user experience without
us trying to make all the components by ourselves.

The libraries we used were:

com.android.support:appcompat-v7:23.0.1

o includes support for material design user interface

implementations

com.android.support:design:23.0.1
 4

o This design package provides APIs to support adding

material design components and patterns to your apps .

o Includes material design view components such as

Toolbar, Floating Action Button etc.

com.android.support:cardview-v7:23.0.1

o adds support for cardview widget, an implementation of

material design view pattern

com.android.support:recyclerview-v7:23.0.1

o provides support for RecyclerView widget. View for

efficiently displaying large data sets by providing a
limited window of data items.

com.flipboard:bottomsheet:1.4.3

o provides support for bottom sheet, a material design

pattern

com.gordonwong:material-sheet-fab:1.2

o provides support for morphing the floating action button

to a sheet of material

4. Use cases

as a user I want to add climb ascend so that I can later browse

through them

as a user I want to to add hangboard session so that I can later

browse what I have done

as a user I want to add campusing session so that I can later browse

what I have done
 5

as a user I want to see a summary of my most recent training days

so that I can review what I have been doing

as a user I want to browse individual

exercises(campus/hangboard/climb) so that I can have a glimpse of
what I have done

as a user I want to see statistical graphs about my performances so

that I can from time to time see how am I improving.

as a user I want to make different kind of session layouts to

hangboarding so that I can follow my own training plan

as a user I want to sync my workout sessions to google fit so that I

can track all my fitness activities in one place.
 6

5. Mockups
7
8
9
10
11
12
13
14
15
16
 17

6. Application architecture

1. Clean Architecture
The project's code base tries to follow a Clean architecture pattern
first mentioned by Robert C. martin in his blog post The Clean
Architecture, and later implemented into android development by
Fernando Docejas.
The main objective of any application architecture is to make
developing easier as the application grows. This helps to avoid
spaghetti style code in which everything is done in same class. Also
applying correct architecture patterns to the problem makes the
application more testable, thus reducing costs of QA and the amount
of possible bugs.
The clean architecture idea manages all of this, if done properly the
architecture should provide system that is:
Independent of frameworks. Does not depend on existence of
some library
Testable. All of the components, UI, database logic, business
logic can be tested with unit tests without other components
Independent of UI. The UI of the application can be easily
changed without changing the rest of the application
Independent of database. Database can be switched easily,
data can come from cloud, or internal store.
Independent of any external agency. Business rules does not
know anything about outside world.
Most of this can be achieved within context of an android project.
Although there are some problems that this kind of architecture
brings when developing on android platform. Especially if we were to
try make the project as testable as possible with unit tests, which
means dependencies should be done using dependency inversion
principle. One such problem emerges when using anything that
needs context. Such as using the SQLite database that android
platform provides. When connecting to the SQLite we need to use
SQLiteOpenHelper class which needs to have the context of the
application in constructor. This creates all kinds of problems of
making the layers independent, and unit testable, because the
context then needs to be passed all the way from the UI layer to the
 18

data access layer. Though these kind of problems should be easily

avoided by using any available dependency injection framework,
such as dagger 2. Using any dependency injection frameworks
though are out of this project's scope and may be implemented in
future.
Clean architecture approach also uses some vocabulary which
makes the architecture easier to understand:
Entities: Entities are the business objects of the application.
Business objects holds a set of attributes and also can contain
behaviour.
Interactor: Interactors are where the logic of the application is.
It contains the application specific business rules. Interactors
use business objects. These contains operations such as
logging user to the service. They also can be called Use cases.
Interface Adapters: These adapters convert data from the
format most convenient for the use cases and entities.
Presenters belong here.

2. Presentation Layer

Presentation layer consists of all the logic that is needed for the user
interface. This includes activities, fragments, and adapters. In this
project we use Model-View-Presenter pattern. Our activities and
fragments are views in this case. The presentation layer only holds
all the logic that is used for the user interface. This includes custom
adapters.
 19

3. Domain Layer

This is the domain of interactors. Presenters give data to interactors,

they do what they're supposed to do with it, give it to mappers, and
return results to presenters. Best case scenario is, that all code here
is pure java, all android things are in activities. This project follows
this rule, except for mappers, which require android context (passed
from activity through all layers to mapper). See section 5, UML
diagram.

4. Data Layer

Workouts (=practices) are like a training days, which can contain

multiple campus, climb and hangboard exercises. Hangboard
exercises are handled as sessions which contains one or many
hangboard training sets.

User adds different exercises and the application automatically

creates workouts, and assigns exercises to it. Day's exercises are
normally grouped as one workout, but if there is a large gap
between groups of exercises, application separates them as different
workouts.
 20

5. UML diagrams

The following UML diagram shows how the classes are related to
each other in general. Due to sheer amount of classes more precise
uml class diagrams are not provided.

6. Activities, classes

There are in total 8 activities, 58 classes 11 interfaces used in this

project. The classes are separated by top level use case folders.

the 8 activites are following:

 21

mainActivity : the activity in where the application launches, holds

the feeds and main pagerview with fragments

campusAcitvity: used for adding campus exercises

practiceDetailActivity: used for practice session details,uses

fragments in viewpager

settinsActivity: for the settings page

practiceBrowserActivity: for browsing history (all practice sessions in

cards)

overviewActivity: for all time stats

 22

7. Product
23
 24

8. Workload

The development phase of project took about 55 hours of work.

sources:

http://fernandocejas.com/2014/09/03/architecting-android-the-clean-
way/
https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-
architecture.html
https://en.wikipedia.org/wiki/Model%E2%80%93view
%E2%80%93presenter