Business Card Application

sacktoysΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 5 μήνες)

112 εμφανίσεις



February
, 2011



Business Card Application

On Android


Submitted by:

Koren Shoval

Eyal Segal


Advisor:

Nethanel Azuleus





Index

1.

INTRODUCTION

................................
................................
................................
................................
...........................

4

1.1.

ABOUT ANDROID

................................
................................
................................
................................
....................

4

1.2.

PROJE
CT GOALS

................................
................................
................................
................................
......................

4

1.3.

WORKING ENVIRONMENT

................................
................................
................................
................................
......

5

2.

SYSTEM OVERVIEW

................................
................................
................................
................................
.....................

6

2.1.

TECHNOLOGIES

................................
................................
................................
................................
.......................

8

2.1.1.

BLUET
OOTH

................................
................................
................................
................................
........................

8

2.1.2.

ENCRYPTION

................................
................................
................................
................................
.......................

9

3.

USE CASES

................................
................................
................................
................................
................................
.

11

3.1.

UC01
-

BUSINESS CARD EDITOR

................................
................................
................................
.............................

11

3.1.1.

UC0101
-

CREATE CARD

................................
................................
................................
................................
.....

11

3.1.2.

UC0102
-

EDIT CARD

................................
................................
................................
................................
..........

12

3.1.3.

UC0103
-

CREATE ITEM LAYOUT

................................
................................
................................
........................

12

3.1.4.

UC0104
-

EDIT ITEM LAYOUT

................................
................................
................................
.............................

13

3.1.5.

UC0105
-

POSITION ITEM ON A C
ARD

................................
................................
................................
...............

13

3.1.6.

UC0106
-

MANAGE ALL ITEMS

................................
................................
................................
...........................

14

3.1.7.

UC0107
-

CREATE NEW THEME FRO
M A CARD

................................
................................
................................
..

14

3.1.8.

UC0108
-

APPLY A THEME

................................
................................
................................
................................
.

15

3.1.9.

UC0109
-

SET BACKGROUND FROM
ANDROID GALLERY

................................
................................
....................

15

3.2.

UC02


TABS BROWSE

................................
................................
................................
................................
...........

16

3.2.1.

UC0201
-

BROWSE FOR A CARD

................................
................................
................................
........................

16

3.2.2.

UC0202
-

SEARCH FOR A CARD

................................
................................
................................
..........................

16

3.2.3.

UC0203
-

CREATE FOLDER

................................
................................
................................
................................
.

17

3.2.4.

UC0204
-

RENAME FOLDER

................................
................................
................................
...............................

17

3.2.5.

UC0205
-

DELETE FOLDER

................................
................................
................................
................................
..

18

3.2.6.

UC0206
-

USE A BUSINESS CARD
(SMS, CALL, EMAIL, E
TC.).

................................
................................
..............

18

3.2.7.

UC0207
-

MOVE A CARD BETWEEN
FOLDERS

................................
................................
................................
....

19

3.3.

UC03


GALLERY BROWSER

................................
................................
................................
................................
...

20

3.3.1.

UC0301
-

BROWSE FOR A CARD

................................
................................
................................
........................

20

3.3.2.

UC0302
-

SEARCH FOR A CARD

................................
................................
................................
..........................

21



3.3.3.

UC0303
-

CREATE FOLDER

................................
................................
................................
................................
.

22

3.3.4.

UC0304
-

RENAME FOLDER

................................
................................
................................
...............................

22

3.3.5.

UC0305
-

DELETE FOLDER

................................
................................
................................
................................
..

23

3.3.6.

UC0306
-

USE A BUSINESS CARD
(SMS, CALL, EMAIL, E
TC.)

................................
................................
...............

23

3.3.7.

UC0307
-

MOVE A CARD BETWEEN
FOLDERS

................................
................................
................................
....

24

3.4.

UC04


BLUETOOTH

................................
................................
................................
................................
..............

25

3.4.1.

UC0401
-

SEND BUSINESS CARD V
IA BLUETOOTH

................................
................................
.............................

25

3.4.2.

UC0402
-

RECEIVE A BUSINESS C
ARD

................................
................................
................................
................

27

4.

DESIGN & IMPLEMENTAT
ION

................................
................................
................................
................................
....

28

4.1.

BACKGROUND SERVICE

................................
................................
................................
................................
.........

30

4.2.

NOTIFICATIONS

................................
................................
................................
................................
.....................

32

4.3.

STORAGE SERVICE

................................
................................
................................
................................
.................

34

4.4.

BLU
ETOOTH & ENCRYPTION
................................
................................
................................
................................
..

35

4.4.1.

SEND
-

RECEIVE SEQUENCE

................................
................................
................................
...............................

38

4.4.2.

ENCRYPTION SEQUENCE

................................
................................
................................
................................
...

39

4.5.

BUSINESS CARDS DATA
STRUCTURES

................................
................................
................................
....................

41

4.6.

BUSINESS CARD EDITOR

................................
................................
................................
................................
........

43

4.7.

BUSINESS CARDS TABS
STYLE BROWSER

................................
................................
................................
...............

45

4.8.

BUSINESS CARDS GALLE
RY STYLE BROWSER

................................
................................
................................
.........

4
7

5.

OPTIMIZATIONS

................................
................................
................................
................................
........................

49

6.

REFERENCE
S

................................
................................
................................
................................
..............................

50






1.

Introduction

1.1.

About Android

Android is an operating system, developed for mobile
phones as open source code
.

The OS init
ially developed by Android Inc.
, which later was bought by Google in 2005. The Android is based
on a modified version of Linux kernel, and provides a Java based libraries for application development.

Today, there is a large community of developers which extends the Android devices abili
ties.

Currently, there are over 200,000 applications available for Android.

Android supports many known standards, including graphical abilities (OpenGL ES), database analysis
(SQLite), data encryption and much more.


In this project we used Android API
level 8 (Version 2.2)


1.2.

Project Goals

One of our main goals in this project was to learn how to use Android API in order to develop an application
for mobile phones. This includes understanding the way Android works in every aspect, and apply our
knowledge

with the Android SDK. Part of this main goal is to understand how a graphical user interface
works in one device or how it fits into many different devices, and to build such a GUI.


Another important
goal is to successfully transmit data from one device
to another, using Bluetooth
protocol. The transmission consists of pairing two devices, connecting them and sending/receiving the data.


The last goal was to make sure that the data can be transferred safe, according to user choice, using
encryption protoc
ol. This includes authentication process between two users who want to exchange data.


To implement all these goals,
we selected
an application
that manages
business cards collection and

allows
transferring

them between users with or without authentication
.






1.3.

Working Environment

The OS we worked with is Windows Vista x86. Our development tools included the Eclipse IDE for Java, the
Android S
DK and emulators, Eclipse Memory
Analyzer and

two HTC mobile devices.


For developing
, building and debugging

Android code, we used Eclipse IDE for Java and Android
ADT
for
eclipse.

At first, in order to simulate Android mobile phones, we used Android emulators which gave us the
opt
ion to develop and debug on PC. Most of the development effort and testing was mad
e on the HTC
devices, since the emulators do not support bluetooth at this point.
After the application was ready, we
used Eclipse Memory Analyzer in order to examine our memory usage.






2.

System
O
verview

This application is for managing business cards col
lection. It consists of your
own personal designed cards and received cards from your colleagues. You can
design a business card, use pictures from the gallery as background, add your
preferred details to the card and customize its layout, font and color.






The application offers several themes that can be applied to your new card. You can also create a theme
from any card, and later apply it to other cards.




In this application, you can manage your cards in two different ways


the gallery
browser or the tabs browser, that provide different ways of cards presentation.

In
both ways, you can manage your folders, create new ones, rename and delete
existing ones,

and do the same with your cards.







Browsing by tabs

Main
s
creen

Editing a c
ard

Cards as icons



As for your cards, if a card has the relevant details, you can use it to call the phone number on the card, send
SMS or Email, and send the card to your colleagues using Bluet
ooth. The data can be encrypted and
authenticated, according to your choice.


Another interesting option is to automatically generate cards for your contacts list. Each contact in the
phone would have its own card with the contact details.


A card can be
sent via Bluetooth by selecting a card and a remove device to send it to. The transmission
takes place in the background and the user is able to view the progress through Android’s notification bar.
When the card arrives at the receiver, the card is displ
ayed and can be accepted or declined.






Receiving in progress…

Select a device

Save Card?



2.1.

Technologies

2.1.1.

Bluetooth

Bluetooth

is a proprietary

open wireless

technology standard for exchanging data over short distances
.

The Bluetooth
specifications are developed and licensed by the

Blueto
oth Special Interest Group

(SIG),
which consists of more than 13,000 companies all over the world.


There are many advantages of using Bluetooth as a data transfer method. Among them
is

low power
consu
mption, which is one of the most problematic issues in the mobile phones world, high data throughput
and high communication distance (depends on Bluetooth hardware).


Android

API
Level
8 (version 2.2)
supports
Bluetooth 2.1

.

Its throughput is about
1.4Mbit/sec and its maximum distance can reach 100 meters (class 1).

To enable Bluetooth usage, Android uses

two main protocols:



SDP


service discovery protocol:

Used to allow devices to discover what services each other support, and what parameters to us
e to
connect to them. For example, when connecting a mobile phone to a Bluetooth headset, SDP will be
used to determine which

Bluetooth profiles

are supported by the headset (headset profile,

hands free
profile,

advanced audio distribution profile, etc.) a
nd the protocol multiplexor settings needed to
connect to each of them. Each service is identified by a

Universally Unique Identifier

(UUID), with official
services (Bluetooth profiles) assigned a short form UUID (16 bits rather than the full 128)



RFCOMM


Radio frequency communication
:

The
RFCOMM
protocol is a simple set of transport protocols, made on top of the

L2CAP

protocol,
providing emulated

RS
-
232

serial ports

(up to sixty simultaneous connections to a Bluetooth device at a
time). The protocol is
based on the ETSI standard TS

07.10.

RFCOMM is sometimes called

serial port
emulation. The Bluetooth

serial port profile

is based on this protocol. RFCOMM provides a simple
reliable data stream to the user, similar to TCP. It is used directly by many telep
hony related profiles as a
carrier for AT commands, as well as being a transport layer for OBEX over Bluetooth.

