Where

This page describes some of the technology underlying the Where app.  There are a couple of interesting design choices.

• Security
• Identification:

There are two types of users, Customers and Vendors (Service Providers).  In general, Where does not need to know the identity of the user.  Most users can find the services they want without identifying themselves.  There are two exceptions:

• Service providers need to identify themselves to manage and modify their "service".  Each service provider can have multiple services.
• Customers that want to provide feedback must identify themselves to prevent multiple posts to the same service provider. 

Both types of users can identify themselves using their Google or Facebook IDs, or create an new accounts using their email or Mobile phone number.  The email or phone number is not recorded by Where.  It is used to create a unique account ID.

• Privacy

As mentioned above, Where does not store the user's name, phone number or email address in its data bases.  It uses the Google authentication service to validate users.  This means that user's identity and other information will not be compromised if the Where database is ever hacked.  Further, publicizing that there is no hacker worthy information in the database should reduce the temptation for people to mess with it.  The information currently stored in the database is limited to:

• Vendor name
• Service Type
• Blurb
• Description
• Vendor's URL
• Phone number
• Active Start time
• Active Stop time
• AuthID string  (a unique key for the database)
• Current Latitude
• Current Longitude
• GeoHash
• Last update time
• Cloud database:

Where uses the Google Firestore database.

• Free / cheap
• Real time updates not required
• Geo-range based search required
• Security & Data validation
• Create, Read, Update, Delete
• Geo searching
• Latitude & Longitude are hashed to a 40 bit geo-hash.  The geo-cell size is about 19 meters.
• Auto Scheduling
• Apart from the database, there are no online servers.  All updates are performed by the service providers' (vendor's) mobile devices.
• When a vendor configures automatic weekly schedules, the schedule is stored on the vendor's phone.  A background process on the device needs to update the opening and closing times.  Where uses the Android Alarms to accomplish this.  Further, these Alarms will be restored if the device is shut down and restarted.   
• There are two consequences to this design: the vendor's device must be on for auto scheduling to work, and auto location setting can be enabled for only one of the vendor's services (if they have multiple services.)