BlackBerry Spark Communications Services for iOS  1.9.0
BBMDSGeneratedModel Class Reference
Inheritance diagram for BBMDSGeneratedModel:
BBMDSModel <BBMModelProtocol>

Instance Methods

(BBMLiveList *) - chatWithCriteria:
 
(BBMLiveList *) - chatMessageWithCriteria:
 
(BBMLiveList *) - chatParticipantWithCriteria:
 
(BBMLiveList *) - userWithCriteria:
 
(BBMUser *) - userWithRegId:
 
(NSNumber *) - globalSyncing
 
(NSString *) - globalRegistrationToken
 
(NSString *) - globalLocalPin
 
(NSString *) - globalSetupStateProgressMessage
 
(NSString *) - globalSetupStateState
 
(NSString *) - globalProfileKeysState
 
(NSNumber *) - globalChatMessageFileAutoDownload
 
(NSString *) - globalEndpointId
 
(NSString *) - globalAuthTokenState
 
(NSString *) - globalLocalUri
 
(NSString *) - globalSetupAccount
 
(NSString *) - globalSyncPasscodeState
 
- Instance Methods inherited from BBMDSModel
(void) - resync
 
- Instance Methods inherited from <BBMModelProtocol>
(id) - valueForKey:
 

Properties

BBMLiveListappMessage
 
BBMLiveListchat
 
BBMLiveMapchatMessage
 
BBMLiveMapchatMessageFileProgress
 
BBMLiveMapchatParticipant
 
BBMLiveMapglobal
 
BBMLiveListstat
 
BBMLiveListtyping
 
BBMLiveMapuser
 
- Properties inherited from BBMDSModel
NSDictionary * data
 The underlying JSON representation of the object. More...
 
BBMConnectionconnection
 The connection used to communicate with the underlying API. More...
 

Additional Inherited Members

- Protected Attributes inherited from BBMDSModel
NSMutableDictionary * _mutableData
 

Method Documentation

◆ chatMessageWithCriteria:()

- (BBMLiveList *) chatMessageWithCriteria: (BBMChatMessageCriteria *)  criteria

Returns a subset of the chatMessage list that includes objects that match the given criteria.

Parameters
criteriaThe criteria to be used to match objects in the list.
Returns
BBMLiveList The list that includes the objects that match the criteria.
Since
R0

◆ chatParticipantWithCriteria:()

- (BBMLiveList *) chatParticipantWithCriteria: (BBMChatParticipantCriteria *)  criteria

Returns a subset of the chatParticipant list that includes objects that match the given criteria.

Parameters
criteriaThe criteria to be used to match objects in the list.
Returns
BBMLiveList The list that includes the objects that match the criteria.
Since
R0

◆ chatWithCriteria:()

- (BBMLiveList *) chatWithCriteria: (BBMChatCriteria *)  criteria

Returns a subset of the chat list that includes objects that match the given criteria.

Parameters
criteriaThe criteria to be used to match objects in the list.
Returns
BBMLiveList The list that includes the objects that match the criteria.
Since
R0

◆ globalAuthTokenState()

- (NSString *) globalAuthTokenState

This global indicates if bbmcore requires an authToken value from your application, using the 'authToken' message. The authToken value is used by identity providers to grant further authorization within the BlackBerry Infrastructure.

Bbmcore will try to avoid requesting authToken values as much as possible.

Your application may rely on bbmcore to rate limit how often this global value is something other than 'Ok'. Your application should react automatically when this global's value changes.

Since
R0

◆ globalChatMessageFileAutoDownload()

- (NSNumber *) globalChatMessageFileAutoDownload

This controls whether bbmcore will automatically download newly received file attachments.

Regardless of this setting, your application can ask for individual attachments to be downloaded using the 'chatMessageFileDownload' request.

Since
R5

◆ globalEndpointId()

- (NSString *) globalEndpointId

The identifier for this endpoint. This must be treated as an opaque value by application.

Since
R5

◆ globalLocalPin()

- (NSString *) globalLocalPin

Associates the PIN that is assigned by the BlackBerry Infrastructure with the local profile. The PIN is an 8-character hexadecimal string (in lower case), or it is an empty string if no PIN is currently assigned to the local profile.

Since
R0

◆ globalLocalUri()

- (NSString *) globalLocalUri

This holds the local user's URI as a foreign key into 'listUser'. When a user URI appears elsewhere in the protocol, your application compares the user URI to the 'localUri' value, to determine if the URI refers to the local user.

Since
R0

◆ globalProfileKeysState()

- (NSString *) globalProfileKeysState

Indicates the current state of the profile's signing and encryption key pairs.

This state only applies when your application uses Cloud Key Storage without the BlackBerry Key Management Service.

Since
R3

◆ globalRegistrationToken()

- (NSString *) globalRegistrationToken

In R5, endpoints are given this registration token when they are assigned a regId during setup. This token is signed by the BlackBerry Infrastructure. When decoded, the token contains trusted information about the association of your application user id (as passed to 'authToken') with the assigned regId. The steps for decoding and verifying the registration token are explained in detail in the Developer Guide.

