Professional Documents
Culture Documents
DP PDF
DP PDF
!"#$%&'()+,-./012345<yA|
MASARYK UNIVERSITY
FACULTY OF INFORMATICS
Cross-platform development
of smartphone application
with the Kivy framework
MASTER THESIS
ii
Acknowledgement
I would like to thank my supervisor Mgr. Juraj Michálek for his valu-
able help, comments, suggestions and time he spent helping me
with this work.
iii
Abstract
The purpose of the thesis is to analyze Kivy Framework (www.kivy.org)
and summarize its capabilities. The main goal is to deliver sufficient
information about the framework to decide on the possibility of its
use it in commercial development. The practical part is devoted to
a prototype application development that is used as a proof of con-
cept. The prototype helps to identify potential problems during the
implementation and deployment.
The text is structured in three parts. The first part familiarizes
the reader with the framework and dependent technologies. The
second part is concerned with using the collected information and
uses that as a base for developing the application. The last part va-
lidates the strengths and weaknesses of the framework during the
application’s development process and describes the problems found
during the implementation.
The results of this research are used as a decision point on whether
the Kivy Framework is suitable for commercial development in Y
Soft Corporation, a.s. The benefit of the thesis is that the compre-
hensive description of the Kivy Framework can be beneficial not
only to Y Soft Corporation but to any potential programmer who is
concerned with this framework and its potential use.
iv
Keywords
Kivy Framework, Python, KV language, Y Soft Corporation, a.s., YSoft
Safeq, REST, multiplatform development, user interface,
Raspberry Pi
v
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Thesis goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Kivy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Y Soft Corporation . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Kivy Framework Development . . . . . . . . . . . . . . . 6
2.1.1 Kivy Organization and Sister Projects . . . . . . 9
2.1.2 Community and Support . . . . . . . . . . . . . . 11
2.2 Development Environment . . . . . . . . . . . . . . . . . 12
2.2.1 IDE Configuration . . . . . . . . . . . . . . . . . . 16
2.2.2 Raspbery Pi . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Application Development using Kivy . . . . . . . . . . . 19
2.3.1 Python and KV language . . . . . . . . . . . . . . 21
2.3.2 Widgets and Behaviors . . . . . . . . . . . . . . . 22
2.3.3 Properties and Events . . . . . . . . . . . . . . . . 24
2.3.4 Clock and Animations . . . . . . . . . . . . . . . 25
2.3.5 Development Guidelines . . . . . . . . . . . . . . 26
2.3.6 Localization . . . . . . . . . . . . . . . . . . . . . . 27
2.4 OS-specific functionality . . . . . . . . . . . . . . . . . . . 29
2.5 REST, json and hal . . . . . . . . . . . . . . . . . . . . . . 29
3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 User interace . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.1 Defining GUI . . . . . . . . . . . . . . . . . . . . . 34
3.1.2 Components . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Animations . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Communication with Server . . . . . . . . . . . . . . . . 41
3.3 Development guidelines . . . . . . . . . . . . . . . . . . . 43
3.3.1 Code structure . . . . . . . . . . . . . . . . . . . . 44
3.3.2 Bad and Best Practices . . . . . . . . . . . . . . . 44
vi
3.4 Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.1 Windows . . . . . . . . . . . . . . . . . . . . . . . . 48
Problems . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Problems . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.3 OS X . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.4 Problems . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.5 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Problems . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.6 Android . . . . . . . . . . . . . . . . . . . . . . . . 53
Problems . . . . . . . . . . . . . . . . . . . . . . . 54
4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1 Other testing . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A Attachment Content . . . . . . . . . . . . . . . . . . . . . . . . 67
B Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
vii
List of Figures
2.1 Kivy Sister Projects 11
2.2 Kivy Simple application example 20
2.3 KV Language Sample 22
2.4 Kivy Properties Declaration 26
2.5 Sample Folder Structure 28
2.6 JSON and HAL example 31
3.1 Mockup describing general
workflow in developed application. 33
3.2 Print Tab Mockup 35
3.3 Screen Manager Division 36
3.4 Job Detail Modal Dialog 39
3.5 Layouts Example 40
3.6 Sub Tab Selectors Animation 42
3.7 Data Access Layer Architecture 43
3.8 SafeQ Folder Structure 45
3.9 KV language Inheritance Definition 47
3.10 PyInstaller specification file 49
4.1 Raspberry Pi Testing Results 61
B.1 Kivy architecture 69
B.2 Application livecycle 70
B.3 Event dispatching 71
B.4 List Adapter Principle 71
viii
Chapter 1
Introduction
Today, the market is filled with many platform and operating sys-
tems. When developing software, it is often necessary to implement
applications for every single system and support them separately.
However, a different approach exists. Implementing application once
and finding out how to run the application on the majority of plat-
forms on the market. One of the frameworks providing a support for
this development approach is the Kivy Framework. It allows to im-
plement an application once and then create a distributable pack-
age for the majority of operating system.
This thesis describes how to create an application using the Kivy
Framework, how creating distributable packages for the supported
platforms works and the inner workings of the framework itself.
1
1. INTRODUCTION
1.2 Kivy
Kivy is an open source community project for multi-platform deve-
lopment supporting most of the desktop and mobile platforms as
Windows, Linux, OS X, iOS and Android. It also allows to run appli-
cations on Raspberry Pi1 . The framework is written in Python and it
can be developed on all three supported desktop operating systems,
on Windows, Linux and OS X.
The first version of Kivy was released on February 1st, 2011. The
current version is 1.9.0, which was released in April 3, 2015 2.1. The
framework has a complete support for Python version 2.7.x. Deve-
lopment of a version with full support of Python 3.x, which is not
fully backward compatible with the previous major version [20], is in
progress. This is possible largely because of $5000 grant from PSF2 .
Kivy is published under the MIT license3 (version prior 1.7.2 are
under LGPL4 ), so it is business friendly and it is possible to use it in
commercial sphere. The main authors are Thomas Hansen, Christo-
pher Denter, Edwin Marshall, Jeff Pittman and Brian Knapp [8]. It
is not only one a core library. It also cooperates with sister projects
such as Python for Android, Kivy for iOS, Kivy Designer, Buildozer,
and others [10, 8].
This was only a brief review of Kivy, mostly from an organiza-
tional point of view to get an idea before the actual research. Tech-
2
1. INTRODUCTION
5. Three-dimensional space.
6. Program that does not require any external support (i.e. emulation) for run-
ning.
7. Application that is written with web technologies, and provided as native app-
lication using an embedded web browser.
3
1. INTRODUCTION
4
Chapter 2
Research
This chapter deals with Kivy in general. It contains a description of
the framework, its architecture and purpose. The main goal of this
part is to convey the main idea of the framework and its capabilities.
It also contains information about the authors and the organization
standing behind the framework. The framework is open source [11],
so the community is a really important part of it. That is why there is
a section about community, support and whole organization, about
its works and description about communication channels in section
2.1.1.
It is good to know the general idea of the development process.
When a programmer makes this initial step and wants to make the
application in a maintainable way, it is necessary to follow certain
rules to make the final application testable, extendable. The sec-
tions that follow in this chapter contain best practices and specific
guidelines. Information that is not covered by the official documen-
tation is written in the form of tips that are mainly based on practical
experience with development of the sample application.
Before the text starts digging down to various technical themes,
let’s summarize all the possible sources that Kivy offers for learning.
Since it is an open source framework which was launched only four
years ago according to the changelog 1 , there are not many sources
to learn from. The main resource is the documentation [7] which
includes an API reference. When a problem comes up during deve-
lopment, the best way to solve it to check the support google group
[4]. The group is called “Kivy users support”2 . This is usually the best
way how to solve any issues that come up during the development
5
2. RESEARCH
phase. There are nearly five thousand of threads and if not one co-
vering the programmer’s problem, it is possible to create a new one
and ask for help. Be aware that official documentation is connected
with the last developed version. The documentation for stable and
released versions are versioned using the Git versioning system 3 .
When a programmer starts writing the application, it is good to
know the basic concepts of the framework. An effective way on how
to get knowledge about the framework is to go through the tuto-
rial, which is part of the documentation. This tutorial is very basic.
A more detailed one is the Kivy Crash Course by Alexander Taylor4 .
This tutorial shows how to work with Kivy objects, describes its ca-
pabilities and explains particular behavior, e.g., setting the size of
widgets.
6
2. RESEARCH
7
2. RESEARCH
8
2. RESEARCH
9
2. RESEARCH
10
2. RESEARCH
Kivy Designer This tool enable to design the graphical user inter-
face (GUI) using the WYSIWIG7 concept. It provides a way for cre-
ating a definition of the GUI and customize widgets by KV language
2.3. This designer is written in Python using the Kivy Framework [6].
7. Acronym for: “What You See Is What You Get”. It is a way of editing documents
that provides a final appearance interpretation by the text editor itself.
11
2. RESEARCH
12
2. RESEARCH
3. Write code for the specified application and run it via com-
mand line.
13
2. RESEARCH
Windows 8.1
14
2. RESEARCH
OS X 10.9.5(Mavericks)
15
2. RESEARCH
16
2. RESEARCH
• Path: <KIVY>\kivy-2.7.bat
• Window Path: <KIVY>\kivywineenv-2.7.sh
• Library Path: <KIVY>\Python27\Lib
• Architecture: Depends on Windows architecture (x86/x64)
• Language version: 2.7
• Path Environment Variable: PYTHONPATH
17
2. RESEARCH
18
2. RESEARCH
interpreter, the path to Kivy in the bin folder is used. The problem
with syntax highlighting for KV files is the same as on Windows.
PyCharm configuration for Linux is exactly the same as on Win-
dows. It is different in case of OS X, though. It is necessary to perform
one additional step before development. That is the configuration of
the interpreter environment variables. This configuration can be set
in Run/Edit Configurations/Environment Variables in the
created interpreter in environment section, there is a property called
Environment variable. It is necessary to set these variables as it is
stated on the official Kivy manual referenced in the beginning of
subsection 2.2.1
2.2.2 Raspbery Pi
Kivy also offers a support for Raspberry Pi. This platform was not
included, but there is a prepared distribution for Raspberry [9] with
a manual and required resources about this approach.
19
2. RESEARCH
import kivy
kivy.require(’1.9.0’)
class MyApp(App):
def build(self):
return Label(text=’Hello world’)
if __name__ == ’__main__’:
MyApp().run()
20
2. RESEARCH
to the system. Above these two layers is a top level layer. This layer
is divided into the two sub-layers. The first layer encapsulates the
functionality of widgets in the widget tree and their visible defini-
tion described by the KV language and the second sub-layer ensures
connection between widgets tree and the second layer by modules
like Cache, Clock, Gesture, Event loop and properties. Whole archi-
tecture is summarized in figure B.1.
21
2. RESEARCH
<StyledButton@Button>:
text_size: self.size
font_size: ’25sp’
markup: True
<Controller>:
id: my_custom_label
info: str(self)
BoxLayout:
orientation: ’vertical’
padding: 20
StyledButton:
text: ’My controller info is: ’ + root.info
on_release: root.do_action()
Label:
id: my_custom_label
text: ’My label before button press’
22
2. RESEARCH
canvas that the widget contains. It is basically the most general build-
ing block that is used for an application construction.
Layouts are like managers that define where will the child wid-
gets be placed, and what size will they have. The base size of a widget
is inherited from the parent. In case of more child widgets, the sizes
are divided equally. It is possible to define the size ratio relatively
between sibling widgets or by an absolute value.
Kivy Framework provides a means of setting the concrete size
of the widget for the specific platform, display resolution or display
density. In combination with layouts, it is possible to create a com-
plex GUI that is responsive and able to be used on various devices.
23
2. RESEARCH
24
2. RESEARCH
cently added widget through the widgets in widget tree to the leaves
and then backwards. It is possible to reverse this order by calling
base implementation of a currently called callback on the parent
class. Another option is to process an event and kill the event in
the current callback method by returning the True value. By com-
bination of these approaches, it is possible to distribute events to all
the nodes in the widget tree and also to save the processor time by
killing the event after successful processing.
Creating a Kivy property automatically creates one event that is
fired every time the value is changed. The naming convention for
this event is on_<PROPERTYNAME>(). After that, it is possible to
bring a custom callback on this event or overwrite the implemen-
tation of this event.
17. Programing language used to make the web pages interactive and providing
a way of animating HTML elements by scheduling animation actions
https://www.javascript.com/.
25
2. RESEARCH
class MyClass(Widget):
presure = BoundedNumericProperty(1, min=0, max=100)
store_item_manager = ObjectProperty(null)
26
2. RESEARCH
2.3.6 Localization
27
2. RESEARCH
Sample application
|-- Presentation Layer
| |-- Initial Screen
| |-- Menu Screen
| |-- Setting Screen
| ‘-- Main Screen
| |-- Menu
| ‘-- Content
|-- Business Logic
| |-- Settings Provider
| ‘-- Data Provider
|-- Data Layer
| |-- Rest Service
| ‘-- Database Service
‘-- Resources
|-- Images
‘-- Resource Strings
bet, RTL and LRT layouts etc. Kivy does not provide an embedded
functionality to create multicultural GUI.
It is possible to implement this feature, but all of the functiona-
lity mentioned in the previous paragraph has to be implemented
from scratch. It is possible to create text widgets from the Kivy de-
fault set by inheritance and implementing them the required fun-
ctionality. To make these widgets able to display all special chara-
cters, it is possible to use encoding and custom font. To ensure that
these widgets show text in the defined language, it is possible to cre-
ate a Python class (language manager) that returns string according
to a language and string key. Then, in the Kivy KV language GUI defi-
nition, import this language manager and use it for setting text pro-
perty of text widgets. Custom font could be also used for rendering
font icons. The font uses vector graphics. This approach allows for
using scalable icons without the necessity to store images in all re-
quired sizes.
28
2. RESEARCH
The most complicated part is to defining the GUI for RTL18 cul-
tures. Kivy provides widgets that are able to work with input and out-
put text in LTR.L19 To be able to create a layout and text widgets in
RTL, it is necessary to implement the complete functionality. That
step requires complete knowledge about rendering, positioning and
animation implementation in Kivy Framework. To cover all the fun-
ctionality that provides Kivy, is it is necessary to add functionality to
all widgets including the text and layout ones.
18. Writing system where text starts on the right and continues to the left. This
system is used in Arabic speaking countries.
19. Writing system that starts writing on the left and continues to the right.
20. Extensible markup language that is used for structuring information in text.
21. Javascript Object Notation is definition of how the object in JavaScript can be
defined by text.
29
2. RESEARCH
30
2. RESEARCH
{
"name": "John Doe",
"balance": "150 EUR",
"billingCode": {
"code": "5.1",
"description": "Internal"
},
"hasEntitlement": true,
"userRights": [
"copyBw",
"copyColor",
"scan",
"printBw",
"printColor"
],
"logoutTimeout": 15,
"_links": {
"self": {
"href":
"et/v1/100000000027/auth/loggedUserInfo"
},
"printApplication": {
"href": "/et/v1/1000000000000027/jobs"
},
"scanApplication": null,
"copyApplication": null,
"billingCodesApplication": {
"href": "/et/v1/1000000000000027/billingCodes"
}
}
}
31
Chapter 3
Implementation
The output of this chapter is a set of development guidelines for po-
tential programmers, installable packages for all supported mobile
and desktop platforms and a list of obstacles blocking their creation.
Focus is put on structured description of problematic topics of de-
velopment in Kivy. Tips and guidelines are made by modern prin-
ciples of object oriented programming, such as dividing the pre-
sentation layer and the business logic or the Single Responsibility
Concept. These principles were taken from following the sources
[22, 14].
The goal is to create functional multi-platform client for Termi-
nal server REST API. This API provides set of functions for the man-
agement of printer actions. These actions are called jobs. Job is a
printable file sent into the printer with meta data used by the printer.
The final application connects to one specific printer. The specifica-
tion consists of a protocol, domain, port and path to accessing the
printer by the HTTP protocol. User logs in the job management in-
terface. After login, the user is able to manage jobs sent by himself
into the connected printer. This application is in general a client that
is able to visualize print jobs and provide user friendly interface to
manage these jobs. General workflow is shown on diagram 3.1.
The minimal part of the functionality the application provides
includes ability to log in into the specified printer using a PIN. An-
other part is managing print jobs, which includes previewing, send-
ing to print, marking as favorites. The last part is to preview the list
of billing codes and list help topics that are able to display manual.
32
3. IMPLEMENTATION
34
3. IMPLEMENTATION
Billing codes tab and a Help tab. These tabs are used for switching
the content of the zones on the right zone from tab buttons. A more
detailed description is in paragraph 3.1.2. Possible views are shown
in figures 3.2 and 3.3.
3.1.2 Components
35
3. IMPLEMENTATION
selected sub tab. These sub tabs are shown under the Sub Tab Menu
Manager. If one or more items in the print job list is selected, Sub
Tab Menu Manager changes its content from sub tab menu into the
selection menu. This change is visible in figure 3.2.
Login screen
36
3. IMPLEMENTATION
Main screen
The second screen contains complex information architecture. The
header contains a logo and one label for the current user name and
billing code and one styled button. The left tab panel is a group of
styled toggle buttons. The Kivy Framework does not provide as ro-
bust an API as is required for the left tabs. So the tabs are styled
toggle buttons with a constraint that enables to select exactly one
button. Switching the tab content is implemented by Tab Content
Manager described in subsection 3.1.2.
Zone managed by Tab Content Manager contains five type of lay-
out. Following description is sorted from the simples to the most
complex one. Copy and scan content is only an image describes how
to perform action on the printer, because it not possible to perform
these actions without presence of the user next to the printer. The
help tab is a group of five buttons. These are only styled buttons that
open a page with manual site about a specified topic. Billing codes
are a list of billing code items. This component is implemented as a
list view using dictionary adapters described in paragraph 3.1.2.
The most complex component managed by the Tab Content
Manager is the Print tab. This component contains three lists or-
ganized into the three tabs. Tab selectors are implemented as styled
toggle buttons, similarly to the tab selectors in the left tab panel. Ad-
ditional support for animation is also implemented. This feature is
described in 3.1.3. Lists contain print job items. The first list is called
“Waiting” and it contains jobs that are ready for print. “Printed” list
lists already printed and “Favorites” list displays job items that are
marked as favorites. Every item in every list has similar layout and
provides an information button for showing the modal dialog that
is described in paragraph 3.1.2. The last component is the selection
menu that is shown, if one or more job items are selected. Selection
menu offers actions for selecting or deselecting all items in the list
and the delete action. Delete button visibility depends on value of
the _show_delete_button boolean property. Delete action is vi-
sible only in list containing items ready to be printed.
37
3. IMPLEMENTATION
38
3. IMPLEMENTATION
39
3. IMPLEMENTATION
3.1.3 Animations
40
3. IMPLEMENTATION
41
3. IMPLEMENTATION
42
3. IMPLEMENTATION
43
3. IMPLEMENTATION
44
3. IMPLEMENTATION
SafeQ
|-- dataaccess
| |-- contracts
| ‘-- rest
| |-- auth
| |-- billingcodes
| ‘-- jobs
|-- images
‘-- ui
|-- loginscreen
‘-- mainscreen
|-- tablayout
| |-- billingtab
| |-- copytab
| |-- helptab
| |-- printtab
| | |-- favoriteslist
| | |-- printedlist
| | |-- topsubmenu
| | ‘-- waitinglist
| ‘-- scantab
‘-- topheader
45
3. IMPLEMENTATION
3.4 Packaging
46
3. IMPLEMENTATION
# loginscreencontent.kv
<FormItem@BoxLayout>: # loginscreencontent.kv
orientation: ’horizontal’ <PinNumberButton>:
label_text : ’default’ background_normal:
padding: 5,5 ’images/pinnumberbutton_normal.png’
Label: background_down:
id: item_label ’images/pinnumberbutton_down.png’
size_hint_y: None color: 0,0,0,1
size : self .texture_size font_name: ’DroidSans−Bold’
padding: 5,5
text : root. label_text
color: 0,0,0,1 # loginscreencontent.py
TextInput: from kivy.uix.button import Button
id: item_input
size_hint_y: None
size : item_label.size class PinNumberButtofn(Button):
padding: 5,5 pass
multiline: False
47
3. IMPLEMENTATION
3.4.1 Windows
Windows uses PyInstaller [15] as a packing tool. It is possible to down-
load PyInstaller using pip. This packaging tool and the Kivy portable
package are required to create a package for distribution. When a
developer wants to perform any action in the packaging process,
he is required to set all necessary environment properties as PATH,
PYTHONPATH etc. These settings can be performed automatically.
Simply run script file kivy.bat, located in Kivy portable package.
The first step is generation of the specification file. This specifi-
cation file is generated by running Pyinstaller main script
pyinstaller.py with parameter name and a value represents
a name of final package. Another parameter is path to main.py, the
bootstrap file containing entrance point into the application. It is
obligatory to name this file main.py. That is the most basic way
how to generate a new folder with specification file.This command
generates a default specification file with spec extension. There are
many possibilities how to change the configuration in generated file.
All of them are described in PyIstaller documentation [15]. The most
important result is a basic template for specification file. This file is
displayed in figure 3.10. Specification file has to be edited according
to Kivy documentation [7] or PyInstaller manual [15].
The second and the last step is to run application compilation.
This is performed by calling pyinstaller.py with path to spec-
ification file as an argument. The program collects all required re-
sources and compile them into one folder. This folder mostly con-
tains dll2 and pyd3 . It also contains Source code and some meta-
data.
2. Dynamic linked library - type of container for shared code using in Microsoft
technologies.
3. Python script made as DLL.
48
3. IMPLEMENTATION
49
3. IMPLEMENTATION
The most essential thing in this process is to set all the environ-
ment variables as was mentioned above. In case of skipping this
step, it is not possible to generate the specification file. It is impor-
tant to keep in mind that environment path setting is valid only for
one session of the command prompt. So the environment set up has
to be performed after every start of the command prompt.
Problems
3.4.2 Linux
50
3. IMPLEMENTATION
Problems
During the installation and running Kivy application on Linux Ubuntu
15.04, there were no problems to run the developed application and
any of the examples provided by the Kivy Framework.
3.4.3 OS X
Packaging application for this operating system is similar as on Win-
dows described in previous subsection 3.4.1. One requirement is a
portable package containing Kivy Framework. The second prereq-
uisite is also PyInstaller [15]. Generating the specification file is si-
milar, just with another argument windowed. Running the compi-
lation is the same. The only difference between OS X and Windows
is finalization. Windows package would be distributed as a folder.
OS X uses dmg6 files to distribute applications. The standard way to
create this image file is hdiutil7 tool. After the compilation, the
package contains most of the Kivy modules. It is possible to delete
the unused parts to reduce the package size. After this step is pro-
gram ready for distribution.
3.4.4 Problems
The first tested version of the OS X operation system was 10.11 (El
Capitan). During the compilation, PyInstaller writes into the ’/usr’
directory. This version of the OS X contains new System Integrity
Protection8 that blocks any writes into this folder. Deployable pack-
age was created on version OS X 10.9.5.
3.4.5 iOS
Packaging process for iPhones and iPads is the most complicated.
Prerequisites are summarized in table 3.2
51
3. IMPLEMENTATION
52
3. IMPLEMENTATION
Problems
The package for iOS was not created because the required mem-
bership to create the portable package is paid11 . That decision was
made with thesis supervisor.
3.4.6 Android
There are two main approaches on how to build applications for An-
droid. The first one is to copy the source code to the Android device
and run it by KivyLauncher12 . This application loads sources from
an SD card and provides Kivy runtime environment. Using this ap-
proach, it is impossible to publish the application on Android store,
however.
The second option is to compile the application locally and get
an APK file. Creating an APK can be performed using two approaches.
The first one is to use python-for-android descibed in paragraph
2.1.1. This process requires Android Software Development Kit
(SDK)13 and Android Native Development Kit (NDK)14 . After the in-
stallation, it is necessary to configure python-for-android and
53
3. IMPLEMENTATION
set location of Android SDK and NDK. The last step is to configure
APK package meta data and run the compilation process.
All steps described in the previous paragraph can be automated
by a tool called buildozer described in paragraph 2.1.1. To build
an application, it is required to generate a specification file. Edit the
configuration file and set the application package meta data, includ-
ing a list of required system permissions. After that, the rest of the
process is performed automatically by one command.
To create the package for Android, it is necessary to use the Linux
operating system. There are mainly two possibilities on how to do
that. The first one is to use a prepared virtual image with Linux with
already installed prerequisites. This approach is easier for installa-
tion, but it is hard to deploy application directly to an Android de-
vice from a virtual environment. The other choice is to install Linux
and all its prerequisites and use native installation. For the testing of
package compilation was used a native installation of Linux Ubuntu
15.04 and buildozer.
Problems
A recommended step before every single packaging is to update all
the required programs. Updating just a single support program can
block the compilation process.
The development application uses custom fonts called Font Awe-
some. File with font definition has to be copied between the stan-
dard font to enable the Kivy Framework to load it and include it into
the distributable package.
• .buildozer/android/platform/python-for-android/
dist/<PACKAGENAME>/private/
lib/python2.7/site-packages/kivy/data
• .buildozer/android/platform/python-for-android/
dist/<PACKAGENAME>/python-install/
lib/python2.7/site-packages/kivy/data/fonts
54
Chapter 4
Validation
This section describes the usability issues of the developed applica-
tion. This chapter is one of the most valuable for deciding whether
the Kivy Framework is appropriate for commercial use. The first part
is a usability test on the provided use case. In this, a specification
of the tested devices and terminal server, initial data on the server,
testing use case and results, is described. The rest of this chapter is
dedicated to additional testing and deployment on Raspberry Pi.
Initial data
Two print jobs are sent to the testing server. Both of them are in wait-
ing list. The first one is marked as a favorite. On this server, a testing
account is created.
55
4. VALIDATION
Tested Platforms
• Android 5.1 (Google Nexus 4)
Testing scenario
1. Run the application.
• Login screen with user name and password input is dis-
played.
2. Swipe right.
• Login option is switched to PIN.
3. Swipe Left
• Login option is switched back to user name and pass-
word.
4. Click OK
• Modal dialog about bad credentials is displayed.
5. Set user name and password according to testing account.
6. Click OK button.
• Login is successful.
• Main screen with tabs on the left sites is displayed.
56
4. VALIDATION
Results
Testing discovered that if it is possible to run the application, then
it is possible to go through the use case without a problem. In some
cases, it was not possible to run the application. Results of the test-
ing are summarized in table 4.1.
58
4. VALIDATION
System Result
Android 5.1 (Google Nexus 4) Executed without a problem dur-
ing the use case. One disadvan-
tage are long loading times of the
application. Time from applica-
tion start to the log in screen ren-
dering is about nine seconds.
Android 4.3 (Rockchip
tablet)
Android X.X (Samsung Same result as on Android 5.1
printer)
Windows Vista 32bit (Desk- Final package was made on 64-bit
top) environment, it is not possible to
run it in 32-bit Windows.
Windows 8.1 (Notebook) No problems during the use case.
The only disadvantage is that app-
lication run requires a visible com-
mand line window.
Windows 10 (Tablet Acer Ico- According to Kivy Windows 10 is
nia Tab 8) currently unsupported. It is not
possible to run a Kivy application
on this system.
Windows Server 2008R2 Running application ends with er-
ror: “The application has failed to
start because its side-by-side con-
figuration is incorrect.”
Linux Ubuntu 15.04 (Note- Linux does not required any
book) portable package. Just run the
source code. Testing did not
uncover any problems.
OS X 10.9.5 Mavericks (Mac Testing did not uncover any prob-
Mini) lems.
OS X 10.11 El Captain (Mac- Testing did not uncover any prob-
book Pro) lems. It is not possible to create
the distributable package, but it is
possible to run a package created
on previous versions- 59
4.2 Raspberry Pi
This section is beyond the scope of the thesis. The goal of the follow-
ing text is to test the application on a Raspberry Pi. For more infor-
mation on Raspberry Pi, go to the official site 1 . Raspberry Pi is, ac-
cording to Kivy official documentation, able to run Kivy source code.
There are three ways how you can prepare environment and run a
Kivy application. First two are by installing Linux (one for Raspbian
Jessie and the second for Raspbian Wheezy distribution) and Kivy
requirements separately. The third is to download an image con-
taining a preinstalled Kivy Framework and all its requirements.
Within this test, it was decided to use the image with preconfi-
gured system. The specific version of the computer is Raspberry Pi
B+. This computer will be controlled by mouse and keyboard con-
nected via the USB port. Internet network is connected by the RJ-45
port.
The goal of the test was to go through the use case described in
subsection 4. It was, however, not possible to go through with the
testing without first overcoming the following complications. The
preinstalled image does not contain the same set of fonts as Kivy on
other platforms. This could be fixed by copying font files to the sys-
tem. Another error that blocked passing the use case was caused by
keyboard input. One click on the keyboard wrote two same chara-
cters in the text input. This error made logging in impossible. After
setting user name and password to text inputs in code, it was pos-
sible to go through the use case. List of all discovered errors is sum-
marized in list 4.1
60
4. VALIDATION
• Input one character into the text input widget causes input
of two same characters (i.e hit “x” input “xx”)
61
Chapter 5
Conclusion
The main goal of this thesis was to find out whether the Kivy Frame-
work is sufficient for commercial development. All of the programs
and tools that were used during the development are distributed un-
der the licenses that allows commercial utilization. It is possible to
use all procedures described in the thesis in commercial sphere.
One of the main advantages in the research phase of the thesis
is that the framework supports multiple platforms. After the test-
ing phase, which included a creation of a distributable package and
deployment on the supported operating systems, the value of this
advantage degraded. It is necessary to make additional changes in
code to make the application run on all officially supported plat-
forms.
The basic set of the widgets provides sufficient functionality to
creating a basic GUI. It is possible to extend this functionality to sa-
tisfy complex user interface requirements. Architecture of the Kivy
Framework is not prepared for a fully localized application. Lack
of localization support, described in subsection 2.3.6, is one of the
main disadvantages in using the Kivy Framework for larger com-
mercial applications.
It is not possible to access many sensors on mobile devices with
the application. Access to devices sensors is described in paragraph
2.1.1. One of the requirement from Y Soft was to analyze the ability to
access camera for barcode scanning. Only Android supports taking
pictures by a camera.
The next disadvantage is the Kivy support. As it is a community
project, the support is provided by community and Kivy developers.
Support did not make any commitment on resolving raised issues.
This leads to a significant chance for unanswered queries to stall the
62
5. CONCLUSION
63
Bibliography
[1] Mobile analytics report [online].
https://www.citrix.com/content/dam/citrix/en_
us/documents/products-solutions/
citrix-mobile-analytics-report-february-2015.
pdf, [cit. 2015-09-27].
64
5. CONCLUSION
65
5. CONCLUSION
66
Appendix A
Attachment Content
As a part of the thesis, it contains:
67
Appendix B
Appendix
68
B. APPENDIX
Figure B.1: Kivy three layer architecture devided into build blocks.
69
B. APPENDIX
Figure B.2: Livecycle of a Kivy application with API for saving and
loading state [7].
70
B. APPENDIX
71
B. APPENDIX
72