PhoneBook Manager App

CodeName: PB-Man ,pbman,PB-App etc (For reference in the document only)

Proposed App name: People’s Book = xPB

Features and Functionality

The main features of the app are divided into following category:

  1. Phonebook Database/Storage : CRUD
  2. Interfaces:Import/Export Database Various Formats
  3. Settings for App,database backup and sync options

First of all ,defining database / needs of a contact information


Database Usage

  1. NumberType and InfoType
    These two tables contains fixed values to be used to identify number type (I.e Mobile,Work etc) and contact info (i.e. Email,Facebook ID,website etc).
  2. Contact
    Contact is a main entry to the app . A contact have Name and LastName(optional) field with a optional Photo. Photo is stored in the database.Using BytesArray(Blob) or Base64 code(Text). Then Contact is added with multiple Number and Info
  3. Number  and Info
    The number and Info entries are created when adding new to the contact.
  4. Group
    Group is created and then contacts ID are added to the GroupContact table.


The import and export of contacts are required for multiple formats. These formats include the essential interfaces of PB-App specific format which is used to backup and restore the application specific contacts data.

Also for Nokia contacts files VCF  and Android vcf file which contains multiple contacts vcf in a single file.

Optionally , future implementation of Android native Contacts import/export using ANE (Air Native Extension).

So all these interface should have a common interface and separate implementations.

Like NokiaImport,will implement “IImportInterface “ and will do the logic for handling Nokia VCF file

Possible Interfaces


The app settings include following features:

Presentation Layer

In this section , I will be trying to generally define every view required for the app features just discussed. These views are provided with the data to be displayed/presented. Robotlegs v2.1.0 will be powering the application , so all views will be mediated. But the mediation should be same for different Views layer (Starling or Flex Components).

Application’s Main Views In General

Main View

Provides Navigation to Contacts,Import Export,settings and About View . Also it will provide methods to load other main views I.e. to show Contact,Settings views etc. All the screen size events etc are handled in View layer and is managed in Main View

Contacts Views

Have ContactList as root view and then sub views as following

Import/Export View

Provides available Import/export options. The Sub views are as following , (first being the root(starting) view)

Settings View

Settings provide views for app settings as discussed in features. The starting view gives navigation to sub views.

The Data base type and database source settings are dependent hence on same view

About View

Single view to represent the app info,logo and author info.

Common Events

There will be a Application Framework (RL2) events and there will be a separate event package only for Views and their Mediators.These events will be mainly triggered on Views and mediators will handle them. Mediator should be using Views API to hook data into views. So a seprate package of AppViews Event will be defined. These Events will be* and as Starling has its own Event package, there may be need to [Inject] IEventDispatcher within starling with , but it will not be the case with flex views.


AVEvent (App Views Event) class will be used for View to Mediator communication. It will contain meaning full names for Event Type and should be used in flex views. From now on I will define AVEvent.SOME_TYPE as will be discussing Views API.

Views Api

To be able to implement different presentation layer for the app , with all the same core functionality , these views needs to implement some common interface. There will be a common Events and Event Names to bridge Views and Logic layers ie AVEvent.

All views have constant names to be referenced. These will be stored as constant strings in AppViews class.

Contacts Views Api

The main or root ContactsView will be responsible to switch between  contacts sub views. The name property refer to AppViews.SOME_VIEW property.


Main List

Contact List View

This will load the Contact Single View with initial dummy data

Contact  Single View

Contact Single Edit