Media Browser on Android Platform

 UMEÅ UNIVERSITY
Department of Computing Science SE‐901 87 UMEÅ SWEDEN Media Browser on Android Platform Master Thesis in Computing Science, 30 ECTS Credits MALIN BERGGREN May 2008 SUPERVISOR AT CS‐UMU Jerry Eriksson SUPERVISOR AT TACTEL Mattias Ohlsson EXAMINER Per Lindström Abstract Abstract
At the moment the Open Handset Alliance is developing a new platform for mobile devices. The platform has a Linux kernel and uses the Java language for implementation of the application. Tactel is a company that develops applications for mobile devices and provides solutions to many of the world's mobile handset vendors. The development of mobile device applications is a constantly changing market and the developers have to be able to make applications for a lot of different platforms available on the market. Concerning the Android platform Tactel wants to know if their graphic engine is portable to this new platform. This report consists of an investigation of differences between Java Micro Edition (JME) and Android and a description of the work of porting a graphic engine and using this engine to develop a media browser. i ii Abstract Abstract Table of Contents 1. Introduction .................................................................... 1 0
5
2. Background of the project ............................................... 3 1
6
2.1 Android .............................................................................. 4 2
6
2.2 Graphic Engine .................................................................... 4 3
6
2.3 Unified Media Bar ................................................................ 4 4
6
3. Problem description ........................................................ 5 5
6
3.1 Android and JME investigation ............................................... 6 6
6
3.2 Porting ............................................................................... 6 7
6
3.3 Implementation of application ............................................... 6 8
6
4. Methods .......................................................................... 9 9
6
4.1 Android and JME investigation .............................................. 10 1
6
4.2 Porting of Graphic Engine..................................................... 10 1
7
4.3 Reusable components.......................................................... 10 1
7
4.4 Media browser .................................................................... 10 1
7
5. Investigation................................................................. 11 1
7
5.1 Overview of Java Micro Edition.............................................. 12 1
7
5.2 Overview of Android ............................................................ 13 1
7
5.3 Overview of package, class and methods comparison ............... 30 1
7
5.4 Comparison ....................................................................... 14 1
7
5.4.1 Project files ....................................................................................................... 15 1
7
5.4.2 Application user interface structure ................................................................ 17 2
7
5.4.3 Displaying graphics ........................................................................................... 20 2
8
5.4.4 Key event handling ........................................................................................... 21 2
8
5.4.5 Multimedia support ......................................................................................... 21 2
8
5.4.6 File access ......................................................................................................... 22 2
8
5.4.7 Communication ................................................................................................ 24 2
8
5.4.8 Request assets .................................................................................................. 25 2
8
5.4.9 Reuse of applications functionality .................................................................. 26 2
8
5.4.10 Permissions and security .................................................................................. 27 2
8
5.4.11 Other functionality ........................................................................................... 29 2
8
iii iv Abstract 6. Porting .......................................................................... 31 3
8
6.1 Porting from JME to Android ................................................. 32 3
9
6.2 Porting of graphical engine from JME to Android ...................... 32 3
9
6.2.1 Media player ................................................................................................... 32 3
9
6.2.2 Graphics ........................................................................................................... 34 3
9
6.2.3 Key handling .................................................................................................... 35 3
9
6.2.4 File access ........................................................................................................ 36 3
9
7. Implementation of the application ................................ 37 3
9
7.1 Reusable components.......................................................... 38 3
9
7.1.1 Layers .............................................................................................................. 38 3
9
7.1.2 Affectors .......................................................................................................... 38 4
9
7.1.3 Collectors ......................................................................................................... 39 4
1
7.1.4 Nodes .............................................................................................................. 39 4
1
7.2 Media browser .................................................................... 40 4
1
7.2.1 Application structure ....................................................................................... 40 4
1
7.2.2 Application functionality ................................................................................. 43 4
1
8. Result ............................................................................ 45 4
1
8.1 Android Media Browser ........................................................ 46 4
1
8.1.1 Starting the application after shutdown ......................................................... 46 4
1
8.1.2 Video ............................................................................................................... 46 4
1
8.1.4 Music ............................................................................................................... 50 5
1
8.1.5 Pictures ............................................................................................................ 54 5
1
8.1.6 Settings ............................................................................................................ 54 5
1
9. Final comments ............................................................. 57 5
1
9.1 Limitations ......................................................................... 58 5
1
9.2 Future work ....................................................................... 58 5
1
Acknowledgements ............................................................ 59 5
1
References ......................................................................... 61 5
1
Appendix............................................................................ 65 5
1
List of Figures List of Figures
Figure 3.3.1 Sony Ericsson W910i UMB (1) ............................................................................ 6 1
1
Figure 5.2.1 Android platform architecture.................................................................... 13 Figure 5.4.2 Displayable and its subclasses. ................................................................... 18 Figure 5.4.4 View hierarchy in Android .......................................................................... 19 Figure 5.4.3 Viewing of content in Android. .................................................................. 19 Figure 5.4.4 View hierarchy in Android .......................................................................... 19 Figure 6.2.1 Stages of a player in JME. ........................................................................... 33 1
1
Figure 6.2.2 Stages of MediaPlyer in Android ................................................................ 33 1
1
Figure 7.2.1 The structure of AMB. ................................................................................ 40 1
1
Figure 7.2.2 The structure of the music part of AMB ..................................................... 41 1
1
Figure 7.2.3 Structure of the pictures part of AMB. ....................................................... 42 1
1
Figure 7.2.4 Structure of the video part of AMB. ........................................................... 43 1
1
Figure 7.2.5 The main class of AMB. ............................................................................... 43 1
1
Figure 7.2.6 The layers implemented in AMB ................................................................ 44 1
1
Figure 7.2.7 The nodes implemented in AMB. ............................................................... 44 1
1
Figure 8.1.1 The main menu of AMB. ............................................................................. 47 1
1
Figure 8.1.2 The video menu. ......................................................................................... 48 1
1
Figure 8.1.3 The list of videos on the external media. ................................................... 48 1
1
Figure 8.1.4 AMB Video player view. ............................................................................. 49 1
1
Figure 8.1.5 The music menu .......................................................................................... 49 1
1
Figure 8.1.6 Artists chosen from the music menu shows the currently available .......... 51 1
1
Figure 8.1.7 An artist is chosen and all tracks from that artist is shown. ...................... 51 1
1
Figure 8.1.8 When a track is chosen all the songs of the list is added to the player ...... 52 1
1
Figure 8.1.9 The playlist view. ........................................................................................ 52 1
1
Figure 8.1.10 When creating a new playlist the list should first be given a .................. 53 1
1
Figure 8.1.11 When the list has a name the tracks are chosen from the list of tracks. . 53 1
Figure 8.1.12 The picture menu, showing how many images there are in the category.54 Figure 8.1.13 The view showing images in a grid, the selected image in the centre. .... 55 Figure 8.1.14 The view of an image in full size or as large the screen allows. ............... 55 v vi List of Figures List of tables List of tables
Table 3.3.1 Menu items .................................................................................................... 7 Table 5.1.1 JSRs included in the full MSA in JSR 248 ...................................................... 12 vii viii List of tables Abbreviations Abbreviations
Abbreviation AMB API APK CLDC DRM HTTP JAD JAR JCP JDBC JDK JME, J2ME JSR MIDlet MIDP MMS MSA OS PKI SAX SDK SMS SOAP SQL UI URL UMB XML Description Android Media Browser Application Programming Interface The Android package file extension Connected Limited Device Configuration Digital Rights Management HyperText Transfer Protocol Java Application Descriptor Java Archive Java Community Process Java database connectivity Java Developers Kit Java Micro Edition Java Specification Requests An application of the MIDP Mobile Information Device Profile Multimedia Messaging Service Mobile Service Architecture Operation System Public Key Infrastructure Simple API for XML Software Development Kit Short Message Service A protocol for exchanging XML‐based messages (once stood for Simple Object Access Protocol) Structured Query Language User Interface Uniform Resource Locator Unified Media Bar Extensible Markup Language ix x Abbreviations Chapter 1 Introduction
Tactel is a developer of mobile applications and solutions and works with many of the world's major network operators and mobile handset vendors. The mobile business is a constant changing area and Tactel wants to be able to meet the future needs. In doing so, trying new platforms and being able to implement applications for many different platforms are essential. This thesis have focused on a new platform coming to the mobile market in a near future, Android, a new mobile platform using Java for implementing applications. The thesis has been carried out at Tactels office in Umeå. The thesis involves mobile platforms investigation, porting of a user interface framework, and development of a media browser on the Android platform. The stages of the works are described in ten chapters as follows: Chapter 2 – Background introduces Android and tools at Tactel. Chapter 3 – Problem description introduces the problem to be discussed. Chapter 4 – Methods describes the methods of approaching the problem. Chapter 5 – Investigation compares Java Micro Edition with Android. Chapter 6 – Porting describes the porting of a graphic engine from JME to Android. Chapter 7 – Implementation of the application describes a way of using the engine. Chapter 8 – Result presents the result of the thesis. Chapter 9 – Final comments some final comments of the work. Chapter 10 – Acknowledgements thanks for the opportunity. 1 2 Introduction Chapter 2 Background of the project
This chapter gives some background information on technologies and products connected to the thesis. It gives an introduction to Android and the Open Handset Alliance and the graphical engine mentioned throughout the project. Some background of what is on the mobile device market, at the moment, when it comes to media browsers is given as well. 3 4 Background of the project 2.1
Android
The Open Handset Alliance, consisting of 30 companies and among them Google, has recently announced their new open source platform for mobile devices. The purpose of this alliance is to develop and support open technologies that will enhance mobile devices, making it easier bringing new technology and applications to the market. The project of the alliance is named Android, an open source platform for developing applications for mobile devices. Android consists of an operating system, middleware and key applications. The operating system at the core of the Android platform is Linux. Applications are written in Java and an amount of new APIs has been created for Android, and an SDK with emulator exists for development (2). So far, most Java programs for mobile devices have been written for Sun’s Java Micro Edition (JME) platform. This platform is quite good, but one of the reasons for developing Android is the fact that the developers think it takes Sun too long to add new API’s to JME. Another reason is that the implementation of the platform differs a lot between different manufacturers where some include more advanced APIs than others. 2.2
Graphic Engine
The graphic engine mentioned in this report is a graphic engine, implemented by SouthEnd a Tactel subsidiary, for creating media browsers and other graphic user interfaces for mobile devices. This engine is originally implemented in JME but has as well been ported to other programming languages. The engine has functions for creating graphic user interfaces by adding different nodes to the display, the nodes can be moved on the display, transformed and changed. It is also possible to group nodes for movements. Functions for playing media files and working with files locally and using http is also a part of the graphic engine. 2.3
Unified Media Bar
Mobile phones now days are not used only for making calls. The devices are rather a small computer or a combination of a phone, mp3‐player and a camera. Many mobile devices do as well have access to Internet and so both offline and online media content are available in the device. Manufacturers are striving towards creating more and more user friendly interfaces for handling these media. Examples of media content that is common in mobile devices are images, music, ring tones, videos, and TV‐ and radio channels. One example of a device with a next generation Media Browser, the Unified Media Bar, is the Sony Ericsson W910i. This Media Browser allows the user to navigate and view all type of content in a single application (3). Chapter 3 Problem description
With the Open Handset Alliance launching a new mobile platform, Android, software developers should be able to offer software also for this platform. To make this economically it would be preferred if existing engines can be used also for this new platform. The developers can then continue developing the same products and they can be used on more than one platform by porting them instead of writing another one. Something is said to be portable if it is less time consuming to port an application then writing a new one. The three steps brought out to investigate the portability of a graphic engine are described below. The first is an investigation of Android and JME and their portability, then porting a graphical engine and at the end using the graphical engine for implementation of a media browser in Android. 5 6 Problem description 3.1
Android and JME investigation
The goal of this thesis is to make an investigation of the similarities and differences in Java Micro Edition (4) and Android (5). The focus of the investigation is to find out how much work it is to port a JME application to Android. The porting investigation is focused on porting from JME to Android, not in the other direction. The investigation also covers application security model and Android SDK multimedia support, information that are of interest in the following tasks. 3.2
Porting
Tactel has developed a graphics engine for Java Micro Edition. The question is if it is portable to Android. In this step it should be investigated what it takes to port this specific engine to Android. The engine will then be ported and the ported and adapted engine will be used by the Media Browser application in the next step. 3.3
Implementation of application
This third and last part of the problem is to use the ported graphic engine to develop an application that list contents stored on the device, in particular sounds and pictures. The graphical user interface for the application shall be similar to UMB (Unified Media Bar), which is a graphical user interface used by Sony Ericsson. The interface of the Unified Media Bar in a Sony Ericsson W910i can be seen in Figure 3.3.1. This media browser serves as the starting point for the development of the media browser of this project called Android Media Browser (AMB). The user interface of the AMB will be a look‐a‐like user interface of the unified media bar as well as the features. (1)
Figure 3.3.1 Sony Ericsson W910i UMB Problem description 7 The Android Media Browser (AMB) should have the menu shown in Table 3.3.1. The focus will be on implementing the part marked as bold in the layout in Table 3.3.1. Music Pictures Video Settings Resume Latest photos Resume Album Camera Videos Artist Pictures Playlists Tracks Playlists Table 3.3.1 Menu items Music – In UMB audio files can be displayed sorted by album, artist or just in alphabetic order. The audio files can be played by clicking the chosen file. A playing file is possible to pause and then resume. Playlist can be created to play songs in a specific order. Pictures ‐ In UMB it is possible to view the latest photos, go to the camera to take a new picture or view all photos or all pictures. A photo is possible to get in full screen by selecting it. Video ‐ In UMB video files is displayed in alphabetic order. The video files are possible to play by selecting a file. A playing file can be paused and the resumed. Playlists can be created to play videos in a specific order. Setting – The screen can be set to be horizontal, vertical or automatic adjusted on tilting the device. Of these features the AMB should be possible to extend to include all of them. In the first implementation the focus is on playing music and presenting the audio files. The audio files should be sorted alphabetically by song name, by album or by artist. Image files should be sorted in the category latest photos and all pictures. 8 Problem description Chapter 4 Methods
This chapter describes the method to carry out the project of investigate porting, porting a graphic engine and implement an application on the Android platform by using the ported engine. 9 10 Methods 4.1
Android and JME investigation
First an overview of JME and Android has to be made. To find out what it takes so port a JME application to Android the APIs and documentations of both JME and Android have to be investigated to find similarities and differences, with special focus on security models and multimedia support. Things to investigate are what media can be showed and played and how is it done. What does the hierarchy of applications objects for displaying objects on the screen look like? Can audio files be played in the background? Is it possible to forward an audio‐file? And other features of media. How can files be accessed in the file system? Is it possible to use files belonging to other applications? What features of the phone is possible to use? The investigation is documented in chapter 5. 4.2
Porting of Graphic Engine
The graphic engine consists of a library of classes to perform tasks on different media and graphic files. Since both JME and Android uses Java for implementation some parts of the engine is reusable, but not all. Both JME and Android have some individual APIs that is not possible to use in an application for the other platform. The classes to be ported mainly performs tasks of media files like audio and video, graphics like what will be show on the screen and file access. All these things were investigated in the first step. Now this should be implemented and adopted to the graphic engine. The porting procedure is described in chapter 6. 4.3
Reusable components
At the beginning of the implementation reusable components for use in the media browser should be constructed. The browser will consist of a lot of lists so a list class will be constructed as well as a grid. A class for retrieving images, music and video files should be constructed for later us in the browser for finding data to present. The reusable components are described in chapter 7. 4.4
Media browser
For implementing the media browser the ported graphics engine should be used. The reusable components implemented on top of the graphic engine for viewing lists should be used when implementing the menus of the application. Main focus will be on determine file types, playing audio files and showing images in a graphic user interface that is similar to the Unified Media Bar in Figure 3.3.1. The application will be tested on the Android phone emulator from the second release M5 of the SDK and emulator for Android. The Android Media Browser is described in chapter 7 and 8. Chapter 5 Investigation
This chapter provides information of the investigation of JME versus Android. First is an overview of both JME and Android then a summary of the comparison. At the end of this chapter is a full description of what has been investigated and a comparison that goes deep in to certain parts of functionality. The focus of the investigation is connected to the graphic engines functionality and portability. 11 12 Investigation 5.1
Overview of Java Micro Edition
Java Micro Edition (JME) is Suns library for developing applications for mobile devices. There are two configurations of JME where the Connected Limited Device Configuration (CLDC) is the one for devices with less power. CLDC is used together with a Mobile Information Device Profile (MIDP). The main class of an application in this type of application is a MIDlet class. The MIDlet can implement graphic user interfaces and user interaction. A MIDlet has a display object for handling what is displayed on the screen. A displayable is an object that can be displayed on the screen, by the display object. A MIDlet has only one display object to manage the screen and input system and it does not keep history of what was last screened. The CLDC and MIDP are often used together with some of the Java Specification Requests (JSR) defined for mobile devices. The JSR 248 (6) defines a standard set of JSRs to be included in a device. It is created to minimize fragmentation of mobile Java environments by defining a predictable and highly interoperable application and service environment for developers. The JSRs included in the full mobile service architecture (MSA) of JSR 248 is presented in Table 5.1.1. The JSR 139 CLDC is the Connected Limited Device Configuration and the JSR 118 MIDP is the CLDC profile for running applications on cell phones. In the following comparison of JME and Android the environment of the full MSA for JME will be used when most new phones implements this specification. There are other JSRs available for JME as well but most of them will not be considered in the comparison for the reason that they does not exists in most phones. JSR 139
JSR 118
CLDC
MIDP
JSR 75
JSR 82
JSR 135
JSR 184
JSR 205
JSR 226
JSR 172
JSR 177
JSR 179
JSR 180
JSR 211
JSR 229
JSR 234
JSR 238
File & PIM
Bluetooth
Mobile Media
3D Graphics
Messaging
Vector Graphics
Web Services
Security & Trust
Location
SIP
Content Handler
Payment
Multimedia Supplements
Internationalization
Table 5.1.1 JSRs included in the full MSA in JSR 248 Investigation 5.2
Overview of Android
Android is a new operating system and platform for mobile devices. By offering an open source platform, with development in the Java language, Google and the open handset alliance hopes to get in to the market of mobile devices. Android is a software stack for mobile devices that includes an operating system, middleware and key applications. The architecture of the Android operating system and platform can be seen in Figure 5.2.1. The focus of this report is on the application framework and to implement an application in the application layer. Applications
Home
Contact
Phone
Browser
AMB
Application framework
Activity manager
Content providers
Notification manager
Telephone manager
Location manager
Window manager
View system
Package manager
Recource manager
XMPP service
Libraries
Android runtime
Surface manager
OpenGL|ES
SGL
Media framework
FreeType
SSL
SQLite
WebKit
libc
Core libraries
Dalvik Viritual machine
Linux kernel
Display driver
Bluetooth driver
Binder (PC) driver
Keypad driver
Audio driver
Camera driver
Flash memory driver
USB driver
WiFi driver
Power manager
Figure 5.2.1 Android platform architecture.
An Android application consists of four main building blocks (7); Activity (8), Intent Receiver (9), Service (10) and Content Provider (11). The most common part is the activity. An activity is the part of an application handling the graphic user interface. An activity is a class that implements the Activity class. Every activity in the application has a user interface with a view and event response. An application consisting of three different screens will have three different activity classes. Moving to a new screen is accomplished by starting the new activity and when returning an activity can return values to the calling activity. When an activity starts another activity the calling activity 13 14 Investigation is paused and therefore also put to the history stack. Android keeps history of all activities from the home screen and forward. An activity can choose to no longer be in the history stack if so is needed and will then be removed. The user can navigate backwards in the history stack to see previous screens.
To move from one screen to another a special class called Intent (12) is used. The intent can be defined to start a specific activity or to find an activity that can provide what is needed. To be able to find an activity; permissions must be set to allow the application to use the activity in the way it wants to. An intent receiver can be used to receive intent broadcasts from other applications in the system. For example when it is midnight or when the phone rings. The application does not need to be running for the intent receivers to receive information. The intent receivers do not have a user interface, but they might use the Notification Manager to alert the user if something has happened (7). Services might be used for code that is long‐lived and will run without a user interface, they are run in the background. For example a media player might want to keep playing the playlist even though a new activity has started. Then the player could be placed in a service instead of an activity. The activity will then keep playing until it is stopped or have reached the end of the playlist. To store and retrieve data a content provider (13) can be used instead of files and databases. A content provider is useful if the data stored by the application should be shared with other applications. The content provider has methods to let other applications store and retrieve the type of data that is handled by that content provider. Two other important parts of an android application are the AndroidManifest.xml (14) file and the notification manager (15). The AndroidManifest.xml file is the control file that tells the system what to do with all the top‐level components. It is a required file for an Android application and is placed in the root folder of the application. The AndroidManifest.xml file describes global values, including the application components and the implementation classes for each component. It does as well describe what kind of data each component can handle, and where they can be launched. The notification manager can notify the user by adding a small icon in the status bar and the user can then use the notification icon to receive information about the notification. The most well‐known notifications are SMS messages, call history and voicemail but applications can create their own notifications as well. The notification mechanism is used for getting the users attention. 5.3
Comparison
This section contains a pretty detailed comparison of JME and Android on package, class and method level. Not all part of the JME and Android APIs are compared, only some selected parts that are important for the following chapters about porting and implementation. Investigation 5.3.1 Project files
This section will compare the files a project of the JME consists of in respect to the files an Android project consists of. First the files of the different project types will be declared and then there will be some comments of the similarities and differences of the files. 5.3.1.1 Files in JME projects A JME project has some files in the project root and some directories consisting of project files of specific types. Not all files declared below are necessary for all projects. 5.3.1.1.1 Src folder The src folder contains the packages with the source code of the project. 5.3.1.1.2 Bin folder The bin folder contains the compiled classes of the project. 5.3.1.1.3 Res folder This folder contains resources to the project, images, audio, text and others. 5.3.1.2
Built files in JME projects 5.3.1.2.1 Jar‐file The Java archive file, jar‐file, is a packed project archive that is possible to deliver to a device, an application file that can be run on the device. 5.3.1.2.2 Manifest.mf A file that describes the content of the jar‐file and contains attributes to describe the contents of the jar‐file. It is mandatory to add a manifest.mf file to the jar archive. There are some mandatory attributes of a manifest.mf file and some optional. 5.3.1.2.3 Jad‐file The Java Application Descriptor file, jad‐file, is an optional file to support the jar archive. The jad‐file contains information about the MIDlet suit and has the purpose to give information about if the application is appropriate for the device (16). Even though the jad‐file is optional if it is used there are some mandatory attributes in the file and some optional. 5.3.1.3 Files in Android projects An Android project consists of a couple of different files and folders. The different types are described below. 5.3.1.3.1 R.java This file contains references to the files in the drawable, layout, values and raw folder. The references in R.java can be accessed in the application through R.<FOLDER>.<NAME>, R.id.<ID> or R.attr.<ATTR>. 15 16 Investigation 5.3.1.3.2 Src folder This folder contains the packages with the source code of the project. 5.3.1.3.3 Bin folder This folder contains the compiled classes of the project. 5.3.1.3.4 Res folder This folder contains folders with the different types of resources for the project, images, values, layout files and others. 5.3.1.3.4.1 Drawable folder This folder contains images like for example the icon of the application, a background image or other images. 5.3.1.3.4.2 Layout folder This folder contains xml‐files defining layouts. The layout can be loaded in to the application by using the R.java file. 5.3.1.3.4.3 Values folder This folder contains xml‐files that define constants global values in the application. The values can be used by the application through the R.java file. 5.3.1.3.4.4 Raw folder This folder contains raw files like music and video files to be used in the application. The raw files can be reached through the R.java file to be accessed in the application. 5.3.1.4
Built files in Android projects 5.3.1.4.1 APK‐file The apk‐file is an Android package file, which contains all of the files related to a single Android application. A project is compiled into a single apk‐file. 5.3.1.4.2 AndroidManifest.xml This file defines the user permissions of the application, the activities and the intent filters of the activities. Here is it also possible to set the icon and theme of the application. 5.3.1.5 Differences and similarities in the Android and JME files The biggest difference in the type of files in the projects is the R.java file that is a part of an Android project; this file is necessary for an Android project and is generated automatically from the resource folder. It is used to easy refer to a resource in the folder like a layout or an image. This file does not have any equivalence in a JME project. The source files are used and arranged in packages in the same way and the recourses are kept in a resource directory. The resource directory is sorted by Investigation resource type in Android, while in JME it is possible to arrange the file in any structure. The JME project can have a manifest‐file, but its purpose is not the same as the file AndroidManifest.xml in the Android project. A JME project does though have a jad‐file which does not exist in an Android project and together with the manifest.mf file contains the features of the AndroidManifest file. An Android application consists of a single file to transfer to the device. In JME there is the jad‐file which describes what is needed to be able to run the jar‐file of the application. The jad consists for example of information about size and needed APIs. The jad–file is needed because of the many different implementations of JME. Android is still the same for every device or rater every emulator since there are no devices yet. 5.3.2 Application user interface structure
The structure of an application differs in JME and Android. This section describes the structure of an applications user interface (UI). 5.3.2.1 Application user interface structure of JME In Figure 5.4.1 the structure of application handling in JME is described. At the top is the device which has some JME applications represented by MIDlets. Every MIDlet has some displayable objects consisting of what should be displayed on the screen. The MIDlet can when it is active send one of its displayable objects to the display object which will show it on the screen. To change what is displayed the MIDlet can send another displayable to the display which will update the screen according to the new displayable. Device
Display
Displayable
Midlet
Displayable
Displayable
Midlet
Displayable
Midlet
Displayable
Displayable
Displayable
Figure 5.4.1 Device handling of what to display
Following is a description of the different classes that is used by a JME MIDP application. MIDlet – The main class of the MIDP application. The MIDP class communicates with the device display object to display their displayable. MIDlet has methods for starting, stopping and pausing the application. Display – is responsible of showing the graphical user interface on the screen. It handles the colors for the background and foreground. Display can change the 17 18 Investigation object to be shown on the screen, the object to be displayed are of the class displayable. Display is the manager of the display and input on the device. Displayable – is an object possible to be placed on the screen. It can have a title, ticker and command listeners. The command listeners added will be added as soft buttons and if there is not enough soft buttons they will be added as a menu. Subclasses to displayable are Canvas and Screen. In Figure 5.4.2 the hierarchy on displayable objects can be seen. Displayable
Canvas
GameCavas
Screen
Alert
Form
List
TextBox
Figure 5.4.2 Displayable and its subclasses.
Canvas ‐ handle low‐level events and can draw graphics on the display. It is possible to be mixed with high‐level screens. Canvas provides methods for handling game actions, key events and pointer events. A class has to subclass Canvas to be able to use it. GameCanvas ‐ provides the basis for a game user interface. It inherited features from Canvas like commands and input events and also provides game‐specific capabilities. It has the ability to query key status and has an off‐screen graphics buffer. Screen ‐ is a high‐level user interface class. A screen updates the content on the screen automatically and the content can be changes while it is shown and will then be updated. 5.3.2.2 Application user interface structure of Android Following is a description of the different classes that builds an Android UI application. Activity – is the main class of an Android application. It creates a window where the user interface can be shown either in full screen or as a floating window. The activity sets what is shown on the screen, by setting its content view to a view object. The screen view can be changed by setting the content view to a different view object. An existing view can as well be updated by adding views to it if the view is a subclass of ViewGroup. Only one view can be shown at the same time by an application but a view can be a view group containing other views in a tree structure. The handling of views in Android can be seen in Figure 5.4.3. Investigation Activity
View Group
View Group
View Group
View
View Group
View
View
View
View
Figure 5.4.3 Viewing of content in Android. An activity must be declared in the AndroidManifest.xml file to be accessed. It can be declared to be a launcher, an entry point to the application, and will then be visible as an application on the device application panel or as a home which will be the home screen or as tab a tab in a tab activity or some other type of activity. The most used is launcher. If the current view of an activity does not handle key events, the activity can handle them. The activity can also create a menu, shown by pushing the menu button of the device, to make it possible for the user to interact with the application. View – The view is the object handling a rectangular surface of the screen. It can handle events and draw object on the screen. Views can be arranged in a tree structure as a view group. The layout of a view can be defined in an xml file or be dynamically created by the activity. A view can handle key events and touch screen events. In Figure 5.4.4 some of the views predefined in Android is shown and how they can be arranged in a tree structure. View
Scroll
Indicator
Progress
Bar
Map
View
Analog
Clock
View
Group
View
Text
View
Surface
View
Image
View
View
Figure 5.4.4 View hierarchy in Android
ViewGroup – is an implementation of a view that combines views in different layouts. Exaples of layouts are absolute layout, relative layout, linear layout and table layout. There is an API of predefined implementations of both views and view groups in the Android API. Some examples of predefined views are TextView and ImageView and some ViewGroups are ListView and ImageSwitcher. To create a new view ViewGroups with different layouts can be combined. 19 20 Investigation 5.3.2.3 Application user interface structure of JME vs. Android The displayable screens implementations in JME can be compared with the pre defined implementations of views. Classes that display pre defined objects and handle key events related to them. In Android the MIDlet and display objects functionality is gathered in one object, the activity. The activity is both the class for displaying views and changing the displayed object or activity. 5.3.3 Displaying graphics
To create a user interface the application has to be able to show some graphics on the screen. To do this there are different high and low level implementations. 5.3.3.1 Displaying graphics in JME In JME there are two types of classes that inherit from displayable that handle the UI. Classes inheriting from Screen are high level implementations of UI and those inheriting from Canvas are low level. Screen ‐ is a high‐level user interface class. A screen updates the content on the screen automatically and the content can be changed while it is shown and will then be updated. There are some different implementations of Screen to be used for UI. Subclasses to screen are Alert, Form, List and TextBox. Canvas – is a low level user interface class. It can draw graphics on the display and is possible to be mixed with high‐level screens. A class has to subclass Canvas to be able to use it. A subclass to canvas is GameCanvas. GameCanvas ‐ provides the basis for a game user interface. It inherited features from Canvas like game‐specific capabilities. It has an off‐screen graphics buffer. 5.3.3.2 Displaying graphics in Android In Android there are views that handle the user interface. There are lots of different implementations of views available together with view groups which use a hierarchy of views to display on the screen. View – is the object handling a rectangular surface of the device screen. It can handle events and draw object on the screen. Views can be arranged in a tree structure as a view group. The layout of a view can be defined in an xml file or be dynamically created by the activity. A view can handle key events and touch screen events. Canvas ‐ is a class for holding calls for draws. It has methods for drawing bitmaps, rectangles, circles, text and others. By overriding a views’ onDraw method the canvas can be manipulated and the graphic user interface changed. 5.3.3.3 Graphics in JME vs. Android In JME user interfaces is separated in to high level, screen, and low level, canvas, implementations. In Android all user interface classes inherits view. In Android there exists more available implementations of UIs and high level and low level implementations are not separated. Investigation 5.3.4 Key event handling
To interact with the user key events are used. These events have to be handled and it must be possible to determine which key was pushed. 5.3.4.1 Key event handling in JME In JME can all displayable objects add soft button events to the application but there are only two classes that handle key events, Canvas and GameCanvas. Canvas and GameCanvas handles events for the buttons 0‐9, * and #. There are also game actions connected to the classes for up, down, left, right, fire and four extra actions called a, b, c and d. GameCanvas can also check the status of a button. Many keys can refer to the same action. 5.3.4.2 Key event handling in Android The main class responsible for key events in an Android application is the class View. The different implementations of views handle the events differently, according to what the views purpose is. If the current view does not handle a specific event that event will be passed back to the activity, which can handle the events that the view does not handle. The activity can also add a menu to the menu button of the device which will show a list of menu choices. There are a lot of different key event codes for Android declared in the KeyEvent (17)
class. There are codes for among others 0‐9, *, # and a‐z and actions for up and down. There are key codes to support devices with an alphabetic keyboard. 5.3.4.3 Key event handling in JME vs. Android Android supports more key events then JME. But, JME has more predefined actions to handle. All key events used in JME can also be used in Android; the actions existing in JME can be implemented in Android as well. 5.3.5 Multimedia support
This multimedia support section considers the types of media files like audio, video and images that are supported by the platforms. 5.3.5.1 JME multimedia support The JME media library supports any time‐based audio and video content according to the API (18) and all registered MIME (19) type media. The limitation is on the device which might not be able to play all kinds of media (18). The Media API of JME does not support 3D graphics and animation, general media transcoding, editing or server‐side streaming transmission. It is up to the device manufactures to support these features. There is an optional package, JSR 184, in JME that supports 3D graphics. The means for the JSR 184 package is to display animated 3D graphics in real time on embedded devices. There is an optional package with an OpenGL ES API for handling 3D graphics in JME (20) as well but this API is not included in the JSR 248 specification. 21 22 Investigation 5.3.5.2 Android multimedia support Android supports a lot of different media types. The types mentioned in the documentation are: Images: PNG (preferred), JPG (acceptable), GIF (discouraged) (21) , 9.PNG Sound: MP3, AIFC, AIFF, AU, M4A, SND, WAVE (22), (MIDI, AMR) Video: MPEG4, AAC, H.264 (23) Android does as well support 3D graphics based on the OpenGL (22) and has the possibility to handle streamed media over a data connection (24). 5.3.5.3 Multimedia support in JME vs. Android It seems like JME can handle any type of media according to its libraries, however the devices might have constrains in what it can handle. Android have constrains in what media is supported according to the API. 3D graphics can be handled in both JME and Android. 5.3.6 File access
This section considers the question of access to files on a device and also covers data storage like databases and others. 5.3.6.1 File access in JME By default JME does not support file handling or databases, but through optional packages both these features can be implemented. It is possible to share data and information between MIDlets. This is controlled by the individual APIs. The Record Management System API is an API that specifies methods for sharing record stores between MIDlets (25). 5.3.6.1.1 File handling In JME there is an optional package for file handling, JSR75. The packages consist of an interface for reading and writing to and from files as well as create files and check if the file exists. There is also possible to list all rote nodes and find and create directories (26). Security check is as well a part of the package. Private files like system files or other applications private files cannot be read, which make the connection restricted to prevent unauthorized manipulation of data. The JME platform is responsible of providing a security model supporting the security of the File Connection APIs. 5.3.6.1.2 Databases Through the optional package Java database connectivity (JDBC), JSR169, a set of interfaces for database handling can be used in JME to access databases (27). The JDBC package includes support for different drivers which can be installed dynamically to access different data sources. It can read and write data to any tabular formatted source. To be considered is that this package is not part of the full MSA of JSR 248 and might not be available on a device. Investigation Information can be stored in record stores as well. Record stores can be private to the application or made public to all applications. When creating a record store the application gives it a name, applications record stores must have unique names. Record stores created by different applications can have the same name. The content of a record store will remain persistent across multiple invocations of the MIDlet creating it (28). 5.3.6.2 File access in Android There are different ways of saving and accessing data in Android. Data can be set private to an application or shared with other applications. In Android it is possible to use databases (29), networks, preferences, content providers (13) and files (30) to store and retrieve data. Both databases and files created by an application are private to the application. By using content providers or networks, data can be shared with other applications. For example the contact list of the phone book is provided for other applications to use. 5.3.6.2.1 File handling Android does not use a common file system as in desktop operating systems. On Android all application data and files are private to the application. Android provides ways to expose application data to other applications and request data from other applications. Private files, belonging to the application, and public files, in the file system and on removable media, are possible for the application to read and write by using the common java file library. 5.3.6.2.2 Databases For databases a database library using SQLite (31) is used. It contains functionality an application can use to manage its own private databases. To store data accessible by other applications a content provider (13) can be used instead of files and databases. The content provider has methods to let other applications store and retrieve the type of data that is handled by that content provider. Permissions must be granted by the application to be able to receive data from other applications and the data available to others must be announced in the AndroidManifest.xml file. 5.3.6.3 File access in JME vs. Android The way of saving and accessing data is pretty much the same in Android as in JME. Files on the device can be private to an application and in that whey not be accessed by other applications or public for everyone to use. Both JME and Android can use databases for data storage. The record store in JME can be compared to the content provider in Android for storing data of a specific type. 23 24 Investigation 5.3.7 Communication
This communications section considers all type of contact with the device, other devices or applications. 5.3.7.1 Communication in JME MIDP supply a variety of communication opportunities and by using some optional packages even more types of communications is possible. 5.3.7.1.1 Sockets The MIDP API provides interfaces for implementation of socket connections in its micro edition io package. 5.3.7.1.2 HTTP and HTTPS connections The MIDP API provides interfaces for implementation of HTTP and HTTPS connections. 5.3.7.1.3 SMS and MMS messages The JSR 205 API provides access to messaging features such as SMS and MMS in JME. It allows applications to send and receive wireless messages independent of the underlying messaging protocol and can therefore send both SMS and MMS messages. 5.3.7.1.4 Push, SMS and MMS wakeup Wakeups for a JME application can be registered using PushRegistry (32). The application can be set to listen for information of different kind like SMS messages or a socket communication at a specific port. A MIDlet can also be launched at a predefined time by using PushRegistry. 5.3.7.1.5 Bluetooth The JSR 82 (33) standardizes how to integrate a Bluetooth environment to the JME application. It contains functionality for setting the device Bluetooth discoverable and to discover Bluetooth devices in the environment. 5.3.7.2 Communication in Android In Android it is possible to use a lot of different type of communication opportunities to communicate both externally, through for example Internet, and internally. 5.3.7.2.1 Sockets The java classes from the nio and net packages for socket handling are possible to use for Android implementation. The Apache package for http client support (34)
is available for creation of sockets. 5.3.7.2.2 HTTP and HTTPS connections Android uses Apaches class for creating a connection to HTTP (35). It supports both http and https connections. Investigation 5.3.7.2.3 SMS and MMS messages SMS and MMS messages can be sent using the Android SmsManager (36) in Android. 5.3.7.2.4 Push, SMS and MMS wakeup An intent receiver (9) can be used to receive intent broadcasts from other applications in the system. For example when it is midnight, a SMS arrives or when the phone rings. The application does not need to be running for the intent receivers to receive information. The intent receivers do not have a user interface, but they might use the Notification Manager to alert the user if something has happened (7). 5.3.7.2.5 Bluetooth The org.bluez package in Android provides classes to manage the functionality connected to Bluetooth on the device. 5.3.7.3 Communication in JME vs. Android Android can handle the same kinds of communications as JME. The biggest different is the wakeup functionality. The intent receiver can be used for executing code but not for viewing an UI or starting an application. But it can alert the user by using the notification manager. 5.3.8 Request assets
An application might need access to external assets. This can be done static at start up or dynamical when the assets are needed. 5.3.8.1 Request assets in JME If there are network connections for PushRegistry that have to work for the MIDP application to function these must be static declared in the JAD file as a MIDlet push attribute. PushRegistry networks are networks that will alert the application when there is incoming data. The installation of the MIDlet will fail if the connection could not be verified to be available and the user gets notified that there are conflicts. Installation failure can depend on syntax error in the push attributes, failure to reserve a connection because the connection is already reserved in the device, declaration of a protocol that is not supported for push in the device or referencing a MIDlet class not listed in the MIDlet attributes of the application. The push registration should be done dynamically if the application can function meaningfully without the push. This is done by using the class PushRegistry which maintains a list of inbound connections. The implementation must guarantee that a MIDlet registered for a push is started in response to an incoming connection and can accept the connection (32). 5.3.8.2 Request assets in Android Permissions to use assets can be checked at installation by using the user permission in the Androidmanifest.xml. The application will only be able to use 25 26 Investigation the assets it has granted permission to. Permissions cannot be granted dynamically while running the application. If permission was not granted for an asset the application will not have access to the asset as well as if it was not successfully granted. Any attempt to use assets that were not granted will result in a failure and will possibly result in a security exception. 5.3.8.3 Request assets in JME vs. Android An application can request access to assets statically in both JME and Android by declaring them in the JAD respectively the AndridManifest.xml file. JME can request access to assets dynamically which Android cannot. In Android all permissions to use assets must be granted at installation. The assets requested dynamically must as well be declared in the jad‐file, but a certain type of protocol communication can be requested dynamically. The application is always responsible for handling the use of the assets. Like connect to internet or starting another application. 5.3.9 Reuse of applications functionality
To not be forced to implement the same functionality in more the one application, an application can request another application to handle some functionalities, for example view the phone book or make a call. 5.3.9.1 JME functionality reuse To handle a specific URL action an application can request the platform to handle it. By doing so the appropriate application for handling the URL will be brought to the foreground and let the user interact with the content. While the running MIDlet will be kept in the background. Where the device does not have the capability or resources to run the applications at the same time, the main application have to exit before the called application can start. When the main application is closed the called application will start (37). A content handler, defined in JSR 211, can be requested to handle data. It can invoke registered JME applications and applications that are not java applications by URL, by content type or by content handler id. Multiple content handlers can be registered for a type, suffix and action. The interactions between the invoking and invoked applications are managed so applications can be active either in parallel or in sequence, depending on the Java runtime environment on the device. 5.3.9.2 Android functionality reuse To make use of other applications functionality an intent object can be used to broadcast an activity to some application that can handle it. Applications can use intent receivers to be able to receive intents from other applications. The intent can request different type of actions like viewing data or call someone on the phone. Actions can be defined by an application but there are also some examples of actions implemented in Android (12). Investigation 5.3.9.3 JME vs. Android functionality reuse The reuse of functionality seems to work in the same way in JME as in Android. One application registers a content it can handle and another application calls for an application that can handle a certain type of data. The main difference is in the capability to run more the one application at once. Android have support for running more the on application at time, though only one will be in the foreground and active. In JME it is up to the device manufactures to support parallelism or not. 5.3.10
Permissions and security
There is some permission and security constrains when it comes to what an application can access. This section explains how JME and Android handles security and permissions. 5.3.10.1 JME security model MIDP uses a security concept of trusted applications. This means the application may be permitted to use sensitive and restricted APIs if it is trusted (25). If the MIDlet is trusted the device can give it access as indicated by the security policy. When a MIDlet requests access to a protected API or function it must request the permission of that API or function. Requested permissions can be listed in the MIDlet-Permissions attribute. The permissions listed in the MIDlet-Permissions attribute are critical for the application to work. It will not operate correctly without them. Permissions that are not critical for the application, when the application can run without them with reduced functionality, the permission should be listed in the MIDlet-Permissions-Opt attribute instead of MIDlet-Permissions. An application can be signed as trusted in three levels, trusted 3rd party, operator and manufacturer. Anyone can sign an application as trusted 3rd party. Applications signed as operator and manufacturer are signed by the operator respective the manufacturer of the device. A device can request different type of permissions according to what domain it is part of. The operator domain is often the top domain and the untrusted is the lowest. A device determines if a MIDlet is trusted or not trusted. For a MIDlet to be trusted, it is signed as trusted by using the X.509 PKI (38). This way the device can determine if the application is trusted though signing and verification. If the jar‐
file integrity cannot be trusted by the device it is not a trusted MIDlet and will not get access to sensitive and restricted APIs (39). If the application is not signed correctly it will not be installed. There are two different types of permissions in JME, allowed and user. The allowed permissions are those allowed and the user permissions may be authorized by the user. A permission can be either an allowed permission or an user permission, not both. User permissions can be of three types; the user is asked once per installation, ones per invocation of the application or ones per 27 28 Investigation invocation of the function. The type of permission an application can have for different functions is depending of what trust domain it belongs to. 5.3.10.2 Android security model Android uses standard Linux facilities, such as user and group IDs that are assigned to applications. Each Android application installed to the mobile device is given a unique id when installed. This gives the application its playground and prevent other applications to use the applications assets it and it from using other applications assets. When an application creates a file, the file will be assigned the same id as the application, which makes the access to the file restricted to that application. To make the file readable or writeable, for other applications, the flags MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE can be used, when the file is created. The id of the file is still the id of the application and is still owned by the application but is globally read and/or writeable and other applications can see them. By default an application has no permissions assigned to it. To be able to use protected features of the device an application must have one or more user permissions set. These permissions are set in the AndroidMainfest.xml file by using the tag <user‐permission>. The permissions of the application are granted at installation time. Permissions are requested and granted based on checks with trusted authorities and interaction with the user. Permissions can only be granted at install time not while running the application. If an attempt to use a fetcher is made without permission the attempt will fail. No check with the user will be made while the application is running. When failing it is not guaranteed that an exception is thrown. Permission failure will be printed to the system log. The Android system provides a couple of different permissions (40) but any application can also define its own permissions. Permissions might not be adoptable at all time. Some operations of applications will not permit certain permissions (41). For an application to declare its own permission this permission needs to be described in the applications AndroidManifest.xml file. The declaration should be at the form <permissionid="package_name.PREMISSION_NAME"
Android:label="@string/label_name"
Android:description="@string/description_name" />
The stings label_name and description_name should in this example be declared in the string.xml file. Android relies on its Linux kernel for core system services such as security, memory management, process management and network stack and driver model (23)
. Investigation 5.3.10.3 Security in JME vs. Android In JME permissions are granted in two levels. First the application has to grant permissions by declaring them in the MIDlet-Permissions attribute. Then, depending of what trusted domain the application belongs to, the access has to be granted once or more by the user. The type of user permission can also be set by the user, and what it can be set to also depends of what trusted domain the application belongs to. While in Android all permissions must be set at installation, the user does not need to grant permissions while running the application. 5.3.11
Other functionality
Both JME and Android consists of much more functionality than considered in this chapter. Here are some more functions to be considered. 5.3.11.1 Alarm start up Both in JME and in Android an application can be scheduled to start at a specific time. In JME the PushRegisty class is used and in Android AlarmManager (42). 5.3.11.2 Background execution In JME execution of applications in the background is up to each manufacturer to decide if it should be possible or not. But according to the specification it is possible. In Android more the one application can be running at the same time. Only one will be in the foreground and active for user input. But an application can run services in the background with no user interface and no input from the user. 5.3.11.3 Auto start application In Android the AlarmManager (42) can be used to set an application to start at a specific time from boot, which makes it possible to start it at the time the device starts. In MIDP 2.0 it is not possible to auto start an application at boot, though some devices might support it. Sony Ericsson mobile phones are one type of devices that supports auto start of application. 5.3.11.4 DRM handling There is no information provided about support of DRM handling in the API for either JME or Android. In modern Sony Ericsson devices it is possible to play DRM protected content via the JME multimedia API. 5.3.11.5 Access XML/SOAP web services and parse XML data In JME parsing of XML data and access to web services is accomplished trough JSR 172. In Android the SAX parser is available for paring XML. There is no class for handling SOAP Web services in Android. 5.3.11.6 Sensor access In JME there is an optional package for accessing the sensors of the device, JSR 256 Mobile Sensor API. But this JSR is not part of the JSR 248 specification. In Android there is a class for accessing hardware sensors called Sensors (43). 29 30 Investigation 5.3.11.7 Camera access The camera of the device can in JME be accessed through the API of JSR 234. In Android it is accessed through the CameraDevice (44) class for capturing or previewing frames. 5.4
Overview of package, class and methods comparison
In the next section a comparison between classes and packages functionality in Java Micro Edition (JME) and Android are described. The main focus of the comparison is media handling, file access and user interface. Media handling like playing music, video and viewing images are according to the APIs no problem to port. Method names differ between the platforms but the functionality is almost the same in the classes for handling and playing media. Android uses one class both for handling the media and creating the player while JME has one class for handing the media and another for creation the player. Images can be drawn directly to the canvas in both JME and Android. Android also have some predefined views for viewing images. The file handling seems to be a bit harder but possible. There are support for the same type of connections in both JME and Android. No further tests were made for the connections. The type of connections needed in the porting of the graphic engine will be tested when needed. The graphics seems like the harder part to port from JME to Android. There are many different types of graphics and lots of different things to do with them. The graphics in Android are structured in a tree hierarchy where every node might influence the interface. Connected to the graphic is also the event handling. Different graphics object can handle events, like key event. The connection between graphics and events are done differently in JME and Android. Android objects are responsible for their own event handling and the JME object relies on the canvas to handle the events. The stack of object handling graphic user interface changes and key events differ where the object used are not the same. Something else that differs is the type of files that are part of the application packages. Though the main files, like source files, resource files and binary files are the same, the build files differ. The build files have to be implemented individual for the two platforms. After the comparison of the two platforms is it possible to make the following conclusion, it is possible to port an application from JME to Android. The main difference is in handling the user interface. This conclusion is made according to the investigation in the next section. Chapter 6 Porting
In the previous chapter JME and Android APIs have been compared to get a view of the possibility to port a JME application to Android. To be able to run a JME application on Android the java micro edition specific classes and package must be ported to Android. The Android platform is being developed during the time of this thesis, and at the beginning of the porting a new version of the SDK for Android where released and with it also some new fetchers that might not have been part of the initial investigation and comparison. The documentation of Android was updated as the new release was released. The M5 version of Android was used when porting and developing. 31 32 Porting 6.1
Porting from JME to Android
Android have its own library for some functionality and uses J2SE API for other. To port a JME application or library to Android all JME specific classes must be ported to classes existing in Android for the application to be able to run on an Android device. 6.2
Porting of graphical engine from JME to Android
At a first look at the graphical engine there were nine classes that were using JME specific classes in their implementation. The focus of classes of the java micro edition packages were methods for playing media, controlling media, displaying graphics, storing and retrieving files and information and connection to the internet. To get some idea of what to do a short introduction was made, by Tactel, to what the engine does and how the classes interact. Then the porting started. A lot of tests had to be done in separate projects to figure out how things were done in Android. The source code of an application that uses the graphic engine in JME was provided, just to see how the engine was used. Not only the functionality of Android had to be tested the functions of the graphic engine had to be tested to figure out how they worked and interacted and what had to be done to port it to Android. Some overview of porting of four different functions, media playing, graphics, key handling and file handling, in the perspective of porting the graphic engine follows. There is just an overview of how the porting is done to not reveal too much of how the graphic engine works since this is property of SouthEnd. 6.2.1 Media player
In JME an interface called Player is used for playing media files. To create a player the class Manager is used. Manager provides access to an implementation specific mechanism for constructing Players. The player can have five different states unrealized, realized, prefetched, started and closed. Figure 6.2.1 shows the different stages of a player in JME and what actions make the player change stage. Porting Unrealised
Realised
realise() deallocate()
Started
prefetch() deallocate()
start()
close() stop()
Closed
Prefetched
Figure 6.2.1 Stages of a player in JME. In Android the class MediaPlayer is used for playing media files like audio and video. The player is created by the MediaPlayer class itself. The MediaPlayer can be in four different stages, these stages are not saved and do not have names, but will be referred to as uninitialized, prepared, started and paused. Figure 6.2.2 shows the different stages of a player in Android and what actions make the player change between the stages. start()
Prepared
reset() reset()
prepareAsync() stop()
prepare() Uninitialized
reset() Started
paus()
start() Paused
Figure 6.2.2 Stages of MediaPlyer in Android 6.2.1.1 Playing sound Both the Player in JME and the MediaPlayer in Android have functions for starting, stopping, pausing and forward and rewind the media. It is also possible to determine how long the file is and how long it has played in both JME and Android. Porting the sound player from JME to Android was no problem. The Player was almost just replaced by the MediaPlayer in Android. 33 34 Porting 6.2.1.2 Viewing video The video in Android has the same functionality as sound. So the sound of the video and starting and stopping the file was not much work. The video though has not only sound but a display. In JME the video is printed to a canvas and in Android it needs an object called surface to display the video. So the porting of the video player caused some problems. The graphics in the graphic engine is implemented painting objects in a hierarchy to a canvas. One object is responsible for updating the view. In Android a video player needs a surface object to view the video. These surface objects are viewed using different Android views for example SurfaceView or VideoView. These views have to be added to the view hierarchy of the application to be visible. As default the graphic engine have only a root view with no children. But to be able to view a video an empty view for when there are no video playing and a SurfaceView are added to the root view. 6.2.1.3 Class porting To port the player of JME to Android a class extending MediaPlayer could be used. The class implements the stages of a player, mentioned for JME. Androids MediaPlayer have slightly different steps for playing media so some changes had to be made to the classes using the player. In the Player of JME it is as well possible to get the stage of a player, in Android the stages does not actually have names and is not possible to retrieve. But by setting a variable stage every time the players’ stage changes the stage could be saved and so also possible to retrieve. The manager creating a player can be ported with an implementation of MediaPlayer as well. The managers’ main responsibility is to create a player suitable for the media to be played; the MediaPlayer of Android can do that by itself. Or rather the MediaPlayer in Android is used for playing all kinds of files. So a manager implementation could be done using the MediaPlayer for creating players. 6.2.2 Graphics
In Android applications uses views to present information or graphics on the screen. These views are defined in specific classes and update the screen by themselves when needed. The developer can define its own views to get the interface needed. The view also handles the key events when focused. A view can contain other views in a tree structure and pass key events to its parent. 6.2.2.1 Painting to canvas The most basic view does not draw anything on the screen and does not do anything on key events. To modify what the view draws on the screen calls can be made to the canvas to draw lines, circles, text or others to the canvas in the views onDraw method. This method is called when the view gets visible on the screen. Porting 6.2.2.2 Updating view The graphics engine to be ported uses different objects to draw directly to the canvas and update the object to be drawn. By updating an object being drawn to the canvas it is important that the change gets visible on the screen. But by updating an object the views draw method will not be called to update the view on the screen. A call to invalidate must be done to attentive the view of an update. To make the view notice the change the onDraw method ends by calling invalidate. This will empty the canvas and make a call to the draw method of the view which calls onDraw which should draw all the object to the canvas and then call invalidate again. Before invalidate calls draw, key inputs will be handled which prevents this loop from blocking the application from user interaction. To make the updating of the screen function well no heavy calculations should be made in the onDraw method to make the updating smooth and not experienced as freezing. 6.2.2.3 Animation The graphic engine uses something called affectors to make animations of object. These affectors are updated every time the onDraw method is called to update the user interface. Some of these affectors makes some heavy calculations and makes the interface slow. 6.2.2.4 Images Images in JME are represented by a class called Image which is not part of Android. In Android images are represented by a Bitmap. But the functionality on Image in JME and Bitmap in Android are almost the same so the implementation of image handling in the graphic engine could almost just be done by representing the image by a Bitmap instead of Image. 6.2.2.5 Fonts Fonts have their own class representation in JME, in Android it is part of Paint. A font class could be implemented extending paint to add methods more directly connected to fonts to make it possible to easily get information about the font and not need to change the use of fonts in the graphic engine. 6.2.3 Key handling
Key events in Android are handled by the currently focused view. A view can implement its own functionality for handling events or pass in on to the parent implementation. The menu key by default opens the menu defined by the activity object if any, the red phone key close the activity object and the back button closes the current activity and goes back to its caller. Menus can be added to the application by its activities. In the graphic engine there is a key handling system making objects handle key event when they are in focus. The key events of the view are transferred to the key handling system of the graphic engine and the key codes are mapped to the codes of the graphic engine. 35 36 Porting 6.2.4 File access
Files in JME are accessed through a special file handling API. In Android the Java IO API is used for accessing public files. The porting of this part was simple in the case of the graphic engine. The engine did not contain much file handling and the file handling that was part of the graphic engine was simple. The functions included are saving a file and accessing data through the HTTP protocol. The porting of the file handling was a simple change of API classes. Chapter 7 Implementation of the application
An application showing the functionality of the graphic engine in the form of a media browser was the last product of this thesis. This application and its parts are described in this chapter as well as the reusable components implemented to be used in the implementation. In the next chapter the user interface of the media browser will be described and shown. 37 38 Implementation of the application 7.1
Reusable components
To make the implementation faster and easy to update, change and extend some reusable components was implemented to be used in the implementation. The components are divided into four different types: layers, affectors, collectors and nodes. 7.1.1 Layers
The graphics engine uses something called layers for implementing different screen views. Some different types of layers have been implemented for use when implementing applications in Android using the graphic engine. 7.1.1.1 Basic A basic layer witch implements support for a background image or a background color and handling of affectors on layers. All other layers should extend this layer to behave correct. 7.1.1.2 List The media browser consists of a lot of listing of content so an implementation of a list and some variants of a list was a good start. The main implementation of a list is a vertical list with the functionality that objects can be added to the list. 7.1.1.3 FocusList FocusList is an implementation of a list; an object can be focused by pushing up respective down to focus the previous respective next object in the list and pushing fire to pass a fire event on to the focused object. 7.1.1.4 Grid The grid is an extension of the FocusList and have the same functionality but the objects can be presented and navigate through a matrix with a predefined number of columns. It is also possible to navigate to the previous row not only the previous object in a grid. Pushing up respective down moves the focus to the previous respective next row and pushing left and right moves to the previous respective next object. 7.1.1.5 MultiselectList This is a FocusList where more than one item can be selected. It is also possible to retrieve the selected items. 7.1.2 Affectors
In the graphic engine there were abstract classes for making animations on objects. Affectors for moving and scaling were implemented for use in the media browser. Implementation of the application 7.1.2.1 Move This affector moves a node in a layer according to some defined line and speed. An extension of the class is the affector move and remove which moves the node and removes it from the layer when it reaches the end point. 7.1.2.2 Wave This affector is similar to move and moves a node in a sinus wave. One large difference is that the wave affector moves the node back and forth from the start point to the end point. An extension of the wave affector is an affector for moving the node in one direction and then setting its position to the start position and start moving it from the beginning. 7.1.2.3 Scale The scale affector works on image nodes and scales the image of the node according to defined values. 7.1.3 Collectors
Static collectors were implemented to retrieve images, audio and video through the Content providers in Android. 7.1.3.1 Images Form the image collector ids for jpg‐images or other images can be retrieved as well as jpg‐images newer then a specified date. A bitmap representing the image can then be loaded using the id as the identification of the image. 7.1.3.2 Audio The collector for audio is a bit more advanced. Here it is possible to get the ids of tracks as for images and load there data from that id. But it is as well possible to get all albums and artist the files have. It is possible to get the ids of all files of a specific album or artist. 7.1.3.3 Video The video collector can retrieve ids for videos and then the URL for the video file form the id. The title of the video is also possible to retrieve from the id. 7.1.4 Nodes
Layers consist of graphic nodes being viewed on the screen. A node can represent an image, text, some symbol or a combination of these. 7.1.4.1 Selectable This is an interface for nodes that is possible to select. A selected node will be viewed differently than a not selected node. 7.1.4.2 AndroidBitmapSprite This node views a image, what is changed from the node in the graphic engine is that this node can retrieve its image from the Android R‐file id. 39 40 Implementation of the application 7.1.4.3 Progress This node represents a progress bar. It shows progress in a bar as well as with text showing the current time and the end time. 7.1.4.4 UpdatableMenu This is a text node displaying one line of text where the text and its font can be changed when necessary. 7.2
Media browser
The media browser is the application developed during the thesis. It uses the predefined components to implement a media browser for displaying images and playing audio and video files. 7.2.1 Application structure
The application consists of a structure of menus and viewers and a service for playback of audio files. The structure can be seen in Figure 7.2.1. At the top of Figure 7.2.1 is the main class AMB, standing for Android Media Browser. This class initiates the background theme and the application colors and adds a soft buttons panel to the. It does as well bind a service for playing audio files in the background of the application and initiate the graphics engine. When these thing are initiated the main menu is create and shown on the screen. The main menu has four choices the video, music, picture or settings menu. Selecting an item in the list takes the user to the selected menu. The structure of the music menu, picture menu and video menu can be seen in the Figure 7.2.2, Figure 7.2.3 and Figure 7.2.4. AMB
BackgroundLayer SoftButtonPanel
MenuMain
Video
MenuVideo
Resume
Videos
Music
MediaPlayerSound
Pictures Settings
MenuMusic
Playlists
Resume
Albums
Artists
Tracks
MenuPicture
Playlists
Latest photos
Photos
Camera
MenuSettings
Pictures
PlaylistViewer
PlaylistViewerVideo
MusicGroupViewer
MusicGroupViewer
New playlist Playlist1
...
ImageViewerJpg
Playlist N
TracksViewer
ImageViewerNewJpg
ImageViwereNotJpg
CameraView
VideoViewer
ImageLayer
TracksViewer
NameSelecter
TracksViewer
ImageLayer
Deleter
VideoPlayerView
ImageLayer
TracksViewer
TracksUpdater
TracksSelecter
SoundPlayerView
Figure 7.2.1 The structure of AMB. Implementation of the application 41 Figure 7.2.2 The structure of the music part of AMB 42 Implementation of the application Figure 7.2.3 Structure of the pictures part of AMB. Implementation of the application Figure 7.2.4 Structure of the video part of AMB. 7.2.2 Application functionality
In the previous section the structure of the application was described, this section describes the classes the application is built of and how they are related to each other. Figure 7.2.5 shows the hierarchy of the AMB class, the main class of the application. It extends the class Activity through the AbstractMain class of the ported graphics engine. Every main class of an Android application should extend Activity and every application using the ported graphic engine should extend the AbstractMain class to initiate all parameters of the engine. Figure 7.2.5 The main class of AMB. 43 44 Implementation of the application Figure 7.2.6 The layers implemented in AMB The graphics user interface of the graphic engine built on layers and nodes. The implemented layers can be seen in Figure 7.2.6 and the nodes in Figure 7.2.7. The graphic engine consists of some nodes and an abstract class for layers. A description of all classes in AMB can be found in Appendix A. Figure 7.2.7 The nodes implemented in AMB. Chapter 8 Result
The thesis resulted in some reusable components for implementing graphic applications on the Android platform using the graphic engine and a Media Browser for the Android platform using the graphic engine. 45 46 Result 8.1
Android Media Browser
The following section describes how to use the Android Media Browser, AMB. It will be described how to start the application and how to use video, music and images in AMB. 8.1.1 Starting the application after shutdown
When the application is started on the device the main menu, Figure 8.1.1, is shown. In this menu the user can get to the different parts of the browser. The choices are videos, music, pictures or settings. 8.1.2 Video
The video menu have options for resuming the playing video, view the list of videos on the device and show the playlists of videos. In this version of AMB it is not possible to create playlists. AMB can view a list of video files and start playing one of them in the video player. Figure 8.1.2 shows the video menu. 8.1.2.1 Select a video to play To start playing a video the user views the video list in Figure 8.1.3. By selecting a video in the list this video will be started. 8.1.2.2 The video player In the video player it is possible to pause, restart, forward and rewind the video. When the video is finished it will be stopped and rewind to start. Figure 8.1.4 shows the player. The video view shows how long the video is and how much have been played. If the music player is playing when the video player is started the music will be paused. When the video view is left the video will be paused 8.1.2.3 Resume a video When the video player view has been left the playing video will be paused if it is playing. To resume the video the menu option resume is chosen in the video menu, Figure 8.1.2. Result Figure 8.1.1 The main menu of AMB. 47 48 Result Figure 8.1.2 The video menu. Figure 8.1.3 The list of videos on the external media. Result Figure 8.1.4 AMB Video player view. Figure 8.1.5 The music menu 49 50 Result 8.1.3 Music
In the music menu the list of files to play can be chosen by selecting an album, artist, all tracks or a playlist. The files will then be shown and the player can be started. The music menu can be seen in Figure 8.1.5. Figure 8.1.6, Figure 8.1.7 and Figure 8.1.8 shows one way to get to the music player. 8.1.3.1 Resuming or pausing When the player view have been left it is possible to get back to it by choosing resume in the music menu, Figure 8.1.5. This will start the player, Figure 8.1.8, and resume the last playing file if it is not already started. In the player it is possible to pause the playing sound. 8.1.3.2 The player In the player it is possible to pause, start, forward and rewind a track. It is also possible to go to the next or previous track in the player and change the volume level. To start and stop the player the center pad is used, to forward and rewind the left and right pad is used and to get to the previous or next track the up and down pad is used. To set the volume level the volume buttons on the device is used. 8.1.3.3 Playlists To use playlist the user chooses playlist in the music menu, Figure 8.1.5. The list of existing playlists will be available and a menu selection for creation new playlists. To play a playlist the playlist is selected in the list and all its tracks will be visible. A track is chosen to start playing the playlist. To create a new playlist the “New playlist” item is chosen and the view in Figure 8.1.10 gets visible. The name of the playlist is chosen and when pushing “OK” the tracks gets visible and it is possible to chose what tracks should be part of the list. The selected tracks are marked as in Figure 8.1.11. Result Figure 8.1.6 Artists chosen from the music menu shows the currently available. Figure 8.1.7 An artist is chosen and all tracks from that artist is shown. 51 52 Result Figure 8.1.8 When a track is chosen all the songs of the list is added to the player. Figure 8.1.9 The playlist view. Result Figure 8.1.10 When creating a new playlist the list should first be given a name. Figure 8.1.11 When the list has a name the tracks are chosen from the list of tracks. 53 54 Result 8.1.4 Pictures
The picture menu can be seen in Figure 8.1.12. There are four choices. The user can view the latest photos from the last seven days, all photos, use the camera or view all images that are not photos. The camera view is not implemented and will show a default screen in this version. 8.1.4.1 Viewing pictures When a category of pictures is chosen in the picture menu the images will be shown in a grid view in three columns as in Figure 8.1.13. To show an image in full size or as large as the screen allows an image is selected and the view in Figure 8.1.14 gets visible. To show the next image in the list in full size the right button is pushed and to view the previous the left button is pushed. 8.1.5 Settings
No settings is implemented is this version of AMB. Figure 8.1.12 The picture menu, showing how many images there are in the category. Result Figure 8.1.13 The view showing images in a grid, the selected image in the centre. Figure 8.1.14 The view of an image in full size or as large the screen allows. 55 56 Result Chapter 9 Final comments
The API for Android is not that well documented. It is sometimes hard to figure out exactly what a method in a class does or what the class is for. But there is a good introduction to developing so you can relatively fast make your own first application. But when you want to make something more advanced it gets harder. Android is new and I believe the documentation of the classes and the classes them self’s and their methods will be improved over time as Android gets in to the market and there actually are devices using the Android platform. So some functions that today are available in JME might be available in Android as well in the future. During this project the Android SDK have been updated; due to this some work have had to be done twice. When updating the SDK from the M3 version to M5 some classes and methods were changed as well as the paths and names of the variables in the AdroidMAnifest.xml file. This update also made the emulator for eclipse instable which made the work slower when eclipse had to be restarted due to the application was never launched and eclipse was not possible to use any longer. The upgrade to M5 from M3 was made to get access to new fetchers connected to media handling on the Android platform. There are some differences and some similarities between Android and JME. I have not been developing for J2ME only J2SE earlier but as I can see the biggest difference in developing for Android from JME is the fact that in Android there is more predefined views for the developer to use but I believe many developers will instead of using these views develop their own to the application unique. 57 58 Final comments 9.1
Limitations
Due to time limits not all functionality of the browser has been implemented and no settings can be done and no playlist created for videos, though the application is prepared to be extended to support this. The browser has not been tested in a real device since there were no device on the market running the Android platform when this thesis was carried out. Performance and functionality have therefore not been tested in a real environment. 9.2
Future work
In continuing developing the browser perhaps some sorting of the video files could be of interest. For audio files there is prepared for sorting audio file according to genre, but due to limitations in the early Android SDK this is not fully implemented. When support is implemented in the future SDKs this function can easily be added. For making the application more fun it could be good to be able to do some settings. Settings like choosing language and theme for background and colors are supported but not implemented in the settings menu. Other settings that might be of interest in future versions are the option to be able to make the application stay in horizontal or portrayal position even when tilting the phone. The Android platform have support for touch screen so adding interaction through the screen might be of interest in the future. The graphic engine used for implementation of AMB does not support interaction through touch screen but support can be added. Chapter 10 Acknowledgements
Thanks to Tactel for letting me perform my master thesis at their office in Umeå and an extra thank you to my external supervisor Mattias Ohlsson and all the staff at the office who have helped me in my work. 59 60 References References
The following pages consist of references to the webpage’s that consists of information about Android and JME and their API’s as well as references to books and documents used in the thesis. 61 62 References 1. Sony Ericsson. W910i. Try the phone. [Online] [Cited: 01 29, 2008.] http://www.sonyericsson.com/cws/products/mobilephones/overview/w910i. 2. Open Handset Alliance. Open Handset Alliance. [Online] [Cited: 02 14, 2008.] http://www.openhandsetalliance.com. 3. Mattias Ohlsson. Media Browser on Android Platform ‐ Investigation. Umeå : Tactel, 2007. 1. 4. Sun. Java ME Technology. [Online] [Cited: 01 29, 2008.] http://java.sun.com/javame/reference/apis.jsp. 5. Android. Android. [Online] [Cited: 01 21, 2008.] http://code.google.com/android/. 6. JCP. JSR 248. [Online] [Cited: 02 04, 2008.] http://www.jcp.org/en/jsr/detail?id=248. 7. Android. Anatomy. [Online] [Cited: 02 04, 2008.] http://code.google.com/android/intro/anatomy.html. 8. —. Activity. [Online] [Cited: 01 21, 2008.] http://code.google.com/android/reference/android/app/Activity.html. 9. —. IntentReceiver. [Online] [Cited: 01 28, 2008.] http://code.google.com/android/reference/android/content/IntentReceiver.html. 10. —. Service. [Online] [Cited: 01 28, 2008.] http://code.google.com/android/reference/android/app/Service.html. 11. —. Content providers. [Online] [Cited: 02 08, 2008.] http://code.google.com/android/devel/data/contentproviders.html. 12. —. Intent. [Online] [Cited: 01 28, 2008.] http://code.google.com/android/reference/android/content/Intent.html. 13. —. ContentProvider. [Online] [Cited: 02 08, 2008.] http://code.google.com/android/reference/android/content/ContentProvider.html. 14. —. AndroidManifest. [Online] [Cited: 02 05, 2008.] http://code.google.com/android/devel/bblocks‐manifest.html. 15. —. NotificationManager. [Online] [Cited: 02 05, 2008.] http://code.google.com/android/reference/android/app/NotificationManager.html. 16. Piroumian, Vartan. Wireless J2ME Pltaform Programming. Califonia : Sun Microsystems Inc., 2002. ISBN 0‐13‐044914‐8. 17. Android. KeyEvent. [Online] Google. [Cited: 01 31, 2008.] http://code.google.com/android/reference/android/view/KeyEvent.html. 18. Sun. Java. Media API (jsr135) ‐ Manager. [Online] [Cited: 01 30, 2008.] http://java.sun.com/javame/reference/apis/jsr135/. 19. Iana. Assignments. Media types. [Online] [Cited: 01 28, 2008.] http://www.iana.org/assignments/media‐types/. 20. Sun. Java ME. JSR 239 ‐ Java Binding for the OpenGL ES API. [Online] [Cited: 02 01, 2008.] http://java.sun.com/javame/reference/apis/jsr239/. References 21. Android. Avalible resources. [Online] [Cited: 01 22, 2008.] http://code.google.com/android/reference/available‐resources.html. 22. —. AudioFileFormat type. [Online] [Cited: 01 22, 2008.] http://code.google.com/android/reference/javax/sound/sampled/AudioFileFormat.Ty
pe.html. 23. —. What is Android. [Online] [Cited: 01 23, 2008.] http://code.google.com/android/what‐is‐android.html. 24. —. Media. [Online] [Cited: 02 01, 2008.] http://code.google.com/android/toolbox/apis/media.html. 25. Sun. Java. MIDlet package summary. [Online] [Cited: 01 29, 2008.] http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/packag
e‐summary.html. 26. Java Community Process. JCP. JSR 75: PDA Optional Packages for the J2ME Platform. [Online] [Cited: 01 30, 2008.] http://www.jcp.org/en/jsr/detail?id=75. 27. Sun. Java. JSR169. [Online] [Cited: 01 30, 2008.] http://java.sun.com/javame/reference/apis/jsr169/. 28. —. Java. RecordStore. [Online] [Cited: 01 30, 2008.] http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/rms/RecordSto
re.html. 29. Android. SQLiteDatabase. [Online] [Cited: 01 30, 2008.] http://code.google.com/android/reference/android/database/sqlite/SQLiteDatabase.
html. 30. —. File. [Online] [Cited: 01 30, 2008.] http://code.google.com/android/reference/java/io/File.html. 31. —. SQLite package summary. [Online] [Cited: 02 08, 2008.] http://code.google.com/android/reference/android/database/sqlite/package‐
summary.html. 32. Sun. Java. PushRegistry. [Online] [Cited: 02 04, 2008.] http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/io/PushRegistr
y.html. 33. —. Java. JSR 82 Bluetooth. [Online] [Cited: 02 04, 2008.] http://java.sun.com/javame/reference/apis/jsr082/. 34. Android. Http client protocol. [Online] [Cited: 02 04, 2008.] http://code.google.com/android/reference/org/apache/commons/httpclient/protocol
/package‐descr.html. 35. —. HttpConnection. [Online] [Cited: 02 04, 2008.] http://code.google.com/android/reference/org/apache/commons/httpclient/HttpCon
nection.html. 63 64 References 36. —. SMS manager. Google. [Online] [Cited: 02 04, 2008.] http://code.google.com/android/reference/android/telephony/gsm/SmsManager.htm
l. 37. Sun. Java. MIDlet. [Online] [Cited: 01 30, 2008.] http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/MIDlet.
html. 38. —. Java. MIDlet PKI Trust. [Online] [Cited: 01 29, 2008.] http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/doc‐
files/PKITrust.html. 39. —. Java. MIDlet Authorization. [Online] [Cited: 01 29, 2008.] http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/doc‐
files/Authorization.html. 40. Android. Manifest permission. [Online] [Cited: 01 28, 2008.] http://code.google.com/android/reference/android/Manifest.permission.html. 41. —. Security. [Online] [Cited: 01 28, 2008.] http://code.google.com/android/devel/security.html. 42. —. AlarmManager. Google. [Online] [Cited: 02 04, 2008.] http://code.google.com/android/reference/android/app/AlarmManager.html. 43. —. Sensors. Google. [Online] [Cited: 02 04, 2008.] http://code.google.com/android/reference/android/hardware/Sensors.html. 44. —. CameraDevice. [Online] [Cited: 02 04, 2008.] http://code.google.com/android/reference/android/hardware/CameraDevice.html. 45. Berggren, Malin. Media Browser on Android. Proposal of thesis work 30 hp. Umeå : s.n., 2008. 46. java.net. java.net. J2ME Tutorial, Part 4: Multimedia and MIDP 2.0. [Online] [Cited: 02 01, 2008.] http://today.java.net/pub/a/today/2005/09/27/j2me4.html. 47. Android. MediaPlayer. [Online] [Cited: 01 28, 2008.] http://code.google.com/android/reference/android/media/MediaPlayer.html. 48. —. ImageView. [Online] [Cited: 01 29, 2008.] http://code.google.com/android/reference/android/widget/ImageView.html. Appendix Appendix
65 66 Appendix Appendix A - Class description AMB
Layers
Menu
Menu is a basic implementation of a menu. It lists its items in a portrait list and keeps the focused item in the center of the screen. Menu does extend ListLayer. MenuMain MenuMain is an implementation of the main menu for AMB. Contains the menu items video, music, pictures and settings and creates menus for these sections. MenuVideo The video menu contains the menu items resume, videos and playlist. Creates a viewer for the video files and have support for implementation of a player and playlists. MenuMusic MenuMusic contains menu items for music related choices. It has items for resume, albums, artists, tracks and playlists. Creates views for viewing albums, artists and tracks and to create playlists and view them. MenuMusic communicates with the MediaPlayerSound service to play sounds and the SoundPlayerView to view information about the playing track. MenuPicture View the choices of viewing the latest photos, all photos, the camera and all pictures. Creates views for photos and pictures and have support for viewing a camera view. MenuSettings Not implemented, shows a default screen. TracksViewer TracksViewer shows tracks according to some selection from the database for music. It retrieves information of the tracks from the AudioCollector. MusicGroupViewer MusicGroupViewer shows groups of audio files like albums, artist or genres. It will shows the tracks of a group when selected using the TracksView. VideoViewer VideoViewer views a list of all video files on the external media of the device using the VideoCollector. PlaylistViewer PlayListViewer views the playlists for music and a choice of creating a new playlist. The playlist are retrieved from the PlaylistCollector. PlaylistViewerVideo Not implemented, shows a default screen. NameSelecter
NameSelecter is a layer for selecting a name. TracksSelecter
TracksSelector is a list view for selecting tracks. ImageViewer
ImageViewer is an abstract implementation of an image viewer viewing images in a grid with three columns. ImageViewerNewJpg ImageViewerNewJpg is an image view viewing all jpg images newer then one week. It retrieves the pictures using the ImageCollector. ImageViewerJpg ImageViewerJpg is an image view viewing all jpg images on the external media using the ImageCollector. ImageViewerNotJpg IamgeViewerNotJpg is an image viewer viewing all images that is not jpg images. It retrieves the images using the ImageCollector. ImageLayer
Views an image in full size or as large the screen allows. BackgroundLayer
BackgroundLayer shows a background image and some animated images according to the settings. It also shows a left panel if there are any items in the panel. SoftButtonsPanel
SoftButtonPanel shows information of the soft buttons in the bottom of the screen if any. CameraView
Not implemented, shows a default screen. SoundPlayerView
SoundPlayerView views a player interface for playing, pausing, forward and rewind a track as well as going to the previous or next track and adjusting the volume level. VideoPlayerView
VideoPlayerView views a player showing the video and has functions for playing, pausing, forward and rewind a video file. NotImplemented
A layer for viewing a default screen for not implemented functionality. Nodes
ImageViewerItem
ImageViewerItem is an item viewing an image either in a predefined maximum size or as large as possible for the screen. PlaylistNameInput
PlaylistNameInput is a node for entering a name for a playlist. MenuListItem
An interface for menu list items AdstarctMenuListItem This is an abstract implementation of a menu list item. It is handling the graphics of the item. MenuListItemImpl This is a standard implementation of a menu list item. MenuListItemSong This is an implementation of a menu list item for tracks starting the player when selected. MenuListItemGroup This is an implementation of a menu list item for a music group viewing a TracksView when selected. MultiselectItem This is a menu list item which can be botch selected and chosen. PlayerControl
PlayerContol is a graphic interface for the control of the music player. It views the information of whet button to use for different choices viewing the choice on the screen when selected. TrackInfoBoard
Views information of a track, whether it is playing or not and what number in a list of tracks it is. Settings
Settings are handling all changeable settings like language, background image and animation images. AMB
The main class of the Android Media Browser initiation all parameters and starting the sound player service. AffectorRollText
An affector for rolling text that is too long for showing the whole text.