High-Speed Blog

In Part 1, we discussed how to get started using Google’s Places API, including all necessary registrations. We also delved lightly on the differences between Place searches and Place details.

Now let’s actually create something fun and useful.  First we need an idea.  And I have a good one!

Exercising Core Location-Based Features Using the Places API

Let’s quickly identify some core location-based features.  These features are made possible by the ability of smart phones to track their GPS location and use GPS coordinates within applications to correlate user location to people and places in proximity to that location.  Generally, the following is a list of such features:

• Ability to identify and publish current location
• Search for places that are in proximity to a given location
• Obtain details about a specific place, usually selected from a proximity search
• Generate a proximity alert upon entering a location proximity
• Generate a proximity alert upon exiting a location proximity

Now, real innovation comes from your ability to enhance those features.  For example, let’s say your smart phone contains an application that alerts you to store specials as you come within proximity to participating stores.  So one day you are driving by and a proximity alert alerts you to a store special (or discount) at your favorite store.  But you don’t have time, and drive on by.

Now let’s say you drive by the same store on your return home.  Since you are within proximity to that store again, you get another proximity alert.  However, this time the application somehow knows you were nearby about an hour ago, and doubles the discount offered earlier.  You are excited and drive straight to the store.

That’s real innovation enhancing the core location-based features we discussed earlier.

Developing an Android-Based Mobile Application Using the Places API – Getting Started

As developers, we tend to learn new concepts and techniques best through examples.  Given the example we discussed earlier in enhancing the core location-based features, let’s develop this into a working mobile application using the Android platform.  To review, we stated the following:

For example, let’s say your smart phone contains an application that alerts you to store specials as you come within proximity to participating stores.  So one day you are driving by and a proximity alert “alerts” you to a store special (or discount) at your favorite store.  But you don’t have time, and drive on by.

Now let’s say you drive by the same store on your return home.  Since you are within proximity to that store again, you get another proximity alert.  However, this time the application somehow “knows” you were nearby about an hour ago, and doubles the discount offered earlier.  You are excited and drive straight to the store.

In order to tackle this, we need to better understand are requirements and end goals.

Use Cases

A great place to start is defining the Use Cases.  Of course we need to identify our key Actors first.  I see the following:

• Retailer
• Consumer
• System

Per Actor, the Use Cases are as follows:

1. Retailer - ability to manage discounts and rules by defining campaigns, similar to CRM and relational marketing
2. Retailer - report results of campaigns
3. Consumer - enable/disable proximity alerts
4. Consumer - ability to select/filter retailers of interest
5. Consumer - ability to select proximity alert radius
6. Consumer - provide display, store, and retrieve functionality for store specials/discounts
7. System - record all consumer proximity alert activities
8. System - manage retailer registrations

Considerations

Let’s identify some considerations and assumptions to make our development simple and well-defined.

We will track retailers and campaigns, and consumer proximity alert activities on the server using RESTful services.  We’ll generate a quick report of customer proximity alert activities by querying the database and returning results in either JSON or XML.

We will assume a standard campaign with simple rules used by all retailers and exclude a full-blown retailer campaign management process.  We will assume two or three registered retailers and exclude a full-blown retailer registration process.

And we will assume store specials/discounts never expire! 

Now did you think we were done?  We need to think about how we should manage the actual redemption of a reward.  We can’t assume the consumer will just click a button.  Therefore we need a website for the retailer to access and manage consumer reward redemption’s and basic reporting needs.

And lastly, you may wonder what technology I have chosen for the server-side.  It is ASP.NET MVC. as it is easy to create RESTful services supported by POCO’s, as Business Objects, and working with DTO’s and Repositories.  Click here to review my previous post for more information on POCO’s, as Business Objects, DTO’s, and Repositories.

Design Overview

Per our Considerations above,

• we will require a database to store retailer and customer information
• we will also require RESTful services to support the retailer and client requests (just a handful)
• and lastly, we need to provide several application screens for management of user configuration settings and display and persistence of store specials/discounts

Entity Diagram

We will define our data model (or entity diagram) as follows:

Entity Diagram

Note that there is no relationship between Retailers and Campaigns.  Normally one would exist (e.g., one-to-many), but we are assuming that all retailers are using the same campaign since we are excluding the retailer campaign management process per our considerations.

Services

Our mobile application is considered a client that requires services to provide the complete system functionality.  Remember that system functionality is required by both retailers and consumers, and all retailer relevant information is stored on the server.  Therefore, we define our required services as follows:

1. Retrieve campaign reward for retailer service (assumes consumer has entered retailer proximity).
2. Record consumer proximity visitation service (consumer enters retailer proximity).
3. Redeem consumer reward service (consumer makes a purchase at the retailer and redeems reward).
4. Retrieve campaign results service (used to report on campaign success).
5. Optional:  If we decided to manage campaigns, we would add a campaign management service.

Application Screens

Our mobile application needs several screens to provide basic settings management and rewards display/management functionality.

The required screens are:

1. Mobile Client – User Configuration Settings
2. Mobile Client – List of Retailer Rewards Display
3. Mobile Client – Detail Retailer Reward Display
4. Server - Redeem Consumer Reward

More on Design – Flushing Out the Details

We’ve already designed our data model, spec’ed our services, and identified our application screens.  Since we are tapping into location-based features, we need to discuss and agree on certain design strategies to allow us to be a mobile friendly mobile application, and not one that sucks battery life, or lives in the user thread (thus, being a bad citizen), etc…

We need a way to identify the places that match the user’s selected categories, and are within the user’s target proximity radius.

Therefore it makes sense for us to create a service that periodically call’s the place’s search API, and return those places that are within the user’s current proximity. From these results, we can easily filter those that match the user’s selected categories.

In general, our mobile application will need the following:

• A service that provides “who is within my proximity”.
• A service that provides details on a retailer, e.g., currently running campaigns and relevant rewards.
• A class that manages and retrieves user proximity, category, and enable/disable settings.
• An activity to display “who is in my proximity”, on-demand.
• A POJO requesting retailer campaign attributes, e.g., rewards. Note, this requires a server-side RESTful service.
• An notification to notify user of retailer reward.
• An activity to display retailer reward.
• An activity to display and manage “user received” retailer rewards. Note, we’ll use local persistence.

And our server-side application will require the following:

• A retailer campaign manager class.
• A “look up” consumer’s information and reward(s) class.
• A redeem consumer reward(s) class.
• A generate reports class.

UML Diagrams

Let’s describe some general classes that depict our system design as follows:

Class Diagram - Places In Proximity

For brevity, I am showing classes that belong to all components found in our system, without showing a more detailed architectural, or component diagram.

And we’ll describe the sequence through those classes for the core use cases in retrieving places in proximity as follows:

Sequence Diagram - Places in Proximity

Note that I did skip some important calls to the Android API to help keep our focus on the main sequence per our use cases.

We’ll start developing the mobile application next.

Enhancements Excluded

The following enhancements are my opinions of details required to make this a practical application.  Since my intention focuses on location-based concepts, not full application development, some application features are excluded as follows:

• Proper handling (both system and user interface) of the volume of reward notifications received by client.  If left unchecked, this will get messy, real fast!
• Consumer reward deletion.  The item above should actually manage this.
• Avoid duplicate reward notifications.  Again, the top item should manage this.
• Retailer campaign management.
• Expiring rewards by date at client.
• Expiring/deletion rewards after redemption at client.

In Part 3 we will start tackling the code for our location-based mobile application.  See you in Part 3.