Patent Publication Number: US-8539512-B2

Title: Transactional environments for event and data binding handlers

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 13/234,375, filed Sep. 16, 2011, now U.S. Pat. No. 8,387,072 entitled “Transactional Environments for Event and Data Binding Handlers”, the contents of all of which are fully incorporated herein by reference. 
    
    
     BACKGROUND 
     Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. 
     Modern operating systems can provide interfaces for application processes and/or sub-processes, such as threads, to be informed of various events. Example events include a key press, a mouse click, expiration of a timer, and a data write operation. 
     To handle these events, application processes and/or sub-processes can invoke “handlers,” or software designed to process the events. Some application processes and/or sub-processes can have one handler, while other application processes and/or sub-processes have multiple handlers. 
     When a given event occurs, one or more handlers can be invoked by the operating system to process the event. These handlers often are executed asynchronously; that is, without any time ordering. 
     SUMMARY 
     In one aspect, a method is provided. One or more handlers are registered for a software application of a computing device. Each of the one or more handlers is configured to be executed upon receiving one or more indications of one or more triggering events. The software application is executed on the computing device using an actual environment of the software application. The computing device determines that a triggering event for the software application has occurred. In response to the triggering event, the computing device: (a) determines a handler environment for the triggering event, where the handler environment is based on the actual environment, (b) determines that one or more triggered handlers of the one or more registered handlers are to be executed, (c) makes available to each individual triggered handler at least a respective portion of the handler environment, (d) executes the one or more triggered handlers, where at least one triggered handler of the one or more triggered handlers updates its respective portion of the handler environment during execution, (e) after executing the one or more triggered handlers, determines an updated-handler environment based on the handler environment and the portions of the handler environments made available to the one or more triggered handlers, and (f) updates the actual environment based on the updated-handler environment. 
     In a second aspect, a computing device is provided. The computing device includes a processor and data storage. The data storage is configured to store at least computer-readable program instructions. The instructions are configured to, upon execution by the processor, cause the processor to perform functions comprising: (a) registering one or more handlers for a software application, where each of the one or more handlers is configured to be executed upon receiving one or more indications of one or more triggering events, (b) executing the software application using an actual environment of the software application, (c) determining that a triggering event for the software application has occurred, and (d) in response to the triggering event: (i) determine a handler environment for the triggering event, wherein the handler environment is based on the actual environment, (ii) determine that one or more triggered handlers of the one or more registered handlers are to be executed, (iii) make available to each individual triggered handler at least a respective portion of the handler environment, (iv) execute the one or more triggered handlers, wherein at least one triggered handler of the one or more triggered handlers updates its respective portion of the handler environment during execution, (v) after executing the one or more triggered handlers, determine an updated-handler environment based on the handler environment and the portions of the handler environments made available to the one or more triggered handlers, and (vi) update the actual environment based on the updated-handler environment. 
     In a third aspect, an article of manufacture is provided. The article of manufacture includes a computer-readable storage medium having instructions stored thereon that, in response to execution by a processor, cause the processor to perform functions. The instructions include: (a) instructions for registering one or more handlers for a software application, where each of the one or more handlers is configured to be executed upon receiving one or more indications of one or more triggering events, (b) instructions for executing the software application using an actual environment of the software application, (c) instructions for determining that a triggering event for the software application has occurred, and (d) instructions for, in response to the triggering event: (i) determining a handler environment for the triggering event, wherein the handler environment is based on the actual environment, (ii) determining that one or more triggered handlers of the one or more registered handlers are to be executed, (iii) making available to each individual triggered handler at least a respective portion of the handler environment, (iv) executing the one or more triggered handlers, wherein at least one triggered handler of the one or more triggered handlers updates its respective portion of the handler environment during execution, (v) after executing the one or more triggered handlers, determining an updated-handler environment based on the handler environment and the portions of the handler environments made available to the one or more triggered handlers, and (vi) updating the actual environment based on the updated-handler environment. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
       In the figures: 
         FIG. 1  depicts a distributed computing architecture in accordance with an example embodiment. 
         FIG. 2A  is a block diagram of a computing device in accordance with an example embodiment. 
         FIG. 2B  depicts a cloud-based server system in accordance with an example embodiment. 
         FIG. 3  is a block diagram of a software application architecture, in accordance with an example embodiment. 
         FIG. 4  depicts a user interface for a programmable device, in accordance with an example embodiment. 
         FIGS. 5A-5F  depict a handler invocation scenario, in accordance with an example embodiment. 
         FIG. 6  is a flow chart of a method, in accordance with an example embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Overview 
     Modern computer operating systems, such as the Android operating system used to control smart devices, can provide services for one or more software applications. One of these services involves allowing a software application to create a number of threads, or sub-processes, to perform various sub-tasks of the software application. Each of these threads can have a “handler” that processes messages related to the thread. The threads of the software application can be executed asynchronously, and therefore the handlers can run asynchronously. The operating system can run the software application in an “actual environment”, which includes the status of memory locations, and perhaps the status of devices and processors associated with the software application. 
     Various “triggering events” can occur in operating the smart devices and computers. One type of triggering event is a “device event”, or an event associated with part or the entire device, such as a touch pad/keyboard, radio antenna, display, power system, etc. Example device events include, but are not limited to, key presses, mouse movements and clicks, incoming phone calls, outgoing phone calls, power status changes, and display requests. Another type of triggering event is a “data event”, or an event associated with reading, writing, updating, and/or deleting one or more data items stored by the device. For example, changing a data value that corresponds to a ring tone can trigger a data event. 
     In some operating systems, a triggering event can start, or “trigger”, execution of multiple handlers on multiple threads. The triggered handlers may not be executed in a specified order. Also, triggering handlers may call each other, have “side effects” that go outside of the scope of the handler—e.g., performing input/output operations and changing global variables—and otherwise interact. As the order of execution of these multiple handlers is not pre-determined and the handlers can interact with each other, debugging software applications that have multiple handlers can be difficult. 
     To help manage this complexity, a common “handler environment” can be generated before a handler is called. The handler environment can be a partial or complete copy of the actual environment, depending on the size of the environment and the storage capacity of the smart device/computer running the software program. 
     Each handler can be invoked with its own partial or complete copy of the handler environment. As the handler executes and makes changes to its respective handler environment, the changes can be recorded as a list of transactions; e.g., read variable X, write object Y, etc. As each handler&#39;s respective handler environment is separate, the changes made by one handler to its handler environment will not affect a handler environment of another handler executing at the same time. When all handlers have completed executing, the transactions from each handler can be used to reconcile the various handler environments with each other and update the actual environment. After updating the actual environment, the software application can continue execution. 
     The following example technique can be used to execute handlers: 
     1. The source code of the handler can be analyzed to find variable references in the handler. 
     2. The argument lists of the handlers are overwritten to replace external references with references to proxy objects of the same name. 
     3. The software application is executed. 
     4. A triggering event occurs to cause invocation of one or more handlers, and so the software application is paused to let the handlers be invoked. 
     5. Handler environments are created before handler invocation. Each handler environment can include one or more proxy objects with fields that match the names of the properties of the original objects. 
     6. The proxy objects will then be passed to the handlers as actual arguments for parameters created in step 2. 
     7. The handlers are invoked and executed. 
     8. After execution of the handlers, changes in the handler environments are determined, perhaps as transactions, so that the actual environment can be updated. 
     9. If invoking the handler and/or updating the actual environment causes one or more additional handlers to be executed, return to step 5. 
     10. The software application execution continues with the updated actual environment. 
     Using the techniques described herein, handlers triggered by the same triggering event will see the same environment. Also, additional handlers that are “cascaded” or triggered by events after an initial triggering event will be executed only after the handlers triggered by the initial triggering event. Utilizing the procedures described herein, handlers can be executed in a more robust fashion with better data security. Thus, software applications will be executed more reliably, while facilitating the debugging of these software applications. Better data security during the execution of handlers can save both programming time and budget used to debug handlers. 
     Example Data Network 
     Turning to the Figures,  FIG. 1  shows server devices  108 ,  110  configured to communicate, via network  106 , with programmable devices  104   a ,  104   b , and  104   c . Network  106  may correspond to a LAN, a wide area network (WAN), a corporate intranet, the public Internet, or any other type of network configured to provide a communications path between networked computing devices. The network  106  may also correspond to a combination of one or more LANs, WANs, corporate intranets, and/or the public Internet. 
     Although  FIG. 1  only shows three programmable devices, distributed application architectures may serve tens, hundreds, or thousands of programmable devices. Moreover, programmable devices  104   a ,  104   b , and  104   c  (or any additional programmable devices) may be any sort of computing device, such as an ordinary laptop computer, desktop computer, network terminal, wireless communication device (e.g., a cell phone or smart phone), and so on. In some embodiments, programmable devices  104   a ,  104   b , and  104   c  may be dedicated to the design and use of software applications. In other embodiments, programmable devices  104   a ,  104   b , and  104   c  may be general purpose computers that are configured to perform a number of tasks and need not be dedicated to software development tools. 
     Server devices  108 ,  110  can be configured to perform one or more services, as requested by programmable devices  104   a ,  104   b , and/or  104   c . For example, server device  108  and/or  110  can provide content to programmable devices  104   a - 104   c . The content can include, but is not limited to, web pages, hypertext, scripts, binary data such as compiled software, images, audio, and/or video. The content can include compressed and/or uncompressed content. The content can be encrypted and/or unencrypted. Other types of content are possible as well. 
     As another example, server device  108  and/or  110  can provide programmable devices  104   a - 104   c  with access to software for database, search, computation, graphical, audio, video, World Wide Web/Internet utilization, and/or other functions. Many other examples of server devices are possible as well. 
     Computing Device Architecture 
       FIG. 2A  is a block diagram of a computing device (e.g., system) in accordance with an example embodiment. In particular, computing device  200  shown in  FIG. 2A  can be configured to perform one or more functions of server devices  108 ,  110 , network  106 , and/or one or more of programmable devices  104   a ,  104   b , and  104   c . Computing device  200  may include a user interface module  201 , a network-communication interface module  202 , one or more processors  203 , and data storage  204 , all of which may be linked together via a system bus, network, or other connection mechanism  205 . 
     User interface module  201  can be operable to send data to and/or receive data from external user input/output devices. For example, user interface module  201  can be configured to send and/or receive data to and/or from user input devices such as a keyboard, a keypad, a touch screen, a computer mouse, a track ball, a joystick, a camera, a voice recognition module, and/or other similar devices. User interface module  201  can also be configured to provide output to user display devices, such as one or more cathode ray tubes (CRT), liquid crystal displays (LCD), light emitting diodes (LEDs), displays using digital light processing (DLP) technology, printers, light bulbs, and/or other similar devices, either now known or later developed. User interface module  201  can also be configured to generate audible output(s), such as a speaker, speaker jack, audio output port, audio output device, earphones, and/or other similar devices. 
     Network-communications interface module  202  can include one or more wireless interfaces  207  and/or one or more wireline interfaces  208  that are configurable to communicate via a network, such as network  106  shown in  FIG. 1 . Wireless interfaces  207  can include one or more wireless transmitters, receivers, and/or transceivers, such as a Bluetooth transceiver, a Zigbee transceiver, a Wi-Fi transceiver, a WiMAX transceiver, and/or other similar type of wireless transceiver configurable to communicate via a wireless network. Wireline interfaces  208  can include one or more wireline transmitters, receivers, and/or transceivers, such as an Ethernet transceiver, a Universal Serial Bus (USB) transceiver, or similar transceiver configurable to communicate via a twisted pair wire, a coaxial cable, a fiber-optic link, or a similar physical connection to a wireline network. 
     In some embodiments, network communications interface module  202  can be configured to provide reliable, secured, and/or authenticated communications. For each communication described herein, information for ensuring reliable communications (i.e., guaranteed message delivery) can be provided, perhaps as part of a message header and/or footer (e.g., packet/message sequencing information, encapsulation header(s) and/or footer(s), size/time information, and transmission verification information such as CRC and/or parity check values). Communications can be made secure (e.g., be encoded or encrypted) and/or decrypted/decoded using one or more cryptographic protocols and/or algorithms, such as, but not limited to, DES, AES, RSA, Diffie-Hellman, and/or DSA. Other cryptographic protocols and/or algorithms can be used as well or in addition to those listed herein to secure (and then decrypt/decode) communications. 
     Processors  203  can include one or more general purpose processors and/or one or more special purpose processors (e.g., digital signal processors, application specific integrated circuits, etc.). Processors  203  can be configured to execute computer-readable program instructions  206   a  that are contained in the data storage  204  and/or other instructions as described herein. 
     Data storage  204  can include one or more computer-readable storage media that can be read and/or accessed by at least one of processors  203 . The one or more computer-readable storage media can include volatile and/or non-volatile storage components, such as optical, magnetic, organic or other memory or disc storage, which can be integrated in whole or in part with at least one of processors  203 . In some embodiments, data storage  204  can be implemented using a single physical device (e.g., one optical, magnetic, organic or other memory or disc storage unit), while in other embodiments, data storage  204  can be implemented using two or more physical devices. 
     Data storage  204  can include computer-readable program instructions  206   a , actual environment  206   b , and perhaps additional data. Actual environment  206   b  can store at least some of the data used by one or more processes and/or threads of a software application. In some embodiments, data storage  204  can additionally include storage required to perform at least part of the herein-described methods and techniques and/or at least part of the functionality of the herein-described devices and networks. 
     Cloud-Based Servers 
       FIG. 2B  depicts a network  106  of computing clusters  209   a ,  209   b ,  209   c  arranged as a cloud-based server system in accordance with an example embodiment. Server devices  108  and/or  110  can be cloud-based devices that store program logic and/or data of cloud-based applications and/or services. In some embodiments, server devices  108  and/or  110  can be a single computing device residing in a single computing center. In other embodiments, server device  108  and/or  110  can include multiple computing devices in a single computing center, or even multiple computing devices located in multiple computing centers located in diverse geographic locations. For example,  FIG. 1  depicts each of server devices  108  and  110  residing in different physical locations. 
     In some embodiments, data and services at server devices  108  and/or  110  can be encoded as computer readable information stored in tangible computer readable media (or computer readable storage media) and accessible by programmable devices  104   a ,  104   b , and  104   c , and/or other computing devices. In some embodiments, data at server device  108  and/or  110  can be stored on a single disk drive or other tangible storage media, or can be implemented on multiple disk drives or other tangible storage media located at one or more diverse geographic locations. 
       FIG. 2B  depicts a cloud-based server system in accordance with an example embodiment. In  FIG. 2B , the functions of server device  108  and/or  110  can be distributed among three computing clusters  209   a ,  209   b , and  208   c . Computing cluster  209   a  can include one or more computing devices  200   a , cluster storage arrays  210   a , and cluster routers  211   a  connected by a local cluster network  212   a . Similarly, computing cluster  209   b  can include one or more computing devices  200   b , cluster storage arrays  210   b , and cluster routers  211   b  connected by a local cluster network  212   b . Likewise, computing cluster  209   c  can include one or more computing devices  200   c , cluster storage arrays  210   c , and cluster routers  211   c  connected by a local cluster network  212   c.    
     In some embodiments, each of the computing clusters  209   a ,  209   b , and  209   c  can have an equal number of computing devices, an equal number of cluster storage arrays, and an equal number of cluster routers. In other embodiments, however, each computing cluster can have different numbers of computing devices, different numbers of cluster storage arrays, and different numbers of cluster routers. The number of computing devices, cluster storage arrays, and cluster routers in each computing cluster can depend on the computing task or tasks assigned to each computing cluster. 
     In computing cluster  209   a , for example, computing devices  200   a  can be configured to perform various computing tasks of electronic communications server  112 . In one embodiment, the various functionalities of electronic communications server  112  can be distributed among one or more of computing devices  200   a ,  200   b , and  200   c . Computing devices  200   b  and  200   c  in computing clusters  209   b  and  209   c  can be configured similarly to computing devices  200   a  in computing cluster  209   a . On the other hand, in some embodiments, computing devices  200   a ,  200   b , and  200   c  can be configured to perform different functions. 
     In some embodiments, computing tasks and stored data associated with server devices  108  and/or  110  can be distributed across computing devices  200   a ,  200   b , and  200   c  based at least in part on the processing requirements of server devices  108  and/or  110 , the processing capabilities of computing devices  200   a ,  200   b , and  200   c , the latency of the network links between the computing devices in each computing cluster and between the computing clusters themselves, and/or other factors that can contribute to the cost, speed, fault-tolerance, resiliency, efficiency, and/or other design goals of the overall system architecture. 
     The cluster storage arrays  210   a ,  210   b , and  210   c  of the computing clusters  209   a ,  209   b , and  209   c  can be data storage arrays that include disk array controllers configured to manage read and write access to groups of hard disk drives. The disk array controllers, alone or in conjunction with their respective computing devices, can also be configured to manage backup or redundant copies of the data stored in the cluster storage arrays to protect against disk drive or other cluster storage array failures and/or network failures that prevent one or more computing devices from accessing one or more cluster storage arrays. 
     Similar to the manner in which the functions of server devices  108  and/or  110  can be distributed across computing devices  200   a ,  200   b , and  200   c  of computing clusters  209   a ,  209   b , and  209   c , various active portions and/or backup portions of these components can be distributed across cluster storage arrays  210   a ,  210   b , and  210   c . For example, some cluster storage arrays can be configured to store the data of server device  108 , while other cluster storage arrays can store data of server device  110 . Additionally, some cluster storage arrays can be configured to store backup versions of data stored in other cluster storage arrays. 
     The cluster routers  211   a ,  211   b , and  211   c  in computing clusters  209   a ,  209   b , and  209   c  can include networking equipment configured to provide internal and external communications for the computing clusters. For example, the cluster routers  211   a  in computing cluster  209   a  can include one or more internet switching and routing devices configured to provide (i) local area network communications between the computing devices  200   a  and the cluster storage arrays  201   a  via the local cluster network  212   a , and (ii) wide area network communications between the computing cluster  209   a  and the computing clusters  209   b  and  209   c  via the wide area network connection  213   a  to network  106 . Cluster routers  211   b  and  211   c  can include network equipment similar to the cluster routers  211   a , and cluster routers  211   b  and  211   c  can perform similar networking functions for computing clusters  209   b  and  209   b  that cluster routers  211   a  perform for computing cluster  209   a.    
     In some embodiments, the configuration of the cluster routers  211   a ,  211   b , and  211   c  can be based at least in part on the data communication requirements of the computing devices and cluster storage arrays, the data communications capabilities of the network equipment in the cluster routers  211   a ,  211   b , and  211   c , the latency and throughput of local networks  212   a ,  212   b ,  212   c , the latency, throughput, and cost of wide area network links  213   a ,  213   b , and  213   c , and/or other factors that can contribute to the cost, speed, fault-tolerance, resiliency, efficiency and/or other design goals of the moderation system architecture. 
     Software Application Architecture 
       FIG. 3  is a block diagram of software application architecture  300 , in accordance with an example embodiment. In particular,  FIG. 3  shows software application architecture  300  that includes processes  302 ,  306 , event/environment coordinator  330 , device interface  340 , and actual environment  350 . Each of processes  302 ,  306  can perform one or more tasks as required by a software application. Example tasks include, but are not limited to tasks related to data processing, communications, resource management, simulations, modeling, and/or control systems. Many other example tasks are possible as well. 
     As depicted in  FIG. 3 , software application architecture  300  can represent one application utilizing two processes or two applications, each utilizing one process. More generally, software application architecture  300  enables execution of a plurality of applications, each application having one or more processes. 
       FIG. 3  shows process  302  with two threads  312   a ,  312   b  and process  306  with one thread  322   a . Each thread can be used to perform one or more sub-tasks for an associated process, where the sub-tasks can be related to the task(s) performed by the associated process. In general, software application architecture  300  enables each process to utilize zero or more threads to accomplish task(s). Threads can be created, destroyed, updated, and examined, among other operations. 
       FIG. 3  indicates that process  302  includes handler (H)  304   a , thread  312   a  includes handlers  314   a ,  316   a  and thread  312   b  includes handlers  314   b ,  316   b , as well as process  306  with two handlers  308   a ,  308   b  and thread  322   a  with handlers  324   a . Each handler can be configured to process one or more events, such as events  336  provided by event/environment coordinator  330 . 
     To associate a particular handler with a corresponding event, a thread or process can register a handler with event/environment coordinator  330  to be associated with the corresponding event. Then, upon an occurrence of the corresponding event, event/environment coordinator  330  can execute the registered handler to process the corresponding event for the thread or process. For example, thread  312   a  can register a handler, such as handler  314   a , with event/environment coordinator  330  to be associated with timer expirations. Then, upon expiration of a timer associated with thread  312   a , event/environment coordinator  330  can invoke handler  314   a  to process the timer expiration event. 
     In some embodiments, an occurrence of a “triggering event” can cause, or trigger, invocation of more than one handler. For example, a triggering event can cause invocation of multiple handlers of a single thread/process or invocation of one or more handlers for a plurality of threads/processes. As another example, the triggering event can cause invocation of one or more handlers, which can generate a “cascade” of one or more additional events. Each of the cascaded events can in turn cause the invocation one or additional handlers, which can in turn cause more cascaded event(s) to be generated. 
     In embodiments where multiple handlers can be invoked, event/environment coordinator  330  can be configured to ensure that the multiple handlers are executed in a more robust fashion with better data security. As one technique, the source code of the handlers can be modified to ensure data changes occur on copies of environments, rather than changing actual environment  350 . For example, source code of the handlers can be scanned and/or parsed to determine parameter, global variable, and/or local variable references. Then, some or all of the parameter, global variable, and/or local variable references in the handler source code can be replaced to refer to respective copies of the parameter(s), global variable(s), and/or local variable(s). The scanning and/or parsing of handler source code to replace references can be performed prior to execution of handler code; e.g., via compilation or pre-processing, and stored. Alternatively, reference replacement can take place during execution; e.g., as part of interpreting or otherwise executing handler code. 
     Then, event/environment coordinator  330  can ensure that all data accesses, such as reads and writes, performed by an invoked handler are performed on a copy of the actual environment, rather than on actual environment  350 . In particular embodiments, event/environment coordinator  330  can generate a partial or complete copy of the actual environment. Upon completion of the invoked handler, event/environment coordinator  330  can compare the copy of the actual environment with actual environment  350  or a pre-invocation copy of actual environment  350  to determine changes made by the invoked handler to actual environment  350 . 
     For example, suppose a handler H1 has the following pseudo code: 
     
       
         
           
               
               
             
               
                   
                 TABLE 1 
               
               
                   
                   
               
             
            
               
                   
                 private Handler H1 = new Handler(double[ ] A, int *count) { 
               
               
                   
                 // A is assumed to have at least count+1 data items 
               
               
                   
                   int i; 
               
               
                   
                   double val = 0; 
               
               
                   
                   Message Msg = obtainMessage( ); // get message from OS 
               
               
                   
                   for (i = 0; i &lt; *count; i++) { 
               
               
                   
                     val = val + (A[i]*A[i]); // sum of squares for A 
               
               
                   
                   } 
               
               
                   
                   A[*count] = val; // store the sum of squares within A 
               
               
                   
                   *count = *count + 1; // update the count 
               
               
                   
                   Msg.setData(val); // put sum of squares in message 
               
               
                   
                   Msg.sendMessage(H2); // send the message to handler H2 
               
               
                   
                   releaseMesssage(Msg); // return message to OS 
               
               
                   
                 } 
               
               
                   
                   
               
            
           
         
       
     
     Handler H1 has two parameters: A, which is an array, and count, which is a pointer to an integer. In some implementations, the parameter A is a pointer to an array. The parameter list can be updated to replace references to data items in the actual environment with copies of the data items. For example, suppose event/environment coordinator  330  maintains copies of (a pointer to) A and the pointer to count named CopyA and Copycount, respectively. 
     Then, the source code and argument lists of H1 can be analyzed to find references to data copied by event/environment coordinator  330 ; in this case, the analysis can find the parameters A and count of the argument list to H1. These references can be replaced with references to the copied data, respectively CopyA and Copycount. This analysis to find parameter references can be performed via scanning, parsing, and/or during code execution as discussed above. 
     Table 1 also shows that handler H1 declares three local variables: an integer i, a double precision variable val, and a Message Msg. H1 does not access any global variables. In some embodiments, the source code and argument lists of H1 can be analyzed to find references to globally and/or locally declared variables as well. In these embodiments, copies of some or all of the globally and/or locally variables declared within a handler are copied by event/environment coordinator  330  as well. In these embodiments, event/environment coordinator  330  can generate copies of the globally and/or locally declared variables as well, and replace references to the globally and/or locally declared variables to the copies of the globally and/or locally declared variables. This analysis to find globally and/or locally declared variable references can be performed via scanning, parsing, and/or during code execution as discussed above. 
     For example, the copies of i, val, and Msg can be referred to as Copyi, Copyval, and CopyMsg, respectively. In these embodiments, the copied locally declared variables can be accessed by a handler as global variables, as one or more additional parameters of the parameter list, or perhaps by some other technique. Also, the portion of handler code that declares the declared variables can then be modified or deleted so not to actually declare any variables. 
     Table 1AA shows handler H1AA, which is a modified version of handler H1. While H1 does not utilize global variables, H1AA utilizes two global variables: a global array AA that performs the role of the parameter A in handler H1, and a global integer “Invocation_Counter” that tracks the number of invocations of handler H1AA. Handler H1AA has the following pseudo code: 
     
       
         
           
               
               
             
               
                   
                 TABLE 1AA 
               
               
                   
                   
               
             
            
               
                   
                 global int Invocation_Counter = 0; 
               
               
                   
                 global double[ ] AA; 
               
               
                   
                 private Handler H1AA = new Handler(int *count) { 
               
               
                   
                    // AA is assumed to have at least count+1 data items 
               
               
                   
                   int i; 
               
               
                   
                   double val = 0; 
               
               
                   
                   Invocation_Counter++; // global variable 
               
               
                   
                   Message Msg = obtainMessage( ); // get message from OS 
               
               
                   
                   for (i = 0; i &lt; *count; i++) { 
               
               
                   
                     val = val + (AA[i]*AA[i]); // sum of squares for AA 
               
               
                   
                   } 
               
               
                   
                   AA[*count] = val; // store the sum of squares within AA 
               
               
                   
                   *count = *count + 1; // update the count 
               
               
                   
                   Msg.setData(val); // put sum of squares in message 
               
               
                   
                   Msg.sendMessage(H2); // send the message to handler H2 
               
               
                   
                   releaseMesssage(Msg); // return message to OS 
               
               
                   
                 } 
               
               
                   
                   
               
            
           
         
       
     
     In some embodiments, parameters and variable references, both local and global, can be replaced with references to copies of these parameters and variable references. For example, Table 2 shows handler H1 with both parameters in the argument list and variable references replaced with references to data copied by event/environment coordinator  330 . 
     
       
         
           
               
             
               
                 TABLE 2 
               
               
                   
               
             
            
               
                 // This is a version of handler H1 that utilizes 
               
               
                 // copies of parameters and local variables. 
               
               
                 // copies of declared variables now global for this example. 
               
               
                 int Copyi; 
               
               
                 double Copyval; 
               
               
                 Message CopyMsg; 
               
               
                 private Handler H1 = new Handler(double[ ] CopyA, int *Copycount) 
               
               
                 { 
               
               
                 // A is assumed to have at least count+1 data items 
               
               
                 // comment out variable declarations 
               
               
                 //  int i; 
               
               
                 //  double val = 0; 
               
               
                 // Message Msg = obtainMessage( ); // get message from OS 
               
               
                   // replace variable inits with equivalent global inits 
               
               
                   Copyval = 0; 
               
               
                   CopyMsg = obtainMessage( ); 
               
               
                   for (Copyi = 0; Copyi &lt; *Copycount; Copyi++) { 
               
               
                     Copyval = Copyval + (CopyA[i] * CopyA[i]); // sum of 
               
               
                 squares for A 
               
               
                   } 
               
               
                   CopyA[*Copycount] = Copyval; // store the sum of squares 
               
               
                 within A 
               
               
                   *Copycount = *Copycount + 1; // update the count 
               
               
                   CopyMsg.setData(Copyval); // put sum of squares in message 
               
               
                   CopyMsg.sendMessage(H2); // send the message to handler H2 
               
               
                   releaseMesssage(CopyMsg); // return message to OS 
               
               
                 } 
               
               
                   
               
            
           
         
       
     
     In other embodiments, references to global variables of the actual environment can be replaced with references to copies of the global variables. Table 2AA shows handler H1AA with global variable references replaced with references to data copied by event/environment coordinator  330 . 
     
       
         
           
               
               
             
               
                   
                 TABLE 2AA 
               
               
                   
                   
               
             
            
               
                   
                 // This is a version of handler H1AA with global 
               
               
                   
                 // variable references replaced with references to copies of 
               
               
                   
                 // the global variables. 
               
               
                   
                 // copies of global variables declared globally as well. 
               
               
                   
                 global int CopyInvocation_Counter = 0; 
               
               
                   
                 global double[ ] CopyAA; 
               
               
                   
                 private Handler H1AA = new Handler(int *count) { 
               
               
                   
                    // AA is assumed to have at least count+1 data items 
               
               
                   
                   int i; 
               
               
                   
                   double val = 0; 
               
               
                   
                   // comment out global references 
               
               
                   
                   // Invocation_Counter++; // global variable 
               
               
                   
                   // replace global references with environment references 
               
               
                   
                   CopyInvocation_Counter++; 
               
               
                   
                   Message Msg = obtainMessage( ); // get message from OS 
               
               
                   
                   for (i = 0; i &lt; *count; i++) { 
               
               
                   
                   //  val = val + (AA[i]*AA[i]); // sum of squares for AA 
               
               
                   
                       val = val + (CopyAA[i]*CopyAA[i]); // sum of squares 
               
               
                   
                 for AA 
               
               
                   
                   } 
               
               
                   
                   // AA[*count] = val; // store the sum of squares within AA 
               
               
                   
                   CopyAA[*count] = val; // store the sum of squares within AA 
               
               
                   
                   *count = *count + 1; // update the count 
               
               
                   
                   Msg.setData(val); // put sum of squares in message 
               
               
                   
                   Msg.sendMessage(H2); // send the message to handler H2 
               
               
                   
                   releaseMesssage(Msg); // return message to OS 
               
               
                   
                 } 
               
               
                   
                   
               
            
           
         
       
     
     As a software application with handler H1 or H1AA is executed, a triggering event causes H1 or H1AA to be invoked. Prior to invoking handler H1, event/environment coordinator  330  generates a copy of actual environment  350 , including at least, copies of CopyA and Copycount, and copies of variables declared for H1—in this example, Copyi, Copyval, and CopyMsg. Prior to invoking handler H1AA, event/environment coordinator  330  generates a copy of actual environment  350 , including at least copies of AA and CopyInvocation_Counter. Then, event/environment coordinator  330  can invoke H1 or H1AA, which in turn will use the respective copies of the declared and/or global variables. 
     Note that any initializations performed as part of a new global or local variable declaration, such as double val=0, which declares a double precision number val as a new variable and initializes val to 0− can be performed on the respective copies of the declared global or local variables. These lines of the pseudo code of Table 2 perform initializations on the global variable copies of the declared local variables of handler H1 that are equivalent to the initializations performed as part of variable declarations. 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 // replace variable inits with equivalent global inits 
               
               
                   
                 Copyval = 0; 
               
               
                   
                 CopyMsg = obtainMessage( ); 
               
               
                   
                   
               
            
           
         
       
     
     Consequently, H1 executes by operating on the CopyA and Copycount data. After H1 completes, event/environment coordinator  330  can determine the changes made to the CopyA and Copycount data. In this example, this involves the data updates made by the following two lines in the pseudo-code of Table 2: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                   CopyA[*Copycount] = Copyval; // store the sum of squares 
               
               
                   
                 within A 
               
               
                   
                   *Copycount = *Copycount + 1; // update the count 
               
               
                   
                   
               
            
           
         
       
     
     Event/environment coordinator  330  can determine that two updates to actual environment  350  need to be made based on execution of H1: 
     (1) A[*count]=CopyA[*count] and 
     (2)*count=*Copycount. 
     In this example, the following two lines of pseudo code in H1 will, upon execution, invoke another handler H2: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 CopyMsg.setData(Copyval); // put sum of squares in message 
               
               
                   
                 CopyMsg.sendMessage(H2); // send the message to handler H2 
               
               
                   
                   
               
            
           
         
       
     
     Prior to invoking H2, event/environment coordinator  330  can perform the updates to actual environment  350 , copy any parameters and/or declared variables used by H2 from actual environment  350  after the updates, and invoke H2 to operate on CopyMsg. 
     Similarly, handler H1AA executes by operating on the copies of global variables CopyAA that is a copy of the AA array, and CopyInvocation_Counter that is a copy of the Invocation_Counter global integer variable. After H1AA completes, event/environment coordinator  330  can determine the changes made to the CopyAA and CopyInvocation_Counter variables. In this example, this involves the data updates made by the following line in the pseudo-code of Table 2AA: 
     CopyInvocation_Counter++; 
     Event/environment coordinator  330  can determine that one update to actual environment  350  needs to be made based on execution of H1AA: 
     (1) CopyInvocation_Counter++ 
     For each execution of the following loop, 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 for (i = 0; i &lt; *count; i++) { 
               
               
                   
                 //  val = val + (AA[i]*AA[i]); // sum of squares for AA 
               
               
                   
                     val = val + (CopyAA[i]*CopyAA[i]); // sum of squares 
               
               
                   
                 for AA 
               
               
                   
                 } 
               
               
                   
                   
               
            
           
         
       
     
     event/environment coordinator  330  can determine that one or perhaps two reads of the CopyAA array with index i are performed. Also, upon execution of the following line of pseudo-code: 
     CopyAA[*count]=val; //store the sum of squares within AA 
     event/environment coordinator  330  can determine that one write to the CopyAA array array with index*count is performed. 
     In the H1AA example, the following two lines of pseudo code will, upon execution, invoke another handler H2: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 Msg.setData(val); // put sum of squares in message 
               
               
                   
                 Msg.sendMessage(H2); // send the message to handler H2 
               
               
                   
                   
               
            
           
         
       
     
     Prior to invoking H2 from handler H1AA, event/environment coordinator  330  can perform the updates to actual environment  350 , copy any parameters and/or variables used by H2 from actual environment  350  after the updates, and invoke H2 to operate on Msg. 
     In some embodiments, actual environment  350  can be updated using atomic transactions; e.g., actual environment  350  can include a database system configured to perform data changes in a deterministic fashion by applying transactions atomically, consistently, durably, and in an isolated fashion. In these embodiments, event/environment coordinator  330  can generate one or more atomic data transactions corresponding to the determined changes, and apply those transactions to actual environment  350 . 
     For example, the data accesses performed by H1 shown in Table 2 on the parameters Copycount and CopyA would include: 
     1. For each iteration of the “for (Copyi=0; Copyi&lt;*Copycount; Copyi++)” loop, *Copycount may be read once to perform the comparison of Copyi and *Copycount. In some embodiments, after the first read of *Copycount, the value of *Copycount can be stored in a register, cache, or other memory location and/or is optimized to only perform one read of *Copycount to perform all loop iterations. 
     2. For the loop body, which is the “Copyval=Copyval+(CopyA [i]*CopyA [i]);” statement, either one or two reads of the CopyA[i] variable are performed. One read of the CopyA[i] variable may be performed in implementations that store the CopyA[i] value, after the first read, in a register, cache, or other memory location and/or is optimized to only perform one read of CopyA[i], while in other implementations, two reads of the CopyA[i] are required. 
     3. For the “CopyA [*Copycount]=Copyval” statement, *Copycount is read once and CopyA[*Copycount] is written once. 
     4. For the “*Copycount=*Copycount+1” statement, *Copycount is read once and then written once. 
     Assuming no optimizations, the read and write operations when *Copycount=2 performed by H1 may be 
     One read of *Copycount for the comparison when i=0, which succeeds. 
     Two reads of CopyA[0] in the loop body. 
     One read of *Copycount for the comparison when i=1, which succeeds. 
     Two reads of CopyA[1] in the loop body. 
     One read of *Copycount for the comparison when i=2, which fails as *Copycount=2. 
     One read of *Copycount and one write of CopyA[2] in the “CopyA [*Copycount]=Copyval” statement. 
     One read and one write of *Copycount for the “*Copycount=*Copycount+1” statement. 
     Event/environment coordinator  330  can then convert this series of read and write operations on the copied variables into a list of one or more corresponding transactions on data in the actual environment. For example, the following example transaction list, corresponds to un-optimized transactions performed by handler H1 when *count=2, and thus *Copycount=2: 
     Read(*count) 
     Read(A[0]) 
     Read(A[0]) 
     Read(*count) 
     Read(A[1]) 
     Read(A[1]) 
     Read(*count) 
     Write(A[*count], *count)//store the value of *count at A[*count] 
     Read(*count) 
     Write(*count, *count+1)//store the value of *count+1 at *count 
     As another example, suppose handler H1AA shown in Table 2AA was executed. The data accesses performed by H1AA shown in Table 2AA on the variables CopyInvocation_Counter and CopyAA would include: 
     1. For the CopyInvocation_Counter++; statement, which is equivalent to the statement CopyInvocation_Counter=CopyInvocation_Counter+1, one read and one write access of the CopyInvocation_Counter variable are required. 
     2. For each iteration of the “for (i=0; i&lt;*count; i++)” loop, the loop body is executed. In the loop body, which is the “val=val+(CopyAA [i]*CopyAA [i]);” statement, either one or two reads of the CopyAA [i] variable are performed. One read of the CopyAA [i] variable may be performed in implementations that store the CopyAA [i] value, after the first read, in a register, cache, or other memory location and/or is optimized to only perform one read of CopyAA [i], while in other implementations, two reads of CopyAA [i] are required. 
     3. For the “CopyAA [*count]=val” statement, CopyAA [*count] is written once. 
     Assuming no optimizations, the read and write operations when *count=2 performed by H1AA may be 
     One read of CopyInvocation_Counter. 
     One write of CopyInvocation_Counter. 
     One or two reads of CopyAA [0] in the loop body. 
     One read of *count for the comparison when i=1, which succeeds. 
     One or two reads of CopyAA [1] in the loop body. 
     One read of *count for the comparison when i=2, which fails as *count=2. 
     One write of CopyAA [2] for the “CopyAA [*count]=val” statement. 
     Event/environment coordinator  330  can then convert this series of read and write operations on the copied variables into a list of one or more corresponding transactions on data in the actual environment. For example, the following example transaction list, corresponds to un-optimized transactions performed by handler H1AA when *count=2: 
     Read(CopyInvocation_Counter) 
     Write(CopyInvocation_Counter, 
     CopyInvocation_Counter+1)//store value of CopyInvocation_Counter+1 as CopyInvocation_Counter 
     Read(CopyAA [0]) 
     Read(CopyAA [0])) 
     Read(CopyAA [1]) 
     Read(CopyAA [1]) 
     Write(CopyAA[*count], val)//store the value of val at CopyAA[*count] 
     These transactions can be performed atomically to read and write data in actual environment  328 . The use of atomic transactions ensure each read or write transaction for a given data item completes before any competing write, and perhaps read, transactions for the given data item take place. Many other generated transactions, including examples with transactions involving declared variables, are possible as well. 
     In other embodiments, event/environment coordinator  330  can track cascaded events and ensure deterministic execution of cascaded events. For example, event/environment coordinator  330  can ensure that a handler for an event, once invoked, runs to completion before processing any events cascading from the handler invocation, such as mentioned above in the example where handler H2 was not invoked until handler H1 had completed. 
     Any cascaded events can be executed using a deterministic ordering scheme, such as a first-in-first-out (FIFO) scheme, a last-in-first-out (LIFO) scheme, or other deterministic ordering scheme. In some embodiments, each handler invoked on a cascaded event can be executed using a copy of the actual environment as modified by any completed handlers, such as discussed in the example of Tables 1 and 2 above. In other embodiments, the handler invoked on a cascaded event can be executed using a copy of the actual environment prior to any modifications by any completed handlers; e.g., a copy of the “original” actual environment. 
     In some embodiments, “cycles” of handlers can be executed, detected, reported, and or broken. A cycle of handlers involves a first handler HC1, calling a second handler HC2, and so on, until some handler calls HC1 (or another previously called handler) for a second time. For example, suppose HC1 calls HC2, which in turn calls HC1 again, leading to a calling chain of HC1-&gt;HC2-&gt;HC1, with a cycle between HC1 and HC2. As another example, suppose HC1 calls HC2, HC2 calls a third handler HC3, which in turn calls a fourth handler HC4, which in turn calls HC2. The corresponding calling chain would be HC1-&gt;HC2-&gt;HC3-&gt;HC4-&gt;HC2, and a cycle between HC2-&gt;HC3-&gt;HC4-&gt;HC2. 
     Cycle-detection algorithms can be used to detect cycles in calling chains. For example, event/environment coordinator  330  or another entity within software application architecture  300  can execute a cycle detection algorithm to detect a cycle of handler calls. Once detected, the cycle of handler calls can be: (a) executed and perhaps ignored as cycles are valid programming constructs, (b) broken by terminating execution of a handler within the cycle of handler calls, and/or (c) reported as being executed or being broken. 
     In some embodiments, event/environment coordinator  330  can track side effects, such as interactions with input/output devices, allocation/deallocation of shared resources, and modifications to global variables. For example, in some embodiments, the following line of handler H1 of Table 1 calls an “obtainMessage( )” function, which can cause allocation of a shared pool of messages: 
     CopyMsg=obtainMessage ( ); 
     In these embodiments, the analysis to find declared variable references and parameters, can be expanded to include an analysis to find references related to side effects, such as, but not limited to, functions, methods, and/or operators for performing input/output operations and/or shared resource allocation/deallocation and names of global variables. Then, the references related to side effects can be replaced with references to an environment controlled by event/environment coordinator  330 . 
     For example, references to operations for input/output devices can be replaced with operations to virtual devices and/or device queues. That is, the operation to be performed on an actual device can be placed into a queue to be performed along with transactions performed on the environment. In the case of allocation of resources and global variables, event/environment coordinator  330  can either provide resources, such as memory and copies of global variables using an environment copy—e.g., the “obtainMessage( )” function call can be replaced with an function call such as “obtainCopyMessage( )”. The obtainCopyMessage( ) function can allocate a message from a copy of the actual environment rather than from actual environment  350 . 
     As another example, global variable references can be processed in a similar fashion to parameter and declared variable accesses. For example, let CURRENT_PROCS track a number of processes (running and idle) that utilize software application architecture  300  in software application architecture  300 . Then, a reference to the CURRENT_PROCS variable within a handler, such as H1, can be replaced with a reference to a copy of the global variable maintained by event/environment coordinator  330 . Also or instead, a transaction corresponding to the reference to the global variable can be added to the transaction list, and the transaction carried out with the other transactions in the transaction list. 
     For requests for input/output operations, these requests can be queued until event/environment coordinator  330  determines that operations on actual environment can be performed. In some embodiments, the queued requests can be ordered with operations, such as transactions, performed on actual environment  350 . 
     For example, take the following three lines of H1AA as shown in Table 2AA: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 CopyAA[*count] = val; // store the sum of squares within A 
               
               
                   
                 *count = *count + 1; // update the count 
               
               
                   
                 Msg.setData(val); // put sum of squares in message 
               
               
                   
                   
               
            
           
         
       
     
     which, when executed, lead to the last transaction in the un-optimized list of transactions shown above: 
     Write(CopyAA[*count], val)//store the value of val at CopyAA[*count] 
     Then, suppose these three lines of code were updated as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                   Print(“AA[count−1]  =  “,  CopyAA[*count−1]);  //print 
               
               
                 AA[count−1] 
               
               
                   CopyAA[*count] = val; // store the sum of squares within A 
               
               
                   *count = *count + 1; // update the count 
               
               
                   Print(“AA[count−1]  =  “,  CopyAA[*count−1]);  //print 
               
               
                 AA[count−1] = sum of squares 
               
               
                   Msg.setData(val); // put sum of squares in message 
               
               
                   
               
            
           
         
       
     
     Then, the last transaction of the un-optimized list shown above which relate to the original three lines of H1AA can be updated to include input/output operations, such as shown in the example below: 
     Read(CopyAA [−1]);)//for the first new print statement 
     Print(“AA[count−1]=”, CopyAA [*count−1]);)//carry out the first print statement 
     Write(CopyAA [*count], val)//previous transaction 
     Read(CopyAA [*count−1])//for the second new print statement 
     Print(“count=”, CopyAA [*count−1])//carry out second print statement 
     Many other examples of side effects and techniques for handling side effects are possible as well. 
       FIG. 3  shows examples of events  336  including device events  332  and data events  334 . Device events  332  can be generated in response to information provided about one or more devices via device interface  340 , such as information about input/output operations, interrupts, device status reports, and requested information. Other types of information can be provided via device events  332  as well. 
     Data events  334  can be generated in response to one or more operations performed on one or more specified data items typically stored in and associated with actual environment  350 . For example, recall that the CURRENT_PROCS global variable mentioned above tracks a number of processes that utilize software application architecture  300 , and for a given process, a data item, PROC_DATA_ITEM, in a table of PROC_DATA_ITEMS is used to store information about the given process. A data event can be generated when CURRENT_PROCS is read or changed, and/or when one or more PROC_DATA_ITEMS are read, updated, deleted, or inserted. Many other examples of device events  332  and/or data events  334  are possible as well. 
     In some embodiments, events can be generated by a software application. For example, a handler, after processing a message treated as an event, can send one or more messages to other handler(s), which in turn can treat the received message(s) as event(s) and process these events. Many other examples are possible as well. 
       FIG. 4  depicts user interface  400  for a programmable device, in accordance with an example embodiment. User interface  400  can be generated and used by the programmable device, such as one or more of programmable devices  104   a - 104   c . In some embodiments, user interface  400  can be part of a larger user interface, for example, a user interface configured to permit review, updating, and changing settings for a programmable device, or, more generally, a user interface configured to control the programmable device. 
     User interface  400  can be displayed on the programmable device and may be updated based on received input; for example, input received via user interface  400 . To receive input, user interface  400  can be associated with one or more keyboards, keypads, touch screens, computer mice, track balls, joysticks, cameras, voice recognition modules, and/or other similar devices, such as via user interface module  201 . For example, user interface  400  can be displayed on a display of a smart phone, with a touch screen overlaying the display, and can receive inputs as one or more touches of the touch screen. 
     In this example, user interface  400  is divided by header  410  and sub-headers  412 ,  414 ,  416 , and  418 .  FIG. 4  shows that header  410  indicates user interface  400  is for “Sound Setup” with “General” sound-setup items of user interface  400  displayed under sub-header  412 . Similarly,  FIG. 4  shows that calling-sound sound-setup items are displayed under sub-header  414  of “Sounds when Someone Calls You,” and text-sound sound-setup items are displayed under sub-header  416  of “Sounds when Someone Texts You,” and “Feedback” sound-setup items are displayed under sub-header  418 . 
     General sound-setup items, as depicted in  FIG. 4 , include sound activity sound-setup item  422 , volume sound-setup item  424 , and vibrate sound-setup item  426 . Calling-sound sound-setup items, as depicted in  FIG. 4 , include phone-ringtone sound-setup item  442 , quiet-on-pickup sound-setup item  444 , and pocket-mode sound-setup item  446 . Additionally,  FIG. 4  depicts text-sound sound-setup items with notification-tone sound-setup item  462  and feedback sound-setup items with audible-touch-tones sound-setup item  482 . 
     Sound activity sound-setup item  422  includes a menu indicator (MI)  422   a , depicted in  FIG. 4  as a downward-pointing triangle within a circle. Menu indicator  422   a , when activated, can cause user interface  400  to display additional items for sound activity sound-setup item  422 , such as different types of sound profiles for possible selection. While not depicted in  FIG. 4 , additional items can be displayed via an additional dialog, such as a pop-up, and/or as additional sound-setup items. 
     Vibrate sound-setup item  426  includes a check box (CB)  426   a , depicted in  FIG. 4  as a white check-mark inside a square, indicate that corresponding vibrate sound-setup item  426  is not selected; i.e., the programmable device will not vibrate for calls or notifications. In contract, check box  444   a  is shown with a black check-mark inside a square, indicate that corresponding quiet-on-pickup sound-setup item  444  is selected; i.e., ringing volume will be reduces when the programmable device moves. 
     User interface  400  is just one example of a portion of a user interface that a smart phone, programmable device, and/or computing device can provide using a corresponding software application. Many other examples of user interfaces for smart phones, programmable devices, and/or computing devices are possible as well. 
       FIGS. 5A-5F  depict an example handler invocation scenario  500 , in accordance with an example embodiment.  FIG. 5A  shows that scenario  500  begins with triggering event  510  when a person touches the programmable device on check-box  426   a  of user interface  400 .  FIG. 5A  shows that check-box  426   a  with a white check-mark, indicating that corresponding vibrate sound-setup item  426  is not selected. 
       FIG. 5B  shows an example software application  520  utilizing software application architecture  300 , with processes  522 ,  524 , device interface  526 , actual environment  528 , and event/environment coordinator  530 . Communication process  522  has two threads,  522   a  and  522   c , and a handler H  522   e . Thread  522   a  has a handler  522   b  and thread  522   c  has a handler  522   d . User interface (UI) process  524  has one thread  524   a  with one handler  524   b , and a handler  524   c  for user interface process  524 . 
     In scenario  500 , thread  522   a  is utilized by communication process  522  to process telephone calls, and thread  522   a  uses handler  522   b  to process events for telephone calls. Similarly, thread  522   c  is utilized by communication process  522  to process text messages, and thread  522   c  uses handler  522   d  to process events for text messages. Also, user interface process  524  administers a user interface that includes user interface  400 , and handler  524   b  is configured to process events for the user interface. 
     In scenario  500 , both communication process  522  and user interface process  524  have registered handlers. In particular, thread  522   a  has registered handler  522   b  to handle click events, thread  522   c  has registered handler  522   d  to handle click events, and thread  524   a  has registered handler  524   b  to handle data events. Also, the source code of all handlers utilized in scenario  500  have been updated to operate on copies of parameters and declared variables, such as discussed above in the context of  FIG. 3 . 
     Triggering event  510  can be detected via a touch screen or similar device. As such, triggering event  510  can be generated by device interface  526  related to the touch screen. Upon reception of triggering event  510 , event/environment coordinator  530  can determine that two handlers—handlers  522   b  and  522   d —are registered to process triggering event  510  as a click event. 
     Event/environment coordinator  530  can generate copy request  532  for copies of part or all of actual environment  528 . In some embodiments, only one copy is used for all handlers, while in other embodiments, a separate copy is made for each handler to be invoked. In particular embodiments where separate copies are made, each copy is the same, such as when a copy of the entire actual environment  528  is provided to the handler; while in other embodiments, each copy can differ depending on the handler, such as providing a copy of all data referenced directly by the given handler. 
     In response, event/environment coordinator  530  receives copy response  534  with the requested copies of actual environment  528 . In some embodiments, a separate copy request can be provided to actual environment  528  for each copy. In other embodiments, event/environment coordinator  530  includes the functionality to perform copies of actual environment  528  directly; e.g., without use of copy request  532  or copy response  534 . 
     Event/environment coordinator  530  can generate two copies of the click event, shown in  FIG. 5B  as respective click events  512   b  and  512   d . Click event  512   b  has includes Copy1, which is a copy of actual environment  528 , and click event  512   b  includes a separate copy, Copy2, of actual environment  528 . Upon reception of click event  512   b , thread  522   a  can invoke handler  522   b  to process click event  512   b . Similarly, upon reception of click event  512   d , thread  522   c  can invoke handler  522   d  to process click event  512   d . In some embodiments, only one of handlers  522   b  and  522   d  is invoked at one time, while in other embodiments, multiple handlers are invoked and executed simultaneously, perhaps with each handler operating on their own copy of actual environment  528 . In all embodiments, handlers  522   b  and  522   d  are executed deterministically. 
       FIG. 5C  shows that scenario  500  continues with handler  522   b  processing click event  510 , in part, by sending message  536   b  to update a “Vib.phone” value of a name table to “YES.” Similarly, handler  522   d  processes click event  510 , in part, by sending message  536   d  to update the “Vib.txt” value of the name table to “YES.” 
       FIG. 5D  shows that scenario  500  proceeds with handler  522   b  sending handler complete (HC) message  538   b  to event/environment coordinator  530 , and handler  522   d  sending handler complete message  538   d  to event/environment coordinator  530 . In response, event/environment coordinator  530  generates write request  540  to update actual environment  528  to at least update the Vib.phone and Vib.txt values of the name table as respectively indicated by handlers  522   b  and  522   d.    
     In response, actual environment  528  sends write response  542  indicating that actual environment  528  has been updated with at least the values for Vib.phone and Vib.txt for the name table. In scenario  500 , handler  524   b  is registered to process data events when the name table has been changed. Therefore, in response to write response  542 , event/environment coordinator  530  generates a data event  548  (“DataEvt” as shown in  FIG. 5D ) and sends data event  548  with a copy of the name table (“CopyNT” as shown in  FIG. 5D ) to handler  524   b . In some embodiments, the name table can be an object, and the copy of the name table can be a copy of the object. In still other embodiments, event/environment coordinator  530  can make a copy of the name table and provide a pointer to the copy of the name table in data event  548 . 
     The copy made by event/environment coordinator  530  can be a shallow copy or a deep copy. For example, suppose that the name table is an object, defined using the pseudo code of Table 3 below: 
     
       
         
           
               
               
             
               
                   
                 TABLE 3 
               
               
                   
                   
               
             
            
               
                   
                 Public class NameTable { 
               
               
                   
                   int NumEntries; 
               
               
                   
                   NameEntry data[ ]; 
               
               
                   
                   Public class NameEntry { 
               
               
                   
                     String name; 
               
               
                   
                     String type; 
               
               
                   
                     String str_val; 
               
               
                   
                     int int_val; 
               
               
                   
                     void init( ) { 
               
               
                   
                      name = “”; 
               
               
                   
                      type = “”; 
               
               
                   
                      str_val = “”; 
               
               
                   
                      int_val = 0; 
               
               
                   
                     } 
               
               
                   
                     int get_int_val( ) { 
               
               
                   
                      if (type == “INT”) 
               
               
                   
                       return (int_val); 
               
               
                   
                      else 
               
               
                   
                       return (−1); 
               
               
                   
                     } 
               
               
                   
                     String get_string_val( ) { 
               
               
                   
                      if (type == “STRING”) 
               
               
                   
                       return (str_val); 
               
               
                   
                      else 
               
               
                   
                       return (NULL); 
               
               
                   
                     } 
               
               
                   
                    } // end of class NameEntry 
               
               
                   
                    // create a table of size num_ent 
               
               
                   
                    void CreateEntries(int num_ent) { 
               
               
                   
                      int i; 
               
               
                   
                      int datasize = sizeof(NameEntry) * num_ent; 
               
               
                   
                      // allocate data for the table 
               
               
                   
                      data = (NameEntry [ ]) allocate(datasize); 
               
               
                   
                      if (data == NULL) // if fail 
               
               
                   
                        exit( ); // quit 
               
               
                   
                      // here only if successfully allocated table 
               
               
                   
                      num_entries = num_ent; 
               
               
                   
                      // initialize each new entry 
               
               
                   
                      for (i = 0; i &lt; num_entries; i++) 
               
               
                   
                      data[i].init( ); 
               
               
                   
                    } 
               
               
                   
                    // do a shallow copy of the instant object to p 
               
               
                   
                    void ShallowCopy(NameTable *p) 
               
               
                   
                    { 
               
               
                   
                     p-&gt;num_entries = num_entries; 
               
               
                   
                     p-&gt;data = data; 
               
               
                   
                    } 
               
               
                   
                    // do a deep copy of the instant object to p 
               
               
                   
                    void DeepCopy(NameTable *p) 
               
               
                   
                    { 
               
               
                   
                      // calculate size of new data array 
               
               
                   
                      int i, datasize = sizeof(NameEntry) * num_entries; 
               
               
                   
                      // allocate storage for the copy of the name table. 
               
               
                   
                      p-&gt;data = (NameEntry [ ]) allocate(datasize); 
               
               
                   
                      // if allocation unsuccessful, exit 
               
               
                   
                      if (p-&gt;data == NULL) 
               
               
                   
                      exit( ); 
               
               
                   
                      // copy data 
               
               
                   
                      p-&gt;num_entries = num_entries; 
               
               
                   
                      // copy each DataEntry into the allocated storage 
               
               
                   
                      for (i = 0; i &lt; p-&gt;num_entries; i++) 
               
               
                   
                      { 
               
               
                   
                       p-&gt;data[i].name = data[i].name; 
               
               
                   
                       p-&gt;data[i].type = data[i].type; 
               
               
                   
                       p-&gt;data[i].str_val = data[i].str_val; 
               
               
                   
                       p-&gt;data[i].int_val = data[i].int_val; 
               
               
                   
                       } 
               
               
                   
                      } 
               
               
                   
                    // additional operations for the NameTable... 
               
               
                   
                   } 
               
               
                   
                   
               
            
           
         
       
     
     As indicated by the pseudo code of Table 3, a shallow copy copies all items at a top level of an object (or data structure), but does not make copies of objects below the top level. In contrast, a deep copy makes copies of all levels of the object (or data structure). For examples, Table 3 shows that at the top level, a NameTable is defined with two variables: num_entries, which is an integer, and data, which is an array of type NameEntry. Table 3 shows that a shallow copy of a NameTable, as indicated by the ShallowCopy(p) method of class NameTable in Table 3, includes copying the num_entries and data values alone. 
     Continuing this example, Table 3 also shows that a deep copy of a NameTable, as indicated by the DeepCopy(p) method of class NameTable in Table 3, includes first allocating space for a copy of the data array. If the allocation is unsuccessful, then DeepCopy(p) exits. Otherwise, DeepCopy(p) sets the num_entries value of p to the value of the copied object&#39;s num_entries value. Then, DeepCopy(p) copies each of the NameEntry data items from the copied object&#39;s data array to p&#39;s data array. 
     In some embodiments, the NameEntry class can include one or more references to NameTable values to represent an object hierarchy. In those embodiments, DeepCopy can be modified to operate recursively. In these embodiments, DeepCopy can include functionality to detect and/or break cycles in the object hierarchy for implementations where cycles are allowed in the object hierarchy. 
     In response to data event  548 , handler  524   b  reviews the copy of the name table. Based on the updated Vib.phone and Vib.txt values in the name table, handler  524   b  can determine that check box  426   a  for vibrate sound-setup item  426  on user interface  400  should have black check mark to show that vibrate sound-setup item  426  is on. 
     In response to this determination, handler  524   b  can generate display event  550   a  to mark an “SSetup.vibrate.box” based on a “CHECK_ON” value; that is, handler  524   b  uses display event  550   a  to instruct a display to change check box  426   a  to show a black check mark. Event/environment coordinator  530  then provides display event  550   b  to device interface  526 . In some embodiments, display event  550   b  is a copy of display event  550   a ; while in other embodiments, display event  550   b  is generated by event/environment coordinator  530  based on processing and perhaps modifying display event  550   a.    
     As shown in  FIG. 5E , scenario  500  continues with handler  524   b  sending handler complete message  560  to indicate to event/environment coordinator  530  completion of handler  524   b . In response, event/environment coordinator  530  can send write request  562  to actual environment  528  to perform data changes made by handler  524   b  during invocation. Actual environment can responsively send write response  564  when actual environment  528  has completed making the data changes indicated by write request  562 . 
       FIG. 5F  shows check-box  426   a  with a black check-mark, indicating that corresponding vibrate sound-setup item  426  is selected in response to triggering event  510  and that check box  426   a  has a black check mark in response to display event  550   b . In some scenarios, software application  520  continues executing after performing the activities of scenario  500 . Many other scenarios are possible as well, with more or fewer events, handlers, threads and/or processes than indicated in scenario  500 . 
     Example Operations 
       FIG. 6  is a flow chart of method  600 , in accordance with an example embodiment. Method  600  begins at block  610 , where one or more handlers for a software application of a computing device are registered. Each of the one or more handlers can be configured to be executed upon receiving one or more indications of one or more triggering events, such as discussed above in the context of at least  FIGS. 3-5F . 
     At block  620 , the software application can be executed on the computing device. The software application can be executed using an actual environment, such as discussed above in the context of at least  FIGS. 3-5F . 
     At block  630 , the computing device can determine that a triggering event for the software application has occurred, such as discussed above in the context of at least  FIGS. 3-5F . 
     At block  640 , the computing device can, in response to the triggering event: (a) determine a handler environment for the triggering event, wherein the handler environment is based on the actual environment, (b) determine that one or more triggered handlers of the one or more registered handlers are to be executed, (c) provide at least a portion of the handler environment to each of the one or more triggered handlers, (d) execute the one or more triggered handlers, where at least one triggered handler of the one or more triggered handlers updates the portion of the handler environment during execution, (e) after executing the one or more triggered handlers, determining an updated-handler environment based on the handler environment and the portions of the handler environments of one or more triggered handlers, and (f) update the actual environment based on the updated-handler environment. The procedures of block  640  are discussed above in more detail at least in the context of FIGS.  3  and  5 A- 5 F. 
     In some embodiments, the handler environment includes a partial copy of the actual environment, such as discussed above in more detail at least in the context of FIGS.  3  and  5 A- 5 F. In other embodiments, the handler environment includes a complete copy of the actual environment, such as discussed above in more detail at least in the context of FIGS.  3  and  5 A- 5 F. 
     In still other embodiments, the portion of the handler environment includes a copy of an object of the actual environment. In particular of the still other embodiments, the copy of the object includes a shallow copy of the object; while in even other embodiments, the copy of the object includes a deep copy of the object. Copying objects is discussed above in more detail at least in the context of at least FIGS.  3  and  5 A- 5 F. 
     In yet other embodiments, executing the one or more triggered handlers includes generating one or more transactions to be performed on an environment based on an execution of a triggered handler of the one or more triggered handlers. In particular of the yet other embodiments, the one or more transactions comprise at least one atomic transaction. In other particular of the yet other embodiments, updating the actual environment includes performing the one or more transactions on the actual environment. Generating transactions, including atomic transactions, which can be performed on the actual environment, is discussed above in more detail at least in the context of at least  FIG. 3 . 
     In even other embodiments, executing the one or more triggered handlers includes executing a cycle of two or more triggered handlers. In particular of the even other embodiments, the cycle of two or more triggered handlers can be detected and reported. In other particular of the even other embodiments, executing a cycle of two or more triggered handlers includes breaking the cycle of two or more triggered handlers. Executing, detecting, reporting, and breaking cycles of triggered handlers is discussed above in more detail at least in the context of at least  FIG. 3 . 
     In some embodiments, method  600  additionally includes continuing execution of the software application using the updated actual environment, such as discussed above in the context of at least  FIG. 5F . 
     The above detailed description describes various features and functions of the disclosed systems, devices, and methods with reference to the accompanying figures. In the figures, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the detailed description, figures, and claims are not meant to be limiting. Other embodiments can be utilized, and other changes can be made, without departing from the spirit or scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein. 
     With respect to any or all of the ladder diagrams, scenarios, and flow charts in the figures and as discussed herein, each block and/or communication may represent a processing of information and/or a transmission of information in accordance with example embodiments. Alternative embodiments are included within the scope of these example embodiments. In these alternative embodiments, for example, functions described as blocks, transmissions, communications, requests, responses, and/or messages may be executed out of order from that shown or discussed, including substantially concurrent or in reverse order, depending on the functionality involved. Further, more or fewer blocks and/or functions may be used with any of the ladder diagrams, scenarios, and flow charts discussed herein, and these ladder diagrams, scenarios, and flow charts may be combined with one another, in part or in whole. 
     A block that represents a processing of information may correspond to circuitry that can be configured to perform the specific logical functions of a herein-described method or technique. Alternatively or additionally, a block that represents a processing of information may correspond to a module, a segment, or a portion of program code (including related data). The program code may include one or more instructions executable by a processor for implementing specific logical functions or actions in the method or technique. The program code and/or related data may be stored on any type of computer readable medium such as a storage device including a disk or hard drive or other storage medium. 
     The computer readable medium may also include non-transitory computer readable media such as computer-readable media that stores data for short periods of time like register memory, processor cache, and random access memory (RAM). The computer readable media may also include non-transitory computer readable media that stores program code and/or data for longer periods of time, such as secondary or persistent long term storage, like read only memory (ROM), optical or magnetic disks, compact-disc read only memory (CD-ROM), for example. The computer readable media may also be any other volatile or non-volatile storage systems. A computer readable medium may be considered a computer readable storage medium, for example, or a tangible storage device. 
     Moreover, a block that represents one or more information transmissions may correspond to information transmissions between software and/or hardware modules in the same physical device. However, other information transmissions may be between software modules and/or hardware modules in different physical devices. 
     While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.