The EMMobileClient
project is a general purpose framework for integrating Endeca pages into an iOS project and does not assume that the targeted device is an iPhone or an iPad. The framework provides a series of OOTB Model object and Content Items:
Content Items
Content item include:
AutoSuggestPanel
Breadcrumbs
ContentSlot
ContentSlot
-MainContentSlot
-SecondaryContentSlotMain
ContentSlotSecondary
DimensionSearchAutoSuggestItem
GuidedNavigation
HorizontalRecordSpotlight
HorizontalResultsList
MediaBanner
MobilePage
OneColumnPage
PageSlot
PriceSlider
ProductDetail
PromotionalContent
-ATGSlotRefinementMenu
ResultsList
RichTextMain
SearchAdjustments
SearchBox
TwoColumnPage
Data Objects
Data objects include:
Action
AdjustedSearch
Ancestor
DimensionSearchGroup
DimensionSearchValue
MediaObject
NavigationAction
RangeFilterBreadcrumb
Record
RecordAction
Refinement
RefinementBreadcrumb
SearchBreadcrumb
SortOptionLabel
SuggestedSearch
Parsing
By default, parsing is done by examining the @type
and @class
properties of the JSON response objects. Each @type
is prefaced with EM
and the corresponding class is constructed. For example, @type:ResultsList
constructs the content item EMResultsList
.
For dataObjects
there is a configurable class package property, which by default is:
com.endeca.infront.cartridge.model
This value is stripped and the resulting class name is prefaced with ‘EM’ and constructed. For example: @class:com.endeca.infront.cartridge.model.SortOptionLabel
is constructed as the data object EMSortOptionLabel
. The framework offers very convenient extension points for overriding the defaults.
Renderers are also constructed dynamically via reflection. Each renderer is controlled using EMContentItemAdaptor
which acts as a translator between content items and UICollectionViews
. The controlling class, EMAssemblerViewController
, begins the adaptor construction by sending the root content item to a class called the EMAdaptorManager
.
The adaptor manager recursively traverses the content item structure creating EMContentItemAdaptors,
for each contentItem
. In this process, contentItem @type
and string Adaptor
are combined.
For example, the EMResultsList
content item has an @type
of ResultsList
, so a class called ResultsListAdaptor
is created. If ResultsListAdaptor
does not exist a default of EMContentItemAdaptor
is created instead. This adaptor is responsible for constructing the view to be rendered. By default, the ResultsListAdaptor
constructs a ResultsListRenderer
that is @type
+ Renderer
.
Both Adaptors and Renderers are considered reference code, so they do not reside in EMMobileClient
.
For a more a flexible dynamic layout, UICollectionViews
are used. Pages are rendered based on the content items they contain rather than a pre-defined page layout, so that your merchandiser can direct the page layout without developer intervention. A collectionview
can be thought of as an endless blank canvas, in that there are no restrictions on what can be displayed as long as you can direct what should display. When you define a simple adaptor that allows collectionviews
to retrieve the required data from content items, it can be easy to build dynamic pages.
Supporting New Content Items
With this structure, when a new content item is introduced, there is a well defined set of steps needed to support it in iOS:
Extend
EMJSONParser
for the new model object to be parsed correctly. By default a content item with@type MyContentItem
attempts to create a classEMMyContentItem
.Note: We do not recommend that you use this prefix scheme, and instead extend
EMJSONParser
(for example,CommerceJSONParser
) and develop your own naming convention. For example, your extended parser could be configured to look for a class called simplyMyContentItem
without a prefix. There are examples of this inCommerceJSONParser
.Construct the content item adaptor
MyContentItemAdaptor.
Construct the content item renderer
MyContentItemRenderer.
In the custom adaptor you will need, at a minimum, to return a size and count in order for the renderer to be shown.