meta data for this page
  •  

This is an old revision of the document!


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. Emulator worked well though it started lazily and once we managed to jam it. Good thing to add to Eclipse/Android SDK 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 standardized 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 cutting edge 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 project progressed we noticed that there is no way to download the whole text tv because of the limited 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 contentNetworking 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 gesturesUser 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 DELAYEDNetwork status Networking Client checks if network is available to fetch data
12 DELAYEDSettings User interface User interface for changing settings. Currently no meaningfull setting to change!
13 DELAYEDProviders Networking Add additional service providers using filters
14 DELAYEDAnimations User interface Animate page changing using slide animation
23 DELAYEDHeuristics Basic functionality Downloads pages in paraller threads based on previous user activity.
28 DELAYEDCode Cleanup Codebase Cleanup and optimize codebase
29 DELAYEDCode ReorganizeCodebase Reorganizer codebase based on learned during codecamp
30 DELAYEDDownload all Networking Downloads every page of teletext for offline usage
22 DELAYEDSingle 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.

Sreenshots

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

Package

Presentation