Endpoints that have not yet been assigned a regId and endpoints that were assigned a regId before the R5 release do not have a registration token value. In those endpoints, this global will be the empty string.

Since
R5

◆ globalSetupAccount()

- (NSString *) globalSetupAccount

Indicates if a new or existing Spark Communications identity was used during the most recent setup attempt. Note: the value of this global changes before setup is complete. To see what kind of identity was used for the most recent setup attempt that was successful, check this 'setupAccount' value when 'setupState' transitions to 'Success'.

Since
R0

◆ globalSetupStateProgressMessage()

- (NSString *) globalSetupStateProgressMessage

When the 'state' is 'Ongoing', this indicates the current phase of setup. When the 'state' is not 'Ongoing', this field is omitted or set to 'Unknown'.

Since
R0

◆ globalSetupStateState()

- (NSString *) globalSetupStateState

This indicates the current setup state. The initial 'authToken' request triggers bbmcore to begin setup. However, 'authTokenState' transitions don't change the setup state. For example, the 'authTokenState' transitions to 'Rejected' or 'Needed', setup doesn't fail (but it might not succeed until a usable 'authToken' is provided). The 'authTokenState' and the 'setupState' are independent, but 'authToken' can trigger a setup attempt when 'setupState' is set to 'NotRequested'. The only way to stop setup after it starts is by sending the 'wipe' command to delete all bbmcore data.When certain minor errors occur during setup, bbmcore automatically retries the setup by using the 'retryServerRequests' message. These minor errors are handled by bbmcore, and they don't result in 'state' changes.

Since
R0

◆ globalSyncing()

- (NSNumber *) globalSyncing

This global boolean indicates when bbmcore is performing reconnect synchronization with the BlackBerry Infrastructure. On mobile OSes and within other environments that are aggressive about terminating or suspending applications, your application should take steps to keep bbmcore running while this global is true.For example, consider an Android application that receives push notifications when there are protocol messages waiting for bbmcore to fetch from the BlackBerry Infrastructure. Your application could use this global as part of the following strategy.When your application receives the push, it raises a "connected" foreground notification (if one is not already raised) that will keep your application running.When that notification is raised, your application starts a short timer. This timer will give bbmcore time to connect to the BlackBerry Infrastructure, which will happen before this global is raised. If this timer expires, your application "gives up" on waiting for the global to change, and removes the foreground notification.Your application then forwards that push notification to the lower layers which will react by connecting to the BlackBerry Infrastructure.Once bbmcore has successfully connected, it changes the 'syncing' global to 'true'. In response, your application raises the notification if it isn't already raised. Your application also sets or extends the notification timer for a longer duration. Again, if that timer expires, your application removes the notification.When the syncing process completes, bbmcore changes the 'syncing' global back to 'false'. In response, if the notification is still raised, your application removes it and cancels the timer.In extreme circumstances, the 'syncing' global can remain true for a long time as bbmcore attempts to recover from unusual failure cases. The timers described above give your application control over the maximum duration it is willing to keep the notification raised.

Since
R7

◆ globalSyncPasscodeState()

- (NSString *) globalSyncPasscodeState

This state is only used when your application uses the BlackBerry Key Management Service and the 'setupState' is 'SyncRequired'.

When your application sees 'setupState' change to 'SyncRequired', it should examine this global.When 'syncPasscodeState' is 'None', your application should wait for 'syncPasscodeState' to change before sending 'syncStart'.When 'syncPasscodeState' is not 'None', its value is already current and your application does not have to wait.See 'syncStart' for more information.

Since
R6

◆ userWithCriteria:()

- (BBMLiveList *) userWithCriteria: (BBMUserCriteria *)  criteria

Returns a subset of the user list that includes objects that match the given criteria.

Parameters
criteriaThe criteria to be used to match objects in the list.
Returns
BBMLiveList The list that includes the objects that match the criteria.
Since
R0

◆ userWithRegId:()

- (BBMUser *) userWithRegId: (NSNumber *)  regId

Returns a user that matches the given regId. If there is no match the state value will not be set to current.

Parameters
regIdThe regId to be used to match objects in the user list.
Returns
BBMUser The user that matches the given pin.
Since
R4

Property Documentation

◆ appMessage

- (BBMLiveList*) appMessage
readnonatomicstrong

This list holds the set of application messages known to bbmcore. Application messages are application-specific messages with application-defined content sent to one or more identities for delivery to all their registered endpoints. Application messages are injected at the infrastructure level, not by typical endpoints. If you are interested in sending application messages to your application, please contact the Spark Communications Services sales team.

These messages are not processed by bbmcore but are stored for your application to consume as it sees fit. Only 1000 application messages will be stored by bbmcore at any one time. If more application messages arrive, older ones will be deleted to make room. No 'listRemove' notification will be sent for such removals.

Since
R4

◆ chat

- (BBMLiveList*) chat
readnonatomicstrong

This list contains an entry for each chat the user is participating in. Chats are backed by the BlackBerry Infrastructure, and they will be restored when signing into an existing Spark Communications identity.

