lobbygov iphone app

LobbyGov iPhone App Spec of 13 Page 1 of 13

LobbyGov iPhone App (iOS 7) Specs

Summary This project encompasses developing a native Objective-‐C iOS app that connects to my LobbyGov SaaS. Backend integration will be through a RESTful API. In order to make development easier, this app is only for iPhone and will require iOS 7. Details of the app’s functionality are discussed below. Here are a few requirements and expectations to consider:

1. The app must follow the iOS 7 design guidelines as announced by Apple. 2. Best practices throughout must be used. 3. Deprecated functionality/approaches must be avoided (i.e., fixed layouts, closed or

nonexistent APIs). 4. There’s a right way and a lazy way. Let’s do this app the right way. 5. Write elegant and well-‐documented code. 6. Implement and be sensitive to the new iOS 7 gestures (i.e., right swipe to go to

previous window). 7. Error handling should be mature. App crashes are bad. Error messages that help

the user (and the support agent) understand the problem are good. 8. Frameworks save time. Use them if it makes sense. (I.e., RESTkit) 9. We’ll use the New Relic framework to track errors and log app performance. 10. If there are problems or there’s a legitimate design/development question with pros

and cons – bring it to my attention ASAP so we can talk it out. API Resource The REST API will be accessible at the following URL: https://backenddev.lobbygov.com/ios/api/v1.0/ When the app goes live, the “dev” portion of the URL will drop off. API Error Handling Errors are returned using a standard HTTP error code syntax. Any additional info is included in the body of the return call, JSON-‐formatted. New Relic Framework Read more about it here: https://newrelic.com/docs/mobile-‐apps/ios-‐installation-‐and-‐configuration Login/User Authentication


After the app splash screen, user should be shown a login screen if they aren’t already authenticated. If previously authenticated (token should be stored in the Keychain or some other secure method), immediately send a login post auth request. The login screen should have a username dialog, a password dialog, and a Login button. After successful login, user’s session should persist until either (1) the user logs out or (2) the token expires. REST API Resource: /auth/ Authentication with Preexisting Token { “token” : TOKEN_VALUE } If valid, you’ll get a 200 OK return. Take the user to the home screen of the app. If invalid token/expired, you’ll get a 401 error return. Show the login screen to the user and destroy the previous token record. Authentication without Token { “username” : USERNAME_VALUE, “password” : PASSWORD_VALUE } If valid, you’ll get a 200 OK and a JSON return with the token (see below). Take the user to the home screen of the app. { “token” : TOKEN_VALUE } If invalid, you’ll get a 401 error. Advise the user that their username or password was incorrect. Note: Every time the user opens the app this authentication process must occur. If you have advise on a better way to do this, please let me know.


Login Screen

1. API Calls (See Above for Login/Auth)

2. Mockup

Sign In

Username

Password

Forgot your username or password?Click here to retrieve it.

Not a LobbyGov user? Sign up.


Home Screen

1. Summary This “Home” page of the app lists all upcoming events for the day in some sort of layout that makes sense. The following information is provided for each entry: Bill Str, Short Description, Cmte Name, Event Title, Location/Time.

2. API Calls

A GET request to /dashboard/ with the token will return JSON-‐encoded string organized by date. Simply display the events in date order and then in the order of the events within each date object.

3. Mockup


Navigation Menu

1. Summary I want a button on the home page (upper left) that slides the main page to the right and shows the navigation bar. This is a pretty typical iOS approach to navigation/menus. Under iOS 7, however, user needs to be able to swipe the main window back to main view. Navigation will have little icons for each option.

2. Mockup


Legislators

1. Summary

Main page of the legislators page is a roster/contacts style interface (like iOS contacts). A thumbnail picture and the A-‐Z stuff on the right side. Each legislator will fall under an “upper” or “lower” chamber – the actual name for upper or lower will be returned along with the legislator results array. Tapping Lower or Upper should filter the list as appropriate. Tapping an individual legislator in the roster/list, goes to the Details page for that Legislator. On the individual details page, tapping phone will trigger a call, email will trigger a new email.

