SYNC BASED ON NAVIGATION HISTORY

Abstract

Disclosed are various examples for syncing files based on a navigation history. A client application maintains a navigation history for a file management system. The client application identifies files and directories accessed according to the navigation history. The identified files or associated metadata are downloaded from the file management system during a sync operation.

Description

BACKGROUND

File management systems can allow a user to perform various operations with respect to remotely stored files. For example, a user can upload a file for storage, download stored files, or edit files. This allows for remote access to files independent of the client device assessing the file management system.

Some file management systems allow for multiple users to have access to files. This allows for additional features for the users. For example, the file management system can implement access controls or permissions that dictate which users can access a particular file. Sharing controls can allow a user to extend access privileges to another user of the file management system. Files can also be edited by multiple users, allowing for collaborative document creation or editing.

A client device can periodically sync with the file management system. This can include downloading an updated directory of available files, updates to files, downloading newly shared or required files, or downloading other files. This can also include pushing updates to files to the file management system. As the number of users in a system and the number of files available for editing increases, the file directories can become quickly outdated. As a result, a user browsing a list of available files might not be presented with a list that shows, for example, the most recent versions of files. The process of synchronizing an entire file directory structure can be time consuming particularly as the size of an organization's file directories rapidly expand.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, with emphasis instead being placed upon clearly illustrating the principles of the disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

FIG. 1 is a drawing of a networked environment according to various examples.

FIG. 2 is a pictorial diagram of an example user interface rendered by a client in the networked environment of FIG. 1 according to various examples.

FIGS. 3 and 4 are flowcharts illustrating examples of functionality implemented as portions of a client application.

DETAILED DESCRIPTION

File management systems allow users of client devices to perform various operations with respect to remotely stored files. For example, the file management system can allow the upload or download of files between a client device and the file management system. The file management system can also allow a client device to read files or write changes to files. These read or written files can include remotely stored instances stored by the file management system or locally stored instances of files that can be uploaded or synced with the file management system. Additionally, the file management system can maintain user accounts defining permissions, requirements, or other attributes with respect to files.

A client application used to access the file management system can periodically synchronize information between the file management system and the client device. For example, the client application can upload newly created files or push updates to existing files to the file management system. The client application can also download files, updates to files, or directory data from the file management system. This can ensure version consistency between instances of files stored by the client device and the file management application and that the client device stores designated or necessary files.

As the client application can have access to large amounts of data of the file management system, a sync operation should optimize which data is downloaded from the file management system so as not to use excessive bandwidth or other computational resources. To this end, a client application maintains a navigation history as a user of the client application navigates through a file system of the file management system. As a directory or data file can be accessed by the client application, an indication of the accessed directory or data file can be added to the navigation history. Navigation of the file system can be performed using gesture inputs to a touch screen display. During a sync operation, the client application requests, from the file management system, data based on the navigation history. This can include updated directory listings, changes to locally stored files, required files, or other data.

In the following discussion, a general description of the system and its components is provided, followed by a discussion of the operation of the same.

With reference to FIG. 1, shown is a networked environment 100 according to various examples. The networked environment 100 includes a computing environment 101, and a client device 104, which are in data communication with each other via a network 107. The network 107 includes, for example, the Internet, intranets, extranets, wide area networks (WANs), local area networks (LANs), wired networks, wireless networks, or other suitable networks, or any combination of two or more such networks. For example, such networks can include satellite networks, cable networks, Ethernet networks, and other types of networks.

The computing environment 101 can include, for example, a server computer or any other system providing computing capabilities. Alternatively, the computing environment 101 can employ multiple computing devices that can be arranged, for example, in one or more server banks, computer banks, or other arrangements. The computing devices can be located in a single installation or can be distributed among many different geographical locations. For example, the computing environment 101 can include multiple computing devices that together form a hosted computing resource, a grid computing resource, or any other distributed computing arrangement. In some cases, the computing environment 101 can operate as at least a portion of an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources can vary over time. The computing environment 101 can also include or be operated as one or more virtualized computer instances. Generally, the computing environment 101 is operated in accordance with particular security protocols such that it is considered a trusted computing environment. The data store 111 can be representative of a single data store 111, or a plurality of data stores 111 as can be appreciated.

The components executed on the computing environment 101, for example, include a file management system 114, and other applications, services, processes, systems, engines, or functionality. The file management system 114 can facilitate the access and potentially the modification of files 117 by client devices 104. To this end, the file management system 114 can obtain files from client devices 104 through the network 107 or from other sources for storage in the data store 111. The file management system 114 can also communicate files 117 to client devices 104 through the network 107. The file management system 114 can also track versions, updates, or modifications of files 117. To this end, the file management system 114 can include version management or version control systems. The operations of the file management system 114 can be performed in accordance with permissions or requirements defined with respect to user accounts 121.

