Skip to content

Requirements

Jump to bottom Edit New page
Andy edited this page Apr 21, 2017 · 15 revisions

Attachments

Use Cases

  1. The client needs the ability to store attachments while the application is offline. Examples of attachments include pictures and text documents. (any supported file type)
  2. The client needs the ability to resync attachments with a Feature Service when the application returns from an offline state to an online state.

Requirements

  1. The library shall be able to provide the following fundamental functionality:
    • Determine if it is offline or online.
    • If an offline condition is detected then all attachments shall be written to the local database.
    • When the library returns to an online condition all stored attachments shall be synced with a Feature Service.
  2. The library shall work with the JavaScript API Attachment Editor in regards to creating and working with attachments.
  3. The library shall override the following functionality and implement the overrides within offlineFeaturesManager.js:
  4. The library shall provide the ability to resync edits with a Feature Service.
  5. The library shall provide the ability to store images and text files.
  6. The library shall support the following events:
  7. The library shall include the following self-generated events: [JA: events should give the app level code the opportunity to do something useful when something - unkown to it - happens. I don't think we need to add events to inform the app level of actions that they have requested, such as ATTACHMENTS_INFO. We should add only events of new actions introduced by us, like the result of sending attachments to the server]
    • ATTACHMENTS_SENT - stored attachments have been synced with the Feature Service.
    • ATTACHMENTS_INFO - the result of a queryAttachmentInfos request that returns information on the attachment
    • ATTACHMENTS_ADD - attachment was sent to the Feature Service while online. If the library is offline then attachments shall be added to the local database.
    • ATTACHMENTS_DELETED - attachment was deleted from the Feature Service while online. If the library is offline then the attachments shall be deleted from the local database.
  8. The library shall provide a dedicated indexedDB database for storing just attachments. This database inherits its basic requirements capabilities from the tiles indexedDB database (dbStore.js) which include but aren't limited to:
    • isSupported
    • store
    • retrieve
    • deleteAll
    • delete
    • getAllAttachmentsForFeatureId
    • getUsage

Tile Caching (from my notes, feel free to add/comment)

Use Cases

  1. The client needs the ability to store mapping tiles locally
  2. The client needs the ability to set the extent and zoom levels for a particular area of interest.
  3. The client needs the ability to access the locally stored tiles when the browser is offline. This access includes panning and zooming within the designated extent.
  4. The client needs the ability to download tiles in a format that can be imported into other applications.

Requirements

  1. The library shall store tiles in the browser. These tiles may be from a tiled map service or from a file type such as a TPK.
  2. The library shall provide a mechanism that allows the client to retrieves tiles.
  3. The library shall work with PhoneGap for use in hybrid applications.
  4. The library shall provide the ability to store at least 50 MB of tiles.
    • This is the theoretical limit for most browsers when using the indexedDB API. Some browsers now and in the future may be able to bypass this limit after providing the user with a browser message asking for permission to bypass this limit.
  5. The library shall provide a mechanism for downloading and reading tiles in a easily transportable format such CSV.

Offline Editing

Use cases:

  1. The client needs the ability to ADD, UPDATE, DELETE points, lines and polygon features while offline. [OK]
  2. The client needs the ability to undo/redo a queued/pending edit. In other words, the client needs to be able to modify or delete a queued edit that is stored on the client application and controlled by the offline library.
  • [Well, my view is that once you do an edit, that is done, no matter whether you are online or offline. You can always reverse an edit. For instance, you can delete a feature that you have added, but in my opinion, allowing the deletion of arbitrary edits can cause serious coherence problems. What if you do an ADD, and then and UPDATE and after you 'cancel' the ADD? What would happen to the subsequent UPDATE?]
  • AG: If you ADD an item > UPDATE it > then Cancel you'd get no edit whatsoever. Only the very last edit on any single item is valid. Last edit wins.
  • AG: As far as I know you cannot ADD then DELETE a feature in our queue. The ADD event will be processed, but don't we need to know the ObjectID in order to DELETE it? If that is true, we won't have that information until the ADD event is processed by the server and it issues the ObjectID in the response. The pending DELETE operation will not know that ID. I've added more information below under Req's section 3.
  • JA: we do this correctly. We insert a temporary ID so that the user can apply subsequent UPDATEs and DELETE to that feature
  1. Users and application developers need information on which edits were successfully sent from the queue. [OK]
  2. Users and application developers need information on edits which have not been successfully sent after a specific online time period has elapsed. [OK, for me this situation should be handled in the same way as unsuccessful edits made online]
  3. Users and application developers need information when an edit failed so that the appropriate corrective action can be applied.
  • [We need to determine which corrective actions are appropriate]
  • AG: Agreed.

Requirements

  1. The library shall store information in the browser on all ADDs, UPDATEs and DELETEs while the application is offline. This store can also be referred to as a “queue.” [OK]
  2. The library shall provide public method(s) for allowing the client to do #1 [OK]
  3. The library internally needs the ability to delete an edit from its “queue” without affecting any other pending edits.
  • [Why is this needed? It is much simpler to ensure data integrity if we see the queue as a real queue where elements can only be added at the end and they can only be removed from the beginning]
  • AG: As mentioned above, I think there are some technical issues with maintaining the queue.
  • Additional scenarios for consideration. I think we need to map all of these out to help us clarify in our minds what scenarios can be handled:
    • ADD. No problems here.
    • DELETE. No problems here.
    • UPDATE. No problems here.
    • ADD item > DELETE. We won't know the ObjectId in order to insure valid deletion (unless we implement an architecture to capture that information and store it appropriately).
    • ADD item > UPDATE. I also think we need the ObjectId to perform the update. We won't get that until the ADD event has returned a valid response object. We would need a mechanism for retrieving the ObjectId and associating it with the UPDATE request?
    • ADD > [courtesy] undo. Alleviates the possible issues with ADD > DELETE mentioned above.
    • DELETE > [courtesy] Undo. Following the online protocol, an item that is deleted from server can only be added again from scratch. Providing "undo" is a convenience method for the end user that eliminates the need to completely recreate an object that was, for example, accidentally deleted while offline.
    • UPDATE > UPDATE. I believe this scenario can use your suggested approach. A [courtesy] update would be a nice thing to have, but not completely necessary as you've suggested.
  1. The library internally needs the ability to modify an edit in the “queue” without affecting any other pending edits.
  • [Why? It is much simpler to simply add subsequent edits to the queue. If you want to 'cancel' an ADD, then you should enqueue a DELETE. There is already support for this Undo/Redo management at the application level, using esri/dijit/editing/Editor and UndoManager classes]
  • AG: I'm not 100% familiar with how the Editor works, so it's not clear to me yet that all of it's workflows will be appropriate for offline use and that should be taken into careful consideration. I think "offline" introduces some complexities, mentioned above, that it may or may not have been taken into account appropriately. If I'm wrong then cool, I'm just exercising the use cases to test if we are on the right track.
  1. The library internally needs the ability to track if an ADD, UPDATE or DELETE was not successful. This is required to insure data integrity of the queue.
  • [Yes, what would the appropriate action be?]
  • AG: At a minimum we should provide a way to flag actions that weren't successful and assign a property that indicates what the problem might have been.
  1. The library needs a mechanism for notifying the client if an edit was unsuccessful.
    • Unsuccessful events shall not be silent in order to prevent data corruption and to eliminate unintentionally mis-information to the client.
      • [Agreed. I think that the offline editing feature is not different than online editing in this regard. The app should behave in the same way and report problems to the user in the same way]
      • AG: Needs more discussion. It's not clear to me yet that offline behavior can be treated exactly the same as online for reasons mentioned above.
  2. The library needs a mechanism for providing detail information to the client if an edit was unsuccessful.
    • At a minimum, the library should store information on a failed edit to include at least: objectid, datetime, attributes, geometry.
    • There shall be a distinction between an edit that failed because of a bad internet connection and an edit that failed because it was rejected by ArcGIS.
      • [Well, one is an error (ArcGIS Server rejected) and the other is a normal condition (we are offline, we keep the edit until we are online again)]
      • AG: Right, bad internet connection we keep the edit in the queue.
      • AG: However, what do we do with edits that were reject by ArcGIS Server? Delete them from the queue? Or, do we create another queue that becomes a holding pen for bad edits so that information is not lost? Send an event that some edits were rejected?
  3. The library shall only delete a queued edit if the following criteria are met:
    • The pending edit was sent to server and a success property was received back. [OK]
    • The user requests to modify or delete the pending edit.
      • [I don't think this is needed and it makes preserving integrity more difficult]
      • AG: Potentially. We need to validate my queueing scenarios above (and make sure I didn't miss any others) to verify if we can take the approach you have suggested.
    • The user clears the browser cache (we have no control over this) [OK]
  4. The library shall replace/modify a queued edit if the client requests an update to its properties.
    • [Disagree, the correct way to do this IMO is to enqueue another UPDATE on the same feature and replay them in order]
    • AG: It's quite possible that UPDATEs might operate under slightly different use case than ADDS or DELETE. You'll probably agree on this point. With an UPDATE we already know it's ObjectID, that's not going to change. Furthermore, it's perfectly okay that last edit wins.
  5. The library shall provide a mechanism for tracking if an unsent edit is more than X hours old. [OK]
Add a custom footer
Add a custom sidebar
Clone this wiki locally