2. API Calls a. GET request to /legislators/ returns a JSON result with all legislators. b. GET request to /legislators/{id}/ returns JSON result for particular legislator.

Result includes all details to place on the details page and a URL for the image.

3. Mockups


Calendars

1. Summary

Shows calendar events for the next several days. Tapping a value/entry goes to the detail of the calendar/mtg. Most meetings/calendar entries will have bills associated with them. Tapping bill goes to the bill details page.

2. API Calls a. GET /calendars/ returns a list of events for each of the next several days. b. GET /calendars/{id}/ gets the details for the calendar event.

i. Also includes bills scheduled for the meetings; tapping the individual bill should take the user to the bill details page for it.

3. Mockup


Committees

1. Summary

Lower and Upper filter (same as for legislators) also applies. The main view will have a list of the committees. Tapping the cmte will take user to a details page for the cmte. For legislators that are committee members, they’ll be listed under the Members section. Tapping the particular member will go to their legislator details page (see above).

2. API Calls a. GET request to /cmtes/ returns a JSON result list of all committees. b. GET request to /cmtes/{id}/ returns a JSON result for the cmte.

3. Mockup


Vote Cards

1. Summary “Vote Cards” are used to track the positions legislators are taking on bills or other issues. This feature simply lets users record those positions and keep notes.

2. API Calls a. GET /votecards/ returns the list of all vote cards user has access to. b. GET /votecards/{id}/ returns the details of the card. c. GET /votecards/{id}/legislators/ returns a list of legislators. d. GET /votecards/{id}/legislators/{id}/ returns the details of the legislator. e. POST /votecards/{id}/legislators/{id}/ updates the details. f. POST /votecards/add/ with a short description to create a new card.

3. Mockup


Notifications

1. Summary

Notifications are events that happen through my web service. User will see a list of their notifications. Swiping they should see a button to “Dismiss” the notification, which sends a POST request to the API and reloads the notifications page. Tapping a particular notification will either go to the bill details page for the related bill or an add bill view if the notification is a new bill found type notification. That type info will be returned by the API.

2. API Calls a. GET request to /notifications/ with a valid token returns the notifications. b. POST request to /notifications/ with valid token and notification ID will

dismiss. 3. Mockup

Add Bills

1. Summary Lets users add bills to their tracking lists.

2. API Calls a. POST /addbill/ with bill ID, list ID, position, priority, short_descr &

comments value. If successful, returns 200 OK.


Search Bills

1. Summary This page gives the user the ability to search for bills by Keyword or Bill #. After search results are returned, display each bill. User taps the bill to go to a details page for the bill. The user then has the option to add the bill which takes the user to the Add Bill page with the bill number filled in.

2. API Calls

a. POST /search/ with a search_string value returns a list of bills that match the search string.

b. GET /bill/{id}/ returns a bill’s details. 3. Mockup


Tracking Lists

1. Summary

Tracking lists are where “bills” the user is tracking are stored. User needs to be able to view the bills and edit details for the bills (short description, comments, position & priority). Short descr is a text box, comments is a larger text area, pos/priority are wheels to make predefined selection.

2. API Calls a. GET /lists/ returns a JSON result of all lists. b. GET /lists/{id}/ returns a list of all bills in the list along with permissions for

the list (user might not have rights to delete or edit) and the priority/position options.

c. GET /lists/{id}/bill/{id}/ returns the bill’s details. d. POST /lists/{id}/bill/{id}/ short_descr, comments, position, priority to

update. e. DELETE /lists/{id}/bill/{id}/ to delete the bill.

3. Mockups


Support Tapping support opens a new email (using Mail) with the to address as “[email protected]” and the subject as “Support Request”. User can then decide whether to send the email and fill in the details or not. About This App Will show details about the app. Text/layout to be provided. Sign Out POSTs a sign out request to the API (/signout/) with the current token. That’ll end the session. Return user back to the login screen.

lobbygov iphone app

Documents