MobyRek: A Restaurant Recommender for Mobile Phone Users Faculty of Computer Science Free University...

MobyRek:A Restaurant

Recommenderfor Mobile Phone Users

Faculty of Computer Science

Free University of Bozen-Bolzano

May, 2007

Quang Nhat Nguyen

(Presented in the course “Mobile Services”)

MobyRek: A Restaurant Recommender for

Mobile Phone Users

Content

User problem

Usage scenario

System architecture

Midlet-side components

Server-side components

Common components

Hints for design of mobile applications

MobyRek: A Restaurant Recommender for Mobile Phone Users

User problem User uses a mobile phone to find his/her desired

restaurant for lunch or dinner

A huge number of restaurants in a city• different types• different characteristics• different locations

How a user can find the restaurant that best suits his/her needs and preferences??

The user needs the system support• by means of the system recommendations• to browse the recommended restaurants, to evaluate and

criticize them, and finally to select a desired one


Recommender systems Recommender Systems

decision support tools that suggest to users those products and services which best suit their needs and preferences in their particular situation and context

very useful in case users are overwhelmed with alternatives to consider

Based on a number of techniques including, for example, information filtering and retrieval, decision theory, machine learning, adaptation and personalization, user modeling, etc.

Successfully applied in a number of domains, such as books, news, movies, CDs, travel products, etc.

