System and method for introducing functionality to an application for use with a network service
A computing device operates an application to receive and implement new functionality from a network service. If the new functionality causes the application to fail, the application can automatically discard or ignore the new functionality when the application is re-launched.
1. A method for operating a computing device to receive a network service, the method being implemented by one or more processors and comprising:
receiving instructions for implementing new functionality for an application, on the computing device, that is linked to operate in communication with one or more servers of the network service;
implementing one or more processes to monitor multiple types of application failures;
in response to detecting an application failure of one of the multiple types of application failures, storing a data set which is indicative of the application failure;
upon the application being initiated to re-launch, determining, based at least in part on the stored data set, that the application previously failed upon executing the instructions for implementing the new functionality; and
re-launching the application without executing the instructions for implementing the new functionality so that the new functionality is not triggered or enabled.
2. The method of claim 1 , wherein the multiple types of application failures include the application terminating unexpectedly.
3. The method of claim 1 , wherein the multiple types of application failures include the application entering a suspended state of operation.
4. The method of claim 1 , wherein implementing one or more processes to detect multiple types of application failures includes generating token data that includes (i) a first state indicating the application initiated, and (ii) a second state indicating the application successfully completed a runtime process in reaching a predetermined stage.
5. The method of claim 4 , wherein the token data in the first state establishes a token, and wherein the token data in the second state removes the token from the computing device.
6. The method of claim 1 , wherein the new functionality requires that the computing device access a specific server associated with the network service, and wherein the method further comprises determining that the specific server is available before attempting to re-launch the application with the new functionality.
7. The method of claim 6 , wherein determining that the specific server is available includes receiving one or more messages indicating availability or unavailability of the specific server.
8. The method of claim 1 , wherein determining that the application previously failed includes receiving one or more messages that indicate a particular failure or success of the application when the application was previously launched.
9. A method for changing functionality of a network service provided to a population of user computing devices, the method being implemented by one or more processors and comprising:
providing an application for a population of computing devices operated by users, each computing device of the population being operable to run the application to receive the network service, wherein the application runs on each computing device to (i) communicate over one or more networks with one or more servers that provide the network service, (ii) perform tasks specified by the one or more servers, and (iii) monitor application failures;
introducing a new functionality to the application on a set of computing devices in the population when each computing device in the set launches the application; and
providing instructions to each computing device in the set, the instructions including: (i) new functionality instructions that implement the new functionality, (ii) default mode instructions to cause the computing device to implement a default mode re-launch process for the application that executes the new functionality instructions, and (iii) safe mode instructions to cause the computing device to implement a safe mode re-launch that omits execution of the new functionality instructions when monitoring detects that execution of the new functionality instructions causes the application to fail on that computing device.
10. The method of claim 9 , wherein monitoring application failures includes detecting when the application terminates unexpectedly.
11. The method of claim 9 , wherein monitoring application failures includes detecting when the application enters into a suspended state of operation.
12. The method of claim 11 , wherein monitoring application failures includes generating token data that includes (i) a first default state indicating the application initiated, and (ii) a second state indicating the application successfully completed a runtime process in reaching a predetermined stage.
13. The method of claim 9 , further comprising:
collecting data when the new functionality is run on individual computing devices of the set to evaluate performance and/or failure of the new functionality.
14. The method of claim 9 , further comprising:
associating a temporary identifier to each computing device of the population, the temporary identifier of each computing device in the population being subject to reset based on an event or condition that occurs on that computing device; and
selecting the computing devices of the set based on the temporary identifier.
15. The method of claim 9 , further comprising:
associating a temporary identifier to each computing device of the population, the temporary identifier of each computing device in the population being subject to reset based on an event or condition that occurs on that computing device; and
using the temporary identifier to collect data from when the new functionality is run on individual computing devices of the set to evaluate performance and/or failure of the new functionality.
16. A non-transitory computer-readable medium that stores instructions which, when executed by one or more processors of a system, cause the system to perform operations that comprise:
receiving instructions for implementing new functionality for an application, on a computing device, that is linked to operate in communication with one or more servers of a network service;
implementing one or more processes to monitor multiple types of application failures;
in response to detecting an application failure of one of the multiple types of application failures, storing a data set which is indicative of the application failure;
upon the application being initiated to re-launch, determining, based at least in part on the stored data set, that the application previously failed upon executing the instructions for implementing the new functionality; and
re-launching the application without executing the instructions for implementing the new functionality so that the new functionality is not triggered or enabled.
17. The non-transitory computer-readable medium of claim 16 , wherein the multiple types of application failures includes the application terminating unexpectedly.
18. The non-transitory computer-readable medium of claim 16 , wherein the multiple types of application failures includes the application entering a suspended state of operation.
19. The non-transitory computer-readable medium of claim 16 , wherein implementing one or more processes to detect multiple types of application failures includes generate token data that includes (i) a first state indicating the application initiated, and (ii) a second state indicating the application successfully completed a runtime process in reaching a predetermined stage.
20. The non-transitory computer-readable medium of claim 16 , wherein the new functionality requires that the computing device access a specific server associated with the network service, and wherein the system further comprises determining that the specific server is available before attempting to re-launch the application with the new functionality.