Many Bluetooth
applications use RFCOMM because of its widespread support and publicly available API on most
operating systems. Additionally, app
lications that used a serial port to communicate can be quickly
ported to use RFCOMM
.



With the Bluetooth API, a user can scan for other Bluetooth device
s, connect or pair with them,

query for
paired Bluetooth devices, establish RFCOMM channels/sockets, connect to a specified socket on
a remote
device

or transfer data to and from
it.


2.1.2.

Encryption

The Java
security APIs spans

a wide range of areas. Cryptographic and public key infrastructure (PKI)
interfaces provide the underlying basis for developing secure applications. Interfaces for performing
authentication and access control enable applications to guard against unauthori
zed access to protected
resources.


The APIs allow for multiple interoperable implementations of algorithms and other security services.
Services are implemented in

providers, which are plugged into the Java platform via a standard interface
that makes it
easy for applications to obtain security services without having to know anything about their
implementations. This allows developers to focus on how to integrate security into their applications, rather
than on how to actually implement complex security m
echanisms.

The Java platform includes a number of providers that implement a core set of security services. It also
allows for additional custom providers to be installed. This enables developers to extend the platform with
new security mechanisms.


The Ja
va cryptography architecture is a framework for accessing and developing cryptographic functionality
for the Java platform. It includes APIs for a large variety of cryptographic services, including
:



Message digest algorithms



Digital signature algorithms



Sy
mmetric bulk encryption



Symmetric stream encryption



Asymmetric encryption



Password
-
based encryption (PBE)



Elliptic Curve Cryptography (ECC)



Key agreement algorithms



Key generators



Message Authentication Codes (MACs)





(Pseudo
-
)random number generators


The
Java platform includes built
-
in providers for many of the most commonly

used cryptographic algorithms,
including the RSA and DSA signature algorithms, the DES, AES, and ARCFOUR encryption algorithms, the
MD5 and SHA
-
1 message digest algorithms, and the Dif
fie
-
Hellman key agreement algorithm. These default
providers implement cryptographic algorithms in Java code.


EKE


Encrypted Key Exchange

Encrypted Key Exchange

(also known as

EKE) is a family of

password
-
authenticated key agreement

methods
described by

Steven M. Bellovin

and Michael Merritt. Although several of the forms of EKE in this paper
were later found to be flawed, the surviving, refined, and enhanced forms of EKE effectively make this the
first method to amplify a shared

password

into a shared ke
y, where the

shared key

may subsequently be
used to provide a

zero
-
knowledge password proof

or other functions.

In the most general form of EKE, at
least one party encrypts an ephemeral (one
-
time) public key using a password, and sends it to a second
party
, who decrypts it and uses it to negotiate a shared key with the first party.


A second paper describes Augmented
-
EKE, and introduced the concept of

augmented

password
-
authenticated key agreement

for client/server scenarios. Augmented methods have the adde
d goal of
ensuring that password verification data stolen from a server cannot be used by an attacker to masquerade
as the client, unless the attacker first determines the password (e.g. by performing a brute force attack on
the stolen data).



A version o
f EKE based on

Diffie
-
Hellman, known as DH
-
EKE, has survived attack and has led to improved
variations, such as the

PAKfamily of methods in

IEEE P1363.2.








3.

Use Cases

In the following section we will describe the use cases for the application according to the project goals and
usage scenarios. These will later be used in the
application design
.


3.1.

UC01
-

Business Card
Editor

T
hese use cases describe
usage scenarios for
the business card editor activity
.


3.1.1.


UC0101
-

Create card

This use case describes creation of a new business card. It is triggered by st
arting the card editor from the
main screen.


-

Main s
cenario

1.

User starts card editor (from main)

2.

A card is generated
using the default theme

3.

A popup screen opens and lets user edit item values

4.

User edits
default items and clicks “save”

5.

The popup cl
oses showing the editor surface

6.

The user clicks on menu option “save as” and saves the card

7.

A save dialog opens and the user

selects where to save the card and it
s filename

8.

Users clicks “ok” and the card is saved


-

Exceptions

4.

User clicks “cancel” or presses the back button in the popup

screen and the changes are ignored.

8.

User clicks “cancel” in save dialog






3.1.2.

UC0102
-

Edit card

This use case describes editing of an existing card. It is triggered from
main screen.


-

Main scenario

1.

User starts cards browser

2.

User selects the wanted folder

3.

User browse for the card to edit

4.

User clicks on menu option “Edit”

5.

The editor opens with the sel
ected card


3.1.3.

UC0103
-

Create item layout

This use case describes creation of new business card item when creating or editing a card. It is triggered by
the user at the editor surface screen.


-

Main Scenario

1.

User clicks on menu option “Add Item”

2.

Layout dialog

opens with the item’s information

3.

User edits item’s text content

4.

User updates item’s type, style and color

5.

User clicks on “ok” button to save the changes

6.

Editor gets back the updated item, save the changes to the card and updates the surface


-

Exceptions

6.

User
clicks “cancel” or presses the back button in the dialog screen and the changes are ignored.






3.1.4.

UC0104
-

Edit item layout

This use case describes how to edit a business card item that is already on the card’s surface.

It is triggered by the user at
the editor surface.


-

Main Scenario

1.

User clicks on
surface where the item’s bounding box should be

2.

The top item with a bounding box that contains the clicked position will be selected and several
options will show on the side of the item (delete, edit, move
)

3.

User clicks on the “edit” option

4.

Layout dialog opens with the item’s information

5.

User edits item’s text content

6.

User updates item’s type, style and color

7.

User clicks on “ok” button to save the changes

8.

Editor gets back the updated item, save the changes
to the card and updates the surface


-

Exceptions

7.

User clicks “cancel” or presses the back button in the dialog screen and the changes are ignored.


3.1.5.

UC0105
-

Position item on a card

This use case describes how to move a business card item on the surface of
the card. It is triggered by the
user and s
tarts at the editor surface
.


-

Main Scenario

1.

User clicks on an item

2.

Editor surface shows edit, remove and drag buttons and a frame around the item

3.

The user presses on the surface inside the frame or on the drag but
ton and drags the item on the
surface to its new position

4.

The editor surface saves the changes to the card


-

Exceptions

2.

User clicks outside of the item’s frame to cancel the item’s selection.



3.1.6.

UC0106
-

Manage all items

This use case describes how to edit
all of the business card items at once. It is triggered by the user and
s
tarts at the editor surface
.


-

Main Scenario

1.

User clicks on
menu option “Items”

2.

Items dialog opens with a list the card’s items

3.

User edits each item’s value and selects “Save”

4.

The
editor surface saves the changes to the card


-

Exceptions

3.

User clicks
back or “Cancel” and the changes are discarded


3.1.7.

UC0107
-

Create new theme from a card

This use case describes creating a new theme based on an existing card. It is triggered from editor

surface.

-

Main Scenario

1.

User clicks menu option “save as theme”

2.

A “save as…” dialog pops up

3.

User enters the name of the
new theme and presses “ok”.

4.

The theme is saved to storage


-

Exceptions

4.

User clicks
on “Cancel
.

The theme is not created







3.1.8.

UC0108
-

Apply a theme

This use case describes how to apply a theme on a business card. It is triggered by the user and s
tarts at the
editor surface
.


-

Main Scenario

1.

User clicks on menu option “Set Theme”

2.

A themes gallery popup with the first theme applied to the
card.

3.

User swipes left or right to iterate between themes, each swipe alters the layout of the card
according to the current theme.

4.

User clicks on “Select theme” and the theme is set on the card

5.

Editor gets the result back from the themes gallery and set
the updates business card on the surface.


-

Exceptions

4.

User clicks the back button and the changes are ignored.


3.1.9.

UC0109
-

Set background from android gallery

This use case describes setup of card background, which is chosen from phone gallery. It is trigger
ed from
editor surface
.

-

Main Scenario

1.

User clicks on

menu option

“Set background”


2.

The phone gallery opens

3.

User
clicks on

the
wanted picture

4.

The editor surface returns, and the selected picture is set as background





3.2.

UC02


Tabs
Browse

These use cases
describe usage scenarios for the business card tabs browser

activity
.


3.2.1.

UC0201
-

Browse for a card

This use case describes how to locate a business card inside the tabs browser. It is triggered by the user and
s
tarts at the
main activity
.


-

Main Scenario

1.

Use
r cl
icks on “browse” button at main.

2.

Browse activity opens up to show the default search tab

3.

User selects the folder with the card by clicking the folder’s tab

4.

The tabs view updates the list of cards to display the cards in the current folder

5.

User scrolls
to the requested card and clicks on the card to select it


3.2.2.

UC0202
-

Search for a card

This use case describes how to locate a business card inside the tabs browser. It is triggered by the user and
s
tarts at the
browser’s default tab
.



-

Main Scenario

1.

User
clicks on “
Search


tab

2.

Browse activity
moves to the Search tab and shows all available cards

3.

User
clicks on the search text box and the keyboard appears

4.

User writes a set of characters or words to find

5.

Browse activity hides cards that do not contain the
search text

6.

User scrolls to the requested card and clicks on the card to select it






3.2.3.

UC0203
-

Create folder

This use case describes creation of a new folder. It is triggered from tabs browser screen.


-

Main Scenario

1.

User clicks the “New…” tab or chooses
menu option “Create folder”

2.

An input dialog pops up

3.

User inserts the new folder name and clicks “Ok” button

4.

The folder is created and appears as a tab


-

Exceptions

3.

User clicks the back button or “Cancel” button and the folder is not created.

3.

User enters an

existing name. The current tab is changed to the existing tab, and no new folder is
created

3.

User enters a forbidden name (“New…”, “Contacts”, “Search”). No folder is created and the last
used tab is active again


3.2.4.

UC0204
-

Rename folder

This use case
describes renaming of an existing folder. It is triggered from tabs browser screen.


-

Main Scenario

1.

User selects the folder he want to rename

2.

User clicks on menu option

Rename folder” while no card is selected

3.

An input dialog pops up

4.

User inserts the new
folder name and clicks “Ok” button

5.

The folder is
renamed

and appears as a tab

with the new name


-

Exceptions

4.

User clicks the back button or “Cancel” button and the folder is not
renamed
.




3.2.5.

UC0205
-

Delete folder