The data stored in the data store 111 includes, for example, a file system 116 of files 117, file directory structures 118, user accounts 121, and potentially other data. A file system 116 defines the storage and access of files 117 by the file management system 114. Files 117 include instances of data accessed or modified by the file management system 114. To this end, files 117 can include documents, media, executable applications, or other data. File directory structures 118 can include folders or directories encoding a hierarchy, grouping or relationship of files 117.

User accounts 121 can define privileges or rights associated with the access or modification of files 117. For example, user accounts 121 can indicate files 117, file directory structures 118, or components of a file system to which a user account 121 can have permission to read, download, or otherwise access. User accounts 121 can also indicate files 117 or components of a file system to which a user account 121 can have permission to write, update, delete, or otherwise modify. User accounts 121 can also indicate files 117 that are required for download or update by a client device 104 accessing the file management system 114 through the user account 121. User accounts 121 can also define logic or access credentials, including usernames, passwords, encryption keys, temporary or permanent tokens, or other credentials.

The client device 104 is representative of a plurality of client devices that can be coupled to the network 107. The client device 104 can include, for example, a processor-based system such as a computer system. Such a computer system can be embodied in the form of a desktop computer, a laptop computer, personal digital assistants, cellular telephones, smartphones, set-top boxes, music players, web pads, tablet computer systems, game consoles, electronic book readers, or other devices with like capability. The client device 104 can include a display 124. The display 124 can include, for example, one or more devices such as liquid crystal display (LCD) displays, gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink (E ink) displays, LCD projectors, or other types of display devices.

The client device 104 can be configured to execute various applications such as a client application 127 and/or other applications. The client application 127 can be executed in a client device 104, for example, to access network content served up by the computing environment 101 and/or other servers, thereby rendering a user interface 131 on the display 124. To this end, the client application 127 can include, for example, a browser, or a dedicated application, and the user interface 131 can include a network page, or an application screen. The client device 104 can be configured to execute applications beyond the client application 127 such as email applications, social networking applications, word processors, spreadsheets, and/or other applications.

Next, a general description of the operation of the various components of the networked environment 100 is provided. To begin, a client application 127 accesses the file management system 114 using a user account 121. This can include, for example, authenticating the client device 104 with the file management system 114 using authentication credentials or passing in a session identifier, cookie, token, or other identifier if the client device 104 has been previously authenticated. The client application 127 can then navigate through all or a portion of the file system 116. This can include, for example, traversing through one or more directory files or accessing one or more data files 117 accessible through the user account 121. In one example, the entire file directory structure for available files can be sent to the client application 127 upon initial launch, and updates can be subsequently be provided based on a user's navigation history, as described below.

As the client application 127 navigates the file system 116, the client application 127 maintains and updates a navigation history 134 indicating a progression through the file system 116. For example, if the client application 127 accesses a file 117, an indication of the file 117 is added to the navigation history 134. As another example, if the client application 127 browses or navigates to a particular file directory structure 118, an indication of the directory file may be added to the navigation history 134. Similarly, if a client application 127 reads, updates, deletes, or otherwise modifies a file 117, an indication of the action applied to the file 117 can also be stored in the navigation history 134. The navigation history 134 can be stored as a sequential progression through the file system 116, or as a list of accessed files 117.

Navigation through the file system 116 can be performed according to gesture inputs to a touch screen or capacitive display 124 of the client device 104. For example, a gesture can direct the client application 127 to navigate to a sequentially preceding portion of the navigation history 134, or “go back” in the navigation history 134. A navigation state 136 indicating a currently accessed or browsed file directory structure 118 can be updated to the file directory structure 118 last accessed before the current file directory structure 118. For example, if the client application 127 is browsing a directory file, in response to the first gesture, the client application 127 can update the navigation state 136 to a previously browsed file directory structure 118. This can include, for example, a parent directory from which the client application 127 navigated to the currently browsed directory. Similarly, the client application 127 can also use a second gesture to navigate to a sequentially subsequent portion of the navigation history 134, or “go forward” in the navigation history 134. The gestures to “go back” and “go forward” through the navigation history 134 can include swipe gestures. In this example, the gesture to “go back” can correspond to a first direction, while the gesture to “go forward” can correspond to a second direction substantially opposite to the first direction.

