grpN 5: Niko Reunanen, Petri Hienonen, Joel Kurola

**TxTTV**

PROJECTPLAN 1.0 Project plan for the txt-television project. Txt television is a project produced in the Android Code Camp that aims to provide text television to android phones in an easy and useful way.

1. IDEA

Project has it aim at producing working text television program for Android environment. Our team sees that there is a large user base available for use of mobile text television. Text television is still widely in use because of its easiness to reach relevant news information fast and when people need it. Though text television can be reached from the web with browser it doesn’t fit well into a screen, fonts are hard to read and accessing it needs active internet connection. Our project aims to produce program that sole purpose is to provide text television, easily and always with you when you need to reach the most relevant news.

Project document(depricated)

1.1. PRODUCT AND ENVIROMENT

Product will be produced using Eclipse and Android development toolkit. Unfortunately we can not test program using real Android device, but we hope that emulator will be enough to produce balanced and bug free software. Program will be produced against newest android API 2.1. In the program we will also be using SQLite database to store information and make searches.

As platform Android and Eclipse work well for software development. Eclipse is pretty easy to use and gives nice suggestions. Integration between development platform and Android works well and you can find almost everything that came to our minds during codecamp easily. Good thing to add would be GUI for database browsing, but using command promp as debugging tool for database works pretty well, though information about its usage was at first hard to find.

We also encountered some problems. Our main problem was finding good examples on how to make something; in Android there are no standartized ways of doing things like database access. Another problem came from androids fast evolution, even Google didn't always have good documentation for the newest API and googles example applications are too complicated and too few for simple developers like us, and they were hard to access. Numerous barebone examples would be nice thing to have. Google could also add pictures with things like menus and keyboard layouts so that developers wouldn't have to test everything out to find good solution.

Good example page on how to handle newest SDK:s examples can be found on Nokia QT 4.6 Example page

2. ADVANTAGES AND CHALLENGES

2.1. ADVANTAGES

Because our programs sole purpose will be to provide seamless and easy to use user experience will it be very good at what it does. This provides several advantages over programs like browsers and feed readers. For example new information from certain sport events will be very easy follow through bookmarks and automatic notifications if new information will be available. The most important advantage is high usability.

2.2. CHALLENGES

Text reader is very dependant on the internet and if there is no connection, there will be no new news. The tight time limit and virtually no previous experience of android will provide challenges that we shall hopefully overcome. At our advantage we have lots of good example code and several books explaining Androids soul-life.

As the ptoject progressed we noticed that there is no way to download the whole text tv because of the limiten internet connectivity. Our solution for the problem would be to load on the seperate process only those pages that the user uses the most in advantage. Another big problem that we faced was that Yle and MTV3 were using non-standart encoding in their pages so that they couldn't be shown directly. We solved this problem by downloading and parsing data on php server and parsing the data there.

In thursday we decited not to finish all the feature implementation because of the limited time. All TODO features were chosen to be dalayed until further notice. We also had some dificulties with networks status checking.

3. DESIGN

FUNCTIONAL REQUIREMENTS AND ANALYSIS

CURRENTLY 30 (FEATURE FREEZE)

We had pretty clear picture forehand, what we wanted our application to do. We decided not no plan the program very deeply forehand because we had no previous expirience on android development. Requirements were added anytime when we found new intresting ideas to make our application better.

Note: As you can see, using wikipage to store data is poor solution and the list is no longer updated. Better version can be found as PDF when the file is uploaded.

DONE

ID	Status	Name	Module	Description
2	DONE	Download content	Networking	Downloads data from selected provider-module (yle)
4	DONE	Convert data	Database	Save downloaded data into SQLite–database for faster browsing. See attachment#1.
5	DONE	Fetch & Show	User interface	Fetch page using page number and render it using webview
8	DONE	Bookmark	Database	Add bookmarks to pages
10	DONE	History	Database	History of visited pages
15	DONE	Arrow keys	User interface	Change pages using arrow keys
16	DONE	Page box	User interface	Allow user to define wanted page
21	DONE	Finger gestures	User interface	Finger gesture navigation
18	DONE	Bookmark GUI	User interface	Gui for using bookmarks using dropdown menu
19	DONE	Downpages	Basic functionality	Allow user to navigate trough downpages.
3	DONE	Parsing data	Networking	Parse the data to be able to use it efficiently
25	DONE	Empty database	Database	Empty page database, when closing app.
27	DONE	Up and Down gestures	User interface	Swich between downpages using up and down gestures
24	DONE	Relevant icons	User interface	Show relevant icons only when they are needed.
20	DONE	Display chars	Basic functionality	Display basic characters like ä and ö
26	DONE	Numeric keyboard	Database	Show only numeric software keyboard when selecting page
11	DONE	Automatic fetching	Networking	Fetch bookmark pages intervally using deamon and service.

IN PROGRESS

ID	Status	Name	Module	Description	Importance 1-3

TODO

ID	Status	Name	Module	Description	Importance 1-3
1	DELAYED	Network status	Networking	Client checks if network is available to fetch data
12	DELAYED	Settings	User interface	User interface for changing settings. Currently no meaningfull setting to change!
13	DELAYED	Providers	Networking	Add additional service providers using filters
14	DELAYED	Animations	User interface	Animate page changing using slide animation
23	DELAYED	Heuristics	Basic functionality	Downloads pages in paraller threads based on previous user activity.
28	DELAYED	Code Cleanup	Codebase	Cleanup and optimize codebase
29	DELAYED	Code Reorganize	Codebase	Reorganizer codebase based on learned during codecamp
30	DELAYED	Download all	Networking	Downloads every page of teletext for offline usage
22	DELAYED	Single column	User interface	Show text television in single column. No vertical scrolling.

DOOMED

ID	Status	Name	Module	Description	Reason
6	DOOMED	Search	Database	Search pages from database by term defined by user	There is no good usercase
7	DOOMED	Search relevance	Database	Calculate relevance for search results	There is no good usercase
17	DOOMED	Change colors	User interface	Allow user to change font color	There is no good usercase

User cases:

Sarake	Tieto
Use Case Number:	1
Date added:	5.03.2010
Use Case Name:	Browsing text television
Description:	Marko has used teletext his whole life. He is very used using it, and has gotten to his new telephone TxTTV application. Now teletext is allways with Marko and he can find relevant information anytime he wants even easier than he previously has been able to. Marko is a very happy teletext user.

4. GOALS AND ENDING

4.1. GOAL: GOAL MET

Our goal is to produce working and bug-free text television client and add as much functionality as we can in a given time. Atleast basic functionality like changing pages and database buffering should be implemented.

4.2. FAILURE CRITERIA: PROJECT WAS CONCLUTED TO BE A SUCCESS

The project is considered to be a failure if we can’t make a functioning program till deadline, or the final product is buggy and hard to use.

4.3. ENDING CRITERIA

Project will end on 19.03.2010 when it will be presented to our competitors

5. PROGRESS

17.03.2010

Focus: Framework and idea composing. Work started.

18.03.2010

Focus: Implemented databases, data fetching and parsing and all basic components needed for basic implementation, still no killer app. Finger gestures and other nice functionality added. Problems with Ä and Ö averted. The fundamental functionality of the program finished.

19.03.2010

Focus: Implementing more features and preparing dokumentation. Both goals were met and we decited to stop implementing new features until presentation.

20.03.2010

PRESENTATION

7. CONCLUSION

Project was finished in thursday at (17:00). All main goals were met.

Presentation

Notket joutsenet

Sreenshots

200px|Menu 200px|Bookmarks 200px|Softwarekeybord

Package

TxTTV Binaarit