To understand in detail about Recommender Systems, you may go to the “Advanced Topics in Information Systems” course (http://www.inf.unibz.it/~ricci/ATIS/index.html)


Usage scenario

MobyRekMobyRek

Knowledge sources

Knowledge sources

requests for desired restaurant

shows best candidates

browses the restaurantscriticizes a restaurant

adapts the query rep.

shows new recommendations initializes the query rep.

selects a restaurant, or quits

stores the rec. case


A recommendation session• starts when a user requests the system to find some desired restaurants• ends when the user either selects a restaurant or gives up the current session• evolves in cycles (in each cycle, a set of recommended restaurants are

shown to the user)

User’s initial conditions

and

contextual constraints

Computation of a recommendation list

Recommended restaurants

Critique to a restaurant

Adaptation to new preferences

Storage ofcurrent case

Recommendation session case base

Initialization ofthe user queryrepresentation


System architecture (1)

MobyRek

midlet

MobyRek

server

Local stores Back-end database

GPS receiver

HTTP connection

(MIDP 2.0 / CLDC 1.0)


System architecture (2)

OS for mobile devices (e.g., Symbian)

K virtual machine (KVM)

OS for computers (e.g., Windows)

Java HotSpot virtual machine

Common components

Midlet-side components Server-side components

User access authentication

Recommendation session management

Data transferHandling

exceptions

User pos. detection

Search initialization

User critique management

Display of recommendations

Display of restaurant details

Rating sel. restaurant

Similarity & ranking

Management of Travel Notes

Management of user opinions

Management of local stores

Logging user actions

Management of user def. pref.

Transfer oftype-defined data

Transfer oftype-defined data

Service requestcontrollers

Back-end databasecommunicators

Computation & filtering on location data

User query execution

Initialization ofuser query representation


Package diagram

The MobyRek package consists of 115 classes

uiLocalStore

clientAccessControl

DataControl

GeoInfoManage

ment

QueryManage

ment

UserPrefRepInitial

ization

PreliminaryRep

client server client server client server

client Exception serverFeature

ValueRepUserModel

SimilarityComputation

utilData

Exchange

MobyRek

datapackage


Midlet-side components (1) Design of the graphical user interfaces

• Examples of the GUIs: displaying the list of recommended restaurants, displaying restaurant details, reading/writing opinions about restaurants, etc.

• Types of the GUIs: The MobyRekMIDlet root screen is a subclass of javax.microedition.midlet.MIDlet

The other GUIs are subclasses of either javax.microedition.lcdui.Form or javax.microedition.lcdui.List

• For time-consuming tasks, always show a screen explaining what the system is doing

• On every screen, always provide a Back/Home command to return to the parent/root screen


Midlet-side components (2) Design of the user navigation/interaction structure

• Each system’s function (e.g., showing the recommendation list) has a separate (i.e., own) screen

• Every screen is reachable from the MobyRekMIDlet root screen

MobyRekMIDlet

Screen for showing rec. list

Screen for showing restaurant details

Screen for viewing value of a feature

Screen for criticizing the feature value

. . .. . .

. . . . . .

. . . . . .

(the root screen)

Screen for initializing the search

. . . . . .


Midlet-side components (3) Detection of the user’s current position

• Did not exploit the Location API package (javax.microedition.location), because no mobile phones, at that time, implemented this API

• The midlet communicated, via bluetooth, with a GPS receiver

• Exploited the Bluetooth API package (javax.bluetooth)

• Read the GPS data from the GPS receiver. If the data is available and reliable, get the latitude and longitude in the NMEA0183 format

– (lat: <DD><MM.MMMM><N/S>, long: <DDD><MM.MMMM><E/W>)

– e.g., (lat: 4605.2094N, long: 01107.2941E)

– Defined by the National Marine Electronics Association (NMEA) in the USA

– The only standard Input/Output message format in the GPS industry (both for GPS Hardware and for GPS Application Software)


Midlet-side components (4) Management of local stores in the mobile device’s storage

• There are 4 local stores (using the RecordStore class)– TravelNotesStore: the user’s selected products and services– UserSettingsStore: the user’s default preferences (e.g., non-smoking rooms)– CustomerOpinionStore: the user’s opinions about restaurants– LogDataStore: the log of the user’s navigation history (i.e., session-scoped

sequence of time-stamped actions)

• Each record is a structured (i.e., typed) object, stored as a bytes array (i.e., byte[]) in a RecordStore

– E.g., each record in the CustomerOpinionStore local store represents an object of the CustomerOpinionRecord class

– Advantages: compact storing and very fast reading (e.g., compared to reading/writing comma-separated string data)

• Exploit the javax.microedition.rms package, and the java.io.DataInputStream, java.io.ByteArrayInputStream, java.io.DataOutputStream, java.io.ByteArrayOutputStream classes


Server-side components (1) Service request controllers

• Java servlets that serve the service requests from the midlet

• Exploit the javax.servlet package

• A service request from the midlet is identified, and served appropriately, based on the request id/code

e.g., STARTING_REC_SESSION

• A service response code (i.e., to the midlet) may indicate OK_HEADER

the service request was served successfully

CONNECTION_ERROR_HEADER | DATABASE_ERROR_HEADER

errors occurred in serving the request


Server-side components (2) Back-end database communicators

• The service request controllers (i.e., servlets) do not exchange data directly with the back-end database

• This data exchange is managed by the back-end database communicators

• Connection to the database through JDBC (e.g., jdbc:oracle:thin:@<dbms_host>:<dbms_port>:<db_schema>)

• Database connections are managed by a connections pool, instead of creating new connection per request

• Requests that modify data in the database (e.g., insertion) are performed in transactions A database transaction is a set of database

operations that should be done as a whole

Service request controllers

Database Communicators

Back-end database


Common components Data transfer between the midlet and the server

• Via HTTP connection

• Support sending/receiving data at both the midlet-side and the server-side

• Data is exchanged in either the primitive types (e.g., byte or int) or the types defined by the MobyRek application (e.g., CustomerOpinionRecord)

Handling exceptions• Midlet-server communication exceptions

• Database access exceptions

• RecordStore access (i.e., midlet-side) exceptions


Hints for design of mobile applications (1) Early and carefully define the target mobile devices

• Which device classes?

e.g., mobile phones, PDAs, or tablet PCs?

• Which device configuration?

e.g., CDC, CLDC v1.0, or CLDC v1.1?

• Which device profile?

e.g., MIDP v1.0, MIDP v2.0, or MIDP v2.1?


Hints for design of mobile applications (2) Always keep in mind that mobile devices are limited,

especially in screen size and computing power

For example …

Small screen, enough for showing only 3 restaurants

We have to divide the recommendation list into pages

Small screen makes it difficult to show all the restaurant detailsNot enough space to show a feature’s value


Hints for design of mobile applications (3) Always put time-consuming tasks in separate threads

to avoid blocking the user interface• For example, in the MobyRek system the following tasks are

implemented to run in separate threads– User authentication (i.e., log-in)– Detection of the user’s position– Retrieval of the pre-defined list of landmarks (i.e., from the server)– Computation of recommendation lists– Retrieval of a restaurant’s picture and routing guide– Saving/reading user opinions about restaurants– Saving the user’s critiques in the server database– Saving the user’s recommendation session– Computation of the distance from the user’s position to a given restaurant– Uploading the user’s actions log to the server– . . .


Hints for design of mobile applications (4) Always display a

notice/explanation during the execution of a time-consuming task

Always provide the user a menu command to pause/discard the running task


Hints for design of mobile applications (5) Handling exceptions

• Precisely and exhaustively capture all exceptions that may occur, especially in midlet-server communications

• Provide the user some ways to get over the problem, such as to retry the failed task to roll back to the previous state . . .

• Use the finally clause of the {try/catch/finally} exception handling framework to do some important tasks (e.g., closing the open connection) in case an exception occur

For example...I►


Hints for design of mobile applications (6) Test with real mobile devices, not just with emulators,

especially for:

• Midlet-server communications, or data transfer (i.e., disconnected, interrupted, incomplete data transfer, etc.)

• Display of graphical user interfaces (different devices displays GUIs in different looks and feels)

• User-system interactions (# of buttons, buttons’ positions on the device, menu organization of the device, etc.)


Hints for design of mobile applications (7)

• Different in the layout and rendering

Emulator: caption and content are in the same line

Phone: caption and content are separated in two lines

• Different in the organization and order of menu commands

Emulator: contextual menu is located on the right

Phone: contextual menu is located on the left


Hints for design of mobile applications (8)

• Different in navigation between the objects on the screen

Emulator: static objects are traversable

Phone: static objects are not traversable

• Different behaviors regarding the internal state of interactive items

Emulator: a ChoiceGroup item’s internal state does not change if the user clicks twice on the same option

Phone: the internal state changes

MobyRek: A Restaurant Recommender for

Mobile Phone Users

Thank you for the attention!

MobyRek: A Restaurant Recommender for Mobile Phone Users Faculty of Computer Science Free University...

Documents

Transcript of MobyRek: A Restaurant Recommender for Mobile Phone Users Faculty of Computer Science Free University...