This use case describes how to remove a busin
ess card using the tabs browser. It is triggered by the user and
s
tarts at tabs
browse activity


-

Main Scenario

1.

User selects a specific folder by clicking its tab

2.

User chooses menu option “Delete folder”

3.

A confirmation dialog pops up

4.

User clicks “Ok”
button and the folder is deleted


-

Exceptions

4.

User clicks the back button or
“Cancel” button and the folder
is not deleted.


3.2.6.

UC0206
-

Use
a
business card

(SMS, Call, Email, etc.)
.

This use case describes usage of a business card, in order to call existing
phone number, send Email or SMS,
and send via bluetooth. It is triggered from tabs browser screen


-

Main Scenario

1.

User selects a specific folder by clicking its tab

2.

User
searches the wanted card in the list

3.

User selects the card


4.

User clicks
on menu
button

and chooses the wanted action from the enabled actions






3.2.7.

UC0207
-

Move a card between folders

This use case describes how to move a business card from one folder to another using the tabs browser. It is
triggered by the user and
s
tarts at tabs
browse
activity


-

Main Scenario

5.

User selects the
specific
card

6.

User chooses menu option “
Move


7.

A
folder selection
dialog pops up

8.

User
selects the folder to move the card to and
clicks “Ok”

9.

The card is moved to the selected tab and the Browser sets that tab as the

current view


-

Exceptions

5.

User clicks the back button or “Cancel” button and the

user returns to the current tab
.







3.3.

UC0
3



Gallery
Browse
r


These use cases describe usage scenarios for the business card
gallery browser

activity
.


3.3.1.

UC0
3
01
-

Browse for a
card

This use case describes browsing a card within the gallery browser. It is triggered from main screen.


-

Main Scenario

1.

User clicks on “browse” button at main

2.

Browse activity opens up to show the
first folder in the gallery

3.

User
finds and clicks

the folder with the card by
swiping the folders

4.

A
list of cards
in the selected folder is shown

5.

User
swipes on the cards in order to browse the wanted card


-

Branch

3b.

User flips up the view

3b.1

Explorer view is opened with all of the folders as little icons

3b.2

User

clicks on the wanted folder

3b.3

Continue to step 4


5b.

User flips up the view

5b.1

Explorer view is opened with all of the cards as little icons

5b.2

User
clicks on the wanted card

5b.3

The card is shown on full screen






3.3.2.

UC0
3
02
-

Search for a card

This use case describes how
to locate a business card inside the gallery browser. It is triggered by the user
and s
tarts at the
browser’s first screen
.


-

Main Scenario

1.

Browse activity opens up to show the
first folder in the gallery

2.

The user swipes down the screen and the search line
appears

3.

The user clicks on the search line and the keyboard appears

4.

The user writes down the string sequence he wants to search for

5.

All the cards with an item that contains such string will appear as list


-

Branch

2b.

If the user wants to search inside specific

folder

2b.1

User swipes to a specific folder and clicks it

2b.2

The user swipes down the screen and the search line appears

2b.3

Continue to step 3


2b.1b.

User flips up the view

1b.1

Explorer view is opened with all of the folders as little icons

1b.2

User
clicks on the wanted folder
he wants to search in

1b.3

Continue to step 2b.2







3.3.3.

UC0
3
03
-

Create folder

This use case describes creation of a new folder. It is triggered from gallery browser screen.


-

Main Scenario

1.

User clicks
on menu option

Create folder"

within the folders view

2.

An input

dialog pops up

3.

User inserts the new folder name and clicks “Ok” button

4.

The folder is created


-

Exceptions

3.

User clicks the back button or “Cancel” button

and the folder is not created

3.

User enters an existing name.
No new folder is created

3.

User enters a forb
idden name (“New…”, “Contacts”, “Search”). No folder is created


3.3.4.

UC0
3
04
-

Rename folder

This use case describes renaming of an existing folder. It is triggered from
gallery

browser screen.


-

Main Scenario

1.

User
swipes the folders and
selects the folder he
want to rename

2.

User clicks on menu option “Rename folder”

3.

An input dialog pops up

4.

User inserts the new folder name and clicks “Ok” button

5.

The folder is renamed


-

Exceptions

4.

User clicks the back button or “Cancel” button and the folder is not renamed.






3.3.5.

UC0
3
05
-

Delete folder

This use case describes how to remove a business card. It is triggered by the user and
s
tarts at
gallery

browser
.


-

Main Scenario

1.

User selects a specific folder by
swiping the folders


2.

User chooses menu option “Delete folder”

3.

A confirmation dialog pops up

4.

User clicks “Ok” button and the folder is deleted


-

Exceptions

4.

User clicks the back button or “Cancel” button and the folder is not deleted.


3.3.6.

UC0
3
06
-

Use
a
business card (SMS, Call, Email, etc.)

This use case describes usage

of a business card, in order to call existing phone number, send Email or SMS,
and send via Bluetooth. It is triggered from gallery browser screen.


-

Main Scenario

1.

User selects a specific folder by
swiping the folders

and clicks the folder

2.

User
searches
the wanted card in the list by swiping the cards

3.

User clicks on menu button and chooses the wanted action from the enabled actions


-

Branch

1b.

User flips up the view

1b.1

Explorer view is opened with all of the folders as little icons

1b.2

User
clicks on the wanted
folder he wants to enter

1b.3

Continue to step 2






3.3.7.

UC0
3
07
-

Move a card between folders

This use case describes how to move a business card from one folder to another using the gallery browser. It
is triggered by the user and
s
tarts at
the gallery browser.


-

Main Scenario

1.

User selects a specific folder by
swiping the folders

and clicks the folder

2.

User searches the wanted card in the list by swiping the cards

3.

User chooses menu option “
Move


4.

A
folder selection
dialog pops up

5.

User
selects the folder to move the card to and
clicks “Ok”

6.

The card is moved to the selected folder


-

Branch

1b.

User flips up the view

1b.1

Explorer view is opened with all of the folders as little icons

1b.2

User
clicks on the wanted folder he wants to enter

1b.3

Continue to
step 2


2b.

User flips up the view

2b.1

Explorer view is opened with all of the cards in the folder as little icons

2b.2

User
clicks on the wanted card

2b.3

Continue to step 3


-

Exceptions


5.

User clicks the back button or “Cancel” button and the user returns to the current
tab.





3.4.

UC0
4



Bluetooth

These use cases describe usage scenarios for
sending and receiving
business card
s via Bluetooth
.


3.4.1.

UC0
4
0
1

-

Send business card via Bluetooth

Starts at browser with a selected card


-

Main Scenario

1.

User clicks on menu option "Send”

2.

Device picker opens up with a list of paired devices

3.

User clicks on a device

4.

Connection is made with the device

5.

The card is sent to the remote device

6.

Application waits for a status response

7.

Application displays the status to the user


-

Branch

3.

If the device

is not in the known device list

3b.1

User clicks on “Scan for new devices”

3b.2

Application request device detection

3b.3

Each detected device is added to the list

3b.4

User clicks on a device

3b.5

Continue to step 4


5b.


If encryption is enabled

5b.1

Application asks user for a password

5b.2

User inserts an agreed upon password and clicks “ok”

5b.3

Application starts the EKE protocol to agree on a secret key

5b.4

Application sends an encrypted card using the key

5b.5

Continue to step 6






-

Exceptions

1.

If bluetooth is not enab
led ask user to enable bluetooth

1.1

If user clicks “cancel” the operation is canceled and the application return to the browser
v
iew

4.

Connection to remote device fails

4.1

Display error message

5b.3

Authentication fails

5b.3.1

Display error message and abort operation

6.

Read timeout exception

6.1

Display unknown
response message






3.4.2.

UC0
4
02
-

Receive a business card

Service listens for an incoming connection


-

Main Scenario

1.

A remote device a connection is accepted

2.

Service forks the socket to a receive handler

3.

Receiver reads the data from the remote device

4.

Receiver
notifies the user about an incoming card

5.

Receiver saves the card to the default “received” folder

6.

Receiver sends the status (Accepted, Refused, Failed) to the remote device


-

Branch

4b.

If the message is encrypted

3b.4

Receiver opens a password dialog

3b.5

User inserts a

password and clicks on “ok”

3b.6

Receiver start the EKE protocol

3b.7

Receiver reads encrypted data from the remote device


3b.

If the preference for “confirmation dialog” is checked

2b.4

Receiver open a save card dialog, showing the card

2b.5

User selects the location to save a
nd clicks “ok”

2b.6

Receiver saves the card to that location

2b.7

Continue with step 6


-

Exceptions

1.

If bluetooth is not enabled then nothing will happen

3.

Read timeout exception

3.1

Display error message

3b.3

Authentication fails

3b.3.1

Display error message and abort operation




4.

Design & Implementati
on


This project wa
s designed in 3 layers
-

Android SDK Layer, Framework Layer

and

Business Card Application
Layer. Each layer is built on top of the previous layer
,

adding more functionality to the next one.


The Framework layer con
tains most of the code and is completely disconnected from the business card
aspect of the project. In the following sections we will describe the large components that make up this
layer.




Drawing 4.1


Framework layer components in general






The
Business Cards Application layer contains several UI components that are specific to editing and
managing business cards. It contains the logic concerning business cards structural data

and

utilities for
painting,
importing

Android contacts and business ca
rd theme management.



Drawing 4.2


Business Cards Application layer components in general






4.1.

Background
S
ervice


A Service is an application component representing either an application's desire to perform a longer
-
running operation while not interactin
g with the user or to supply functionality for other applications to
use.”
-

Android docs


Our Background service runs as part of the application’s process (default behavior) in a separate thread. It
starts

when the phone is started or when the application

is opened. It handles incoming and outgoing
bluetooth messages using our bluetooth
implementation
.


The service allows for an application to register a message type to be handled either

by

a handler class or an
answer activity. The Business cards applica
tion registers a message of type “business card” in the service to
be handled either by an business card answer activity or by a batch handler (according to the preferences
set by the user). The service can also accept requests from activities in the appl
ication to send a message via
bluetooth to a specified device address. The bluetooth messaging sequences will be explained in the
bluetooth section later on.


The background service also uses the notification component to alert the user about changes in t
he
application such as “service started”, “bluetooth not

available”, “incoming message”, etc.


