For the mobile platform, we have implemented the support of add-in technology. You can create Native API-based add-ins in the same way as it is done on the platform for personal computers. Of course, there are some specifics that are associated with mobile operating systems. But in general, everything is very similar.
When developing an add-in, you must create its variants for all operating systems that interest you and for all processors of mobile devices, where it is supposed to work. All of these variants must be placed in a ZIP archive and then in an Add-in configuration template (this is the only way to add the add-in to your configuration). This is a new type of template that we added to the platform.
You will then install and attach it on the mobile application in the same manner as in the desktop platform. For example:
&AtClient
Procedure StartCounting(Command)
// Variable for add-in access.
Addn = Undefined;
// Transferring the add-in object from the server to the client.
InstallAddIn("CommonTemplate.AddnTemplate");
// Attaching add-in.
AddInAttached = AttachAddIn("CommonTemplate.AddnTemplate", "com_1c_StepCounter", AddInType.Native);
If AddInAttached Then
//Creating StepCounter class.
Try
Addn = New ("AddIn.com_1c_StepCounter.com_1c_StepCounterExtension");
Except
Message("Cannot create class: StepCounter.");
EndTry;
// Using the add-in.
If Not Addn = Undefined Then
Addn.Enable();
EndIf
Else
Message("Cannot attach the add-in.");
EndIf
EndProcedure
|
We added the option to load such archives to the mobile application builder:
For debugging purposes, you can manually replace the files in the archive to correct the behavior of the applications that you build.
The builder includes the required libraries in target applications automatically during the building.
Add-in archive
ZIP archive of the add-in must contain a set of required files. The builder automatically disables the generation of target applications for specific operating systems if the deliverable archive does not include all of the files required for these operating systems.
ZIP archive may include:
- Add-in variants for Windows (x86, ARM).
- Add-in variants for Android (x86, ARM).
- Additionally, you can include the *.apk file for the Java code.
- Additionally, you can include the *.apk file for the Java code.
- Add-in variants for iOS (ARM and ARM64 merged into a single universal file).
- Note that iOS requires both dynamic (*.dylib) and static (*.a) libraries.
- Note that iOS requires both dynamic (*.dylib) and static (*.a) libraries.
- MANIFEST.XML file describing the contents of the archive.
- You can include the ANDROID_MANIFEST_EXTENTIONS.XML file to describe the changes in AndroidManifest.xml.
- You can include the WINDOWS_RT_MANIFEST_EXTENTIONS.XML and/or WINDOWS_RT_PHONE_MANIFEST_EXTENTIONS.XML files to describe the changes in AppxManifest.xml.
The specifics of developing applications for iOS do not allow us to publish non-system dynamic libraries in the AppStore. Therefore, when developing a variant of the add-in for iOS, you need to have a dynamic library file (*.dylib) for testing and debugging purposes. In addition, you will need a binary file (*.a) for static linking that will be performed by the mobile application builder.
To exclude a possibility of name conflict, the add-in code must be located in its own unique namespace. The namespace name must match the name of the add-in or must include it as a part. The add-in is registered statically at the application startup.
In order to develop a variant of the add-in for Windows Runtime, you need to have at least Windows 8.1 with MS Visual Studio 2013 SP4 (Windows Phone SDK package). The result of the development should be a group of dynamic libraries (*.dll) for mobile devices and tablets of all supported processors.
When developing a variant of the add-in for Android, you can write a code in C++ or use Java Native Interface technology. The result of the development should be a group of dynamic libraries (*.so) for all supported processors. If you use Java code, you must have the *.apk file.
When the application is published, you must add in the settings of the HTTP server the MIME types for the following extensions: .so, .apk, .dylib, and .a. MIME type: application/octet-stream.
Restrictions
Add-in functionality for mobile applications has a number of restrictions:
- You cannot use the user interface.
- You cannot call the following methods from the system stream:
- bool ADDIN_API Confirm(const WCHAR_T* queryText, tVariant* retVal)
- bool ADDIN_API Alert(const WCHAR_T* text)
- These methods are not allowed because the display of modal windows in this scenario can cause the application to “freeze”.
- You cannot load dynamic libraries from the publication of the HTTP server in Windows Runtime.
We added some materials that will help you use this technology in mobile applications to the .
Firstly, we have added an add-in template for the mobile platform. It will help you create add-ins “from scratch”. Secondly, we have added an example of usage of the add-in developed using the Native API technology in the configuration, including the description of its properties, methods and events.
