First draft

From CS219

Jump to: navigation, search

LoCal ::: The Calendar Reminder System that Knows Where You Are

First draft - presented on 05/21

1 Timeline
2 Architecture/Design
3 Resources
4 Challenges and lessons learned
5 Left to do
6 Current Testing
- 6.1 UI Prototype
- 6.2 What we can do so far

Timeline

4/27-5/04
- Administrative things
  - Came up with a name,blog,proposal
- Architecture/Design
  - Created initial architecture for the project (client-server approach) [[1]]
  - XML file for client/server communication [[2]]
- Test Verifications
  - Bluetooth (different modules)
    - visible when not paired
    - visible when not discoverable
  - Alerts outside of python
    - Sound
5/04-5/11
- Administrative things
  - Decided to concentrate on the phone part first. Leaving server implementation to the end.
- Architecture/Design
  - Due to connection challenges, we had to rethink architecture design. Now application is mostly phone-based. Server will be used for viewing/storage and additional features.
  - Designed a db schema. DB schema will be the same for phone and for the server.
  - Updated LoCalXML to handle deletes
  - Decided that everything will be stored based on uid(user id) to be able to handle multiple users
  - To be able to handle additions of new items through phone and server decided not to use auto incremented ids on the phone's db.
- Test Verifications
  - Wifi Module (Able to track wifi signals using wlantools)
    - "We had the program loop every 10 seconds and check all the MAC addresses it found.We set it to the Grad Lab's AP's MAC address and walked around the 3rd floor.It worked."
  - Learning about xml parsers in php (server) and python (phone)
5/11-5/18
- Administrative things
  - Created loCal user in CSGSC so that we can store our source code there (no need for Google Code storage)
- Architecture/Design
  - Implemented DB schema
  - Created a skeleton for all the objects (events,locations,etc)
  - Created a structure for db interface
  - Learning db module on the phone. The module is very limited.
  - Started coding LoCalTools.py (all the different tools we tried and will be using)
  - Started implementing LoCalObjects.py (our objects) and LoCalDbInterface.py
- Test Verifications
  - GPS Distance Calculator
  - DB module on the phone (e32db)
  - Alerts outside of python
    - Vibration alert (Finally made the vibration to work. Tried different module. Using misty)
    - Popup alert
5/19-5/25
- Administrative things
  - Decided what we can get done by this wed
  - Collected more location points for the demo
- Architecture/Design
  - Implementing LoCalDbInterface.py (done with locations,work on events)
  - Implemented LoCalObjects.py
  - Added more tools into LoCalTools
  - Combined multiple alerts together (vibrations & popups)
- Test Verifications
  - Switch application

Architecture/Design

Initial draft

The system was designed in an extensible and modular manner

Server side

Not implemented

PHP in the front end and SQL in the backend.
Uses LoCalXML to communicate with client

Phone side

Python
uses wifi,bluetooth,gps,internal phone db
uses LoCalXML to communicate with server
additional modules: misty,wlantools,appswitcher
use modular code approach for extendability and clarity

Resources

Challenges and lessons learned

Experienced a lack of a stable internet connection in cs building. Solution: Store everything on the phone. Use server only as a backup. No connection required expect for login.
Deduced that since user cannot always connect to the server, he/she may not be able to login for a long duration. Solution: Store user passwords on phone, let user login locally. No server dependency anymore.
Found out that letting users access multiple devices is is not feasible because of non-ubiquitous connectivity. Solution: Restrict access of each user to a single device.
Learned how to sign modules and find modules that are not signed.
Internal db (e32db) on the phone is very limited
- Doesn't support joins
- Doesn't support any sql functions like now()
- Incremented id starts with 0
Handling fault-tolerance due to device limitations (battery life, connection)
Kostas doesn't like to work on the weekends but for some reason random loads of code show up in the middle of the night
Anand always has to leave at a random time but somehow manages to get his stuff done. We suspect that he never sleeps.