PhoneBook Manager App
CodeName: PB-Man ,pbman,PB-App etc (For reference in the document only)
Proposed App name: People’s Book = xPB
The main features of the app are divided into following category:
First of all ,defining database / needs of a contact information
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
The app settings include following features:
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).
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
Have ContactList as root view and then sub views as following
Provides available Import/export options. The Sub views are as following , (first being the root(starting) 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
Single view to represent the app info,logo and author info.
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 flash.events.* 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.
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.
The main or root ContactsView will be responsible to switch between contacts sub views. The name property refer to AppViews.SOME_VIEW property.
This will load the Contact Single View with initial dummy data