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.
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 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.
Sreenshots