Chats must be started explicitly via the 'chatStart' message, and content may be added using the 'chatMessageSend' message.

When bbmcore issues a 'listRemove' for a chat, or when the 'numMessages' counter decreases, it is not necessary to also issue a separate 'listRemove' for the messages. Your application will cleanup their cache of the (now orphaned) messages when appropriate.

Since
R2

◆ chatMessage

- (BBMLiveMap*) chatMessage
readnonatomicstrong

Each element in this list is a message in a chat. The primary key for each element is the 'chatId' and 'messageId'.

The range of valid message ids for a given chat can be found in the chat list as ['lastMessage'

  • 'numMessages', 'lastMessage'].

When a new message is added to a chat, bbmcore will first 'listAdd' the message entry, and then will 'listChange' the chat to update the 'lastMessage' and 'numMessages' fields.

Note that 'listRemove' is not supported for this list. The message counters maintained in the chat list indicate when messages have been removed from this list.

Since
R2

◆ chatMessageFileProgress

- (BBMLiveMap*) chatMessageFileProgress
readnonatomicstrong

This list reports upload and download progress information for active 'chatMessage' file attachment transfers.

Each item in this list corresponds to a single 'chatMessage' entry and is identified by the same key fields: 'chatId' and 'messageId'. When an entry exists in this list, bbmcore is actively trying to upload or download the attached file. The fields of the entry in this list indicate the progress bbmcore has made in that active transfer. When an entry is removed from this list, bbmcore is no longer actively trying to transfer it. When a transfer attempt fails, it will not be represented in this list until bbmcore retries it, but the associated 'chatMessage' 'fileState' will still be 'Transferring'.

Changes in this list will be reported only when the previously reported value of 'bytes' and the current value of 'bytes' differ enough that the progress towards the 'total' achieves a different 5% increment.

For example, if a file was 100 bytes in 'total' and the previous report was 37 'bytes', then a change would only be reported for this entry after 'bytes' reached at least 40. A change from 37 to 39 would not be reported by bbmcore because 'bytes' must reach at least 40 to move from the 35-40% increment to the 40-45% (or higher) increment.

Your application doesn't have to wait for a change in 'bytes' to get an initial progress value for an active transfer it has previously been ignoring. Your application can query the list directly with 'requestListElements' at any time. When such a request returns no entry for a given pair of ids, it means that bbmcore isn't currently trying to upload or download the attached file or no progress information is available for the transfer. (See the caveat on 'total'.)

Since
R5

◆ chatParticipant

- (BBMLiveMap*) chatParticipant
readnonatomicstrong

This list holds the participants for each chat identified by chatId. The local user is never included in this list.

Since
R4

◆ global

- (BBMLiveMap*) global
readnonatomicstrong

This list holds the set of global variables exchanged between your application and bbmcore. The list uses string keys and mixed-type values. The key is the variable name. The set of valid variables and their meaning is documented in the 'globals' section.

Since
R0

◆ stat

- (BBMLiveList*) stat
readnonatomicstrong

Your application uses this list to retrieve stats that bbmcore has recorded about its operation and performance. Stats recorded by bbmcore are local to the device and do not contain personally identifiable information. bbmcore will only ever provide this data to your application when requested to do so.

Every time your application retrieves this list with 'requestListAll', it can contain different data. Bbmcore remembers what values were sent in the most recent 'stat' list collected by your application until your application sends a 'statsCommitted' message. When it receives 'statsCommitted', bbmcore considers the values in the most recently collected 'stat' list to have been exported by your application and committed permanently. After that 'statsCommitted' message, subsequent collections of stats with this list will no longer include that committed data.

If your application can't commit the values it collected with 'requestListAll', it must not send 'statsCommitted'. In such cases, the next copy of of this list that your application collects will be even more up to date and will include the data returned previously (back to the previous 'statsCommitted').

The values in this list persist across bbmcore restarts, and a 'statsCommitted' message can and will complete a 'stats' retrieval even if it was from a previous incarnation of bbmcore.

Statistics whose values are zero when the list is requested are not included in the list.

No 'listElements' or 'listChange' will ever be sent for this list.

This list does not define which statistics are recorded. Interpretation of the statistics is intended to be done by offline analysis and reporting.

Since
R5

◆ typing

- (BBMLiveList*) typing
readnonatomicstrong

This is used to store the set of users that are currently typing a message in a chat. When bbmcore believes the remote user to be typing a message in a chat, it will insert the user/chat pair into this list. When it no longer believes the user to be typing a message, it removes the pair from the list. The same user may be typing in multiple chats, and the same chat may contain multiple typing users. This list never contains entries for the local user. This list may contain entries for nonexistent users and chats.

Since
R4

◆ user

- (BBMLiveMap*) user
readnonatomicstrong

This list consists of all the users known to bbmcore. Other lists, such as the 'participant' list, often refer to entries in this 'user' list. Your application never requests the list in full. Instead, it uses 'requestListElements' calls to lookup one or more users by their 'uri'.

Since
R0