The client application 127 can then request a sync operation be performed with respect to the file management system 114. This can be performed at a predefined interval, at a predefined time, in response to an indication from a user of the client application 127 to perform the sync, in response to a network 107 connection to the file management system 114 becoming available, or in response to other criteria. Performing the sync operation can include the client application 127 generating a sync request 137 indicating one or more file directory structures 118 for which metadata 138 will be downloaded. The metadata 138 can describe, for example, the contents of a file directory structure 118, such as a listing of the files, when the files were last accessed, a current version of the files, a history of who edited the files. The metadata 138 can also indicate corresponding permissions, states, or other attributes corresponding to the files 117 indicated in the metadata 138.

To generate the sync request 137, the client application 127 can access the navigation history 134 to identify file directory structures 118 browsed or data files 117 accessed by the client application 127. To this end, the client application 127 can filter the navigation history 134 used to generate the sync request 137. For example, the client application 127 can generate the sync request 137 using portions of the navigation history 134 created since a last sync operation. As another example, the client application 127 can generate the sync request 137 using portions of the navigation history 134 created within a predefined time period. As a result, the file directories which a user has recently accessed and therefore is more likely to access again can be updated with priority. Where systems include many users and files being edited, the directory structure itself can become large and the metadata regarding files within a particular directory can quickly fall out of date.

After identifying the file directory structures 118 or files 117 from the navigation history 134, the client application 127 generates the sync request 137 indicating the identified file directory structures 118 or files 117. The sync request 137 can also indicate an order or priority for downloading the metadata 138 in a sync response 141. For example, the priority of download can be based on a frequency or recency of access of the corresponding file 117 as indicated in the navigation history 134, with more recently accessed directories being updated first. The priority can also be based on attributes defining an importance or priority tier for a corresponding file directory structure 118 or file 117. In another example, the priority of file directory structures 118 or files 117 to update can be prioritized based on a user's location or a time of day. For example, when a synchronization request originating early in the morning while GPS information associated with the client device 104 indicates the user is at work can trigger a sync request for updated file directory structures 118 associated with the user's work environment. File directories that the user accessed on the previous day while at work can therefore be updated with priority. When the GPS information indicates the user has returned to home, file directory structures 118 associated with prior browsing history while a user is at home can be update with priority. In this manner, mobile browsing of file directory structures can be contextually aware to provide faster access for a user.

The client application 127 then communicates the sync request 137 to the file management system 114. The file management system 114 then generates a sync response 141 for communication to the client application 127. The generated sync response 141 includes the metadata 138 corresponding to the files 117 identified in the sync request 137 that fall within the identified file directory structure(s) 118. Thus, the sync response 141 includes metadata 138 corresponding to file directory structures 118 and files 117 navigated to according to the navigation history 134.

The sync response 141 can also include data encoding a delta between a version or instance of a file directory structure 118 or file 117 stored by the file management system 114 and a version or instance of a file directory structure 118 or file 117 stored on the client device 104. In some examples, files 117 of the file management system 114 can be indicated as required for download by a client device 104. In this example, the designated files 117 or updates for the designated files 117 can be included in the sync response 141 regardless of whether they were identified in the sync request 137. After obtaining the sync response 141, the client application 127 stores the contents of the sync response 141 in the client device 104. This can include writing new file directory structures 118 and files 117 to memory of the client device 104, or applying updates to stored instances of files 117.

Moving on to FIG. 2, shown is a pictorial diagram of example user interfaces 131 encoded by a client application 127 for rendering on a display 124 of a client device 104. Items 201 and 204 indicate examples of user interfaces for browsing a file system 116 accessible through a file management system 114. Item 207 is a text indication of a currently browsed “Work” file directory structure 118, nested within the “My Files,” “Projects,” and “First Quarter” file directory structures 118. Within the user interface 131 of item 201 is a user interface element 211 corresponding to a file directory structure 118 for the “Secret” directory. In this example, the “Secret” directory is included in the “Work” directory. Also in the user interface 131 of item 201 are user interface elements 214, 217, and 221, corresponding to data files 117 within the “Work” directory.

Item 224 is an exemplary text indication of a current navigation state 136 for the “First Quarter” directory, nested within the “My Files” and “Projects” directories. Within the user interface 131 of item 204 are user interface elements 227 and 231 corresponding to file directory structures 118 for the “Work” and “Personal” directories, respectively. In this example, the “Work” directory corresponds to the currently file directory structure 118 of the user interface 131 of item 201. Also in the user interface 131 of item 204 is a user interface element 234, corresponding to a data files 117 within the “First Quarter” directory.

