forked from martyf6/FriendlyWager
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathappDesign.txt
75 lines (55 loc) · 4.78 KB
/
appDesign.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
TODO:
- action handlers for most of the events in all the pages I described above need coding:
- i believe i wrote the java->php backend for updating a user's vote, but it hasn't been hooked into the layout
- some page transitions need to be coded
- class hierarchy hasn't been fully visioned
- java date formatter to handle the string version of date/time for client side time handling (has the event passed, display a pretty time, etc.) - need to iron out what time handling is done on server vs. client
should probably read this article first: http://derickrethans.nl/storing-date-time-in-database.html
- php backend for get_wagers needs to be updated:
- JSON data needs to be updated to include details about whether or not a particular wager has been closed
- JSON data needs to be updated to include details about the wager result
- php backend for get_responses needs to be implemented (the list of participant responses to be shown for a closed wager)
- java code needs to be written to handle disabling of viewing responses if the admin has not entered a result
(in other words, the admin needs to provide a result for the wager, but he/she cannot view what people answered before he provides this result)
- what does it mean to invite someone? do you use a username or email, etc? this needs to be communicated to the server, so the server php backend needs to know how to handle the string it is given
- what does view participant responses do? does it determine if the wager is a number and see who is closest? does it check if the wager is a string and see if any participant matched the string correctly? what if the answer is a number of responses, and the user only needed to get one of them right?
for instance - "Who will blackout on Thursday?" - jay vs. j vs. jason rome, or what about jay, corey or jay and corey, or jay and garvey and someone responded with 'jay' or 'corey', etc. Maybe we can ignore the scoring for now and just view the responses and make your own judgement - there just won't be any leaderboard or score keeping
- add styling to text, buttons, lists, labels, etc. (positioning, alignment, size, etc.)
- clean up and remove Toast messages and other debugging code
- php backend for sending an email confirmation to the user when registering
other things that would be nice (but not completely necessary)
separating out the invite users and update vote when an admin views his wager
some sort of leader board
remembering passwords
automatic refresh of the welcome page (right now the refresh button needs to be accessed from the menu)
colors and styles, etc.
adding wager types (ints, strings, lists, etc.)
User Credentials:
we need a way to persist user credentials in the application.
In the same manner that twitter, facebook, etc. only requires you to login once, then remembers you every time you
open up the application again, we need to store this data.
The way this works in Android apps is using SharedPreferences (http://developer.android.com/guide/topics/data/data-storage.html#pref)
To be secure, it is probably ideal to store a hashed password (instead of the raw string).
Should we store the session id instead? cookie?
DONE:
We also need a way to store session data - essentially a cookie, so that we don't need to pass the username and password
back and forth to the server on every single request.
We can probably achieve this by first initiating a login request with the username and password to the server.
Then, the server will pass back a session object (some sort of hashed session id).
This id will be stored in the applications memory and wont be persisted. Subsequent requests from the application
will carry this id so that the server knows the user has already been logged in and is good to go.
MORE TODO:
- deal with errors (not by simply printing them, as currently implemented)
- abstract session.php into login.php and session.php
- http client needs to shutdown when exiting the app (so not to draw resources when idle)
- server mysql connection needs to close after query
- server transactions needs to be ACID
- register should send an email confirmation before adding the user (server side script)
- 'toast' messages should probably vanish - replace by adding text to the actual layout (in red for errors, etc.)
- fine for debug purposes
- abstract MVC - create reusable sessions/login library (for other apps)
- use user id instead of username in session object
- request and responses should use ids as well (getWager(id) - where does the id come from? getWagers() should return all data (including wager data - making getWager obsolete)
- getWagers - returns wager name, id (has voted? - should probably return all data then.)
- put links to online utils in emails (forgot pw etc.)
- add wager types - for instance, boolean vote types, int vote types, string vote types, etc.