29.3.6. Special features of the mobile device

29.3.6.1. Used functionalities

Used functionality feature combines management of the following features:

Specify the mobile operating system features that the mobile application will use. When you specify the functionality, the system automatically determines the mobile operating system permissions that the Mobile Application Builder will set for a mobile application to be built.
A permission request text that will be displayed to the user when the mobile application first requires access to the functionality protected by the user permission request.
Size of a mobile application to be built. If a functionality is not included in the configuration, the respective module of the mobile 1C:Enterprise version might not be included in the built application when you build a mobile application. This behavior determines another feature: if you attempt to call any method of a disabled module in the mobile application, an exception will be thrown.

Let us take a closer look at the interaction between the used functionality setup and the code in 1C:Enterprise language. To determine whether a functionality is allowed for a mobile application, use the MobileApplicationFunctionalitySupported() method. If the method returns True, the requested features are enabled in the built application. You can also check whether a feature associated with the used functionality is available on this device. For example, if you need to check whether the device supports dialing, use the TelephonyTools.NumberDialingSupported() method. However, this method is related to the Telephony/Dialing functionality. So, the full process of checking whether you can dial a number might look as follows:

If MobileApplicationFunctionalitySupported(MobileApplicationFunctionalities.NumberDialing) Then
If TelephonyTools.NumberDialingSupported(Undefined) Then
// here you can use dialing
EndIf;
EndIf;

Note that this code is redundant. The application developer almost always knows which functionalities their application uses. That is why you can simplify the code to the following:

If TelephonyTools.NumberDialingSupported(Undefined) Then
// here you can use dialing
EndIf;

However, the first option is also possible. When you use the MobileApplicationFunctionalitySupported() method in the mobile client, the list of selected functionalities is checked not only on the mobile device but also on the server. The method returns True only if the functionality to be checked is enabled both on the mobile device and the server. If functionalities can be enabled or disabled for various mobile application versions when developing a mobile client configuration, we recommend that you allow using the MobileApplicationFunctionalitySupported() method to prevent runtime exceptions. This precaution is redundant in a mobile application.

Below you can find information about the object model of 1C:Enterprise language, its features and used functionalities related to them. Besides, you can find information about the system behavior upon an attempt to use a disabled functionality:

Functionality	When disabled	Affects
Bluetooth printers	Exc
NFC	Und	Availability of the NFCTools global context property
Push-notification	Exc	DeliverableNotificationSubscriberID, DeliverableNotifications, ReceiveNotificationSubscriberID()
WiFi printers	Exc
Automatically send text messages	Exc	Non-interactive usage of the TelephonyTools.SendSMS() method
Music library	Und
Picture and video libraries	Und
Biometrics	Exc	SecureStorageAccessProtectionMethod, AdditionalUserVerificationMethod, BiometricVerificationMethod, SecureStorage, AdditionalUserVerification
Video conferences	Und	Using video conferences of the Collaboration System and screen sharing in the mobile client
Audio playback and vibration in background	Exc	MultimediaTools.PlayAudio(), MultimediaTools.PlayText()
Audio playback and vibration	Exc	MultimediaTools.TextPlaybackSupported(), MultimediaTools.PlayAudio(), MultimediaTools.PlaySoundAlert(), MultimediaTools.PlayText(), MultimediaTools.StopAudioPlayback(), MultimediaTools.StopTextPlayback()
In-app purchases	Exc	InAppPurchases
Location	Exc	Geofence, LocationData, LocationProviderInformation, LocationTools
Location in background	Und
Deliverable notifications	Exc	DeliverableNotification, DeliverableNotificationSubscriberType, DeliverableNotifications
Access to all files	Exc	Access to the file system (including file management) outside the application directory (only for Android).
Text message log	Exc	TelephonyTools.SMSLogSupported(), TelephonyTools.GetSMSLog()
Phone log	Exc	CallLog, CallLogCallType, TelephonyToolsCallEventVariant, TelephonyTools.CallLogSupported(), TelephonyTools.GetCallLog()
Audio recording in background	app1	Background use MultimediaTools.MakeAudioRecording()
Calendars	Exc	AccountCalendarData, AccountCalendarEventData, CalendarEventData, Account, GlobalCalendarKey, GlobalCalendarEventKey, LocalCalendarKey, LocalCalendarEventKey, CalendarsManager
Camera	Exc	DeviceCameraType, VideoQuality, DeviceCameraResolution, CameraLightingType, PhotoStamp, MultimediaTools.VideoRecordingSupported(), MultimediaTools.PhotoSupported(), MultimediaTools.GetSupportedCameraResolutions(), MultimediaTools.MakeVideoRecording(), MultimediaTools.MakePhoto()
Contacts	Exc	AccountContactData, LocalContactKey, ContactAccount, ContactManager
Local notifications	Exc	DeliverableNotifications.AddLocalNotification(), DeliverableNotifications.CancelLocalNotifications()
Microphone	Exc	MultimediaTools.AudioRecordingSupported(), MultimediaTools.MakeAudioRecording()
Multimedia	Exc	MultimediaData, MultimediaTools
File exchange with personal computer	Und
Call handling	Exc	TelephonyToolsCallEventVariant, TelephonyTools.CallsHandlingSupported(), TelephonyTools.AttachCallsHandler(), TelephonyTools.DetachCallsHandler()
Printing	Exc	PrintDialogUseMode, SpreadsheetDocument.Print(), Planner.Print(), RepresentableDocumentBatch.Print()
Getting text messages	Exc	TelephonyTools.SMSReceivingSupported(), TelephonyTools.AttachSMSMessageHandler(), TelephonyTools.DetachSMSMessageHandler()
Backup using OS	Und
Ads	Exc	AdRepresentation
Document scanning	Exc	MultimediaTools.DocumentScanningSupported(), MultimediaTools.ShowDocumentScanning(), MultimediaTools.ScanDocumentsAsync(), MultimediaTools.CloseDocumentScanning()
Barcode scanning	Exc	MultimediaTools.BarcodeScanningSupported(), MultimediaTools.ShowBarcodeScanning(), MultimediaTools.CloseBarcodeScanning()
Application usage statistics	Und
Telephony	Exc	TelephonyTools, TelephonyTools.NumberDialingSupported(), TelephonyTools.DialNumber()
Installing applications	Exc

In the table:

Exc means that an attempt to use a functionality that is disabled in the configuration properties throws a runtime exception.
Und means that the system behavior is undefined. In general, the behavior of the mobile 1C:Enterprise version is determined by the used mobile operating system and the applied feature. In some cases, the action might not be executed, a mobile operating system error might occur, and so on. If the developer does not include a functionality in the configuration, they automatically refuse to use all mobile version features associated with this functionality.
app1 means that audio recording is possible only in an active application. In a minimized application, audio is not recorded.

29.3.6.2. Telephony operations

The mobile 1C:Enterprise version provides a set of features that allow you to make calls from mobile applications. Calls can be made with or without user confirmation. The system also provides access to the call log and the ability to handle events that occur when receiving or making phone calls. In the application, you can define supported telephony features. To do it, use the NumberDialingSupported(), CallLogSupported(), and CallsHandlingSupported() methods of the TelephonyTools object. Call processing is possible only on Android.

Dialing is done as follows:

If TelephonyTools. NumberDialingSupported() Then
TelephonyTools. DialNumber(PhoneNumber, CallDirect);
EndIf;

The DirectCall parameter is responsible for how the subscriber’s call will be made:

If the parameter is set to True, the number dialing is triggered automatically upon a method call. A standard call program interface appears on the screen.
If the parameter is set to False, the call handling application is opened when the method is executed, and the specified number is set there. The user only needs to tap the call start button after that.

Mobile devices running Android provide access to the call log. You can iterate log records with a required filter. To perform operations with the log, use the GetCallLog() method of the TelephonyTools object.

The following example demonstrates getting a list of all missed calls on a mobile device.

If TelephonyTools.CallLogSupported() Then
Log = TelephonyTools.GetCallLog();
Filter = New DataCompositionFilter;
NewItem = Filter.Items.Add(Type("DataCompositionFilterItem"));
NewItem.LeftValue = New DataCompositionField("CallType");
NewItem.ComparisonType = DataCompositionComparisonType.Equal;
NewItem.RightValue = CallLogCallType.Missed;
NewItem. Use = True;
LogRecords = Log.FindRecords(Filter);
For Each Record In LogRecords Do
// call list processing
EndDo;
EndIf;

When you perform operations with the call log, remember that the log is filtered using the DataCompositionFilter object.

To process call events (on Android devices), you can attach/detach the call handler. After the call event handler is registered in the system, it is called upon any event occurrence, and call data is passed to that handler. The handler does not support actual call management. The standard operating system program is used for that.

You can use this feature to implement, for example, your own call log for a mobile application or a missed call reminder.

&AtClient
Procedure CallHandlerManagement(AttachHandler)
If NOT TelephonyTools.CallsHandlingSupported() Then
// call processing is not supported
Return;
EndIf;
Handler = New NotifyDescription("CallsProcessing", ThisObject, "Parameters");
If ProcessCallEvents Then
TelephonyTools. AttachCallsHandler(Handler);
Else
TelephonyTools.DetachCallsHandler();
EndIf;
EndProcedure

Procedure CallsHandler(PhoneNumber, Date, EventVariant, CallType, AddlParameters) Export
// call event processing
EndProcedure

29.3.6.3. Operation with messages (SMS and MMS)

The mobile 1C:Enterprise version provides a set of tools to perform operations with SMS and MMS messages. Messages can be sent and received. Access to the list of messages is determined by the mobile operating system in use. Sending messages is possible both interactively and completely programmatically.

The mobile 1C:Enterprise version provides some tools to determine features of the mobile OS in use. For that, the TelephonyTools global context object has the following methods: SMSSendingSupported(), SMSReceivingSupported(), and MMSSendingSupported(). Depending on the mobile operating system in use, the following restrictions for message operations are applied:

On iOS:
- Subscription to receive SMS/MMS is unavailable.
- SMS/MMS cannot be sent programmatically.
On Android:
- MMS cannot be sent programmatically.
On Windows:
- Subscription to receive SMS/MMS is unavailable.
- SMS/MMS cannot be sent programmatically.

The message in 1C:Enterprise is represented by the SMSMessage object. Sending a message looks as follows:

&AtClient
Procedure SendSMS(To, Text, SendInteractively)
SMS = New SMSMessage();
SMS.Text = Text;
StringRecipients = StrReplace(To, ",", Chars.LF);
For Counter=1 In StrLineCount(StringRecipients) Do
SMS.Recipients.Add (TrimAll(StrGetLine(StringRecipients, Counter)));
EndDo;
TelephonyTools.SendSMS(SMS, SendInteractively);
EndProcedure

As a value of the To parameter, several comma-separated phone numbers can be passed. The SendInteractively parameter defines how the message will be sent:

If the parameter is set to True, the message is sent immediately.
If the parameter is set to False, the default messaging application for the mobile OS in use is opened. In this application, the form for sending a message with filled fields is opened. In this case, the user must manually tap the button for sending a message in the opened form.

To convert an SMS message into an MMS message, you need to add attachments to messages. To do it, use the SMSMessage.Attachments property. Specify the MIME type of the passed data as the value of the MIMEType property of the MMSAttachment object. For example, for a JPEG file, this is image/jpeg.

In the mobile 1C:Enterprise version, you can subscribe to notifications of received SMS messages if the mobile OS in use supports this feature.

&AtClient
Procedure AttachMessagesReceiptHandler()
MessageRecipient = New NotifyDescription("MessageReceipt", ThisObject);
TelephonyTools.AttachSMSMessageHandler(MessageRecipient);
EndProcedure

&AtClient
Procedure MessageReceipt(Message, AdditionalParameters) Export
Message(Message.Sender + " - " + Message.Text);
EndProcedure

When an incoming message is received, the notification handler will be called to process the received message. Messages received using the attached notification handler will also be available from the system messaging application.

To check the accessibility of the message log, use the TelephonyTools.SMSLogSupported() method. If the mobile OS in use provides access to the message log, it becomes possible to receive messages according to the applied filter.

The following example demonstrates getting a list of all unread messages on a mobile device.

If TelephonyTools.SMSLogSupported() Then
Log = TelephonyTools.GetSMSLog();
Filter = New DataCompositionFilter;
NewItem = Filter.Items.Add(Type("DataCompositionFilterItem"));
NewItem.LeftValue = New DataCompositionField("Read");
NewItem.ComparisonType = DataCompositionComparisonType.Equal;
NewItem.RightValue = False;
NewItem. Use = True;
LogRecords = Log.FindRecords(Filter);
For Each Record In LogRecords Do
// message list processing
EndDo;
EndIf;

When you perform operations with the SMS log, remember that it is filtered using the DataCompositionFilter object.

When you filter messages by the PhoneNumbers field, consider some features:

The user can specify fragments of numbers only if the string is used as the right value of the filter item and the comparison type is DataCompositionComparisonType.Contain or DataCompositionComparisonType.NotContains. Spaces, parentheses, and hyphens in the number are not ignored.
Indication of names from the address book (list of contacts) is not supported.
If an array of numbers is specified as the filter value, the message meets the condition only if there is the same number of numbers in the message and filter and all these numbers match.

The search returns a list of messages ordered starting from the most recent messages.

29.3.6.4. Location tools

29.3.6.4.1. General information

Numerous mobile devices support determination of mobile device coordinates. They also can convert received coordinates into addresses and vice versa. To access these features, you can use the location provider. Each provider is described by a name and a specific set of parameters (features). A specific location provider may not support all features.

The general algorithm for operation with location tools is as follows:

The required provider is selected. In each case, you need to select a provider that is most suitable for completion of assigned task. In general, it is preferred that you select a provider with minimum power consumption and maximum accuracy in terms of coordinates determination.

Example:

// Define a provider that does not lead to spending
// funds and uses a cellular network to determine
// coordinates
RequiredProvider = Undefined;
Providers = LocationTools.GetProviders();
For Each Provider In Providers Do
If NOT Provider.Paid and Provider.UsesCellNetwork Then
RequiredProvider = Provider;
Break;
EndIf;
EndDo;
If RequiredProvider = Undefined Then
Message("Required provider not found");
Else
Message("Provider found: " + RequiredProvider.Name);
EndIf;

If you need to get the most energy-efficient provider or the most accurate provider, you can use the GetMostPowerSavingProvider() or GetMostAccurateProvider() methods, respectively.

The coordinates are determined using the selected location provider. Two methods are used to obtain the coordinates. The GetLastLocation() method returns the latest location data received by the selected provider. Among the properties of the LocationData object (which returns the GetLastLocation() method), there is the Date property that describes when the location data was received. If this data is obsolete, call the UpdateLocation() method for the location provider to refresh the location data. One of the method parameters determines the timeout for location determination. If the method is terminated upon timeout, the actual determination of coordinates in this case depends on the implementation specifics of a particular mobile operating system version.

Example:

// If the location on this device has never been performed
// or completed more than an hour ago, update the location and
// receive specific coordinates
Coordinates = LocationTools.GetLastLocation(ProviderName);
If Coordinates = Undefined Or CurrentDate()-ToLocalTime(Coordinates.Date) > 3600 Then
LocationTools.UpdateLocation(ProviderName, 60);
Coordinates = LocationTools.GetLastLocation(ProviderName);
EndIf;

If required, you can subscribe to coordinates change. If you no longer need the subscription, you can to turn off the notification of coordinates change.

After receiving the location data, you can perform several auxiliary operations related to the received location:

Get the address by coordinates. To do this, use the GetAddressByLocation() method.
Get location coordinates by address. To do this, use the GetLocationByAddress() method.
Show a map that displays the coordinates of one or more points. To do this, use the ShowOnMap() method. This feature is unavailable for some mobile OS. Use the MapRepresentationSupported() method to determine whether one or more points are displayed on the map. To display points on the map on any mobile OS, use a branded application by the operating system developer.