The “Work” file directory structure 118 browsed in item 201 can be navigated to through the “First Quarter” file directory structure 118 browsed in item 204. Accordingly, a user can transition between item 201 and item 204 using a “go back” operation applied to a navigation history 134, as indicated by item 237. After doing so, a user can transition between item 204 and item 201 using a “go forward” operation applied to a navigation history 134, as indicated by item 241. The transitions indicated by items 237 and 241 can correspond to gesture inputs to a touch screen or capacitive display 124 rendering the user interfaces 131 of items 201 and item 204. Accordingly, these gesture inputs can correspond to swipe gestures, including swipe gestures in substantially opposite directions.

Turning now to FIG. 3, shown is a flowchart that provides one example of the operation of a portion of the client application 127. As an alternative, the flowchart of FIG. 3 can be viewed as depicting an example of elements of a method implemented in the client device 104 according to one or more examples

Beginning with step 301, the client application 127 detects a gesture input to a touch screen display 124 of the client device 104. Next, in step 304, the client application 127 determines a change to a navigation state 136 according to the gesture input. This can include, for example, determining whether one or more components of a directional vector of the gesture input meet or exceed a threshold. This can also include determining whether one or more components of the directional vector are positive of negative values, and selecting the change to the navigation state 136 based on the determining. For example, the client application 127 can determine whether the gesture input corresponds to a substantially left direction or substantially right direction. If the gesture input corresponds to a substantially left direction, the client application 127 can change the navigation state 136 to a sequentially preceding portion of a navigation history 134, which can be considered a “go back” operation in the navigation history 134. In this example, if the gesture input corresponds to a substantially right direction, the client application 127 can change the navigation state 136 to a sequentially subsequent portion of a navigation history 134, which can be considered a “go forward” operation in the navigation history 134.

After determining the change to the navigation state 136, the client application 127 modifies the navigation state 136 to reflect the determined change in step 307. In step 311, the client application 127 updates a user interface 131 to reflect the new navigation state 136. This can include rendering user interface elements corresponding to files 117 of a browsed file directory structure 118, after which the process ends.

Referring next to FIG. 4, shown is a flowchart that provides one example of the operation of a portion of the client application 127. As an alternative, the flowchart of FIG. 4 can be viewed as depicting an example of elements of a method implemented in the client device 104 according to one or more examples.

Beginning with step 401, the client application 127 can access a navigation history 134 to identify browsed file directory structures 181 or data files 117 accessed by the client application 127. To this end, the client application 127 can filter the navigation history 134 used to generate the sync request 137. For example, the client application 127 can filter the navigation history 134 to portions of the navigation history 134 created since a last sync operation. As another example, the client application 127 can filter the navigation history 134 to portions of the navigation history 134 created within a predefined time period. A synchronization operation can be requested by a user, performed automatically whenever a user accesses a new directory, or at predetermined intervals (e.g., every ten minutes once logged in, every time a user logs into the system, or every time a user navigates across a defined number of directories).

After identifying the file directory structures 118 and/or files 117 from the navigation history 134, in step 404, the client application 127 generates the sync request 137 indicating the identified file directory structures 118 and files 117. Then, in step 407, the client application 127 communicates the sync request 137 to the file management system 114. In step 411 the client application 127 obtains a sync response 141 from the file management system 114. In some examples, the sync response 141 can include an updated file directory structure 118, such as by providing metadata 138 associated with files 117 in the file directory structure 118 identified in the sync request 137. The sync response 141 can also include data encoding a delta between a version or instance of a file 117 stored by the file management system 114 and a version or instance of a file 117 stored on the client device 104. In some examples, the sync response 141 can also include files 117 or file 117 metadata indicated as being required for download, or otherwise designated. Once the initial sync response based on a user's navigation history 134 has been sent, in one example, a full sync can occur. For example, the file directory structures in a user's navigation history 134 can first be updated, and then a full sync of system file directory structures can be performed so that all directory structures can be updated. After obtaining the sync response 141, the process ends.

Although the client application 127, and other various systems described herein can be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same can also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components.

The flowcharts of FIGS. 3 and 4 show the functionality and operation of an implementation of portions of the client application 127. If embodied in software, each block can represent a module, segment, or portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that includes human-readable statements written in a programming language or machine code that includes numerical instructions recognizable by a suitable execution system such as a processor in a computer system or other system. The machine code can be converted from the source code. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function(s).

Although the flowcharts of FIGS. 3 and 4 show a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more blocks can be scrambled relative to the order shown. Also, two or more blocks shown in succession in FIGS. 3 and 4 can be executed concurrently or with partial concurrence. Further, in some examples, one or more of the blocks shown in FIGS. 3 and 4 can be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids. It is understood that all such variations are within the scope of the present disclosure.

Also, any logic or application described herein, including the client application 127, that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as, for example, a processor in a computer system or other system. In this sense, the logic can include, for example, statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system.

