{"_id":"593878f4682adc0031784c05","category":{"_id":"593878f2682adc0031784bf5","version":"593878f2682adc0031784bf3","project":"55f0757d4624ec2d00814345","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-09-09T21:17:41.905Z","from_sync":false,"order":1,"slug":"tigerconnect-basics","title":"Basics"},"user":"55f0756a1e63fc37004b8d2b","parentDoc":null,"project":"55f0757d4624ec2d00814345","version":{"_id":"593878f2682adc0031784bf3","project":"55f0757d4624ec2d00814345","__v":1,"createdAt":"2017-06-07T22:06:42.610Z","releaseDate":"2017-06-07T22:06:42.610Z","categories":["593878f2682adc0031784bf4","593878f2682adc0031784bf5","593878f2682adc0031784bf6","593878f2682adc0031784bf7","593878f2682adc0031784bf8","593878f2682adc0031784bf9","593878f2682adc0031784bfa","593878f2682adc0031784bfb"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"3.0.0","version":"3"},"__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-11-13T23:24:17.285Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":true,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"Here is a typical application lifecycle of a client.  Keep in mind, you might not need to go through all of these steps if you are doing something simple like [sending a single message](doc:getting-started)  but we are assuming most folks out there are looking to integrate real-time messaging capabilities. \n\nFor those that are looking to simply send a single message, check out our guide on [Sending Your First Message](doc:getting-started).\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Logging in\"\n}\n[/block]\nIn order to receive messages, a client must first connect to the TigerConnect platform by logging in with a username and password - for most users, the username would be an email address of the account and the associated password.  \n\nFor single-sign on experiences that rely on existing user management systems., we have various authentication methods which can be leveraged such as LDAP, A/D and an external authentication callback URL.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"Note that each SDK will require some installation prior to logging in.  Refer to the documentation below for the respective SDK you are interested in.\",\n  \"title\": \"Before Logging In\"\n}\n[/block]\nAdditionally, for mobile clients, logging in also enables push notifications to be triggered.  If a particular user is not logged in on a device, they will not receive the respective push notifications.  \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Event Stream\"\n}\n[/block]\nThe Event Stream is the main channel to receive various server events which include new messages, updates to groups, updates to metadata and many of the other dynamic elements of the platform.  See the [/events](doc:events) documentation regarding the various Event types.  \n\nAfter logging in, clients will connect to the event stream to start processing events which include all the existing messages for that particular user.  As each event is received, it is up to the client to acknowledge them.  If Events are not acknowledged, they will continue to be delivered by the platform as it continues to retry until acknowledged.  \n\nConnecting to the Event Stream is what designates whether the user is marked as \"Present\" or not.  The presence indicator is a powerful user experience element that can signal active use of the application.  \n\nFinally, for housekeeping, stale Event Streams are automatically disconnected by the Platform after 7 minutes.  The client will receive an Event when this happens and can choose to reconnect if necessary.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Can't TigerConnect take care of this for me?\",\n  \"body\": \"Absolutely.  By leveraging our SDKs, you won't need to get into the gritty details of the Event Stream.  The SDKs each handle and process the various event types and even handle the connections to the platform so you don't have to.\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Logging Out\"\n}\n[/block]\nLogging out completes a few housekeeping items for each client.  \n\n1.  Closes the Event Stream connection to the platform.  No more messages and events will get pushed to the associated device.\n\n2.  Removes any user key and secret that may have been generated at login time and invalidates it for further use.  \n\nAs part of the logging out, the client will need to remember to remove all local persisted messages and information for security purposes.  Again, we highly recommend the SDK to take care of this so you won't have to.","excerpt":"","slug":"app-lifecycle","type":"basic","title":"Application Lifecycle"}

Application Lifecycle


Here is a typical application lifecycle of a client. Keep in mind, you might not need to go through all of these steps if you are doing something simple like [sending a single message](doc:getting-started) but we are assuming most folks out there are looking to integrate real-time messaging capabilities. For those that are looking to simply send a single message, check out our guide on [Sending Your First Message](doc:getting-started). [block:api-header] { "type": "basic", "title": "Logging in" } [/block] In order to receive messages, a client must first connect to the TigerConnect platform by logging in with a username and password - for most users, the username would be an email address of the account and the associated password. For single-sign on experiences that rely on existing user management systems., we have various authentication methods which can be leveraged such as LDAP, A/D and an external authentication callback URL. [block:callout] { "type": "info", "body": "Note that each SDK will require some installation prior to logging in. Refer to the documentation below for the respective SDK you are interested in.", "title": "Before Logging In" } [/block] Additionally, for mobile clients, logging in also enables push notifications to be triggered. If a particular user is not logged in on a device, they will not receive the respective push notifications. [block:api-header] { "type": "basic", "title": "Event Stream" } [/block] The Event Stream is the main channel to receive various server events which include new messages, updates to groups, updates to metadata and many of the other dynamic elements of the platform. See the [/events](doc:events) documentation regarding the various Event types. After logging in, clients will connect to the event stream to start processing events which include all the existing messages for that particular user. As each event is received, it is up to the client to acknowledge them. If Events are not acknowledged, they will continue to be delivered by the platform as it continues to retry until acknowledged. Connecting to the Event Stream is what designates whether the user is marked as "Present" or not. The presence indicator is a powerful user experience element that can signal active use of the application. Finally, for housekeeping, stale Event Streams are automatically disconnected by the Platform after 7 minutes. The client will receive an Event when this happens and can choose to reconnect if necessary. [block:callout] { "type": "info", "title": "Can't TigerConnect take care of this for me?", "body": "Absolutely. By leveraging our SDKs, you won't need to get into the gritty details of the Event Stream. The SDKs each handle and process the various event types and even handle the connections to the platform so you don't have to." } [/block] [block:api-header] { "type": "basic", "title": "Logging Out" } [/block] Logging out completes a few housekeeping items for each client. 1. Closes the Event Stream connection to the platform. No more messages and events will get pushed to the associated device. 2. Removes any user key and secret that may have been generated at login time and invalidates it for further use. As part of the logging out, the client will need to remember to remove all local persisted messages and information for security purposes. Again, we highly recommend the SDK to take care of this so you won't have to.