3

I'm using php to create a USSD page. I've done this before and it was quite the time-constrained hack-job; basically one huge file with a switch statement for all the possible states that the cellphone user can be in (which is then saved in a DB and retrieved upon the next USSD request) -- a state machine of sorts.

This time round I have a bit more time and would like to use something more professional. Are there any design patterns or best practices that I can use for this kind of scenario?

11
  • What kind API will you expose? What kinds of requests will be coming in, and what kind of responses will you give? Commented Sep 21, 2011 at 16:14
  • 2
    @DanielSchilling USSD as per the tag description: "Unstructured Supplementary Service Data is a communication protocol used in GSM". Those *140# type numbers that (afaik) any cellphone can utilise. Commented Sep 21, 2011 at 19:31
  • @Jonah I'm exposing our own in-house API (not sure if I understand your question correctly). The responses will be either menus (e.g. Select a service 1) Profile 2) View Balance 3) Load Credit) or direct questions (e.g. 'Enter your name:'). The requests will mostly be either selecting a menu option (e.g. '2' in the previous example will then display the View Balance menu) or entering a value to a direct question. Commented Sep 21, 2011 at 19:41
  • I just saw a related question. My previous implementation was similar to Albert's suggestion. I guess that's the way to go (or stay in this case). Commented Sep 21, 2011 at 20:49
  • @fjdutoit: Did the answers of the related question solve your problem? Commented Sep 22, 2011 at 12:25

1 Answer 1

1

I've battled with this problem too. My approach is to use a tree where each ussd state is a node. Let me illutrate the best way I can

interface Node { render(), process(input) } 

The nodes are classified into Selection and Input nodes.

Selection

Selection nodes simply present users with options that the can choose from then refer the user to one its child nodes or display an error message

class Selection extends Node { Node[] children; string title; render() { // create a ussd menu here appending title to // menu items based on this.children } process(input) { // get input and select from children node // call its render method } } 

Input

Input nodes collect actual input from users (like names, voucher number, etc) and do processing like query a database or call a remote API, then present the user with a response.

class Input extends Node { string title; string instruction; Handler handler; render() { // show title and/or instruction to user } process(input) { // validate input and then pass to this.handler } } 

To further decouple logic, I added a handler interface, every Input node needs to have a handler. All the processing logic resides in the Handler

interface Handler { handle() } 

Resolver

Now with this you create a Resolver class that handlers the ussd session information, and all the http stuff (if you're receiving ussd requests via http). The Resolver also transverses the tree based on the user input to collect the responsible Node then either calls it's render or process method. Your tree with look something like this

new Selection('Main Menu (title)', [ new Selection('My account', [...]), new Input('Recharge', 'Enter voucher number', new RechargeHandler()) ]); 

This is a limited solution specific to my use case, I believe it can be extended to cater for other situations. I would like to hear how everyone else is solving this problem

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.