The computer-readable medium can include any one of many physical media such as, magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium would include magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium can be a random access memory (RAM) including, for example, static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device.

Further, any logic or application described herein, including the client application 127, can be implemented and structured in a variety of ways. For example, one or more applications described can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices in the same computing environment 103.

It should be emphasized that the above-described examples of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications can be made to the above-described example(s) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims

1. A non-transitory computer-readable medium embodying a program executable in at least one computing device, the program, when executed by the at least one computing device, being configured to cause the at least one computing device to at least: maintain a navigation history of a file management system by the at least one computing device;generate a sync request for the file management system based at least in part on a portion of a file system indicated in the navigation history; andcommunicate the sync request to the file management system.

2. The non-transitory computer-readable medium of claim 1, wherein the program is further configured to cause the at least one computing device to obtain at least one file from the file management system based on a designation of the at least one file as being required for download.

3. The non-transitory computer-readable medium of claim 1, wherein the navigation history indicates at least one folder of the file management system browsed by the at least one computing device, and the program is further configured to cause the at least one computing device to obtain at least an indication of a content of the at least one folder.

4. The non-transitory computer-readable medium of claim 1, wherein the navigation history indicates at least one file of the file management system accessed by the at least one computing device, and wherein the program is further configured to cause the at least one computing device to obtain the at least one file from the file management system.

5. The non-transitory computer-readable medium of claim 1, wherein the program is further configured to cause the at least one computing device to: generate a user interface depicting a current navigation state of the file management system; andmodify, in response to a gesture input to a display rendering the user interface, the current navigation state to a preceding navigation state or a subsequent navigation state.

6. The non-transitory computer-readable medium of claim 5, wherein the gesture input comprises a swipe gesture.

7. The non-transitory computer-readable medium of claim 6, wherein modifying the current navigation state comprises: modifying the current navigation state to the preceding navigation state in response to the swipe gesture corresponding to a first direction; andmodifying the current navigation state to the subsequent navigation state in response to the swipe gesture corresponding to a second direction substantially opposite to the first direction.

8. A system, comprising: a processor and instructions in memory that, when executed by the processor, cause the processor to at least: maintain a navigation history of a file management system by the at least one computing device;generate a sync request for the file management system based at least in part on a portion of a file system indicated in the navigation history; andcommunicate the sync request to the file management system.

9. The system of claim 8, wherein the instructions further cause the processor to obtain at least one file from the file management system based at least in part on a designation of the at least one file as being required for download.

10. The system of claim 8, wherein the navigation history indicates browsing of at least one folder of the file management system, and wherein the instructions further cause the processor to obtain at least an indication of a content of the at least one folder.

11. The system of claim 8, wherein the navigation history indicates at least one access of at least one file of the file management system, and wherein the instructions further cause the processor to obtain the at least one file from the file management system.

12. The system of claim 8, wherein the instructions further cause the processor to: render a user interface depicting a current navigation state of the file management system; andmodify, in response to a gesture input to a display rendering the user interface, the current navigation state to a preceding navigation state or a subsequent navigation state.

13. The system of claim 12, wherein the gesture input comprises a swipe gesture.

14. The system of claim 13, wherein modifying the current navigation state further comprises: modifying the current navigation state to the preceding navigation state in response to the swipe gesture corresponding to a first direction; andmodifying the current navigation state to the subsequent navigation state in response to the swipe gesture corresponding to a second direction substantially opposite to the first direction.

15. A method, comprising: maintaining a navigation history of a file management system by the at least one computing device;generating a sync request for the file management system based at least in part on a portion of a file system indicated in the navigation history; andcommunicating the sync request to the file management system.

16. The method of claim 15, further comprising obtaining at least one file from the file management system based at least in part on a designation of the at least one file as being required for download.

17. The method of claim 15, wherein the navigation history indicates browsing of at least one folder of the file management system, and wherein the method further comprises obtaining at least an indication of a content of the at least one folder.

18. The method of claim 15, wherein the navigation history indicates access of at least one file of the file management system, and the method further comprises obtaining the at least one file from the file management system.

19. The method of claim 15, further comprising: render a user interface depicting a current navigation state of the file management system; andmodifying, in response to a gesture input to a display rendering the user interface, the current navigation state to a preceding navigation state or a subsequent navigation state.

20. The method of claim 19, wherein modifying the current navigation state further comprises: modifying the current navigation state to the preceding navigation state in response to the gesture input corresponding to a first direction; andmodifying the current navigation state to the subsequent navigation state in response to the gesture input corresponding to a second direction substantially opposite to the first direction.