In the following class diagram, you can see the “LocalService” which is the name of the class representing
the background service. In is started by a boot
completed receiver which is an Android broadcast receiver.

An Android broadcast receiver is a class that listens to intents moving around the system. Each receiver
filters the intents it wants to
accept

by specifying an action to filter by. That way the re
ceiver wakes up only
when
an intent

with that
specific
action is sent by another activity. Th
e boot completed

receiver listens to a
boot action only and wakes up accordingly.


As described above, the Registration block manages registration for message type
s and returns
an

IRunnableBlock to handle the incoming message type data.









Here is a sample of code that registers a message type for an IRunnableBlock
.


Drawing 4.1.1


registering a runnable block

for a message type
code snippet


The
B
luetooth package represents the logic that manages bluetooth communication. The service uses this
package to spawn new senders when a req
uest to send a message arrives

a
nd to keep a listener alive
in
order
to accept
incoming
bluetooth
connections
.


Drawing 4.1.2



background service class diagram




class localservice
BroadcastRecei ver
BootCompletedReceiver
+
onRecei ve(Context, Intent) : voi d
Servi ce
LocalService
+
getServi ce() : Local Servi ce
+
start(Context) : voi d
+
stop(Context) : voi d
+
Regi sterMessageTypeFor(Stri ng, Regi sterati onBl ock) : voi d
+
getRegi stredBl ockFor(Stri ng) : Regi sterati onBl ock
+
onBi nd(Intent) : IBi nder
+
onStartCommand(Intent, i nt, i nt) : i nt
+
onCreate() : voi d
+
onDestroy() : voi d
RegisterationBlock
+
AnswerActi vi tyCl ass: Cl ass<?>
+
Bl ockType: EnumBl ockType
+
getAnswerActi vi tyBl ock(Cl ass<?>) : Regi sterati onBl ock
+
getRunnabl eBl ock(Cl ass<?>) : Regi sterati onBl ock
«i nterface»
RegisterationBlock::IRunnableBlock
+
handl eMessage(MessageBl ock) : voi d
«enumerati on»
RegisterationBlock::
EnumBlockType
«enum»

AnswerActi vi ty

Runnabl e
Bluetooth Package
Notification Service
+Bl ockType
Start()
new Sender()
new Li stener()
getRegi strati onBl ock()
«use»
if

(
ask_confimation == true
)

{

LocalService
.RegisterMessageTypeFor(
Constants
.
BUSINESS_CARD_TYPE
,




RegisterationBlock
.getAnswerActivityBlock(
BusinessCardAnswerActivity
.
class
));

}

else

{

LocalService
.RegisterMessageTypeFor(
Constants
.
BUSINESS_CARD_TYPE
,





RegisterationBlock
.getRunnableBlock(
BusinessCardRunnableBlock
.
class
));

}



4.2.

Notifications

Android provides a way to interact with the user without blocking the current

work, using it’s notification
mechanism. Each notification is an alert the shows up on the top panel of the screen. An application can
post, remove and update notifications as needed.


We added an abstraction over the basic android code
that

give
s

u
s

the ability to keep the state of each
notification in its own class and change its layout
and text
as needed.


In the following class diagram you can see the notification service which is the notifications

provider
.

The service i
s

a singleton and supplies

activities with new
notificators

by returning one of the implemented
n
otificator objects (Notificator, ProgressBarNotificator). The common one is the
n
otificator that supports
updating and canceling the notification, setting a title and a description. A
notificator ca
n also accept a
callback object which will be activated when the

user click on the notification. This allows for
interacting
with the user while waiting for a response (usually with a timeout).


Drawing 4.2.1


notification service class
diagram




class localservice
«i nterface»
INotificationCallback
+
onActi vi tyResul t(Intent) : voi d
«i nterface»
INotificationService
+
getNoti fi cator(Stri ng, Stri ng) : INoti fi cator
+
getNoti fi cator() : INoti fi cator
+
getProgressBarNoti fi cator(Stri ng) : ProgressBarNoti fi cator
+
noti fy(i nt, Noti fi cati on) : voi d
+
noti fy(i nt, Stri ng, Stri ng) : voi d
+
noti fy(i nt, Stri ng, Stri ng, Cl ass<?>, Bundl e, INoti fi cati onCal l back) : voi d
+
getLocal Noti fi cator() : INoti fi cator
+
cancel (i nt) : voi d
«i nterface»
INotificator
+
noti fy(Stri ng, Stri ng, Cl ass<?>, Bundl e, INoti fi cati onCal l back) : voi d
+
noti fy(Stri ng, Cl ass<?>, Bundl e, INoti fi cati onCal l back) : voi d
+
noti fy(Stri ng, Stri ng) : voi d
+
noti fy(Stri ng) : voi d
+
cancel () : voi d
+
setTi tl e(Stri ng) : voi d
+
setDescri pti on(Stri ng) : voi d
NotificationService
+
getInstance() : INoti fi cati onServi ce
+
start(Context, Stri ng) : voi d
+
stop() : voi d
+
getLocal Noti fi cator() : INoti fi cator
+
getNoti fi cator(Stri ng, Stri ng) : INoti fi cator
+
getProgressBarNoti fi cator(Stri ng) : ProgressBarNoti fi cator
+
getNoti fi cator() : INoti fi cator
+
noti fy(i nt, Stri ng, Stri ng) : voi d
+
noti fy(i nt, Stri ng, Stri ng, Cl ass<?>, Bundl e, INoti fi cati onCal l back) : voi d
+
noti fy(i nt, Noti fi cati on) : voi d
+
cancel (i nt) : voi d
Notificator
+
Noti fi cator(INoti fi cati onServi ce, i nt)
+
Noti fi cator(INoti fi cati onServi ce, i nt, Stri ng, Stri ng)
+
setTi tl e(Stri ng) : voi d
+
setDescri pti on(Stri ng) : voi d
+
noti fy(Stri ng, Stri ng) : voi d
+
noti fy(Stri ng) : voi d
+
noti fy(Stri ng, Stri ng, Cl ass<?>, Bundl e, INoti fi cati onCal l back) : voi d
+
noti fy(Stri ng, Cl ass<?>, Bundl e, INoti fi cati onCal l back) : voi d
+
cancel () : voi d
ProgressBarNotificator
+
ProgressBarNoti fi cator(Context, INoti fi cati onServi ce, i nt, Stri ng)
+
noti fy(i nt) : voi d
+
cancel () : voi d
-m_servi ce
-m_servi ce
-m_servi ce
-m_noti fi cator
«use»


The following code snippet shows how to create a notificator and add a notification to the alerts panel on
the screen.


Drawing 4.2.2


notifications code snippet





INotificator notificator = NotificationService.getInstance().getNotificator();


// send a notification

notificator.notify(
"What's up..."
);


// send an update

notificator.notify(
"goodbye!"
);


// remove the notification

notificator.cancel();



4.3.

Storage S
ervice

An
droid provid
e
s several options for persistency
.

It has i
nternal storage v
isible only to the application and
external storage which is basically the SD
-
Card

and SQLite databases.


In our design we added an abstraction over the storage type and automatically selected the external as
default or the internal st
orage if an SD
-
Card is missing.

We used a strategy pattern for selecting a storage
adapter. There are s
everal adapter types and a decorator cache adapter that can be used over the internal
and external adapters. The usage model is to first configure several adapters
and access
each using a key.
For example
, using the key


images” will access an adapter whic
h is directed to “images” directory. Same
applies with “cards”, “themes” or every other directory. This gives us the ability to use different directories
without the need to change the application accordingly.


In the following class diagram
you can see th
e singleton storage service that allows adding new adapte
rs
.
The service uses

t
he
StorageF
actory

which is a simple factory pattern

that
we
use to abstract access to the
actual class created
. The null storage adapter is used when both the external and
internal adapters fail to
instantiate.

The storage service also provides two storage tools, the temporary storage that allows caching
data and the image storage that eases loading of resources.


Drawing

4.3.1