NOTE 1. To use methods that convert coordinates into addresses and vice versa, the mobile device must have access to the Internet.

NOTE 2. The location feature is not supported in the background on iOS devices.

29.3.6.4.2. Getting the key for GoogleMaps

IMPORTANT. Description of the developer console is as of the writing of the documentation.

For a mobile application to support location on Android, you need to get a special key for Google Maps. To do this, follow these steps:

Sign in to the Google Developer Console (https://console.developers.google.com/project).
Create a project by clicking Create project.
Enable the Google Maps service. To do this, select an application and click Products and Services ‑ API Manager. The menu is available in the upper left corner of the page, next to the Google APIs label. On the Library page, enter Google Maps Android API in the input field. In the list, below the input field, select Google Maps Android API. On the page that opens, click Enable. The hyperlink is located at the top of the page, to the right of the Google Maps Android API label.
Obtain an API Key. To do this, select Credentials in the menu on the left side of the page. In the Credentials section, click Create credentials and select API Key in the drop-down menu. After creating the key, click Close in the resulting dialog box.
Create a mobile application group in the mobile application builder, which was set up in an appropriate way first. After that, copy the contents of the Parameter of getting the Google Maps key field.
For the Key restriction radio button, select Android application. Click Add resource: package name and checksum. Insert the copied data into the SHA-1 certificate checksum field. Then, at the end of the inserted line, select the full application ID and transfer it to the Package name field. Not that the checksum must not end with ";".
After key generation is completed, it will be displayed in the API Key field. Enter the resulting value in the Google maps key field located in the mobile application group form. Finally, save the mobile application group.

29.3.6.5. Multimedia operations

29.3.6.5.1. Audio

Recording

Mobile devices can record audio information. To define whether the operation can be performed, use the MultimediaTools.AudioRecordingSupported() method.

In this case, if a mobile device supports this feature, the mobile version provides the following methods to record audio:

MultimediaTools.MakeAudioRecording(). Starts the audio recording interface. The program in 1C:Enterprise language will run after the requested action is performed (recording is completed).
MultimediaTools.StartAudioRecording(). Starts background audio recording. The application will continue running. To stop recording, you can use a special button on the screen. You can stop recording programmatically by calling the MultimediaTools.StopAudioRecording() method. To notify the application about the end of the recording, use a handler that is passed to the StartAudioRecording() method.

To manage audio recording parameters, use the AudioRecordingParameters object. Use this object to specify the following parameters:

Audio recording mode: mono or stereo. It is specified by the AudioRecordingChannelUse property.
Recording bitrate. Determines how much (in bits) one second of recording will take. Unit of measure: bits per second. It is specified by the EncodingBitrate property.
Audio sampling rate. Determines how exactly the audio will be recorded. In other words, it sets the frequency at which the audio is digitized. Unit of measure: kHz. It is specified by the SamplingRate property.
Format in which the recorded data will be received. Determines the format of data to be received. The data format, MIME type, and file extension depend on the property value. It is specified by the AudioRecordingFormat property.

You can specify recording parameters both for synchronous audio recording and background recording. To do this, use the respective parameters of each method. To enable background recording and ensure that it does not stop when the device goes to sleep, specify the Audio recording in background functionality in the Used mobile application functionality configuration property.

Playback

In the mobile 1C:Enterprise version, you can play audio notifications, play audio files, and perform speech synthesis. The ability to perform speech synthesis depends on the language in which you want to perform it.

To play a sound notification (short sound or vibration), use the MultimediaTools.PlaySoundAlert() method. You can play either a standard system sound or a sound file whose name is passed as the Sound parameter of this method. This sound file must be part of the mobile application. However, you cannot attach resources with playable files on the mobile platform for developers. To attach the specified file to the mobile application, use mobile application builder tools. For that reason, you can check the use of sound notifications from files only in a built application. To control vibration when playing a sound notification, use the Vibration parameter of the PlaySoundAlert() method. If the file name with the sound notification is specified without an extension, the following extensions (depending on the OS) are used by default:

iOS: .caf
Android: .mp3
Windows: .mp3

Playback of notifications cannot be paused or stopped. They are always played completely.

Calling the Signal() global context method is equivalent to calling the MultimediaTools.PlaySoundAlert(SoundAlert.Default) method.

If you need to play a sound file, use the MultimediaTools.PlayAudio() method. The playback source can be the MultimediaData object (the result of the MakeAudioRecording() or StartAudioRecording() method), the BinaryData object (which contains the audio file of the required format), or the file name (the String type). Playback of the audio file included in the mobile application is not supported. If an application must handle the playback stop state, specify a notification handler (in the StopPlaybackHandler parameter) that will be called if playback is stopped or interrupted.

To stop playing an audio file, use the MultimediaTools.StopAudioPlayback() method. If the audio file is not currently playing, nothing will happen.

In terms of ability to play audio files of various formats, we recommend that you rely on the MIME type of the file. You can play audio files of the following MIME types (depending on the mobile OS in use):

iOS: audio/mp4
Android: audio/3gpp
Windows: audio/aac

In addition, audio files of the following MIME types can be played:

MP3 format: audio/mpeg
AAC format: audio/aac
WAVE format: audio/vnd.wave (for Android version 4.1 and later).

Playing audio files whose MIME types differ from those listed above is not supported.

Further, you can find a simple example of a form with two buttons. Tapping one of them (the PlayAudio() handler) selects a file and starts playing it. Tapping the second button (the Stop() handler) stops the playback.

&AtClient
Procedure PlayAudio(Command)
Dialog = New FileDialog(FileDialogMode.Open);
If Dialog.Select() Then
Data = Dialog.FullFileName;
MultimediaTools.PlayAudio(Data);
File = New File(Dialog.FullFileName);
Message("" + File.GetMobileDeviceLibraryFilePresentation() + " with duration of " + MultimediaTools.GetAudioDuration(Data) + " seconds");
EndIf;
EndProcedure

&AtClient
Procedure Stop(Command)
MultimediaTools.StopAudioPlayback();
EndProcedure

On the mobile platform, you can use a speech synthesizer built into the operating system. To check whether a synthesizer for a specific language is available, use the MultimediaTools.TextPlaybackSupported() method. If a speech synthesizer is available, you can play texts using the MultimediaTools.PlayText() method. To process the interruption of speech synthesis, you can set the appropriate handler using the StopPlaybackHandler parameter. To interrupt text playback, use the MultimediaTools.StopTextPlayback() method.

29.3.6.5.2. Photo and video

With mobile devices, you can take photos and record videos. For various mobile devices, these features may or may not be available. To determine whether an operation can performed, you can use the following functions: PhotoSupported() and VideoRecordingSupported().

If a mobile device supports a feature, you can use the global context method that activates the necessary system application to perform the required action: MakePhoto() and MakeVideoRecording().

Since mobile devices can have two cameras (front and rear), you can select any of them for operations on the mobile platform. To do this, use the DeviceCameraType system enumeration when determining the features of a mobile device and when performing an action.

Front = MultimediaTools.PhotoSupported(DeviceCameraType.Front);
Rear = MultimediaTools.PhotoSupported(DeviceCameraType.Rear);

The code above allows you to determine which of the two device cameras supports photography. Using these methods, you can determine the presence of a particular camera on the device. You can also specify the camera to be used for taking photos and recording videos. If the camera type is DeviceCameraType.Auto, it is interpreted on devices as follows:

If the device has two cameras, the rear camera is used.
If the device has one camera, this camera is used (depending on availability).

You can also specify some additional photo and video parameters that affect the final result.

For photos, you can specify the following parameters in addition to the camera type:

Required camera resolution. If you specify a resolution that is not supported by the device, resolution closest to the specified one is selected. To get the list of supported resolutions, use the GetSupportedCameraResolutions() method of the MultimediaTools object. For iOS devices, this parameter is ignored.
Picture quality. Defines the compression degree of JPEG files. 100 means maximum quality.
Color mode of the resulting picture: color or black and white. For iOS devices, selecting the black and white mode does not affect the camera interface. However, the resulting picture will be black and white.
Initial flash mode when opening the camera interface. To control it, use the LightingType parameter of the MakePhoto() method. You can manually turn on or turn off the flash or let the device determine the flash mode automatically.
Use the Mark parameter to control the insertion of the date and time the photo was taken or free text in the right lower corner of the photo. Pass the PhotoStamp object as the parameter value.

To speed up the acquisition of picture data on Android, we recommend that you do the following:

If the application does not require the front camera, forcible set the rear camera as the main one by using the CameraType parameter of the MultimediaTools.MakePhoto() method. If automatic camera selection mode is set, switching to the front device camera in the camera interface is not recommended.
The recommended device position for taking pictures is horizontal (wide side down) with camera on the left.
Do not enable photo conversion to black and white (the BlackAndWhite parameter of the MultimediaTools.MakePhoto() method) without obvious need.
If possible, reduce the resolution and quality of the resulting photo to a reasonable value (the Resolution and Quality parameters of the MultimediaTools.MakePhoto() method). For example, setting the Quality parameter to 50%, and the Resolution parameter to 50% of the maximum camera resolution can reduce the time required to take a photo by 1.5 times.

For video recording, in addition to specifying the camera type, you can also specify the quality of the resulting video. This parameter is ignored on iOS devices.

29.3.6.6. Barcode scanning

Barcode scanning is supported on mobile devices with a camera. To access this feature, the platform provides a special interface.

NOTE. To effectively scan barcodes, it is desirable that the camera of the mobile device has the ability to automatically focus the camera lens (autofocus). Otherwise, scanning barcodes will be difficult.

The general scheme of operation with a barcode scanner is as follows:

You need to determine whether scanning is supported. To do this, use the BarcodeScanningSupported() method of the MultimediaTools global context object.
If scanning is supported, use the ShowBarcodeScanning() method of the MultimediaTools object to open a special barcode scanning interface. During scanning, a special handler with data on the scanning result is called.
To close the scanning interface manually, use the standard Android button to go to the previous form. To close the scanning interface programmatically, use the CloseBarcodeScanning method of the MultimediaTools()object.

Consider an example that demonstrates the scanning feature. In the example, we used a simple form with a button that opens the scanning interface and a flag for closing this interface after a single scan. The scanned barcode will be displayed as a message.

NOTE. This example is not a completed tool. It only demonstrates how to use the scanning feature.

In the form, create the CloseInterface attribute of the Boolean type and add an item that displays this attribute to the form. Create the OpenScanningInterface form command and add it to the form as well. The form module looks as follows:

// The OpenScanningInterface form command handler
&AtClient
Procedure OpenScanningInterface(Command)
ScanHandler = New NotifyDescription("ScanHandling", ThisObject);
CloseHandler = New NotifyDescription("InterfaceCloseHandling", ThisObject);
MultimediaTools.ShowBarcodeScanning("Point the camera at the barcode", ScanHandler, CloseHandler);
EndProcedure

&AtClient
Procedure ScanHandling(Barcode, Result, Message, AdditionalParameters) Export
If Result Then
Text = "" + Barcode;
Else
Text = "Error: " + Message;
EndIf;
If CloseInterface Then
MultimediaTools.CloseBarcodeScanning();
EndIf;
Message(Text);
EndProcedure

&AtClient
Procedure InterfaceCloseHandling(AdditionalParameters) Export
Message("The scanning interface is closed");
EndProcedure

&AtClient
Procedure OnOpen(Cancel)
If NOT MultimediaTools.BarcodeScanningSupported() Then
Raise "Barcode scanning is not supported";
EndIf;
CloseInterface = False;
EndProcedure

When the scanning interface is opened, two notification descriptions are passed to the ShowBarcodeScanning() method. The first notification is triggered (the <ScanHandler> parameter) if the system has successfully recognized the barcode. The second notification (the <CloseHandler>parameter) is triggered when the barcode scanning window is closed. The interface can be closed both interactively and programmatically. The programmatic option is demonstrated in the ScanHandling() notification handler. To close the interface interactively, tap Back in the scanning interface.

After opening the scanning form, you can specify barcode kinds the system will recognize: linear (for example, EAN), two-dimensional (for example, QR code), or all barcodes. To set it up, use the <BarcodeType> parameter of the ShowBarcodeScanning() method. Remember that if you specify recognition of all barcode types, it will reduce scanning performance, since the system will spend more time searching for different barcodes in the image.

When scanning barcodes using a mobile device camera, the following barcodes will be recognized, depending on the operating system of the mobile device:

Android:
- Linear barcodes:
  - UPC-A
  - UPC-E
  - EAN-8
  - EAN-13
  - Code39
  - Code93
  - Code128
  - RSS-14
  - RSS Expanded
  - ITF
  - Codabar
- Two-dimensional barcodes:
  - QR Code
  - Data Matrix
iOS:
- Linear barcodes:
  - UPC-A
  - UPC-E
  - EAN-8
  - EAN-13
  - Code39
  - Code93
  - Code128
  - RSS-14
  - RSS Expanded
  - ITF
  - Codabar
  - PDF417
- Two-dimensional barcodes:
  - QR Code
  - DataMatrix
  - Aztec Code
  - MaxiCode
Windows:
- Linear barcodes:
  - UPC-A
  - UPC-E
  - EAN-8
  - EAN-13
  - Code39
  - Code93
  - Code128
  - ITF
  - Codabar
  - RSS-14
  - RSS Expanded
  - PDF417
- Two-dimensional barcodes:
  - QR Code
  - DataMatrix
  - Aztec Code
  - MaxiCode

29.3.6.7. Email operations

The mobile 1C:Enterprise version provides application developers with several ways to operate with emails. One method allows you to implement a full-fledged email client on the 1C:Enterprise platform (the InternetMail object and related objects). The other method allows you to send email messages only by using the default email application installed in the system (the MailTools object).

When email messages of the InternetMailTextType.HTML type are sent using the MailTools object (on Android), the message text is converted into Spannable format. The email sent is displayed by most email clients.

If you use email message texts of the InternetMailTextType.HTML type (on OS Android), using the following features is not recommended:

Cascading tables of styles
Embedded tables
Embedded images
Fonts of different sizes

We recommend that you check the display of emails on as many devices as possible to minimize the dependence on the implementation differences of different operating systems and mail application versions.

Note that the InternetMailTextType.RichText email message text type is not supported by the MailTools object.

29.3.6.8. Contact list operations

Contact list is a database that stores information about the subjects with whom the owner of the mobile device communicates. The contact description contains the contact identification data, addresses, phone numbers, and other information necessary to communicate with the subject. Also, accounts of various services can be registered on the mobile device. An account is a set of information that users use to identify themselves in any service. For example, this is a username and password. There is always an account on the mobile device that describes the device itself (local account).

Each record in the contact list is associated with a single account. The mobile operating system can synchronize the list of contacts with the account data (depending on the OS settings). If the contact is associated with a local account, information is not synchronized, and all data is located only on the mobile device.

The main information about the contact is stored in objects of ContactData type. Objects of this type contain all information about the contact, except for the link of the contact with the account. There are several data types in the contact description that can contain more than one value. Such data includes phone numbers, addresses, email addresses, and so on. To store such data, use object arrays of the ContactDataItem type. To store the list of identifiers in instant messaging applications, use an array of ContactDataItemInstantMessaging objects.

The accounts registered on this mobile device for contact synchronization are described using the ContactAccount object.

The AccountContactData object generates the link between the contact account and actual contact list items. In addition to information about the contact and account, this object also contains an ID by which the list of contacts on the mobile device and the account are synchronized. One could say that the GlobalContactKey property of the AccountContactData object is similar to the Link property for applied 1C:Enterprise objects.

To identify a contact on a mobile device, use the LocalContactKey object. All operations with contacts (creation, modification, deletion, and search) are performed using this object. To perform operations with contacts, use the contact manager (the object of the same name).

The following example shows the way contact list items are created in a local account:

&AtClient
Procedure CreateContactItem(Name,MiddleName, LastName, Email, PhoneNumber)

ContactData = New ContactData;
ContactData.Name = Name;
ContactData.MiddleName = MiddleName;
ContactData.LastName = LastName;
EmailItem = New ContactDataItem(ContactDataEmailAddressType.Office, Email);
ContactData.Emails.Add(EmailItem);
PhoneNumberItem = New ContactDataItem(ContactDataPhoneNumberType.Office, PhoneNumber);
ContactData.PhoneNumbers.Add(PhoneNumberItem);
CM = New ContactManager;
LocalContacts = CM.GetLocalContactAccount();
Contact = New AccountContactData(ContactData, LocalContacts);
CM.AddContact(Contact);

EndProcedure

If you need to search for a contact by any set of parameters, use the FindContacts() method of the contact manager. Since the contact filter is set using the DataCompositionFilter object, you can set a rather complex contact filter. Note that top-level filter items are added "by AND". For a list of fields available for the contact filter, see the description of the FindContacts() method in the Syntax Assistant.

29.3.6.9. Calendar operations

On a mobile device, you can view the calendar and create various events in it. Events are characterized by some set of characteristics, such as the start and end date and time, description, involved parties, and so on. Also, accounts of various services can be registered on the mobile device. An account is a set of information that users use to identify themselves in any service. For example, this is a username and password. There is always an account on the mobile device that describes the device itself (local account).

There can be several calendars (with different names) on a mobile device. Each calendar is associated with a single account. The mobile operating system can synchronize calendar events with the account data (depending on the OS settings). If calendar events are associated with a local account, the information is not synchronized and all data is located only on the mobile device.

Basic calendar information is stored in the CalendarData object. Calendar events are described by the CalendarEventData object. These objects describe the characteristics of the calendar or calendar events, but do not describe the account linked to the object.

Accounts registered on this mobile device for contacts synchronization are described using the CalendarAccount object.

Calendar and event data is synchronized with accounts by the AccountCalendarData and AccountCalendarEventData objects. In addition to account information, these objects store value data of the keys used for synchronization between the mobile device and a certain service. The GlobalCalendarKey is used to synchronize calendar data. The GlobalCalendarEventKey is used to synchronize data about calendar events.

To identify these calendars and events on the mobile device, use the LocalCalendarKey and LocalCalendarEventKey objects. All operations with calendars and events (creation, modification, deletion, and search) are performed using this object. To perform operations with calendars and events, use the calendar manager (the object of the same name).

If you need to search for a calendar or a calendar event by any set of parameters, use the FindCalendars() or FindEvents() methods of the calendar manager. Since the data filter is set using the DataCompositionFilter object, you can set a rather complex contact filter. Note that top-level filter items are added "by AND". For a list of fields available for the contact filter, see the description of the FindCalendars() and FindEvents() methods in the Syntax Assistant.

29.3.6.10. Screen orientation

The platform provides information on some characteristics of the screen of the device on which the client application is running (personal computer or mobile device). To get this information, use the GetClientDisplaysInformation() method. It returns an array of structures that describe the screens attached to the device.

Each array element describes one screen attached to the device. The Height and Width parameters describe the height and width of the screen in points, respectively. At the same time, for mobile devices, these parameters depend on the device orientation (if it is allowed in the settings). Platforms for personal computers always return the canonical parameters of attached screens. This way, on a mobile device, you can analyze the device position and make decisions about application interface conversion based on this data. To facilitate orientation operations, use the OnChangeDisplaySettings event, which can be processed in the managed application module and in the managed form module.

As an example, consider changing the display of a form displayed on the desktop. In this form, there are two lists that display some information. In case of portrait screen orientation (the narrow side of the device is below), lists will be displayed one above the other. In case of landscape screen orientation (the wide side of the device is below), lists will be located side by side. To implement this behavior, in the form module on the desktop, create the OnChangeDisplaySettings event handler that looks as follows:

&AtClient
Procedure OnChangeDisplaySettings()
InformationArray = GetClientDisplaysInformation();
If InformationArray[0].Width > InformationArray[0].Height Then
ThisForm.Grouping = ChildFormItemsGroup.Horizontal;
Else
ThisForm.Grouping = ChildFormItemsGroup.Vertical;
EndIf;
EndProcedure

29.3.6.11. Notification operations

29.3.6.11.1. General information

During the information system runtime, the user must be regularly notified of certain events. An event can be scheduled or triggered by another event. The event can occur on a mobile device owned by the user, or somewhere else in the information system.

Notifications are used to notify the user about the occurrence of events. Notifications can be created locally or sent via push services. Local notifications inform the user about events that occur on their device. Typically, the source of push notifications is the central node of the information system. Using push notifications, it informs remote users that data important to users has changed. However, this is not the only scenario for using push notifications. Push notifications can be sent by specialized services that inform users about currency rates, sports scores, weather forecasts, and so on.

29.3.6.11.2. Local notifications

Local notifications are used to notify on events that occur directly on the mobile device. Local notifications can be instant and scheduled. They are used to inform users about different events. Their behavior on mobile devices has some specific features. Instant notifications are used to notify the user about occurrence of a certain event "here and now". For example, such event can be the end of a process. Such process can be the synchronization operation with an external system. Scheduled notifications allow the user to be reminded of the need to perform an operation at the appointed time. Scheduled notification may be one-time or periodic. A one-time scheduled notification can be used, for example, if the system indicates that some counterparty needs to call back at a specific time. Repeated scheduled notification can be used, for example, when some operation is repeated every day, regardless of external events.

To use local notifications, set the Local notifications permission. The mobile application builder adds the appropriate permission for the mobile application being built. Note that the mobile 1C:Enterprise version for developers has all the permissions to operate with local notifications. Therefore, after the feature is developed, we recommend that you check its operation on the usual mobile 1C:Enterprise version. To do this, use the mobile application builder and test the resulting application on one or more devices.

For operation with local notifications, use the deliverable notification manager (the DeliverableNotifications global context property) and the DeliverableNotification object. The object describes the notification itself (including its display parameters), and the manager controls the notification feature.

Let use consider creating local notifications in more detail.

&AtClient
Function CreateNotification(Title, Text, Data = 0, TriggeringDate, RepetitionInterval = 0)

Notification = New DeliverableNotification;
Notification.Title = Title;
Notification.Text = Text;
Notification.Data = Data;
Notification.FireDateUniversalTime = TrigerringDate;
Notification.RepeatInterval = RepetitionInterval;
Notification.SoundAlert = SoundAlert.Default;
Return Notification;

EndFunction

&AtClient
Procedure SetNotification(Command)

Notification = CreateNotification("Title", "Text", 2014, '00010101');
DeliverableNotifications.AddLocalNotification(Notification);

EndProcedure

When you create a notification, remember the following features:

Date and time of the first display of the notification is set in the universal time format (UTC). To change the time zone, you can use the UniversalTime() global context function.
If the FireDateUniversalTime property is set to an empty value (or not specified at all), the notification will be displayed immediately. This notification can notify the user that the mobile application has completed some long-running operation, for example, completed the data synchronization operation.
To display a notification regularly, use the RepeatInterval property of the DeliverableNotification object. As a result, you can implement a simple unconditional timer that will generate a notification after a specified time interval. The value that describes the notification repetition interval depends on the mobile operating system in use. The features of specifying the interval are described in the syntax assistant. In the system, you cannot specify the date and time of notification completion. On Windows, the notification is shown 5 times (including the first display).
If necessary, you can set a number sticker displayed in the notification blind (on Android) or on top of the application icon (on iOS). Use the Sticker property for that. On iOS, you can set and get the value of the sticker using the SetBadge() and GetBadge() methods of the deliverable notification manager. On Windows, you cannot create a sticker on the application icon.
A certain melody can be played upon notification display. To specify a melody to play, use the SoundAlert property of the DeliverableNotification object. If SoundAlert.Default is set as the value of this property, the melody set for notifications in the used operating system will be played. If a file name is specified as the value of the SoundAlert property, this file will be played. However, developers cannot attach resources (which include playable files) in the mobile 1C:Enterprise version. To attach a notification file to the mobile application, use features of the mobile application builder. For that reason, you can check the use of sound notifications from files only in a built mobile application.

In some cases, you might need to delete set notifications that have not been triggered yet. It might be required if the action for which a notification was set has already been completed. To delete a notification, you can use the CancelLocalNotifications() method of the deliverable notification manager. Remember that if you use this method, all local notifications that were set by this mobile application, but have not been triggered are canceled at once.

After a notification appears, tapping it will start (or activate) the application. However, this may not be enough to fully process the notification. In this case, you can use the notification handler. To attach this handler, use the AttachNotificationHandler() method of the deliverable notification manager.

&AtClient
Procedure OnOpen(Cancel)
Handler = New NotifyDescription("NotificationHandler", ThisObject);
DeliverableNotifications.AttachNotificationHandler(Handler);
EndProcedure

&AtClient
Procedure NotificationHandler(Notification, Local, Shown, AdditionalParameters) Export
// Important and necessary actions
EndProcedure

As a result, after the mobile application user taps the notification, the mobile application that created the notification will be activated, and the notification handler will be called in this application. Within this handler, you can implement required notification processing. Remember that the object passed in the Notification parameter contains real data only in the Text and Data properties. The remaining properties are filled with default values.

Also consider that the notification may not be displayed in the notification blind. To inform the mobile application about this fact, the Shown parameter is passed to the notification processing procedure. So, if the mobile application is running and active, the local notification will not be displayed on the screen, but the notification handler will be called, and the Shown parameter will be set to False. In this case, the task of attracting the user's attention lies with the application developer.

29.3.6.11.3. Push-notification

General information

Push-notifications (further in this section, the terms "notification" and "push-notification" mean the same) are used to notify users of events that have occurred somewhere else. For example, in the corporate information system, some data that is important for mobile users of the system has changed.

Several different systems are used for operations with push-notifications:

Mobile application itself. It receives notifications and implements the response to them from the mobile device.
Application that sends notifications (sender). The application created on the 1C:Enterprise platform acts as the sender.
Notification delivery service. This service ensures notification transfer from the sender to the recipient (to the mobile application). This service can be:
- Apple Push Notification Service or APNs: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html
- Firebase Cloud Messaging or FCM: https://firebase.google.com/docs/cloud-messaging/
- Windows Push Notification Services or WNS: https://docs.microsoft.com/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services--wns--overview
1C Company has developed a special service for sending notifications called 1C:Notification Center. The service simplifies the process of sending notifications from the production-ready applications. The service allows you to use all services for sending notifications that are supported by the mobile 1C:Enterprise version. The service allows you to isolate recipients of one sender's notifications from other senders that use the same mobile application. Besides, the service allows you to avoid publishing confidential information, which can be directly prohibited by the policy of the service for sending notifications. The features of operating with this service will be described further in the corresponding sections. Note that 1C:Notification Center cannot function without the services for sending notifications. The service is located at https://pushnotifications.1c.com.

In general, sending a notification includes several steps:

The sender generates a notification.
The sender defines the list of notification recipients.
The sender attaches to the notification service.
The sender passes the notification and the list of recipients to the service.
The service ensures delivery of notifications to mobile devices.
The mobile application on the device processes the notification.

The push-notification delivery service does not guarantee notification delivery to a mobile device.

To use notifications, set the Push-notifications permission. The mobile application builder adds the appropriate privilege to the mobile application being built. The mobile 1C:Enterprise version for developers has some features that will be covered below. In any case, we recommend that you check the developed feature in the usual mobile 1C: Enterprise version. To do this, use the mobile application builder and check the performance of the resulting mobile application using all notification delivery services.

Push-notification processing is similar to the one of a local notification. Obviously, the Local parameter will be set to False if the handler is called to process a push-notification.

The scheme of operation with services for sending notifications

To understand how to deal with push-notifications, note that several different roles are involved in the system deployment and implementation. In some cases, role performers can be joined, but the number of roles remains unchanged:

Mobile application developer develops the mobile application (notification recipient) and implements all the required application features to receive notifications.
Notification sender's developer develops the information system that distributes notifications and the mechanism to obtain and store IDs of notification recipients.
Mobile application user uses the mobile application. This user also sets up the mobile application, so the mobile application settings must be as simple and understandable as possible even to an inexperienced user.
Sender's integrator installs and configures the system that sends notifications to the user's network.

When considering schemes of operation with a certain service, actions will be described from the point of view of the performer of a particular role.

The scheme of operation contains a description of actions to be performed by the representative of a particular role at the time of execution of their actions. The order of actions will always be the same: mobile application developer, sender's developer, sender's integrator, and mobile application user. However, this does not mean that the actual order will be exactly the same.

In addition to the actions described later in the section, the implementation of the following steps is required and will not be mentioned further:

Reaction to the notification is implemented by the mobile application developer.
Sending of notifications is implemented by the sender's developer.

It is also considered that the mobile application and the sender "know" that they can interact with each other:

The sender has a public API (exchange service) to get the notification recipient ID from the mobile application.
The recipient (mobile application) can use the exchange service that the sender publishes to perform both actions.

The actions (by roles) that must be performed to operate with a particular service for sending notifications are described further. Step-by-step instructions for performing specific steps will be given later in this section.

APNs

The mobile application developer must:

Register for the mobile application the option of receiving push-notifications on the Apple website. During registration, get a specific certificate.
Provide the received certificate to the notification sender.
Implement receiving the notification recipient ID and delivering the resulting object to the notification sender.

The sender’s developer must:

Implement a mechanism for entering and storing certificates of notification recipients.
Implement a feature for obtaining and storing IDs of notification recipients.

The sender's integrator must:

Upload the mobile application certificate to the sending system that will receive notifications.
The certificate must be obtained from the mobile application developer.

The mobile application user must:

In the mobile application, specify the parameters of the exchange service provided by the sending application.
Initiate the command to create a notification recipient ID and send it to the notification sender.

FCM

The mobile application developer must:

Register in the Firebase service for the mobile application to be able to receive push-notifications. During registration, get a server key.
Provide the received server key to the notification sender.
Implement receiving the notification recipient ID and delivering the resulting object to the notification sender.

The sender’s developer must:

Implement a feature for entering and storing server keys of notification recipients.
Implement a feature for obtaining and storing IDs of notification recipients.

The sender's integrator must:

Import the server key of the Firebase project for the mobile application (notification recipient) to the sending system.
The server key must be obtained from the mobile application developer.

The mobile application user must:

In the mobile application, specify the parameters of the exchange service provided by the sending application.
Initiate the command to create a notification recipient ID and send it to the notification sender.

WNS

The mobile application developer must:

Register on the Microsoft website for the mobile application to be able to receive push-notifications. During registration, get Application secrets and Application security IDs.
Provide the received Application secrets and Application security IDs to the notification sender.
Implement receiving the notification recipient ID and delivering the resulting object to the notification sender.

The sender’s developer must:

Implement a feature for entering and storing Application secrets and Application security IDs. This data is required to obtain an access marker, which, in turn, is used to send notifications.
Implement getting, storing, and updating access markers.
Implement a feature for obtaining and storing IDs of notification recipients.

The sender's integrator must:

Specify in the sending system the Application secrets and the Application security IDs that will receive notifications.
Application secrets and Application security IDs must be obtained from the mobile application developer.

The mobile application user must:

In the mobile application, specify the parameters of the exchange service provided by the sending application.
Initiate the command to create a notification recipient ID and send it to the notification sender.

1C:Notification Center

Use 1C:Notification Center to simplify the process of sending and receiving notifications for mass-production solutions.

The mobile application developer must:

Select the services to deliver notifications to a mobile device. Provide 1C:Notification Center with the artifacts that are required to send notifications for the used services. Remember that provided artifacts can be confidential information.
Implement receiving the notification recipient ID and delivering the resulting object to the notification sender.

The sender’s developer must:

Implement the feature for entering and storing the application server key (Sender access key) for the current instance of the system that sends notifications. The sender's integrator registrates a specific sender instance on 1C:Notification Center website.
Implement a feature for obtaining and storing IDs of notification recipients.

The sender's integrator must:

Register a specific sender instance on 1C:Notification Center website. Enter the resulting server key of the registered application (Sender access key) into respective sender settings.

The mobile application user must:

In the mobile application, specify the parameters of the exchange service provided by the sending application.
Initiate the command to create a notification recipient ID and send it to the notification sender.

APNs service operations

To test the feature for sending notifications on iOS, you need to build your own mobile 1C:Enterprise version for developers. When building, use a provision profile that supports push-notifications. When you create your own mobile 1C:Enterprise version for developers, you must specify a correct mobile application ID. Note that you cannot use com.e1c.mobile and com.e1c.mobile.ios, since they are reserved by 1C Company.

To establish connection with APNs, the mobile application certificate of the notification recipient must be available on the sending computer. There are two kinds of certificates for APNs: Apple Development IOS Push Services (developer certificate) and Apple Production IOS Push Services (public mobile application certificate). The developer certificate is designed to develop a mobile application and debug it. Use it if the application is installed on a device using development tools. Use the public mobile application certificate if the mobile application is distributed via an application store.

The mobile 1C:Enterprise version imposes the following requirements for the certificate in use:

The application certificate must be in PEM format.
The certificate must contain the Bag Attributes section with the friendlyName attribute. The system uses the value of the friendlyName attribute to distinguish between a developer certificate and a public mobile application certificate. A certificate without the friendlyName attribute will be rejected by the mobile 1C:Enterprise version.

IMPORTANT. Description of the developer console is as of the writing of the documentation.

To prepare for sending notifications using APNs, the mobile application developer must:

Sign in to the developer console (iOS Dev Center, https://developer.apple.com/devcenter/ios/index.action). The user that signed in to the console must have administrator rights in the developer console.
In the right part of the web browser window, select the Certificates, Identifiers & Profiles menu item in the iOS Developer Program section.
If the mobile application that will receive notifications does not have App ID, create it. The order of creation is described below. If the App ID exists, skip this step and go to the next one.
1. In the iOS Apps section, select Identifiers.
2. Click + above the iOS AppIDs list. If the user has insufficient rights, the create button will be unavailable.
3. In the Name field, define the application description in Latin letters. In the App ID Suffix section, select Explicit App ID. In the Bundle ID field, specify the full ID of the mobile application, which you can find in the mobile application builder. In the App Services section, select Push Notifications.
4. To go to the next screen, click Continue.
5. Check all the specified parameters and click Submit to confirm App ID creation.
6. Click Done to complete the App ID creation process.
Create a provision profile to build a mobile application that can receive notifications. This provision profile must be further used in the mobile application builder.
1. Select Provisioning profiles ‑ All in the menu on the left of the Certificates, Identifiers & Profiles screen.
2. Click + above the iOS Provisioning Profiles list.
3. Select a profile kind based on your goals. If you need it to develop and debug an application, select iOS App Development in the Development section. If a provision profile is created for application distribution, then in the Distribution section, it is necessary to select App Store item. Depending on the provision profile type, your further steps will vary.
  1. If you select a provision profile for developers and click Continue:
    1. Select the App ID of the application whose building requires a provision profile and click Continue.
    2. Select certificates for those developers who can create applications in Xcode using this provision profile and click Continue.
    3. Select devices on which the application with this provision profile will run and click Continue.
    4. Describe the profile you create in Latin letters and click Generate.
  2. If you select a provision profile for distribution and click Continue:
    1. Select the App ID of the application whose building requires a provision profile and click Continue.
    2. Select the certificate of the company that provides the application and click Continue.
    3. Describe the profile you create in Latin letters and click Generate.
  3. Download the created provision profile for further use in the Xcode system or the mobile application builder by clicking Download.
To create a mobile application certificate, you first need to generate a certificate request file. You need a Mac computer for that. Do not close the web browser window with the developer console open while creating a certificate request.
On a Mac computer:
1. Start the Keychain utility.
2. Click Keychain ‑ Certification Assistant ‑ Request a certificate from a certification authority.
3. In the opened dialog box, fill the fields. We recommend that you specify the email address specified during registration in iOS Developer Program in the User email field. In the Request property, specify Saved to hard drive.
4. Click Continue to generate the *.certSigningRequest certificate request file.
Generate a certificate for the notification sender. To do this, return to the web browser window with the open developer console.
1. Select Certificates ‑ All in the menu on the left of the Certificates, Identifiers & Profiles screen.
2. Click + above the iOS Certificates list.
3. Specify Apple Push Notification service SSL (Sandbox) if you need a certificate to develop and debug an application. Select Apple Push Notification service SSL (Production) if you need a certificate to distribute an application. Then click Continue.
4. Specify the App ID of the application in use and click Continue.
5. Click Continue. This screen prompts you to create a certificate request file that has already been created at the previous step.
6. Download the file with the .certSigningRequest extension generated at the previous step and click Generate.
7. After the certificate is generated, click Download to download it from the website.
The final step is to convert the certificate into required formats. For that, on the Mac computer where the certificate request file was generated, do the following:
1. For conversion, use Keychain.
2. Import the certificate obtained on the website to Keychain.
3. The certificate will be exported from Keychain in the P12 format.
4. The resulting certificate is converted from the P12 format into the PEM format. To do this, run the following command in the macOS console:

openssl pkcs12 ‑in pushcert.p12 ‑out pushcert.pem ‑nodes ‑clcerts

The resulting certificates are required for:

P12 certificate is required to send notifications via the 1C Company service. The certificate must be used by the recipient's developer to register the application receiving notifications in the 1C Company service.
PEM certificate is required if notifications will be sent directly over the APNs service. In this case, the certificate must be provided to the sender’s developer or the sender’s integrator if the interface of the notification sender application provides the option of specifying the certificate of the application receiving notifications.

FCM service operations

IMPORTANT. Description of the developer console is as of the writing of the documentation.

Registering a new application for FCM

The following actions must be performed by the integrator of the sending application during deployment and settings of the sending application on the customer’s computer network:

Sign in to the developer console (Firebase Console, https://console.firebase.google.com).
Create a project by clicking Add project. When creating a project, specify the project name and the country where the organization is located. The project name must contain only Latin characters. After you finish creating the project, click Continue.
On the project page, click Add Firebase to your Android application. After that:
1. In the Android package name field, specify the full application ID. With this ID, the application will be published in the Google Play store. The same ID will be used to build the mobile application in the mobile application builder. After specifying the application ID, click Register application.
2. Download the proposed file: google-services.json. You will need to specify this file in the mobile application builder. After downloading the file, click Continue.
3. Click Finish.
In the application settings, go to the Cloud Messaging tab.
The value located in the Server key field must be used as the authentication key for sending notifications (the AuthenticationData parameter of the Send() method of the DeliverableNotificationSendManager object). It is recommended to treat this key as confidential information. Receiving this key by third parties will allow them to send push-notifications on your behalf.

The resulting Server key must be provided to the integrator of the sending application to be further specified in the application settings.

Migration from GCM to FCM

The following actions must be performed by the integrator of the sending application during deployment and settings of the sending application on the customer’s computer network:

Sign in to the developer console (Firebase Console, https://console.firebase.google.com).
Create a project by clicking Add project. In the Project name field, click the selection button from the list and select the GCM application to be transferred to FCM. After that, specify the country of the organization. Click Add Firebase to start the import process.
The remaining steps are similar to those described above.
Change the code in 1C:Enterprise language so that notifications are sent by the FCM service.

GCM service operation description

You can read about GCM service operations in the documentation for 1C:Enterprise 8.3.12 or earlier (https://its.1c.ru/db/v8312doc/bookmark/dev/TI000001543).

WNS service operations

IMPORTANT. Description of the developer’s portals is provided as of the writing of the documentation.

The following actions must be performed by the integrator of the sending application during deployment and settings of the sending application on the customer’s computer network:

Sign in to the Windows Development Center (https://developer.microsoft.com/windows).
Go to the information panel by clicking Information panel.
Create a new application by clicking Create a new application. On the opened page, it is necessary to specify the name of the application that will be displayed in the application store. After specifying the name, click Check the availability to check the availability of this name. After that, click Reserve product name.
Sign in to the Application Registration Portal (https://apps.dev.microsoft.com).
Find the created application and open its page.
On the application page, get the values specified in the Application secrets and Package security IDs sections. It is recommended to treat this key as confidential information.
Specify the received values as parameters for calling the GetAccessToken() method of the DeliverableNotificationSendManager object. As a parameter of the ApplicationID method, specify the value from the Application secrets section. For the ApplicationKey parameter, specify the value from the Package security IDs section. The resulting access marker will be used to send notifications.

Provide the received Application secrets and Package security IDs to the sender's integrator to be further specified in the application settings.

When WNS is running, the value of the DeliverableNotificationSubscriberID.ApplicationID property contains a Push Notification Channel. Push Notification Channel is a URI for receiving notifications by a mobile application. Notifications are sent over a POST-request to the URI. The channel is attached to a specific application on a specific device. Remember that the value of the Push Notification Channel can change over time. It is recommended that the mobile application requests a new notification subscriber ID upon each startup and sends it to its service for sending notifications. However, the developer must consider the value of the ApplicationID property as a string with unknown contents and must not change its contents during operation.

1C:Notification Center operations

The mobile application developer must:

Register in the notification service that the application will use. If the application uses multiple services, register in all of them. Save the artifacts that each notification service provides.
Sign up on the service website: https://pushnotifications.1c.com/signup. To register there, you need a mobile phone number. During registration, a registration confirmation code will be sent to it. We recommend that you specify the data of the responsible person of the mobile application developer in contact information.
Register a mobile application that will receive notifications. To do this, select Deliverable notifications ‑ Mobile applications in the menu and click Register application.
Attach the created mobile application to the used services. To do this, in the Your mobile applications list, click Attach to APNS, FCM, or WNS. On the next screen, click the button corresponding to the service you are using and enter the parameters for interaction with this service (the full mobile application ID is required for all notification services):
- For APNS service, click + Attach to APNS. Required artifacts: mobile application certificate in .P12 format and mobile application password.
- For WNS service, click + Attach to WNS. Required artifacts: the Application secrets value received in the Windows App Store.
- For FCM service, click + Attach to FCM. Required artifacts: project server key values (Server key) received from the Firebase developer console.

The sender’s developer must:

No action is taken.

The sender's integrator must:

Sign up on the service website: https://pushnotifications.1c.com/signup. To register there, you need a mobile phone number. During registration, a registration confirmation code will be sent to it. We recommend that you specify data of the information system administrator in contact information.
Register the sender of notifications. To do this, select Deliverable notifications ‑ Notification senders in the menu and click Register sender. When registering, it is recommended that you specify a list of IP-addresses that can be used to send notifications over this service. If no addresses are specified, sending notifications is allowed from any computer that can sign in to the service.
Note that the sender’s registration is not performed by the sender’s developer, but by the sender’s integrator when the sender system instance is being set.
As a result of registration, an access key will be generated. To save this value, click Copy Access Key or Edit and copy the value from the Sender access key field. The obtained value must be specified in the settings of a specific sender application instance. It will be used as an authentication key for sending notifications (the AuthenticationData parameter of the Send() method of the DeliverableNotificationSendManager object). It is recommended to treat this key as confidential information. Receiving this key by third parties will allow them to send push-notifications on your behalf. For example, if specific values of IP-addresses were not specified when creating the sender.

The mobile application user must:

In the mobile application, specify the parameters of the exchange service provided by the sending application.
Initiate command execution to create a notification recipient ID and send it to the notification sender.

Mass notification

The actions for sending notifications are almost the same for different services. The differences are observed in the parameter values of the method for sending notifications. The actual sending happens using the Send() method of the delivery manager of sent notifications:

The following is used during notification sending as authentication data (the AuthenticationData parameter of the Sent() method):
- APNs service: mobile application certificate acquired from the developer console. It is recommended to treat this key as confidential information. To ensure that notifications are sent using APNs, outgoing connections on 2195 and 2196 IP-ports must be allowed on the computer with the sending system.
- FCM service: project server key (Server key),\ registered in the Firebase Cloud Messaging developer console. It is recommended to treat this key as confidential information.
- WNS service: value returned by the GetAccessToken() method.
- 1C:Notification Center is the sender API key (Sender access key), which was received when the sender was registered on the service website. It is recommended to treat this key as confidential information.
- If you use 1C:Notification Center to send notifications, set the UseIntermediateService parameter to True.
If sending is performed using multiple services, authentication data can be a match, where the key is a service type (the value of the DeliverableNotificationSubscriberType enumeration) and the value is the data required by the respective service.
Note that you cannot send notifications using the notification delivery service (APNs, FCM, WNS) and 1C:Notification Center at the same time (in one call to the Send() method). If the Send() method has the value of the UseIntermediateService parameter set to True, then the value of the AuthenticationData parameter can only be Sender access key received from 1C:Notification Center.
The list of notification recipients is described using the Recipients property of the DeliverableNotification object, which is the value of the first parameter of the Send() method of the delivery manager of sent notifications.

When you use WNS service, remember that the access marker value, which is obtained by the GetAccessToken() method, is not a constant value. You need to periodically get the relevant value. To determine if this procedure is required, use the DeliverableNotificationsSendingIssueInformation parameter of the Send() method. If any problem occurs while sending notifications, the above parameter will contain a list of detected problems. If there is a problem of the AuthenticationDataError type in the list of problems, refresh the access marker and try sending the notification again.

29.3.6.11.4. Features of mobile application notification processing

If the notification handler is not attached, the notification is stored in memory until the end of the session and will be passed to the notification handler after it is attached (in this session). If the handler is not attached by the session end, the notification is lost after the session is closed.

Consider the following features of operations with notifications in mobile applications:

If the mobile application is active, the notification is immediately delivered to the mobile application. In this case, the sticker and sound alert are ignored.
If the mobile application is not active at the time of receiving the notification, the notification is displayed by the operating system. If the user taps the notification, the respective application is started. If the user has deleted the notification, the application is not informed of the existence of such notification. On iOS (version 7 or earlier), the notification is deleted from the notification center either by an explicit user action or is replaced by other notifications of this application.
If the mobile application is running in the background and is not active at the time of receiving a notification, the notification is processed differently on various platforms:
- In iOS, the notification is passed to the mobile application only after being selected by the user from the notification panel.
- In Android, the notification is immediately passed to the mobile application and simultaneously displayed in the notification panel. After the user has selected a notification in the panel, the application is activated, but the notification is not passed to the application again.
- On Windows, the notification is passed to the mobile application only after being selected by the user in the notification center.
If several infobases are deployed in a mobile application, the user is prompted to switch from the current infobase to another one. If a specific infobase cannot be determined, the corresponding diagnostic message is issued.

29.3.6.12. Managing ads

29.3.6.12.1. General information

In the mobile 1C:Enterprise version, you can display ads in mobile applications. If you need to display an ad, you can customize the display of an advertising banner using Google AdMob: https://www.google.com/admob/. This service is supported by both Android and iOS.

There are several ad kinds:

Banner is a rectangular ad that occupies a part of the main application window. It can be updated automatically after some time.
Full-screen banner is a full-screen ad displayed at the moment of navigation from one application form to another. Such declaration occupies the whole screen of a mobile device.
Rewarded video ad is an add that offers a reward for viewing.

This documentation covers only technical aspects of mobile applications with the ad service.

The general scheme of ad management looks as follows:

Register your application in the service. Get an application ID from the service.
Customize ad units in the service (if necessary).
Implement an API for ad operations using the data received at the previous steps.

To manage the way ad information is displayed, use the AdRepresentation global context property. For simplification, the AdRepresentation method prefix will be omitted in the documentation. It is evident that such omissions are unacceptable in examples and real applications. After starting the mobile application, the system has the following default settings:

Ads in the mobile application are not used.
There are no defined ad unit IDs.
Ad units are not imported.
Ad information is not displayed on the screen.

For ad information to be displayed in the application, you need to:

Enable ads in the mobile application by using the SetUsing(True); method.
Depending on the ad unit used, specify the unit ID:
- Banner: the SetAdBannerID() method.
- Full-screen ad banner: the SetFullScreenAdID() method.
- Rewarded video ad: the SetRewardedVideoID() method.
Ad information is displayed by different methods depending on the used ad unit:
- Banner: the SetAdBannerRepresentation() method. Using this method, you can specify where the ad must be displayed or disable ad display.
- Full-screen ad banner: the DisplayFullScreenAdvertising() method.
- Rewarded video ad: the ShowRewardedVideo() method.
  For full-screen ads or rewarded video adds, you can set the display completion notification handler.
Time delays caused by required ad unit loading are possible during ad information display. These delays can be reduced by loading ad units in advance:
- Banner: the DownloadAdBannerAsync()/BeginAdBannerDownloading() method.
- Full-screen ad banner: the DownloadFullscreenAdAsync()/BeginFullscreenAdDownloading() method.
- Rewarded video ad: the DownloadRewardedVideoAsync()/BeginRewardedVideoDownloading() method.
  The respective handler is called after loading is completed. This handler allows determining the ad loading status and performing required actions with the help of the method parameter.
  
  Ad information pre-loading is optional. Calling the ad representation method automatically loads the required ad unit.
Ad information rotation is managed by the ad network.

Use the GetAdStatus() method to get the current status of a certain ad unit (by ad unit ID).

Use the IDs obtained in the system web interface to set ad IDs.

Ads displayed in the mobile application must comply with the AdMob rules: https://support.google.com/admob/answer/6128543. Note the following sections of the Rules:

Rules and recommendations for AdMob publishers.
Rules for rewarded resources.

29.3.6.12.2. Setting ad services

Google AdMob

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

To customize ad units, follow these steps:

Create an account in Google AdMob.
Sign in to your account at https://apps.admob.com.
If the application is built in the mobile application builder and has been tested before, you do not need to do anything. Specify ad unit IDs in the appropriate places in the application. In the mobile application built in the builder, actual ad information must be displayed.
Add a new application. To do it, select Applications ‑ Add application in the menu.
Applications published in an app store are added in a different way compared to unpublished applications. To select one of the adding options, answer the following question: Have you already published your application in Google Play or App Store?
- The application is published in the store:
  - Answer Yes to the question.
  - On the next page, start entering the application name and click Find.
  - Select the required application from the list.
- The application is not published in the store:
  - Answer No to the question.
  - On the next page, specify the application name and the operating system it runs on. If the mobile application where you want to display ads runs on Android and iOS, you need to create two AdMob applications.
  - Click Add to create a respective application.
On the Application settings page, remember the Application ID field value. You will need to specify it later in the mobile application builder.
After the application is created, go to the Ad units page of this application.
When you create an ad unit, select its format: Banner, Interstitial (full-screen ad banner) or Rewarded (rewarded video ad). To do it, click Select next to the required ad type.
The name (property of the same name) is generated and other ad unit parameters (if necessary) are specified afterwards.
Click Create ad unit to complete the creation operation. The button is inactive until all parameters required for the ad unit creation are set.
Two ID types will be presented on the Ad unit created page. The first iD is the application ID. Remember the second ID to use it later in 1C:Enterprise language. The same ID can later be found in the ad unit properties as Ad unit ID field value.

Operations with ad units can also be performed as follows:

Sign in to Google AdMob at https://apps.admob.com.
Select the required application from the list.
Specify Ad units on the left of the page.
After that, you can create and set required ad units. The ad unit ID required for use in 1C:Enterprise language will be accessible in the properties of each ad unit.

Use IDs obtained when creating ad units as parameters of the following methods: AdRepresentation.SetAdBannerID() and AdRepresentation.SetFullScreenAdID().

29.3.6.12.3. Testing ads

Google AdMob

The general testing scheme of ad information display when using Google AdMob is as follows:

Ad information display testing does not require mobile application publication in an application store.
For testing, you only need ad unit IDs. To create ad units, register the application being developed in Google AdMob service.
After registering the application in Google AdMob, you need to create ad units. Their IDs will be used in the developed mobile application both during testing and in actual operation.
While the application is running on a mobile developer platform, ad units display test content. After the application is built by the mobile application builder, it will start displaying real ad information.

29.3.6.13. In-app purchase operations

29.3.6.13.1. General information

In the mobile 1C:Enterprise version, developers can implement in-app purchases in their applications. The following purchases are supported:

Non-consumable purchase. It is used on all supported operating systems. An item is purchased once for the user account of the mobile device. Applies to all mobile devices running under one account. For distribution, a purchase recovery mechanism is used.
Consumable purchase. Used on iOS and Windows. An item can be purchased any number of times. Information on such item acquisition is sent to a mobile device only at the moment of purchase start. On Android, consumable purchase is implemented in applications using platform tools.
Subscription. It is used on all supported operating systems. An item is acquired as a non-consumable purchase valid for a certain time. You can set up automatic renewal of the purchase upon subscription expiration. In this case, the subscription fee is deducted from the payment instrument linked to the user account. Subscription fee cannot be changed on Android. On iOS, changing the subscription fee disables automatic subscription renewal. Deleting the application where a purchase has been made does not disable automatic renewal of subscriptions. Subscriptions are managed via Apple AppStore, Google Wallet, or a Microsoft account. You cannot implement a subscription management interface in a mobile application.
On Windows, subscriptions are available only on mobile devices running Windows 10 version 1607 or later. SDK Windows 10 version 14393 or earlier must be installed on the mobile application builder server.

Mobile application purchases are carried out using external services:

iOS: Apple In-App Purchase.
Android: Google Play In-App Billing. The device must have the latest version of Google Play application installed.
Windows: Windows In-App Purchase.

When you implement purchases in a mobile application, remember that purchased items are regulated by owners of application stores (Apple, Google, and Microsoft companies).

In general, in-app purchases must fully comply with the requirements of service owners:

As an example, the following types of content are permitted and prohibited:

Allowed purchase items:
- Mobile application features
- Services directly related to mobile applications
Forbidden purchase items:
- Goods and services used outside of mobile applications

29.3.6.13.2. Scheme of use

To use purchases, set the In-app purchases permission for the mobile application being developed. To access the data history, use the InAppPurchases global context property. The in-app purchase manager is available via this property. Therefore, calling the API methods will look as follows: InAppPurchases.CalledMethodName(). For simplicity, the name of the global context property will be omitted in the following text. Obviously, in a code in 1C:Enterprise language, such simplification is not applicable.

The general scheme of operation with in-app purchases in a mobile application is as follows:

Configure in-app purchase services to interact with the developed mobile application. When setting up the services, you might need to upload the developed mobile application with enabled in-app purchases to the application store. At the same time, the mobile application you will upload does not have to contain the purchase feature. It is required for the features of the purchase service to function. However, the full ID of the uploaded application must match the one of the final mobile application version with available in-app purchases.
After setting up the services, create required purchase items (in each of the services) and commit their IDs and types.
In the mobile application, check whether purchases are supported on this device. To do this, use the PurchasesSupported() property.
If purchases are supported, update the list of completed and available purchases using the UpdatePurchaseInformation() method. Without that, purchasing will be unavailable in the future.
It is recommended that you update the purchase information regularly, as the list of made purchases can be changed not only on the current device.
To make a purchase, use the BeginPurchasing()/PurchaseAsync() method. As a method parameter, pass the purchase ID (as it is specified in the respective service) or the InAppPurchase object, which you can get using the GetList() method. Some mobile operating systems require a client application to acknowledge purchases. This acknowledgement can be done either automatically by the mobile platform or programmatically. To acknowledge a purchase automatically, use a special method parameter for making purchases and updating the list of purchases. To acknowledge a purchase programmatically, use the AcknowledgePurchase() method. To check whether acknowledgement is required, use the PurchaseAcknowledgementSupported() method.
These algorithms are suitable for manual purchase acknowledgement. The system behavior will be described separately.
To consume purchases, use the ConsumePurchase() method. After the method is executed, a request is made to the purchasing service, which indicates that the purchase has been spent and is available for re-purchase. To determine whether a purchase can be consumed, use the PurchaseConsumingSupported() method. If the method returns True, it means that in-app purchases can be consumed. Such option is provided on Android and Windows.

29.3.6.13.3. Purchase management

When it comes to purchasing an artifact, the developer of the mobile application where the purchase is made tries to find out the following:

Has the user purchased a paid artifact? An artifact is any in-app purchase type.
Has the user paid for the purchase for our application and in our application store? In other words, is the user trying to use a paid artifact without paying, that is, illegally?
Has the user paid immediately or just notified the system that they want to buy an artifact?
Which artifact has been purchased and which parameters does the purchase have?

The application can initiate a purchase using the following methods: BeginPurchasing() and PurchaseAsync(). After the user performs some actions, these methods operate in a slightly different way, but they have similar results: you can get a purchase receipt or a message about problems with a purchase. If the purchase was unsuccessful, this may mean either that an actual error occurred when making the purchase (no connection, payment error, and so on) or that the user postponed the payment for the purchase (in the store where it is possible) and wants to pay for the purchase later. The purchase is successful if:

Purchase completion notification handler has the Success parameter set to True (for the BeginPurchasing() method).
Wait returned the InAppPurchaseReceipt object (for the PurchaseAsync() method).

The purchase fails if:

Purchase completion notification handler has the Success parameter set to False (for the BeginPurchasing() method).
Wait returned Undefined (for the PurchaseAsync() method).

After the user completes their actions, some extra actions might be required in 1C:Enterprise language:

Do the following only if the purchase is unsuccessful:
- Update the list of completed and available purchases using the UpdatePurchaseInformation() method.
- Make sure the purchase is really made. To do this, use the CheckPurchased() method.
- If the purchase is made, follow the next steps. If the purchase is not made, no further actions are required.
Get the purchase receipt. To get the receipt, use the GetInAppPurchaseReceipts() method. You can get the in-app purchase receipt (an object of the InAppPurchaseReceipt type) as a parameter of a purchase completion handler or as a promise execution result.
Validate the purchase receipt using the methods of the InAppPurchasesValidation global context property. You can validate the in-app purchase receipt both on the mobile device and on the side of the application for personal computers. The validation is performed in the same way. The difference is that when you validate the receipt with the application for a personal computer, other channels of communication with the purchase service and a different validating system environment are used. This significantly reduces the possibility that the user tries to use a paid artifact without paying.
The purchase receipt validation is performed as follows:
- Android: the digital signature of the purchase receipt is verified.
- iOS: a request is sent to the Apple server to verify the received receipt. The request is sent to https://buy.itunes.apple.com/verifyRecepient (https://sandbox.itunes.apple.com/verifyRecepient during testing).
- Windows: the digital signature of the purchase receipt is checked. The digital signature validation certificate is obtained from Microsoft website: https://go.microsoft.com/fwlink/?LinkId=246509&cid=CertificateID.
  To validate the receipt on the side of a personal computer (if possible), use the InAppPurchasesValidation.ValidateInAppPurchaseReceipt() method. In the mobile client, it is always recommended that you use this validation method. In the mobile platform, we recommend that you use validation on a personal computer, if possible (the mobile application has a server). If you can validate the receipt only on a mobile device, use the InAppPurchasesValidation.ValidateInAppPurchaseReceiptAtMobileDevice() method.
Acknowledge the purchase. In other words, notify the application store that the user received the purchased artifact. This acknowledgement is not always required and depends on the mobile operating system that the mobile application is running on. To check whether purchase acknowledgement is required, use the PurchaseAcknowledgementSupported() method. If purchase acknowledgement is required, use the AcknowledgePurchase() method to acknowledge the purchase.
If the user makes a consumable purchase that is consumed immediately after the purchase using the ConsumePurchase() method, the purchase is acknowledged automatically. If a consumable purchase is consumed after some time, this purchase must be acknowledged immediately after the purchase as a regular purchase.

The information above describes what to do if automatic purchase acknowledgement is disabled upon purchasing. If automatic purchase acknowledgement is enabled, the purchase receipt is validated automatically and the purchase is also acknowledged automatically. The in-app purchase receipt is automatically validated on the side of a mobile device (the InAppPurchasesValidation.ValidateInAppPurchaseReceiptAtMobileDevice() method is used). The behavior is similar when using the UpdatePurchaseInformation() method:

If automatic purchase acknowledgement is disabled, encode the entire algorithm described above.
If automatic purchase acknowledgement is enabled, the mobile version automatically validates the in-app purchase receipt and acknowledges the purchase.

To ensure that the mobile version can acknowledge purchases automatically, build a mobile application with the In-app purchases verification key parameter specified. If this key is not specified upon building, the mobile application will not allow you to acknowledge purchases.

The application developer can get access to the purchase receipt data. With this data, you can check whether the purchase receipt ID is unique, whether the purchase date is valid, and so on. To do this, you can use the InAppPurchaseReceiptData object. Use this object to get access to the in-app purchase receipt data that is available in all supported in-app purchase services. To get access to the original receipt data, which depends on the operating system and the used application store, use the InAppPurchaseReceiptData.SourceData attribute. To get the in-app purchase receipt data, use the GetInAppPurchaseReceiptsData() method. This method requires an array of in-app purchase receipts and the respective set of purchase IDs.

29.3.6.13.4. Setting in-app purchase services

General information

To find information about the features of specific purchase types and system behavior when operating with purchases, see the documentation of the respective operating system.

Apple In-App Purchase

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

Sign in to the Member Center (https://developer.apple.com/membercenter/index.action) as a developer.
Go to the Certificates, Identifiers & Profiles section.
Go to the Identifiers section.
Register the iOS App ID for the application if it has not been registered in Member Center yet. Note that the registered ID must match the full ID of the mobile application where you plan to integrate in-app purchases. When creating an iOS App ID, make sure that the In-App Purchase service is enabled.
If you plan to use the mobile platform for developers to manage in-app purchases, follow these steps:
1. Go to the Provisioning Profiles section.
2. Create a new provisioning profile.
3. Specify that this profile is intended for iOS App Development.
4. Specify the iOS App ID created at the previous step as as the App ID. You cannot specify iOS Wildcard AppID at this step .
5. Further, you will need to use the created provisioning profile in the mobile application builder.
Sign in to iTunes Connect (https://itunesconnect.apple.com).
Go to the Agreements, taxes and banking section.
Accept the Paid Application agreement. At the same time, specify details of the bank account to which the earned funds will be transferred.
Go to the Functions tab.
Go to the In-app purchases section (open by default).
To add a new in-app purchase, click + to the right of the In-app purchases list title.

Google Play In-App Billing

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

To create in-app purchases, follow these steps:

Sign in to the Google Play Developer Console (https://play.google.com/apps/publish/).
Create or find a mobile application where you plan to implement in-app purchases. At this stage, a mobile application with enabled In-app purchases must be build. It does not have to include the purchasing feature. The application must be built in the mobile application builder. The assembled application should be downloaded to the application store (in the status of the alpha version).
Go to the application page.
On the application page, in the Services and API section, remember the value of the LICENSE KEY FOR THIS APPLICATION field. This value will be required to validate in-app purchase receipts on the side of the application for personal computers.
Go to the Content for sale section.
Add a new in-app purchase item by clicking + Add product. Be careful when adding products! They cannot be deleted.

Windows In-App Purchase

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

To create in-app purchases, follow these steps:

Sign in to the Windows Development Center (https://developer.microsoft.com/windows).
Go to the information panel by clicking Information panel.
Go to the required application page. Find Customization on the page and click Create new customization. This will open the Create new customization page.
Several types of purchases are presented on the page. The following types are supported by the mobile 1C:Enterprise version:
- Durable or non-consumable purchase in 1C:Enterprise terms.
- Developer-managed consumable or consumable purchase in 1C:Enterprise terms.
- Subscription (named the same in 1C:Enterprise terms).
  After slecting one of the types, insert the unique purchase ID in the Product code field. This ID will be used for in-app purchase operations in the configuration code. After that, click Create customization. This will open the page of just created purchase.
Select Start sending on the page. This will open a page where you can fill the following purchase data: Properties, Price and availability, Age category, and Description in Store (in different languages).
In the Properties section, specify the purchase lifetime (if it is a non-consumable purchase) and the type of content supplied with this purchase.

In the Price and availability section, specify the item price and whether it can be searched for in the store or item availability for purchase.

It is recommended that you set the price to "free" at first to avoid charging at the purchase testing stage. The desired price needs to be set after testing.

In the Description in Store section, specify the item description in all supported languages. You can also add an icon for the selected item.

29.3.6.13.5. Testing in-app purchases

General information

This section contains recommendations for testing in-app purchases. The recommendations cover the interaction between a mobile application (mobile platform) and an in-app purchase service.

On Android

General information

In-app purchase testing for mobile applications on Android can be divided into two parts:

Testing in-app purchase algorithms, their accuracy and correctness of the mobile application response to made purchases. This testing is performed using the mobile platform for developers and the mobile application builder provided by the Google Play In-App Billing emulator.
Final testing that involves operation check of the mobile application to be published in the application store. Purchases will be made over the real Google Play In-App Billing service, but without any actual charging.

Both tests will be described further in more detail.

On the developer platform

The developer platform supports testing of in-app purchases without building an actual mobile application. To do this, in the properties of the infobase where testing will be performed, fill the Purchase server address and User ID properties.

Purchase testing tools provided by Google do not allow using the mobile 1C:Enterprise version for developers for that purpose. Therefore, a service that emulates Google Play In-App Billing is implemented in the mobile application builder.

To use this service, publish the PurchasesTest HTTP-service on a web server. Specify the published HTTP service address in the Purchase server address infobase property.

In the builder, create a user with the Purchase test role. In the mobile application builder, open a tool for testing in-app purchases: Desktop ‑ Service ‑ Testing in-app purchases.

In the Mobile application field, select the mobile application whose in-app purchases will be tested. The contents of the remaining tables are associated with the selected application.

In the Test users table, you can specify several users on whose behalf making in-app purchases will be tested. If you specify different test user IDs in the infobase properties on a mobile device (the User ID property), making purchases on behalf of different mobile application users will be checked faster.

In the Available purchases table, create a purchase list that will perfectly match the list to be later created in the Google Play Developer Console. Pay special attention to item IDs and purchase types. When specifying the purchase currency, use a currency code from the standard ISO 4217: http://www.iso.org/iso/ru/home/standards/currency_codes.htm.

In the Made purchases table, you can create the required configuration of the test environment: which user, what they have purchased, if it is possible to disable purchase acquisition, and so on.

Built application

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

At first, perform all required operations to pre-set the Google Play In-App Billing service. When setting up, specify the mobile application ID that will be used for the application being developed.

Sign in to the Google Play Developer Console (https://play.google.com/apps/publish/).
Go to the Settings section on the left of the screen.
In the Testers' Gmail Accounts section, specify the email addresses of those application developers who will test in-app purchases. The developers (or testers) listed here will be able to make purchases without making a real payment. However, when making a test purchase, specify the data of a real, solvent bank card. A test debit (with subsequent return) of a small amount (approximately 1 USD) will be made from this card to verify the correctness of the specified data.
Accounts listed as testers may participate in product testing.

On iOS

General information

Testing of in-app purchases for a mobile application on iOS can be divided into two parts:

Testing in-app purchase algorithms, their accuracy and correctness of the mobile application response to made purchases. This testing is performed using the mobile platform for developers and Apple In-App Purchase service running in test mode.
Final testing that involves operation check of the mobile application to be published in the application store. Purchases will be made over the real Apple In-App Purchase service, but without any actual charging. A special application called TestFlight is used for testing.

Both tests will be described further in more detail.

On the developer platform

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

At first, perform all required operations to pre-set the Apple In-App Purchase service. When setting up, specify the mobile application ID that will be used for the application being developed.

After configuring the settings, build a mobile developer platform and specifying the ID of the mobile application that was used to set up the service.

Specify user accounts that will be able to test in-app purchases in the sandbox. To do this, follow these steps:

Sign in to iTunes Connect (https://itunesconnect.apple.com).
Go to the Users and roles section.
Go to the Sandbox Testers tab.
On this page, add emails of those users who will perform the role of testers.
Accounts listed as testers can participate in product testing using the developer platform.
- Using TestFlight program

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

At first, perform all required operations to pre-set the Apple In-App Purchase service. When setting up, specify the mobile application ID that will be used for the application being developed.

Then perform the following operations:

Sign in to iTunes Connect (https://itunesconnect.apple.com).
Go to the Users and roles section.
Go to the My applications section.
Find the application you plan to test.
Import the mobile application built using the mobile application builder.
Go to the properties of the mobile application.
Go to the TestFlight section.
Go to the the Internal testing section (open by default).
Specify internal testers that will test the selected mobile application.
Accounts listed as testers may participate in product testing.

On Windows

On the developer platform

The in-app purchase testing procedure is similar to the one for applications on Android.

29.3.6.14. Mobile application usage statistics

29.3.6.14.1. General information

Once a mobile application is developed and its first version is released, various questions start arising. For example:

On which devices and operating system versions is the mobile application most often used?
Why is a certain function of the application not used?
Which functions are used most often?
Which application parts cause most issues?
Which advertising source leads to installing the application most often?
Other specifics.

To find answers to these and similar questions, use mobile application analytics services. Note that this information is not a documentation (or a tutorial) for analytics services. It is just a description of the interaction between the mobile 1C:Enterprise version and supported analytics services.

The general procedure is as follows:

A conversion file is attached to the application or a program code is embedded. This file will generate events for the analytics service. We recommend that you first analyze which questions you want to be answered. Most analytics services are paid tools. If you decide to send all possible events to an analytics service for your application, it might not be very cost effective.
In the Mobile Application Builder, specify the analytics service (from the list of supported services) that will be used in the mobile application and the service settings. When the developer needs to use an analytics service in the mobile 1C:Enterprise version, other settings are required. It will be described in a separate section.
Publish the mobile application in the respective application store.
The application will start sending usage statistics to the service and an analyst of the mobile application developer company will start analyzing the received information.

To operate with the statistics service, use the ApplicationUsageStatistics global context property. For simplicity, the ApplicationUsageStatistics method prefix will be omitted in the documentation. It is evident that such omissions are unacceptable in examples and real applications.

The mobile 1C:Enterprise version supports the following statistics services:

AppMetrica (for Android, iOS, and Windows).
Firebase Analytics (for Android and iOS).

29.3.6.14.2. Mechanism structure

To use a statistics service, either use the mobile version of the developer, or build a mobile application and specify that the application will use a statistics service. If an application on a mobile device can interact with a statistics service, manage the actual interaction with the statistics service using a check box in the mobile application settings and a settings file.

The mobile application sends information about its events to a statistics service. For the statistics service, events are divided into two large groups:

Events. An event is any user interaction with a mobile application interface on a mobile device.
Screens (pages). A screen is a particular event instance. A screen is the change of an active form in the application to be analyzed. The term "screen" is used because some statistics services use the concept of screens to generate various reports.

In the documentation, events and screens will be both referred to as "events". If necessary, these terms will be distinguished explicitly. The mobile 1C:Enterprise version divides events into the following subclasses:

Source events. Events that are generated by the mobile version or the code in 1C:Enterprise language.
Sendable event. Events that are created based on source events and sent to the statistics service.

To convert a source event to a sendable event, use special settings. These settings are an XML file in a specific format. The conversion is as follows:

The mobile application statistics provider (the mobile version module that is responsible for the event conversion and interaction with the service) imports the settings file. This happens when the mobile application is started, before the mobile configuration is initialized.
Source events are passed to the statistics provider.
According to the rules specified in the settings file, the statistics provider converts source events to sendable events.
Sendable events are sent to the analytics service.

There are three ways you can send an XML settings file to the mobile application. They are specified below in ascending order of priority:

Use the mobile application builder. Specify this file when setting up the application to be built and do not specify the file update address. In this case, the built version will apply the described rules to convert source events to sendable events. You can change the rules only by releasing a new mobile application version. This method is recommended.
Use the mobile application builder but this time specify the file update address from which the mobile application will receive a new file with event conversion rules. In this case, you can update sendable events without releasing a new mobile application version. This method is also recommended.
Implement the entire script or its part in 1C:Enterprise language. To get and specify settings, use the GetSettings()/SetSettings() methods. There are similar methods for sending source and sendable events. This method is not recommended. The reason why it is not recommended is that to disable a statistics service, you will need not only to rebuild the mobile application but also change application source texts. You will need to change source texts to exclude 1C:Enterprise language calls that will be unavailable if the mobile application is built without the statistics service support.

So, the most optimal option to connect a statistics service to a mobile application is to use the mobile application builder and to avoid using 1C:Enterprise language.

To enable sending events to the analytics service, follow the steps:

Prepare the settings file for event conversion.
In the Mobile Application Builder, specify a statistics service that the mobile application will use, set up the statistics provider, and import the settings file to the Mobile Application Builder.
Build the mobile application.
Send the mobile application to a mobile device.

When you use a statistics service, remember about legal aspects of using such services. The developer of an application using a statistics service must control the information that is sent to the service and comply with the rules of the used statistics services and stores that distribute the application. Besides, the developer must consider the following aspects:

By default, it is assumed that all transferred data is anonymized and there is no way to associate this data with a certain application copy based on this data. In this case, the developer must only warn the user about using statistics services in User Agreement.
If the application sends IDs that can later be associated with a certain application copy to the service (if this does not violate the rules of used services), the user must be shown a separate dialog box where they explicitly agree or disagree with this.
Transferring any personal user data to the statistics service is prohibited.

The developer of an application with enabled application usage statistics must comply with all regional laws related to user data registration. In particular, when using an application on the territory of the Russian Federation, the developer must comply with the requirements of Article 138.1 of the Criminal Code of the Russian Federation, which regulates the illegal trafficking of special technical means intended for secret receipt of information.

29.3.6.14.3. Statistics manager methods

The mobile 1C:Enterprise version allows interacting with the statistics provider in 1C:Enterprise language. This method is not recommended.

With 1C:Enterprise language, you can:

Get and install the settings file. To do this, use the following methods : GetSettings()/SetSettings()/GetCurrentSettings(). The difference between these methods is as follows:
- The GetCurrentSettings() method always returns the settings that are currently being used to convert source events to sendable events. For this method, it does not matter how the settings were received: from the mobile application (set in the builder), as a result of settings update via an Internet resource, or using 1C:Enterprise language methods.
- Use the GetSettings()/SetSettings() methods to specify settings programmatically. If you call the SetSettings() method with a certain settings file, the settings are reset. After that, the GetCurrentSettings() method returns the settings that have been just set. If you call the SetSettings() method by passing it Undefined as a parameter, the GetCurrentSettings() method starts returning the settings specified in the builder or received via a web service.
The GetUpdateAddress()/SetUpdateAddress()/GetCurrentUpdateAddress() methods operate similarly to the methods that process settings. However, these methods process the Internet service address that allows you to update a file with settings for converting source events to sendable events.
The SendEvent()/SendScreen() methods pass events and screens directly to the statistics service, bypassing the conversion.
The CallSourceEvent() method generates a source event that will be input into the event conversion mechanism using the settings file. This method is somewhat similar to an interactive user action.

29.3.6.14.4. Settings file

To set up conversion of source events to sendable events, use the settings file. This XML file describes event conversion rules. The file format is described by a schema (in XSD format), which is a part of the distribution package of the mobile 1C:Enterprise version.

In general, the settings file looks as follows:

<applicationUsageStatistics>
<events>
<sourceEvent name="ApplicationStart">
</sourceEvent>
<sourceEvent name="FormOpen">
<eq property="Name" value="OrderForm"/>
<targetEvent name="Order" param1="%ПолноеИмя%" type="screen"/>
</sourceEvent>
<sourceEvent name="Press_1">
<targetEvent name="PressButton" param1="%event parameter Press_1%"/>
</sourceEvent>
<sourceEvent name="Press_2">
<targetEvent name="PressButton" param1="%event parameter Press_2"/>
</sourceEvent>
</events>
</applicationUsageStatistics>

The file contains a section that describes the event conversion rules (the <events> element). Let us take a closer look at these rules.

events

This element describes how source events will be converted to sendable events. Each source event is described using the nested <sourceEvent> element.

sourceEvent

This element describes a single source event and the rules for its conversion to a sendable event. The source event name is specified in the name attribute of the <sourceEvent> element. To specify the rules, use the following elements: eq (equal to), ne (not equal to), gt (greater than), ge (greater than or equal to), lt (less than), le (less than or equal to), and like (like). To specify a sendable event, use the <targetEvent> element.

Condition elements have the following attributes:

name. Specifies the name of the parameter whose value will be checked. The names and set of parameters depend on the source event.
value. Determines the value of the parameter to be checked.

All conditions specified for one source event are combined "by AND". Names of source events and their parameters are case-insensitive.

The mobile version supports the following source events:

ApplicationStart. Starts the mobile application.
- No parameters.
ApplicationFinish. Exits the mobile application.
- No parameters.
ApplicationSleep. Puts the mobile application to sleep.
- No parameters.
ApplicationWake. Wakes up the mobile application.
- No parameters.
FormOpen. Opens a form. The event has the following parameters:
- FullName. Full form name.
- Name. Form name (the Name property of the form to be opened).
- CurrentTitle. Title of the form to be opened.
- CurrentURL. URL of the form to be opened.
FormClose. Closes the form. The event has the following parameters:
- FullName. Full form name.
- Name. Form name (the Name property of the form to be closed).
- CurrentTitle. Title of the form to be closed.
- CurrentURL. URL of the form to be closed.
CommandExecute. Executes a command. The event has the following parameters:
- FullName. Full command name.
- Name. Command name (the Name property of the command to be executed).
- CurrentTitle. Presentation of the command to be executed.
- CurrentURL. URL of the command to be executed.
Arbitrary ID of the source event that is generated programmatically. In this case, event parameters and their purpose are determined by the parameters of the CallSourceEvent() method.

If the <sourceEvent> property that does not contain subordinate elements is specified in the settings file, this source event will be passed to the statistics service, but the sendable event name will be generated as Object_SourceEventName. Object is a full name of the configuration object that called the source event (accurate to the mobile application settings in the builder). If several infobases from the same configuration of the same mobile application are created on one device, events from these infobases will be completely the same.

targetEvent

The <targetEvent> element describes a sendable event and has the following attributes:

name. Sendable event name. If the name is not specified, it is generated automatically.
param1 and param2. Sendable event parameters. The parameters are determined from the point of statistics services or a user event.
type. Sendable event type:
- event. The event is sent to the statistics service as an "event". This is the default attribute parameter.
- screen. The event is sent to the statistics service as a "screen".

29.3.6.14.5. Setting up statistics services

General information

You can find information on how to set up and operate with certain statistics services in the documentation of these services. In this section, you can find information on how to connect the respective analytics service to the mobile 1C:Enterprise version.

AppMetrica

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

Sign in to the AppMetrica service (https://appmetrica.yandex.ru/) as the user that will analyze operation results (application developer).
On the first screen, click Connect.
In the application add wizard, do the following:
- In the Application name field, specify the name of the application to be added.
- Specify that an application (not a game) is added.
- In the Application category field, specify the most suitable category for the application to be added.
- If the application is published in a store, in the Application link section, specify a link to the published application.
- At the Details step, in the GDPR field, specify the current time zone and confirm additional data processing conditions (if necessary).
- Click Add application.
Once you click Add application, the application to be created is added to the service. On the last page, save data specified in the API key field. Use this value to fill the Application ID in statistics service field in a dialog box to set up the statistics provider in the mobile application builder.

Firebase Analytics

IMPORTANT. The description of operating with the web interface is given as of the time of writing the documentation.

The following actions must be performed by the user that will analyze operation results (application developer):

Sign in to the developer console (Firebase Console, https://console.firebase.google.com).
Create a project by clicking Create project. When creating a project, specify a project name. The project name must contain only Latin characters. Once you enter the project name, click Continue.
On the page with property details of the project to be created, you can specify whether Google Analytics must be enabled in the project. This check box is selected by default. After that, click Next.
Specify the country where the company that owns the project to be created is located. After that, agree to all the service terms and click Create project. Once the project is created, click Next.
On the project page, add a mobile application for Android or iOS. To do it, use two buttons under the title: Add Firebase service to your application. To add an application:
- Android:
  - Click the button with a robot image.
  - In the Android package name field, specify the full application ID from the mobile application builder.
  - Fill the Application alias and Certificate hash for debugging fields if you want.
  - Click Register application to register the application.
  - At the Download configuration file step, click Download google-services.json.
- iOS:
  - Click the button with the iOS label.
  - In the iOS package name field, specify the full application ID from the mobile application builder.
  - Fill the Application alias and App Store ID fields if you want.
  - Click Register application to register the application.
  - At the Download configuration file step, click Download GoogleService-Info.plist.
Import the file downloaded upon registering the application in the service to the mobile application builder. Do it when you set up building parameters for the respective mobile operating system.

29.3.6.15. Internet connection characteristics

When using a mobile application, tasks of exchanging information with an external system via the Internet often arise. In this case, the task of exchanging only through certain types of Internet connection may arise, or only if the Internet connection has sufficient bandwidth (speed) to perform the exchange.

In the mobile 1C:Enterprise version, you can determine parameters of the Internet connection currently used on a mobile device. To get these parameters, use the InternetConnectionInformation global context property.

To determine the type of Internet connection, use the InternetConnectionInformation.GetConnectionType() method. The system recognizes the following Internet connection types: mobile Internet connection (GRPS, EDGE, and so on), WiFi connection, local area network connection, and no Internet connection.

Using the InternetConnectionInformation.GetExpectedSpeedOfInternetConnection() method, you can estimate the expected speed of the current connection. If the method returns 0, there is no Internet access on the mobile device at the moment.

To find out whether the device is roaming, use the InternetConnectionInformation.GetRoamingUsage() method. Roaming may mean that the billing of the downloaded data using a mobile data network significantly (dozens of times!) exceeds that in a home network. If the function returns Unknown, this means that the type of used connection is not equal to the InternetConnectionType.CellularData value.

An important feature of Internet connection tools in the mobile version is the ability to attach a handler that will be triggered in the following cases:

When an Internet connection type is changed. This case also includes the situation when any access to the Internet on the mobile device is turned off. For example, the user enabled “flight mode” on their device.
When expected speed of Internet connection via mobile Internet is changed. In this case, changes in the used mobile cellular standard are recorded. For example, switching from a 2G standard network to a 3G standard network, and so on.
When the roaming state changes for the current mobile device.

To attach or detach the Internet connection change handler, use the AttachInternetConnectionChangeHandler() or DetachInternetConnectionChangeHandler() methods of the InternetConnectionInformation object.

29.3.6.16. Additional user check

29.3.6.16.1. General information

In a mobile application, it might be required to check whether the device is currently used by its owner. For instance, a function unaccessible to all users granted access to an unlocked mobile device is selected. Moreover, the user might need to store confidential data in the mobile device memory. For example, authorization details (username and password) required to access a remote service.

In such cases, an application needs to perform user authentication in any way: using a password, graphic key, fingerprint, and so on. This authentication can be performed using the AdditionalUserVerification and SecureStorage global context objects. For more information concerning these properties, see below.

When it comes to additional user verification, note that such verification is not a method to authenticate a user. The additional user verification does not help to determine whether a device is used by a specific user or not. It only confirms that the user currently using this device knows how the phone is unlocked. In other words, a phone owner can be identified (considering the specified restrictions). For example, if you tell your business partner how to unlock your device (your PIN code or graphical password), the telephone software will not be able to identify who is using your device: you or your business partner.

29.3.6.16.2. Additional user verification

Use the AdditionalUserVerification global context property to ensure that an application installed on a mobile device runs an additional user validation process to verify that a mobile device (and mobile application) is currently used by its legal owner. The AdditionalUserVerification property grants access to the AdditionalUserVerificationManager object. To be granted access to any manager property or method, use AdditionalUserVerification.Method(). To simplify method descriptions, the AdditionalUserVerification prefix will be ignored. It is evident that such omissions are unacceptable in examples and real applications.

Before starting additional verification, make sure the device supports this feature. To do that, use the VerificationSupported() method. An additional verification method required to be checked is used as a parameter. If the device supports the feature, you can perform user verification (identification).

To identify a user, use the VerifyAsync()/BeginVerification() method. An additional verification method and details of a handler to be used upon verification completion are passed to the method. The text message displayed by the platform to the user is also passed to the method. This text has to describe why respective actions must be performed by the user. Obviously, a verification method specified in the VerifyAsync()/BeginVerification() method must match the verification method used to determine whether the additional verification is supported by the device.

If the mobile device supports biometric user identification, to get the currently used method, use the CurrentBiometricVerificationMethod() method. The resulting value can be used for different purposes, for instance:

Generate a message that is passed to the VerifyAsync()/BeginVerification() method.
Determine whether the verification method in use is reliable enough for the application developer.

For a general example of additional verification of a mobile application user, see below:

Procedure VerifyUser()
VerificationMethod = AdditionalUserVerificationMethod.BiometricsOnly;
If Not AdditionalUserVerification.VerificationSupported(VerificationMethod) Then
Return;
EndIf;

CurrentBiometrics = AdditionalUserVerification.CurrentBiometricVerificationMethod();
If CurrentBiometrics <> BiometricVerificationMethod.FingerprintRecognition Then
Return;
EndIf;

Message = "Scan your fingerprint";
Result = Await AdditionalUserVerification.VerifyAsync(VerificationMethod, Message);
If Not Result Then
// the user is verified
EndIf;
EndProcedure

29.3.6.16.3. Secure storage

Use the SecureStorage global context property to enable an application installed on a mobile device to access a secure storage where confidential information is saved. The SecureStorage property grants access to the SecureStorageManager object. To be granted access to any manager property or method, use SecureStorage.Method(). To simplify method description, the SecureStorage prefix will be ignored. It is evident that such omissions are unacceptable in examples and real applications.

Secure storage stores data which can be accessed if you have a proper text key. The key is a unique value within the application. In the storage, data of any kind that supports XDTO-serialization can be used. The Undefined value cannot be placed in the secure storage. Whenever any data is placed in the storage, secure storage access restriction method is set up: a value of the SecureStorageAccessProtectionMethod system enumeration:

ScreenUnlockRequired. The application can access the secure storage if the user unlocks any relevant device (gets access to the device desktop).
AdditionalUserVerificationRequired. To access the secure storage, the user must pass additional verification. To set an additional verification method, use the second parameter of the AccessProtectionSupported() method (one of AdditionalUserVerificationMethod enumeration values).
No. To access the secure storage, no additional verification is required. The mobile operating system guarantees that access to secure storage is granted only when a mobile device is successfully started.

The said setting defines the following behavior:

To access a value, you need to use the verification method specified when the said value is set.
If a proper access protection method supported by a mobile device is disabled, data put in the secure storage with this disabled protection method will be deleted from the storage and become unaccessible.

The secure storage has a number of distinctive features that depend on the mobile operating system in use:

Android:
- Storage size: unlimited.
- Single element size: unlimited.
- Number of storage elements: unlimited.
macOS:
- Storage size: 80 MB.
- Single element size: 16 MB.
- Number of storage elements: unlimited.
Windows:
- Storage size: 320 KB.
- Single element size: 16 KB.
- Number of storage elements: 20.

Before using the secure storage, check that the device supports this feature. To do that, use the AccessProtectionSupported() method. Storage access protection and additional user verification methods are used as parameters.

If the mobile device supports the secure storage feature, the application can place data to that storage and retrieve it from there. A standard set of operations is supported:

Put a value in the storage. Use the PutDataAsync()/BeginPutValue() method.
Get a value from the storage. Use the GetDataAsync()/BeginGetValue() method.
Delete a value from the storage. Use the DeleteDataAsync()/BeginDeleteValue()method.
Check whether data with a specified key is available in the storage. Use the ContainsKey() method.

Key search in the secure storage is not supported.

Let us take a closer look at the storage feature. When you put data in the storage, in addition to a key and data to be saved, specify the way this data will be protected. It is determined by the AccessProtectionMethod and VerificationMethod parameters of the PutDataAsync()/BeginPutData() method. The AccessProtectionMethod parameter is of the SecureStorageAccessProtectionMethod type. This type is described in detail above. If the AccessProtectionMethod parameter is set to SecureStorageAccessProtectionMethod.AdditionalUserVerificationRequired, specify a value of the VerificationMethod parameter. This parameter is of the AdditionalUserVerificationMethod system enumeration type and allows you to define the way additional user verification will be performed.

To get data (the GetDataAsync()/BeginGetData() method), along with the data access key, specify the text that will be shown to the user when additional verification is required. The user can refuse to get data from the secure storage. In this case, the behavior depends on the method option:

GetDataAsync(). Returns Undefined as a promise result.
BeginGetData(). The CanceledByUser callback handler parameter is set to True.

As a rule, storage operation methods do not lock the application. Method results are passed to the respective callback handler. The callback handler is one of the method parameters you must specify upon calling. If an error occurs, control is passed to the error handler that also must be specified when creating the NotifyDescription object. Otherwise, an exception is thrown. The exception can be caught by the standard promise scheme.

The ContainsKey() method that checks whether a certain value is available in the storage for a specified key is the only synchronous method.

Also note that verification methods used upon access to the secure storage do not guarantee that a specific user is using the device. These methods guarantee that a user can unlock the phone using the required method. For example, they know the right PIN code or graphical password to unlock the device.

29.3.6.17. Document scanning

In the mobile 1C:Enterprise version, you can scan documents to further process or archive them. For example, you may need to scan a user's document that the user cannot bring to your company's office for scanning. At the same time, a mobile device has a camera to scan a document in a sufficiently high quality, and almost everyone has such device.

The mobile 1C:Enterprise version provides access to the scanning functionality using the MultimediaTools global context property. For simplification, the MultimediaTools method prefix will be omitted in the documentation. It is evident that such omissions are unacceptable in examples and real applications. Let us take a closer look at the available features.

Before you start scanning documents, check that your current mobile device supports this feature. To do this, use the DocumentScanningSupported() method. Continue to use this method only if it returns True.

To manage document scanning, use an object of the DocumentScanningParameters type, which has the following properties:

Property	Description
WhiteBackgroundDocument	Type: Boolean. When searching for document borders, the document color will be considered as follows: True. When searching for the document borders, the white color of the document background is considered. The image will be cleared of shadows and kinks, which will make it smoother. False. The document border is identified without regard to the document color.
QualityCheck	Type: DocumentScanningQualityCheck. Specifies the quality limits for the document to be scanned. If the quality limits are exceeded, the system will prompt you to rescan the “unsuccessful” page.
RectangularDocument	Type: Boolean. Specifies that it is necessary to make the pages to be scanned rectangular.
AllowAutoCapture	Type: Boolean. Enables (True) or disables (False) the scanning interface control that enables or disables automatic page scanning. If automatic scanning is enabled, then the system specifies the page parameters. If these parameters meet the scanning parameters, then the current page is captured automatically without user intervention. The next page will also be captured automatically. If automatic scanning is disabled, then each page is scanned only after the user explicitly taps the scan button.
OrientationDetectionMode	Type: DocumentScanningOrientationDetectionMode. Specifies how the pages of the document to be scanned are oriented. In batch scanning, this parameter specifies that all pages in the batch must be oriented in the same way.
ScanSeries	Type: Boolean. In this case: True. Scanning will continue until the user closes the scanning form. In other words, a multi-page document will be scanned. False. The interface will close after one page is scanned.
ProcessingFilters	Type: Array of values of the DocumentScanningProcessingFilter type. A set of filters for processing the found document. From this set, the user can select a filter in the scanning interface. An empty array is not allowed.

The system provides several predefined filters (values of the DocumentScanningProcessingFilter system enumeration), which can be combined. If multiple filters are specified in the scanning parameters, all of them will be specified in the scanning interface so that the user can select a filter. In the scanning interface, filters will be switched in the order in which they are listed in the ProcessingFilters property. The following filters are available:

No. Do not use filters on document scanning. We recommend that you always add this filter so that the user can leave the scanned image "as is". If automatic processing of a scanned document is intended, we recommend that you leave the No filter as the only one.
TextWithPictures. Filter for processing a document containing a text with pictures. This filter processes a picture with medium aggressiveness. If a document is supposed to be processed manually, this filter can be the default filter. It makes the document look better, saves toner when printing, and tries not to damage photos and other pictures if they are available in the document.
Text. Filter for processing a document containing only a text. This filter processes a picture as aggressively as possible. If a document is supposed to be processed manually and nothing is expected in the document except a text, tables, stamps, frames, underscores, and similar graphic information, then this filter can be specified as the default filter.

Before scanning, create a value of the DocumentScanningParameters type, which will then be passed to the method that opens the document scanning interface and starts the scanning process.

To start scanning, use the ShowDocumentScanning() method or the ScanDocumentsAsync() method. Both of these methods open the document scanning interface form and allow you to get the scanning result, but they do this in slightly different ways. Use the ShowDocumentScanning() method when you need to immediately send the pages of the document to be scanned (as they are being scanned) to perform any actions with these pages. For this, two notification handlers are passed to the method: control is passed to one (the formal ScanHandler parameter) after each page is scanned, and control is passed to the other (the formal ScanningCompletionHandler parameter) after scanning is completed. The scanning completion handler is passed an array of page IDs that are actually left after scanning of a multi-page document is completed. When you use the ShowDocumentScanning() method, note that when scanning a multi-page document, the user can delete previously scanned pages, and the object that describes the scanning result (the DocumentScanningPage type) is available only in a client application.

The ScanDocumentsAsync() method (unlike the ShowDocumentScanning() method) does not make it possible to get each page individually (during scanning). The method returns an object of the Promise type. After the promise is executed, the object will be converted into an array of values of the DocumentScanningPage type. The values are arranged as the user placed them in the scanning interface. The promise can result in Undefined if the user has closed the scanning interface without confirming the scanning results.

To close the scanning interface, use the CloseDocumentScanning() method. In normal operation of the system, this method is not required. Use this method when you need to close the scanning interface bypassing the regular process.

What does the scanning interface return in the DocumentScanningPage type? Let's take a look at the object properties:

Property	Description
ImageData	Type: MultimediaData. Contains a picture received from the document scanning interface. You can, among other things, save this data as a graphic file.
DocumentFound	Type: Boolean. Indicates that document scanning detected a document in the image.
ID	Type: Number. Contains the page ID (for batch scanning). The ID does not change when you move a page within a batch. It is unique only within one page batch.
QualityParameters	Type: DocumentScanningQualityParameters. Describes the quality parameters of the resulting image.

Let's take a closer look at a value of the DocumentScanningQualityParameters type. The value of this type shows the quality of the current document page according to the scanning functionality. The quality depends on several parameters. Each of the parameters can take a value from 0 to 10 (inclusive). Depending on the value, the parameter falls into three quality intervals:

[1.0, 4.0). Low quality.
[4.0, 7.0). Medium quality.
[7.0, 10.0]. High quality.

In this case, "[" means a "closed boundary" or "including the value", and ")" means an "open boundary" or "excluding the value". Thus, the [1.0, 4.0) expression means that the quality will be considered low if: 1.0 <= ParameterValue < 4.0.

Let's take a look at the DocumentScanningQualityParameters object properties:

Property	Description
WhitePaperQuality	Shows how white and uniform the page paper is: Low quality. The document does not look like a document printed on plain white paper. Medium quality. The document looks like it is printed on plain white paper, but it is not completely white. High quality. The document paper is white and plain.
BorderQuality	Shows how contrasting and aligned the document edges are relative to the background being scanned: Low quality. Document borders are not contrasting or very uneven. It is necessary to additionally specify the document borders. Medium quality. Document borders are distinguishable, but there are defects. High quality. Document borders are contrasting and clearly distinguishable.
TextContrast	Describes the document text contrast: Low quality. Text is not contrasting. Medium quality. Text is contrasting, but there are defects. High quality. Text is contrasting.
GeneralizedQuality	Generalized quality level of a scanned document determined by the platform depending on the scanning parameters: Low quality. Medium quality. High quality.
PerspectiveDistortion	Shows how little perspective distortion there is and whether the document is well positioned in relation to the camera plane: Low quality. The device is not parallel to the document or at a large angle relative to the document. Some document areas are much farther from the device than others and are therefore hard to see. Medium quality. The device is almost parallel to the document plane. Document areas that are farther from the camera are less visible. High quality. The device is above the document and parallel to the document plane. All document areas are clearly visible.

In conclusion, let's look at a simple example of how to start the scanning interface in a client application:

&AtClient
Async Procedure Scan()
If Not MultimediaTools.DocumentScanningSupported() Then
Return;
EndIf;

ScanningParameters = New DocumentScanningParameters;
ScanningParameters.QualityCheck = DocumentScanningQualityCheck.DontCheck;
ScanningParameters.OrientationDetectionMode = DocumentScanningOrientationDetectionMode.ByFirstPageInSeries;
Pages = Await MultimediaTools.ScanDocumentsAsync("Document scanning", ScanningParameters);
If Pages <> Undefined Then
Message("Scanning completed. Number of pages " + Pages.Count());
For every Page From Pages Do
Message("ID = " + Page.ID + "Scanning quality = " + Page.QualityParameters.GeneralizedQuality);
EndDo;
Else
Message("Scanning completed with no result.");
EndIf;
EndProcedure

Note that the above code will not work or even compile on the thin client. In this regard, if you want to develop an application that will run on both the thin client and the mobile device, enclose the above example in a preprocessor command, for example, as follow:

&AtClient
Async Procedure Scan()
#If Not ThinClient Then
If Not MultimediaTools.DocumentScanningSupported() Then
Return;
EndIf;
…
#EndIf
EndProcedure

29.3.6.18. NFC operations

29.3.6.18.1. General information

NFC (Near-Field Communication) is a short-range wireless data transmission technology that allows data exchange between devices up to 10 centimeters apart. You can use NFC technology to:

Make mobile payments.
Quickly connect devices that use the Bluetooth interface.
Swiftly get various information from a special tag.

A special tag is a very thin device that supports NFC technology and allows you to read and write various information from this device. In this documentation, such device will be referred to as an NFC tag. The volume and format of information that can be placed in an NFC tag is regulated by the NDEF format. NDEF (NFC Forum Data Exchange Format) is a light-weight binary format that is a container (called a message) containing records of various formats.

Thus, the mobile 1C:Enterprise version supports NFC tags that can contain data in the NDEF format. The mobile 1C:Enterprise version does not support any other ways and options for NFC operations.

NFC tags are supported:

Android 4.1 or later.
iOS 13.0 or later.

29.3.6.18.2. Application programming interface

To operate with NFC tags, use the NFCTools global context property. To access the entire NDEF data infrastructure, use the NFCTools.NDEFTags property. For simplification, the NFCTools.NDEFTags method prefix will be omitted in the documentation. It is evident that such omissions are unacceptable in examples and real applications.

To operate with NFC tags, enable the NFC functionality. If this functionality is not enabled, then a built mobile application cannot get access to the respective tools of the mobile operating system.

The NFCTools.NDEFTags object is an NFC tag manager. With this manager, you can:

Check that background scanning of an NFC tag is possible using this device. For this, use the BackgroundScanningSupported() method.
Check that active scanning of NFC tags is supported. For this, use the ActiveScanningSupported() method.
Check whether it is possible to write information to an NFC tag using the WriteOnTagSupported() method.

Thus, the application can identify the capabilities of the device on which it is running.

Background scanning of tags differs from active scanning in that background scanning will only actually fire tags whose first message record is a URI record. During active scanning, the application will try to process all tags that fall within the range of the mobile device reader.

Let's take a look at an NFC tag in terms of the 1C:Enterprise object model. The tag itself is an object of the NDEFTag type. You cannot create an object of this type manually, and the platform passes it to the application code when the tag is within the range of the device reader. After the tag is read by the platform, you can get information about what you can do with this tag:

GetMessageAsync(). Reads a message from the tag and packs it into the NDEFMessage object.
WriteOnTagSupportedAsync(). Indicates whether you can write information to the tag or not.
TagWriteLockSupportedAsync(). Indicates whether the tag can be set to read-only mode.
If writing to the tag is supported, then this action can be performed using the WriteMessageAsync() method.
If the tag supports a write lock, then this lock can be performed using the MakeTagReadOnlyAsync() method.
The NDEFTag.MaxSize property shows the maximum amount of data that can be written to the tag.

Once the tag is fully read, you can access the data that is written to this tag. An object of the NDEFMessage type contains two properties. The first property describes the current size of the data in the message: NDEFMessage.Size. To access message records, use the NDEFMessage.Records property. This property contains a fixed array of …NDEFRecord objects that describe the tag data:

1C:Enterprise object	Description
EmptyNDEFRecord	Describes empty NDEF records. You cannot create such object in 1C:Enterprise.
TextNDEFRecord	Places text information on an NFC tag. You can create such object in 1C:Enterprise.
URINDEFRecord	Places a URI on a tag. You can create such object in 1C:Enterprise. If such record is the first message record, then when the device scans such tag, you can start an application using a deep link. You can start a 1C:Enterprise mobile application as well.
MediaRecordNDEF	Places any media data on an NFC tag: pictures or audio files. Note that the size of information that can be written to a tag is limited. You can create such object in 1C:Enterprise.
ExternalTypeNDEFRecord	Places data in a format that cannot be written using the following records on an NFC tag: TextNDEFRecord, URINDEFRecord, and MediaRecordNDEF. This is a custom data type. Keep in mind that different mobile devices may interpret the same data written using the ExternalTypeNDEFRecord record in different ways. The behavior depends on the set of software installed on the mobile device. You can create such object in 1C:Enterprise.
UnknownNDEFRecord	Describes a message record whose format is not recognized. You cannot create such object in 1C:Enterprise.

Now we have a clear idea of how the data on NFC tags is structured. Let's see how to operate with these tags.

If a mobile device supports active scanning, you can use the StartActiveScanning() tag manager method. This method is passed the title of the window that will be opened on the device and a link to the method that will process the connection with the tag. After the mobile device establishes a connection with the nearest NFC tag, the scanning form will be closed and control will be passed to the handler. The NFC tag with which the connection is established will be passed to the handler via the formal Tag parameter. If the Tag parameter value is Undefined, this means that the scanning form was closed before a connection was established with any NFC tag.

All further actions with the NFC tag must be performed from the handler. Note that if you plan to write to an NFC tag, then the NFC tag must always be near the mobile device (the device must not lose connection with the NFC tag).

Example of using active scanning of an NFC tag:

&AtClient
Procedure ScanNDEFTag(Command)
TagManager = NFCTools.NDEFTags;
If TagManager.ActiveScanningSupported() Then
TagScanHandling = New NotifyDescription("OnReadTag", ThisObject);
TagManager.StartActiveScanning("Bring the tag to the device", TagScanHandling);
Else
Message("Active scanning is not supported");
EndIf;
EndProcedure

&AtClient
Async Procedure OnReadTag(Tag, AdditionalData) Export
If Tag = Undefined Then
Return;
EndIf;

Try
NFCMessage = Await Tag.GetMessageAsync();
Exception
Message("Read error: " + ErrorInfo().Description);
EndTry;
EndProcedure

For passive tag scanning, note the following features:

Passive scanning is similar to deep linking (following a URL that is processed by a mobile application).
Passive scanning will lead to any action only if the first record in the NFC tag message is the URINDEFRecord record.

To write to an NFC tag:

Prepare data to be written.
Activate active scanning.
Bring the tag you want to write to the mobile device.
In the tag read handler, check whether writing is possible and, if possible, write the prepared data.
During writing, do not move the NFC tag away from the mobile device. If you do this, the connection between the tag and the device will be lost and the writing will fail.

Example of writing data to an NFC tag:

&AtClient
Procedure NDEFTagRecord(Command)
TagManager = NFCTools.NDEFTags;
If TagManager.WriteOnTagSupported() Then
TagAppearanceNotification = New NotifyDescription("OnScanTag", ThisObject);
TagManager.StartActiveScanning("Bring the tag to the device", TagAppearanceNotification);
Else
Message("Writing tags is not supported");
EndIf;
EndProcedure

&AtClient
Async Procedure OnScanTag(Tag, AdditionalData) Export
If Tag = Undefined Then
Return;
EndIf;

DiscountSize = "10";
ProcessingURL = "https://example.com/mycafe/coupone";
Records = New Array;
Records.Add(New URINDEFRecord(ProcessingURL));
Records.Add(New TextNDEFRecord(DiscountSize,));
Message = New NDEFMessage(New FixedArray(Records));
WriteSupported = Await Tag.WriteOnTagSupportedAsync();
If WriteSupported Then
Try
Await Tag.WriteMessageAsync(Message);
Exception
Message("Write error: " + ErrorInfo().Description);
EndTry;
Else
Message("Writing to this tag is not supported");
EndIf;
EndProcedure

In this example, a 10% discount is written to the NFC tag for the bearer of the NFC tag. The NFC tag will be processed by a mobile application that intercepts the following URL: https://example.com/mycafe/coupone.

29.3.6.18.3. Setting up deep linking with NFC

To set up an NFC tag as a source for deep links:

Develop a deep link format and choose a scheme that will be used to generate the URL. In this case, all deep linking features will apply.
Implement deep link processing code in the application (configuration).
Prepare and build a mobile application that will process deep links.
Generate one or more NFC tags with the required messages as a payload.
Install the application on the device and check if it works.

In the URL navigation handler (NavigationByURLProcessing), you can determine that the navigation is a result of scanning an NFC tag using the formal URLNavigationData parameter. If the value of this parameter is not Undefined, check whether this data contains a value by the MessageNDEF key. To do this, you can use the Get() method of the MobileDeviceApplicationRunAdditionalData type (this is the parameter value type). If the method returns a value of the MobileDeviceApplicationRunAdditionalDataItem type, the URL navigation was initiated by an NFC tag. In this case, the Value property of this type will contain an object of the NDEFMessage type, which is filled with the data of the read NFC tag.

Example of determining that URL navigation is initiated by scanning an NFC tag:

Procedure NavigationByURLProcessing(URLNavigationData, StandardProcessing)
AdditionalData = URLNavigationData.MobileApplicationNavigationAdditionalData;
If AdditionalData <> Undefined Then
AdditionalDataItem = AdditionalData.Get("MessageNDEF");
If AdditionalDataItem <> Undefined Then
// URL navigation is initiated by the NFC tag
NDEFMessage = AdditionalDataItem.Value;
EndIf;
EndIf;
EndProcedure

29.3.6.19. Backup using mobile operating system tools

Mobile operating systems support embedded data backup tools for applications installed on mobile devices. Depending on the operating system, the following services are used for backup purposes:

Android: Google Drive or special backup applications supported by personal computers.
iOS: iCloud or iTunes-supported backup.
Windows: Microsoft OneDrive.

For a mobile device to be able to backup data using operating system tools, select Backup by OS in the Required mobile application permissions property list. If backup by mobile OS tools must be disabled for an application, clear the Backup by OS check box.

No further actions are required. This permission is only applicable to a mobile application being built in the mobile application builder.

29.3.6.20. Other mobile device features

Flashlight

When using a mobile application, it may be necessary to highlight an object. In that case, if the mobile device being used has a flash of the main camera, it can be used as a flashlight.

To verify that this feature is supported by the device, use the DeviceTools.FlashlightSupported() method. If the method returns True, you can turn on the flashlight by calling the DeviceTools.TurnFlashlightOn(True) method. Turning off the flashlight is performed by calling the DeviceTools.TurnFlashlightOn(False) method.

Installing applications

NOTE. Applicable to mobile applications on Android only.

A mobile application can install various third party applications required for its operation on a mobile device. This feature can violate safety regulations applicable to mobile applications.

Installation of third party applications is managed by the Application installation permission. This permission is only applicable to a mobile application being built in the mobile application builder.

Sleep mode

When you use a mobile application, you may need to prevent the mobile device from enabling sleep mode. For example, when data loading in the mobile client takes a long time. Also when a user uses a barcode scanner on the mobile device but the pause between scanning exceeds the period after which the mobile device screen turns off and the device goes to sleep.

To manage sleep mode, the application developer can use the following methods:

To find out whether the device can go to sleep at the moment, use the GetComputerSleepModeProhibition() global context method.
To allow the device to go to sleep or prohibit it, use the SetComputerSleepModeProhibition() global context method.

When you set the sleep mode prohibition for the mobile device, remember that this prohibition negatively affects the mobile device operation time. Enable sleep mode prohibition only when it is required. We do not recommend that you set this mode "just in case". Also remember that sleep mode prohibition applicability is limited:

When the application is closed, the prohibition is disabled.
If the user puts the mobile device to sleep, for example, using the power button, the mobile application also goes to sleep. However, when the application is reactivated, the prohibition is restored.
If the user switches to another application, the prohibition is disabled and the mobile device, including the mobile application on 1C:Enterprise platform, might go to sleep. When the user switches back to the mobile application, the prohibition is restored.

So, the sleep mode prohibition is applied for the mobile device only when the mobile application on 1C:Enterprise platform that sets the prohibition is active.

In the mobile 1C:Enterprise version, you can monitor transitions to sleep mode and back. To do this, use the following module event handlers of the mobile application: OnClientApplicationSuspend() and OnClientApplicationResume(). The first event is activated before the mobile application goes to sleep. The second event is activated as soon as the mobile application wakes up. When the mobile application goes to sleep, performing any long-running operations is not recommended. When the application wakes up, you can perform various service operations, such as: exchange data with the main infobase, restore handlers that might have been disabled when the application went to sleep, and so on.

<< Prev Next >>