The document summarizes the development of the Census Bureau's first official mobile app, which displays 16 economic indicators from 3 backend APIs. It describes the front-end architecture using Adobe Flex and the backend architectures, which include a private LAMP-based API for Census data and APIs from BLS and BEA. It also discusses challenges faced such as lack of documentation, coordination issues, and lessons learned around early planning and testing.
Report
Share
Report
Share
1 of 22
More Related Content
U.S. Census presentation at DC API Meetup 12/13/12 by Alec Permison
1. The Making of the Census Bureau’s First Official Mobile App
Alec Permison, ADIT/ASD
Paul Milbourne, ADIT/ASD
Gustavo Torrico, ADEP/EPD
3. Overview
• First Census Bureau mobile app for
Android/iOS both phone & tablet
• Developed as part of ongoing Web
Transformation effort
• Displays 16 economic indicators
• 13 from Census Bureau Central
Indicators Database Repository
• 2 from Bureau of Economic Analysis
• 1 from Bureau of Labor Statistics
4. Overview
• Collaborative team effort
• Communications Directorate – product owner & manager
• Contractor – front-end development
• Economics Directorate – data experts and back-end
development
• IT Directorate – technical guidance, back-end development,
and technical support
5. Overview
• Mobile app front-end displays data
• Three back-end API‟s supply data at
App
startup, refresh, and indicator release
• CIDR Private API developed by Econ
• BLS Private API developed by IT
• BEA Public API
• Config file on server queried at CIDR BLS BEA
startup
BoC Private
12. Front End Architecture
• Skills Required • Tools Required
– Adobe Flash Builder 4.6
– ActionScript
– Xcode and Eclipse for some
– CSS native components
– XML
13. Front End Architecture
• Pros of Adobe Flex • Cons of Adobe Flex
– Device agnostic from a – Larger footprint
single code base (especially on iOS)
– Easier than native – Android support varies by
development device
– Broad developer – Slower performance
community
– Requires AIR runtime
14. Back End Architecture (CIDR)
• LAMP stack: • JSON-based :
– RHEL 5.8 – Economic dashboard data
– Historical economic indicator
– Apache 2.2.3
data
– Mysql 5.0.95 – Simple format derived from
– PHP 5.1.6 mobile application mockups.
– Private through hash based
“authentication”
• Zend Framework 1.6
– Text-based, easily parse-
– Simple, loosely-coupled able.
component library for web
– Data available as soon as
applications upload process is completed
on internal Census servers.
15. Back End Architecture (CIDR)
dashboard_data
category
time_slot data_type
display_cell
geo_level error_type
17. Back End Architecture (CIDR)
• Historical data available in CIDR database (display_cell table)
18. Back End Architecture (CIDR)
• Basic hash-key based authentication
• Example URL:
– http://www.census.gov/econ/currentdata/api/dashboard?id=sapient&ha
sh=89704299208e7e9d16380e4384861396f3398cb0
• Calculating hash:
– sha1(secret key + time stamp + path requested)
1. Secret key – a 40 character alpha-numeric string
2. Time stamp – in the format YYYY-MM-DD 24HH (e.g. „2012-05-14 17‟)
using UTC timestamp.
3. Path requested – excluding id and hash parameters.
„/econ/currentdata/api/dashboard‟
19. Back End Architecture
• Skills Required • Tools Required
– Dev/test environment
– LAMP web dev
– IDE
– Enterprise-scale
development experience
(not for newbie‟s)
– REST interface design
20. Back End Architecture
• Pros of Private API • Cons of Private API
– Fast performance for – Additional skilled
database on our server resources required
– Customized to need of – Additional application to
front-end developer support
– Access more data than – Dependent on your
public API infrastructure
– Under your control
21. Project Challenges
• Limited insight into technical design and code at handoff
(25,000+ LOC, few comments or technical docs initially)
• Security framework still under development
• Lack of dev/test tools & environment for mobile
• Standardizing data formats from 3 API‟s (e.g. timestamps)
• Timely technical support from other agencies
• Coordination with external contractor (e.g. config updates)
22. Lessons Learned
• Early involvement with contractor on technical design
• Schedule time for review and feedback at milestones
• Early engagement from security to address framework
• Identify and procure tools far in advance
• Test external API‟s for reliability/accuracy