s
torage
s
ervice
c
lass
d
iagram
class storage
ImageStorage
+
ImageStorage(Context)
+
getBi tmap(i nt) : Bi tmap
+
getDrawabl e(i nt) : Bi tmapDrawabl e
+
unpackBi tmap(byte[]) : Bi tmap
+
packBi tmap(Bi tmap) : byte[]
+
asDrawabl e(Bi tmap) : Bi tmapDrawabl e
InternalStorageAdapter
+
Internal StorageAdapter(Context, Stri ng)
«i nterface»
IStorageAdapter
+
getPath() : Stri ng
+
read(Stri ng, Stri ng) : Object
+
wri te(Seri al i zabl e, Stri ng, Stri ng) : voi d
+
del ete(Stri ng, Stri ng) : voi d
+
getItems(Stri ng, Fi l ter) : Stri ng[]
+
getFi l e(Stri ng, Stri ng) : Fi l e
+
readBi tmap(Stri ng, Stri ng) : Bi tmap
+
wri teBi tmap(Bi tmap, Stri ng, Stri ng) : voi d
+
createFol der(Stri ng, Stri ng) : voi d
+
del eteFol der(Stri ng, Stri ng) : voi d
+
moveFol der(Stri ng, Stri ng, Stri ng, Stri ng) : voi d
+
move(Stri ng, Stri ng, Stri ng, Stri ng) : voi d
+
setDefaul tFol ders(Stri ng[]) : voi d
IStorageAdapter::Filter
+
Di rectori es: Fi l ter = new Fi l ter(Enum... {readOnl y}
+
Fi l es: Fi l ter = new Fi l ter(Enum... {readOnl y}
+
Al l: Fi l ter = new Fi l ter(Enum... {readOnl y}
+
setIncl udeVi rtual () : Fi l ter
+
equal s(Obj ect) : bool ean
+
i ncl udeVi rtual () : bool ean
«enumerati on»
IStorageAdapter::Filter::EnumFilter
«enum»

Di rectori es

Fi l es

Al l
NullStorageAdapter
+
Nul l StorageAdapter(Stri ng)
+
read(Stri ng, Stri ng) : Obj ect
+
wri te(Seri al i zabl e, Stri ng, Stri ng) : voi d
+
del ete(Stri ng, Stri ng) : voi d
+
getItems(Stri ng, Fi l ter) : Stri ng[]
+
getFi l e(Stri ng, Stri ng) : Fi l e
+
readBi tmap(Stri ng, Stri ng) : Bi tmap
+
wri teBi tmap(Bi tmap, Stri ng, Stri ng) : voi d
SdCardStorageAdapter
+
SdCardStorageAdapter(Stri ng)
+
i sWri teabl e() : bool ean
+
i sReadabl e() : bool ean
StorageAdapter
+
StorageAdapter(Stri ng)
+
getPath() : Stri ng
+
read(Stri ng, Stri ng) : Obj ect
+
wri te(Seri al i zabl e, Stri ng, Stri ng) : voi d
+
del ete(Stri ng, Stri ng) : voi d
+
move(Stri ng, Stri ng, Stri ng, Stri ng) : voi d
+
getItems(Stri ng, Fi l ter) : Stri ng[]
+
getFi l e(Stri ng, Stri ng) : Fi l e
+
readBi tmap(Stri ng, Stri ng) : Bi tmap
+
wri teBi tmap(Bi tmap, Stri ng, Stri ng) : voi d
+
createFol der(Stri ng, Stri ng) : voi d
+
del eteFol der(Stri ng, Stri ng) : voi d
+
moveFol der(Stri ng, Stri ng, Stri ng, Stri ng) : voi d
+
combi nePath(Stri ng, Stri ng) : Stri ng
+
makeSureExi sts(Stri ng) : voi d
+
setDefaul tFol ders(Stri ng[]) : voi d
StorageAdapterFactory
+
getAdapter(Context, Stri ng, StorageType, bool ean) : IStorageAdapter
«enumerati on»
StorageAdapterFactory::
StorageType
«enum»

Internal

SdCard
StorageCache
+
StorageCache(IStorageAdapter)
+
getPath() : Stri ng
+
read(Stri ng, Stri ng) : Obj ect
+
wri te(Seri al i zabl e, Stri ng, Stri ng) : voi d
+
del ete(Stri ng, Stri ng) : voi d
+
move(Stri ng, Stri ng, Stri ng, Stri ng) : voi d
+
getItems(Stri ng, Fi l ter) : Stri ng[]
+
readBi tmap(Stri ng, Stri ng) : Bi tmap
+
wri teBi tmap(Bi tmap, Stri ng, Stri ng) : voi d
+
getFi l e(Stri ng, Stri ng) : Fi l e
+
createFol der(Stri ng, Stri ng) : voi d
+
del eteFol der(Stri ng, Stri ng) : voi d
+
moveFol der(Stri ng, Stri ng, Stri ng, Stri ng) : voi d
+
setDefaul tFol ders(Stri ng[]) : voi d
StorageService
+
start(Context, Stri ng) : voi d
+
getAdapter(Stri ng) : IStorageAdapter
+
setAdapter(Stri ng, Stri ng, bool ean) : IStorageAdapter
+
setAdapter(Stri ng, IStorageAdapter) : voi d
+
combi nePath(Stri ng, Stri ng) : Stri ng
+
getImageStorage() : ImageStorage
+
getTemporaryStorage() : TemporaryStorage
TemporaryStorage
+
TemporaryStorage(Context)
+
read(Stri ng) : Obj ect
+
remove(Stri ng) : voi d
+
cache(Seri al i zabl e) : Stri ng
~m_adapter
+Al l
+Fi l es
+Di rectori es
«use»
«use»


4.4.

Bluetooth
&
Encryption

In Android 2.2 Bluetooth is supported, therefore there is a built
-
in API for creating Bluetooth

connections
and using them for data transmission. That includ
es

an automatic pairing action while trying to connect
to
an
unpaired remote device. As a result, the developer has to perform few actions in order to use Bluetooth
:
connect or accept, depends i
f he is the
s
erver side or the
c
lient side, and after connection is established use
the read and write methods.
This is an example of how is it done:


Drawing 4.4.1


Bluetooth code snippet


In our design, we use one listening thread, which
listens

to incoming connections for our application, and
an
additional
thread for each card transfer


sending thread

or receiving thread, depends on what side you are.


In general a UI thread should not be used to perform IO operations since these are blocking calls. Moreover,
in order to support multiple transmissions in and out, we
use a different threa
d for each transmission
.


These threads are
created in
the background service

either by an incoming connection or by an activity’s
send request
. The listening thread is started when the background service is started and waits for
connections.

When the user chooses to send a business card, a
request
(using Android broadcast
// *********** on the receiving side *********** //


// create a new listening server socket

BluetoothServerSocket server =

adapter.listenUsingRfcommWithServiceRecord(
"btdevicename"
,
"myid"
);


// wait for incoming connection

BluetoothSocket
socket

= socket.accept();


// *********** on the sending side *********** //


// create socket

BluetoothSocket socket = bluetoothAdapter.getRemoteDevice(
deviceAddress
)



.createRfcommSocketToServiceRecord(
UUIDString
);


// try to connect



socket.connect();


// *********** on both sides *********** //



// get input & output stream

InputStream in =
socket.getInputStream();

OutputStream out = socket.getOutputStream();


// read bytes into buffer
-

blocking

in.read(buffer);


// do something with the data...


// send bytes to client

out.write(buffer);


// close the client

socket.close();




capabilities) is sent to

the background service with a reference

to the card we want to send. The background
service
create
s

and
start
s

a sending thread, which is responsible

for

connecting to the remote device. After
the connection is established,
the send thread

sends the data block by block. On the receiving side, the
listening thread accepts the connection and
starts

a receiving
thread with the accepted socket, which
handl
es the incoming blocks. After the listening thread creates the receiving thread, it continues to listen for
other connections. This gives us the ability to send multiple cards without waiting for each transfer to be
done.


In order to avoid deadlocks, whi
le a thread waits for incoming blocks and no data is arrived, we built
a
watchdog component.
The watchdog is a thread which receives a
timeout parameter

and a callback.

W
hen
the
timeout is over it
triggers the callback
.
The watchdog can be stopped, reset, and started again to allow
reuse of the same instance.
Each of the bluetooth threads start the watchdog when they perform blocking
operations such as read, write and connect. Our implementation for the callback is to clo
se the socket and
cause an exception on the bluetooth thread which stops the blocking operation and handles the exception.


Another ability provided by Java is data encryption. Our encryption (detailed later) based on DH secret key
generator which is used
to encrypt and decrypt the data on both sides. To create such a secret key we
implemented EKE protocol, based on a common password which is known to both sides. If encryption is
enabled on the sender’s side, encryption process
is
started
and an
“encryption

header” message is sent

to
the remote device
. When the
remote device

receives this message, an encryption setup process is
also
started

on the receiving end

(detailed later). After
the encryption has ended

successfully
and both sides
have the same secret
key, the card is
encrypted under it and transmitted.


In

the following class diagram, we can see that most of the
logic is implemented in the abstract class
AbstractBluetoothThread.
Both the BluetoothSendThread and BluetoothClientThread inherit from it and

reuses

the common send/receive logic.

The third thread is the BluetoothListenerThread which creates the
BluetoothClientThread in case of incoming connection.


One of the differen
ces in the

logic between the threads is the creation of Bluetooth sockets. Th
e sending
thread

initiates the connection and
gets

a socket when a connection is established,
while

the receiving
thread

gets the socket

from
th
e listening thread which accepted

the connection. Another difference is the
way the secret key is generated, sin
ce the protocol is different for

the

client side and server side. Both key


generators (AliceDHSecretKeyGenerator as
sender
, BobDHSecretKeyGenerator as
receiver
) inherit from
AbstractDHSecretKeyGenerator, which implement
s the common key generation

logic.
Af
ter the secret key is
generated, we use
the
CipherGenerator component which receives
a

secret key or a password to encrypt or
decrypt the data. The password is used
for initiating
the EKE protocol.


In the sending process, the data itself is wrapped
with

a MessageBlock

object
, which contains
the
s
erializable data and the
message
type. This message block is used by the sending/receiving threads and by
the cipher generator in order to encrypt or decrypt existing message block. Another form of message block
i
s the CacheMessageBlock, which contains
a temporary cached message. This is used in order to pass
business cards from the application to the sending thread, since we can’t pass it through the broadcast
Intent because of

the

card’s size

and the intent’s siz
e limit
.



Drawing 4.4.2


Bluetooth & Encryption class diagram




class crypto
Thread
IWatchDogLi stener
AbstractBluetoothThread
+
AbstractBl uetoothThread(Stri ng)
+
onTi meout() : voi d
+
i ntToByteArray(i nt) : byte[]
+
byteArrayToInt(byte[]) : i nt
+
setProgress(i nt) : voi d
+
getProgress() : i nt
+
run() : voi d
«enumerati on»
AbstractBluetoothThread::
Status
«enum»

Accepted

Refused

Fai l ed

Unknown
AbstractDHSecretKeyGenerator
+
AbstractDHSecretKeyGenerator(KeyPai r)
+
getPubl i cKey() : byte[]
AliceDHSecretKeyGenerator
+
Al i ceDHSecretKeyGenerator()
+
getSecretKey(byte[]) : SecretKey
BluetoothClientThread
+
Bl uetoothCl i entThread(Bl uetoothSocket)
BluetoothSendThread
+
Bl uetoothSendThread(Stri ng, MessageBl ock)
+
connected() : voi d
+
ensurePai red(Bl uetoothDevi ce, Stri ng) : voi d
BobDHSecretKeyGenerator
+
BobDHSecretKeyGenerator(byte[])
+
getSecretKey() : SecretKey
Seri al i zabl e
CacheMessageBlock
+
CacheMessageBl ock(MessageBl ock)
+
getCachedMessage() : MessageBl ock
+
remove() : voi d
CipherGenerator
+
Ci pherGenerator(Stri ng)
+
Ci pherGenerator(SecretKey)
+
encrypt(MessageBl ock) : MessageBl ock
+
i sEncrypted(MessageBl ock) : bool ean
+
decrypt(MessageBl ock) : MessageBl ock
+
generateRandomChal l enge() : Stri ng
Seri al i zabl e
MessageBlock
+
MessageBl ock(Stri ng, Seri al i zabl e)
+
getType() : Stri ng
+
getData() : Seri al i zabl e
+
cache() : CacheMessageBl ock
+
i sCached() : bool ean
+
uncache() : MessageBl ock
+
destroy() : voi d
Thread
BluetoothListenerThread
+
Bl uetoothLi stenerThread()
+
run() : voi d
+
cancel () : voi d
#m_ci pher
«use»


4.4.1.

Send
-

Receive Sequence

This paragraph describes the sending


receiving sequence in details, in chronological order.

Receiver
:

The background service creat
es

a listening thread
,

which waits for incoming connections.

Sender
:

The user selects a card to send and a device to send it to.
The background service receives a
send

request

and creates

a

sending thread
, which connects to the remote device.

Receiver
:

The listening thread
accepts the connection and creates a receiving thread
, which waits for an
incoming message (blocking operation)
.

Sender
:

The sending thread sends the message type
.

Sender &

R
eceiver
:

I
f message type is “Encrypted” then EKE protocol is started
.

剥R敩v敲
:

坡楴
s

fo爠

楮com楮g m敳獡se
.

卥ST敲
:

卥ST
s

瑨攠m敳獡s攠Wo 瑨攠W敭o瑥⁤ v楣i

慮T⁷慩瑳⁦ r

a

獴慴us敳獡来
.

剥R敩v敲
:

剥R敩ve
s


m敳獡ee
⸠䅦W敲e

m敳獡来⁩猠牥c敩e敤Ⱐ
慮⁡n獷s爠慣瑩Wi瑹⁩ ⁳ 慲瑥T
慣捯牤楮g⁴o
瑨W
m敳e慧攠Wype
⸠䙩n慬ayⰠ

s瑡瑵W

m敳獡来⁩猠s敮e

慣ao牤ing⁴o⁵ 敲
’s

慮s睥r
.



D牡睩rg 4⸴⸳


Bluetooth & Encryption class diagram

sd BusinessCard
Sendi ng Thread
Recei vi ng Thread
Devi ce Pi cker
Li steni ng Thread
Background
Servi ce
Background
Servi ce
Answer Acti vi ty
opt Encryption
Send card
New
New
Connect
Accept
New
Send(message type)
Send(card)
GetRunnabl eBl ock(messageType)
New
Show() :Bool ean
Send(status)


4.4.2.

Encryption Sequence

Here is the description of EKE sequence, including the secret key generati
on

based on Diffie
-
Helman
protocol and user

authentication. As mentioned before, a common password is
used

for setting up this
encryption method.


This is the sequence, as implemented, in chronological order:

Step 1


䍬C敮琠䄺

啳敲⁩湳敲瑳W
瑨攠
p慳a睯牤, 睨楣w⁩猠獣s慭b汥l
睩瑨


U慳a⁦畮捴楯n⸠
周楳⁳ 数⁩猠
n散e獳慲y

be捡c獥so瑨敲睩獥s慮⁡ 瑡捫敲ecou汤⁴ry⁴o gu敳猠瑨攠灡W獷o牤
u獩sg⁡
T楣瑩in慲a⁡ 瑡捫⸠
卥ST楮g⁴U攠U慳a敤⁰e獳睯牤 on⁴U攠commun楣慴ion楮攠
楮獴s慤f⁴Ue物r楮慬aon攠
i猠s獳敮瑩慬⁦o爠
p牥v敮e
楮g

M慮
-

-
周T
-
M楤T汥⁡ 瑡捫c

䄠AH
pub汩挠k敹 ⡧
a
mod p) is encrypted using the hashed password, and sent to
client B.

Step 2


䍬C敮琠e
:

No眠捬c敮琠e⁳ 牡mb汥猠瑨W⁰慳獷o牤⁷楴i⁴U攠獡s攠U慳a⁦畮捴楯n⸠坩瑨⁴桥
U慳a敤⁰e獳so牤⁨攠T散特p瑳W捬楥c琠A
’s

pub汩挠k敹,⁡湤⁷楴i⁨楳 o睮⁰wiv慴攠ke
yⰠ
U攠捲敡瑥猠s
common
DH敹


k


g
ab

mod p.

Note: g and p are known constant numbers. Since g is very large, we can’t use k
慮Tn攠o映fU攠pub汩挠k敹s
景爠rompu瑩Wg
瑨攠灲Wv慴攠on敳


䥮牤敲e瑯 敮慢汥⁣汩敮琠䄠
Wo
捲敡ee⁴U攠獡s攠s散牥琠k敹Ⱐ睥 獥湤


捬楥cW⁂
’s

DH⁰ b汩挠步y


b
mod p)

encrypted under the hashed password. In addition, we
send
a

random challenge

(called challengeB)
, encrypted under the secret key


欮k

䥮⁥慣a⁥n捲yp瑩on⁳ 瑵W⁡ n敷⁲慮 om 捨c汬敮e攠楳⁧敮敲慴敤e⁴U敲敦er攠u獩sg
慮
ld one won’t complete the encryption setup process. T
U楳⁳i数⁩猠e散e獳慲礠
b散慵獥e楴⁤敦敮 猠慧慩a獴s牥灬慹a慴瑡捫

慮T⁡汳o⁡汬o睳wu猠so⁡ 瑨敮瑩捡瑥⁴U攠
o瑨敲W獩s攮†

却数″


䍬C敮琠e
:

No眠捬c敮琠䄠捡c⁣ompuW攠瑨攠We捲整ey,
睩瑨⁨楳睮⁰w楶慴攠k敹

慮T

捬楥cW⁂
’s

pub汩挠步y⸠䥮 o牤敲⁴o⁡畴 敮瑩捡瑥⁴U慴⁣汩敮琠e⁩猠慣Wu慬ay⁣汩敮e⁁Ⱐ 攠Te捲cp琠
瑨攠牥c敩e敤⁣桡e汥lge
B

u獩ng⁴U攠獥捲整eyⰠ来,敲慴
e

愠湥a⁣U慬a敮ee

⡣慬汥(
捨c汬敮e敁e
Ⱐm敲e
e

瑨Wm Wog整U敲⁡湤⁥n捲yp琠瑨攠m敲来e⁣U慬a敮ee⁵ T敲e欮k

攠ne眠捨c汬
敮ee⁩猠s敮琠e慣欠Wo⁣汩敮琠䈮⁓
楮c攠onl
y⁣l楥i琠䄠歮o睳⁴U攠獥sr整
步k
,nly⁨攠捡c⁤散 yp琠瑨攠牥r敩e敤⁣桡e汥lg敂⁡湤 捲敡瑥⁡ ne眠敮e特灴敤e
捨c汬敮e攠瑨慴⁣on瑡楮s

捨c汬敮e敁⁡湤
捨c汬敮e敂e



Step 4


Client B
:

Client B decrypts t
he received

challenge, which
consists of challengeA and
challengeB. Since he knows challengeB, he can produce challengeA alone and
send it back encrypted under the secret key.
The fact that
only
client B

knows the
secret key

k and the original challengeB, he can send

back challengeA and
prove

to client A

that he is client B
.


The secret key we generated here is used for data encryption while sending any data (e.g. cards,
statuses and more). This defends the session from session hijacking because even if an attacker would
take over the session, and impersonate one of the sides,
he can’t understand the messages.


Drawing 4.4.4

Encryption sequence diagram



sd Use Case Model
Cl i ent A
Cl i ent B
k=g^ab(mod p)
w=f(password)
w=f(password)
k=g^ab(mod p)
Devi ce Name, Ew(g^a mod p)
Ew(g^b mod p), Ek(chal l engeB)
Ek(chal l engeA,chal l engeB)
Ek(chal l engeA)


4.5.

Business Cards Data Structures

This paragraph describes the way business card is represented in our system. Our main considerations while
creating this
structure were user convenience, memory usage, changeable properties and more…

The main idea is that each business card contains many different items, and the user can decide which items
he wants in the card. Each

item can be edited, and the use
r can decid
e about the text,

font, color and layout.
With the fact that each item is a standalone component, we could implement an editor screen which allows
us to handle each item alone, with no relation to other items on the card.

One other changeable property of
the card is its background. The user can choose a background for his card
from the gallery of the device. That means you can take a picture and use it as background.

Note that because of its size there was a problem in saving the background as picture in t
he business card
structure, therefore we
only
saved a
reference to the background

file
.


Another capability that we created, based on business card structure, is the themes manager. The themes
manager allows the user
to
apply a theme, which includes items
with prepared layout and position, on his
card. That means that the texts will remain, but the layout of the card is changed. Also, a user can create a
th
eme from his designed

or received cards, and later apply it on other cards. The theme structure is
ver
y
similar to

a

business card structure.


In order to improve user experience, we added a utility that imports all the phone's contacts and for each
contact creates

a card based on
its
details. Note that the
contact’s
card isn't actually saved on the device
,
and will be saved only if edited and saved as a card in
another directory.


In the following class diagram
you

can see that BusinessCard contains many BusinessCardItem

objects
. Each
item has its type (ItemType), and its layout (BusinessCardItemLayout). Y
ou can
also
see that the layout
contains font, size and other parameters.


The themes manager (ThemesManager)
contains a collection of

BusinessCardTheme

objects
, while each
theme contai
ns many items, similar to a
BusinessCard

structure
. When applying a theme, the theme's items
would be copied to the business card items. This also includes
the
background.




In order to draw a business card or a theme on

the

screen, we use

the

BusinessCardPainte
r component
which allows us to take
a
busines
s card and create a picture from it, including the background and all
of its
items. This picture is
used

in the application’s activities to display the card
or the theme.

The last component is the ContactUtils, which implements the contact import ability,
as described before.


Drawing 4.5.1


Business card structure class diagram

class themes
Seri al i zabl e
BusinessCard
+
Busi nessCard(bool ean)
+
Busi nessCard(Busi nessCard)
+
getFi l eName() : Stri ng
+
setFi l eName(Stri ng) : voi d
+
getItems() : Li st<Busi nessCardItem>
+
getBackgroundFi l ename() : Stri ng
+
getBackground() : Bi tmapDrawabl e
+
setBackground(Stri ng) : voi d
+
setBackground(Stri ng, Bi tmap) : voi d
+
getFi rstName() : Stri ng
+
setItem(ItemType, Stri ng) : voi d
+
getLastName() : Stri ng
+
getFul l Name() : Stri ng
+
getPhoneNumber() : Stri ng
+
getEmai l () : Stri ng
+
addItem(Busi nessCardItem) : voi d
+
getItem(UUID) : Busi nessCardItem
+
removeItem(UUID) : voi d
+
setItem(Busi nessCardItem) : voi d
+
match(Stri ng) : bool ean
+
removeItems() : voi d
Seri al i zabl e
BusinessCardBlock
+
Busi nessCardBl ock(Busi nessCard)
+
getBusi nessCard() : Busi nessCard
Seri al i zabl e
BusinessCardItem
+
Busi nessCardItem(ItemType, Stri ng)
+
Busi nessCardItem(ItemType, Stri ng, i nt, i nt)
+
Busi nessCardItem(ItemType, Stri ng, i nt, i nt, Busi nessCardItemLayout, bool ean)
+
GetInputType() : i nt
+
equal s(Obj ect) : bool ean
+
equal s(Busi nessCardItem) : bool ean
Seri al i zabl e
BusinessCardItemLayout
+
Busi nessCardItemLayout()
+
Busi nessCardItemLayout(FontItem, FontSi ze, i nt, bool ean, bool ean, bool ean)
+
Busi nessCardItemLayout(Busi nessCardItemLayout)
BusinessCardPainter
+
getBusi nessCardAsBi tmap(Busi nessCard) : Bi tmap
+
getBusi nessCardAsBi tmap(Busi nessCard, i nt) : Bi tmap
+
pai ntBusi nessCardItems(Canvas, Busi nessCard, i nt) : voi d
+
getScal e(Busi nessCard, i nt) : fl oat
+
getPai nt(Pai nt, Busi nessCardItemLayout, i nt) : voi d
Seri al i zabl e
BusinessCardTheme
+
getName() : Stri ng
+
create(Map<ItemType, Stri ng>) : Busi nessCard
+
appl y(Busi nessCard) : Busi nessCard
+
fromBusi nessCard(Stri ng, Busi nessCard) : Busi nessCardTheme
ContactsUtils
+
i ni ti al i ze(Context) : voi d
+
getContacts() : Map<Stri ng, Busi nessCard>
«enumerati on»
ItemType
«enum»

Fi rstName

LastName

Name

Phone

Address

Emai l

Company

Fax

Text

Insti tute

WorkPhone

Descri pti on

Professi on

Department

Li nk
ThemesManager
{l eaf}
+
i ni ti al i ze(Context) : voi d
+
getInstance() : ThemesManager
+
getThemes() : Li st<Stri ng>
+
getTheme(Stri ng) : Busi nessCardTheme
+
getDefaul tTheme() : Busi nessCardTheme
+
save(Busi nessCardTheme) : voi d
+
i sDefaul t(Stri ng) : bool ean
+
remove(Stri ng) : voi d
1..*
-m_defaul tTheme
«use»
appl y theme
1..*
-m_i nstance
+Defaul t
+m_l ayout
+m_type


4.6.

Business Card Editor

The business card editor is made up of an activity that uses a surfac
e view as its drawing surface. T
he system
sends a drawing event which is

handled in the onDraw method. The surface view gets redrawn several times
a second.
Each time we
draw the background, and the business card items
.
Additionally, the editor uses
three activities.


The first one is the item layout activity, which allows ed
iting the text, setting a type for the item, changing
its
color, font, size and style.


The second is the items list activity which gives a global view of all items in the card and allows editin
g or
removing
each
item

in the same screen
.

It’s the first thi
ng that opens when a new card is created. The card is
created using the default theme and
the items are filled with
its

default values. When this activity opens
,

the
user can edit the text values or remove
some of the items. Once “save” i
s clicked, the sur
face gets repainted
with the updated items.


The third activity is the themes selector activity, which allows choosing a theme to apply to the card. When
opened it shows the card with the first theme applied on it. By swiping to the left the next theme wil
l be
applied to the card and shown on the screen. Once a theme is selected, the surface gets repainted with the
selected theme causing items to change position and layout, but not changing the textual values of the
items.


Using the touch screen the user c
an manage the position and layout of the business card’s items. When the
user clicks on an item in the surface, the topmost item is selected and the surface view is updated to show a
bounding box and three clickable icons surrounding the item (edit, delete

and move). When selecting the
edit icon the item layout activity is opened with the item’s properties. When selecting the delete icon, the
item is removed from the card and the surface view.
In order to position an item on the card surface, the
user can d
rag the item or the move icon.


The editor also uses a menu option which allows select
ing

a background from the device’s galle
ry, saving

a
theme
based on the card’s layout
, and displaying a grid
. The grid can be used to align items on the surface. It
also
supports snapping to grid lines for accurate alignment
.


In the following class diagram,
the main editor activity is located at the center and the three additional
activities are above it and are used by it. Below is the surface view that is interconnected

to the activity.
There is also a save dialog used to

save the card when done. The I
tem
L
ist and the
I
tem
L
ayout activities are
mainly written with an xml layout

a
nd have little dependencies in anything other th
a
n
the
business card
structures.

The themes a
ctivity is based mainly on our framework gallery view code, which creates a
very
simple
tree of views. Like all activities it has a main view which is the header. The header view contains a
gallery view of
themes
.
The activity also uses a swipe gesture lis
tener we added to the framework

in order

to detect swipes. Once a left or right swipe event is detected, we send the gallery view request to show the
next or previous theme respectively.




Drawing
4.6.1


business card editor class diagram



class editor
Androi d:Acti vi ty
Acti vi ty
BusinessCardEditor
+
onCreate(Bundl e) : voi d
+
onCreateOpti onsMenu(Menu) : bool ean
+
onMenuItemSel ected(i nt, androi d.vi ew.MenuItem) : bool ean
-
saveTheme() : voi d
-
sel ectTheme() : voi d
+
getWi dth() : i nt
+
getHei ght() : i nt
-
sel ectBackground() : voi d
-
showEdi tItems() : voi d
-
saveBusi nessCard() : voi d
-
makeToast(Stri ng) : voi d
+
showItemTool box(Busi nessCardItem) : voi d
#
onActi vi tyResul t(i nt, i nt, Intent) : voi d
+
getScreenWi dth() : i nt
+
getScreenHei ght() : i nt
Acti vi ty
BusinessCardEditorItemsList
+
onCreate(Bundl e) : voi d
-
setItemsVi ew(Li nearLayout, Li st<Busi nessCardItem>) : voi d
-
saveItems() : voi d
-
addItemsToBusi nessCard() : voi d
#
onSaveInstanceState(Bundl e) : voi d
#
onRestoreInstanceState(Bundl e) : voi d
Acti vi ty
BusinessCardEditorItemToolbox
+
onCreate(Bundl e) : voi d
-
updateControl s() : voi d
-
setSpi nner(Spi nner, Obj ect) : voi d
Androi d:Vi ew
Vi ew
BusinessCardEditorSurface
+
Busi nessCardEdi torSurface(Busi nessCardEdi tor, Busi nessCard)
-
getGri dPai nt() : Pai nt
-
getBoundi ngBoxPai nt() : Pai nt
-
getTextPai nt() : Pai nt
#
snapToAxi s(i nt, i nt, i nt) : i nt
#
fi ndSel ected(i nt, i nt) : Busi nessCardItem
#
onDraw(Canvas) : voi d
+
setBackgroundDrawabl e(Drawabl e) : voi d
+
toggl eGri dLi nes() : voi d
+
setBusi nessCard(Busi nessCard) : voi d
+
toggl eSnapGri dLi nes() : voi d
Acti vi ty
BusinessCardThemeSelector
#
onCreate(Bundl e) : voi d
-
setTheme() : voi d
-
del eteTheme() : voi d
+
onTouchEvent(Moti onEvent) : bool ean
+
onDoubl eTap() : bool ean
+
onSwi pe(i nt) : bool ean
+
onCreateOpti onsMenu(Menu) : bool ean
+
onMenuOpened(i nt, Menu) : bool ean
+
onMenuItemSel ected(i nt, MenuItem) : bool ean
ItemsVi ew
Vi ewFactory
T
GalleryView
Li nearLayout
HeaderView
+
HeaderVi ew(Context)
-
i ni ti al i ze() : voi d
+
setText(Stri ng) : voi d
#
getVi ew() : Vi ew
«i nterface»
ISwipeListener
+
onSwi pe(i nt) : bool ean
+
onDoubl eTap() : bool ean
OkCancelDialog
+
showDi al og() : voi d
SaveInputDialog
+
showDi al og() : voi d
Si mpl eOnGestureLi stener
SwipeGestureDetectorListener
+
Swi peGestureDetectorLi stener(ISwi peLi stener)
+
onFl i ng(Moti onEvent, Moti onEvent, fl oat, fl oat) : bool ean
+
onDoubl eTap(Moti onEvent) : bool ean
Di al og
UberColorPickerDialog
+
UberCol orPi ckerDi al og(Context, OnCol orChangedLi stener, i nt)
#
onCreate(Bundl e) : voi d
-m_themeHeader
«use»
«use»
«use»
~m_l i stener


4.7.

Business Cards

Tabs Style Browser

In our application there are two methods
to manage cards
, which can be
chosen

through application
preferences at the main screen.
The first method is the tabs browser.


In the tabs browser each tab represents a real directory in the
file system, except for the special tabs
(search, contacts and new). Within each tab, the cards inside that directory are shown as a list. Moving from
one tab to another is done by clicking it. One special tab is the search tab, which allows the user to se
arch
for cards that contains his search string. If there is a card (in the whole database) that contains this string in
one of its items, the card would be shown in the search tab list. Another special tab is the "new…" tab which
allows the user to create
new tabs. The last special tab is the contacts tab

(if enabled)
, which shows card for
each
contact in the device

(see section 4.5 for extra details).


In any tab, if there are cards shown, the user can select them by clicking the wanted card. When selecte
d, a
yellow border appears around the card. When a card is selected, the user can use the card through
the
menu options, to call the phone number in the card, send SMS, send email if
an
email address exists, and
send the card via Bluetooth. The user can al
so perfo
rm file operations, such as moving

the car
d to another
directory or deleting

it. If the user chooses the edit option, the editor is opened with the selected card, and
the user can edit the card items and layout.



If no card is selected, it means that the current tab is the selected directory. If the user presses the menu
button, directory options appears. The user can delete or rename the selected directory, or create a new
directory, which will appear as
a
new tab
.


In the following class diagram we can see that the tabs activity contains
a collection of
ViewBusinessCardTabBase
objects
. Notice that ViewBusinessCardTabBase is also an activity. This structure is
en
forced
in
Android
’s

tab
s

implementation. The ViewBus
inessCardTabBase includes all the main logic for
tabs implementation, and
two components inherit

from it


the ViewBusinessCardListViewTab and the
ViewBusinessCardSearchTab. The last one implements the search tab, as mentioned before. The
ViewBusinessCardL
istViewTab implements a
general
tab, which represents a directory or the contacts tab.

In order to create
the card

list, we expanded Android
’s

ListView component and created our own
BusinessCardListView. This view uses an expanded adapter, based on Androi
d
’s

BaseAdapter. This is done in
order to create

a

list with
a
customize
d

view


a
business card in our case.


As you can see, the tabs browser uses two
additional
activities


the device picker and the editor.

The device picker is used for sending
a
card

via Bluetooth. When a user wants to send a card, he presses the
send option in the menu, and then the device picker is opened. If the user presses on the edit option, the
editor opens with the selected card.







Drawing 4.7.1


business card editor class

diagram




class viewer
Li stVi ew
OnItemCl i ckLi stener
BusinessCardListView
+
Busi nessCardLi stVi ew(Context)
+
onItemCl i ck(AdapterVi ew<?>, Vi ew, i nt, l ong) : voi d
+
getSel ected() : Busi nessCard
#
getItems() : Li st<Busi nessCard>
+
noti fyDataSetChanged() : voi d
BaseAdapter
Fi l terabl e
BusinessCardsAdapter
+
Busi nessCardsAdapter(Busi nessCardLi stVi ew)
+
getFi l ter() : Fi l ter
+
getVi ew(i nt, Vi ew, Vi ewGroup) : Vi ew
#
getImage(Busi nessCard) : Bi tmap
+
getCount() : i nt
+
getItem(i nt) : Busi nessCard
+
getItemId(i nt) : l ong
+
noti fyDataSetChanged() : voi d
TabActi vi ty
TabsActivity
+
onCreate(Bundl e) : voi d
+
setCurrentTab(Stri ng) : voi d
+
getCurrentTab() : Stri ng
+
rel oad() : voi d
-
addTab(Cl ass<?>, Stri ng, Stri ng, Stri ng, Drawabl e) : voi d
#
onDestroy() : voi d
#
onResume() : voi d
ViewBusinessCardsListViewTab
+
onCreate(Bundl e) : voi d
ViewBusinessCardsSearchTab
#
onStart() : voi d
+
onCreate(Bundl e) : voi d
#
createBusi nessCards(Stri ng) : Li st<Busi nessCard>
Acti vi ty
ViewBusinessCardsTabBase
+
onCreate(Bundl e) : voi d
#
getLi stVi ew() : Li stVi ew
#
fi nd(Stri ng, Stri ng) : Busi nessCard
#
getBusi nessCards() : Li st<Busi nessCard>
#
createBusi nessCards(Stri ng) : Li st<Busi nessCard>
+
onCreateOpti onsMenu(androi d.vi ew.Menu) : bool ean
+
onMenuOpened(i nt, Menu) : bool ean
+
onMenuItemSel ected(i nt, MenuItem) : bool ean
#
onResume() : voi d
-
refresh() : voi d
Android:Activity
Android:ListView
BusinessCardEditor
Acti vi ty
viewer::BluetoothDevicePicker
#
onCreate(Bundl e) : voi d
-
send(i nt) : voi d
#
onStart() : voi d
-
setupBl uetooth() : voi d
-
createDevi ceInfo(Bl uetoothDevi ce, bool ean)
-
di scoverDevi ces() : voi d
-
stopDi scovery() : voi d
-
setStatus(Stri ng, Stri ng) : voi d
#
onDestroy() : voi d
#
onActi vi tyResul t(i nt, i nt, Intent) : voi d
#m_l i stVi ew
-m_l i stVi ew
«use»
«use»


4.8.

Business Cards Gallery Style Browser


The second business cards management style

is the gallery browser. L
ike the tabs browser, it organizes the
cards into groups managed by the user and displays them in a gallery or in an explorer as icons. T
he view
hierarchy in this activity is made up of several framework code components we created.


The first is the gallery view
which
is a generic view structure that lets the user view images
,

one at a time,
letting the activity that uses it control when to switch to the next view (usually using swipe). It also allows
adding arrows to left and right so that the user can touch the arrows instead of swiping. This is the sa
m
e
view we used in the e
ditor for
the
theme selector activity.


The second is the explorer view which is also a generic structure. This one shows the images as small icons
allowing scrolling either way and selecting one of the images.
Both the gallery view and the explorer view
a
re based on an items container interface and each image is an item in the list managed by the view.

This is
used both for cards and folders.


The third view used here is the multi

view. This view is specifically designed to combine the gallery and
explorer

views together so we can alternate between the visual ways we show the items while using the
same list.


The gallery browser uses a view hierarchy made up of a header view that contains a search view.

The search
view also contains a
flipper view from andr
oid that can switch between two different views. The flipper
contains two
multi view
s, one for
the
folders and the other for the cards themselves.



Similar to the tabs activity, cards and folders can be managed through menu options (the same logic is used

for both tabs and gallery activities).


In the following class diagram we can see

the gallery view in the center.


I
t has a reference to the search
view

in order

to control the filter and to
the header view

in order
to control the header text
.

It also
con
tains
a reference to the flipper
.

W
hen a user clicks on a folder the flipper can update the cards multi view list and
flip between these view hierarchies to show the cards

inside the folder
.


The browser activity also uses the editor
in order
to
allow
the
user to edit a card
,

and the device picker
activity
in order to
send
the selected
card to a remote device.




Drawing 4.8.1


gallery browser class diagram




class gallery
Acti vi ty
IMenuActi onLi stener
GalleryActivity
+
onBackPressed() : voi d
+
onTouchEvent(Moti onEvent) : bool ean
+
onActi onCompl eted(MenuActi on, Obj ect) : voi d
+
onActi onCancel ed(MenuActi on) : voi d
+
onCreateOpti onsMenu(Menu) : bool ean
+
onMenuOpened(i nt, Menu) : bool ean
+
onMenuItemSel ected(i nt, MenuItem) : bool ean
FrameLayout
T
MultiView
+
Mul ti Vi ew(Context, Li st<T>)
+
setItems(Li st<T>) : voi d
+
getItems() : Li st<T>
+
setSel ected(T) : voi d
+
getSel ected() : T
+
noti fyDataChanged() : voi d
+
empty() : bool ean
+
setupSwi pe() : voi d
+
onTouchEvent(Moti onEvent) : bool ean
+
onSwi pe(i nt) : bool ean
+
onDoubl eTap() : bool ean
+
i nExpl orer() : bool ean
+
showExpl orer(bool ean) : voi d
+
hi deExpl orer(bool ean) : voi d
+
setFi l ter(Stri ng) : voi d
T
views::ExplorerView
+
Expl orerVi ew(Context, Li st<T>, bool ean)
+
noti fyDataChanged() : voi d
+
getLayoutCol umnsAmount() : i nt
+
setLayoutCol umnsAmount(i nt) : voi d
Vi ewFactory
T
views::GalleryView
+
Gal l eryVi ew(Context, Li st<T>, bool ean)
+
showPrevi ous() : voi d
+
showNext() : voi d
+
makeVi ew() : Vi ew
+
hasArrows() : bool ean
+
i sCycli c() : bool ean
+
setCycli c(bool ean) : voi d
+
noti fyDataChanged() : voi d
+
setItems(Li st<T>) : voi d
Li nearLayout
views::HeaderView
+
HeaderVi ew(Context)
+
setText(Stri ng) : voi d
«i nterface»
views::ItemsContainer
+
getSel ected() : T
+
setSel ected(T) : voi d
+
getItems() : Li st<T>
+
setItems(Li st<T>) : voi d
+
noti fyDataChanged() : voi d
FrameLayout
T
views::ItemsView
+
ItemsVi ew(Context, Li st<T>)
+
noti fyDataChanged() : voi d
+
setItems(Li st<T>) : voi d
+
getItems() : Li st<T>
+
setSel ected(T) : voi d
+
getSel ected() : T
+
setSel ectedIndex(i nt) : voi d
+
getSel ectedIndex() : i nt
Scrol l Vi ew
views::VerticalScrollView
+
Verti cal Scrol l Vi ew(Context)
+
onTouchEvent(Moti onEvent) : bool ean
+
onInterceptTouchEvent(Moti onEvent) : bool ean
views::Android:View
Li nearLayout
views::SearchView
+
SearchVi ew(Acti vi ty)
+
i nSearchMode() : bool ean
+
showSearch(bool ean) : voi d
+
hi deSearch(bool ean, IAni mati onEnd) : voi d
+
hi deSearch(bool ean) : voi d
+
setFi l ter(Stri ng) : voi d
+
getFi l ter() : Stri ng
viewer::Android:Activity
viewer::BusinessCardEditor
Acti vi ty
viewer::BluetoothDevicePicker
-m_header
-vscrol l
-m_search
«use»
«use»


5.

Optimizations

After implementing the application we tried to optimize its performance. Since Android limits memory
usage to 16MB per application, we had to use less memory and more IO. In order to find where we allocated
large blocks of memory, we used Eclipse Memory An
alyzer and garbage collector logs. From these tools, we
found two main activities with the highest memory usage. Most of the memory was for bitmaps storage,
which was done for performance enhancement. In order to avoid application crashing due to out of me
mory
exceptions, we cached most of the bitmaps to files and stored only 3 bitmaps in
memory at any given time.


Another problem was the size of the business card and the fact that we had to “transfer” it between
different activities in the application. In Android, in order to send data to another activity, Intent objects are
used. The size of an intent is limited an
d couldn’t contain the entire business card. In order to solve this
problem, we cached the card to temporary storage and sent references to the file instead. On the opened
activity, we used the reference to get the card’s instance.


Based on the results fr
om the memory analyzer of from the logs, it seems that memory problem were
solved and the application became more stable.









6.

References




Google’s Android Developers



http://developer.android.com/index.html



Wikipedia



Bluetooth, encryption



Security in
software applications
-

Course site



http://webcourse.cs.technion.ac.il/236350/Spring2010/en/ho_Lectures.html




Java docs



http://java.sun.com/j2se/1.5
/docs/api/