Understand how to effectively include attachments in your MBO Model.
 |
Attachments can be large (photos, product manuals, and so on) and are not always required by the application, as is often the case with e-mail attachments. See The Choice of Synchronization. |
|
It is expensive to always synchronize large objects that are only occasionally required. See Inline Attachments are Expensive. |
|
Use a separate MBO to carry an attachment. See Consider the Attachment as an MBO. |
 |
Inline attachments can result in redundant data transfer to and from the device. In most wireless networks, upload is only a fraction of the advertised bandwidth, further exacerbating long synchronization time. |
 |
Subscribe to required attachments on-demand through synchronization parameters. |
|
Use initial synchronization in a favorable environment to load required attachments (reference data) for full offline access. See Offline Access Pattern. |
 |
Do not include the attachment as an MBO attribute if the mobile application or EIS can update the MBO. |
|
Use Big data types for large attachments to avoid loading on instantiation and use offset based access patterns. See BigString and BigBinary Datatypes. |
The Choice of Synchronization
Synchronizing data that is not required on the device impacts multiple components of data mobilization. However, there is no definitive solution for data that is only used occasionally, since you must take into account connectivity and demand patterns. In general, Sybase recommends that you defer transfers until required. The exception is in an offline mobile application. The developer must analyse business requirements and the environment when making the decision of when to synchronize, and how much data to synchronize.
Inline Attachments are Expensive
Regardless of the decision on synchronization, attachments should not be embedded inline with the MBO as an attribute. Attachments do not generally change, and having it inline results in high data transfer overhead. Updating the MBO can cause transfer of inline attachments even though they are not modified. The cost of uploading and downloading a large attachment can be significant. Updating the status of a service downloads the attachment again if it is handled inline. In most wireless networks, uploads are slower than downloads, so it is not advisable to upload attachments. The same is true for downloads. If the EIS updates regular attributes of the MBO instance, the attachment is downloaded again if it is handled inline. The convenience of having the attachment inline is rarely worth the cost of moving them through the wireless network.
BigString and BigBinary Datatypes
Another cost of inline attachments is object instantiation and resource consumption. Unwired Platform handles this by providing a set of special attributes: BigString and BigBinary. Not only are these attributes not loaded when the object containing them is instantiated, they include a special API to access only the segment in which the application is interested. In other words, very much like the access of a large file, the mobile application can seek to the proper offset to avoid bringing the entire resource into memory.
Consider the Attachment as an MBO
Using a separate MBO to hold the attachment provides flexibility through synchronization parameters and synchronization groups. Modeling the attachment MBO to employ a synchronization parameter allows the application to subscribe to the Attachment when required. A separate synchronization group can hold the attachment MBO, which then can be prefetched or pulled on demand. Prefetching can usually be performed asynchronously without impacting usability of the mobile application. In addition, this pattern enables timely delivery of transactional information, for example, a service ticket by separating or deferring reference data.
Offline Access Pattern
For mobile applications that run in offline mode, on-demand access of attachments is not possible. In this case, it is better to bulk download all attachments during initial synchronization in a high quality connected environment. For example, through device cradle or WiFi connectivity. This approach is possible because attachments rarely change and occasional changes can be downloaded at specific times of the day. The cost of this approach is a more complex and longer application roll out cycle.