Two questions about custom modules
I have two questions about custom modules:
- I noticed that in the Mobile designer we can upload libraries (.js files). I can't find any reference to this in the developer documentation, and I had the impression that for Mobile we should use a custom Xamarin application. I tried to upload a module that I wrote for Web, and indeed it shows up in the toolbox and I can add it to the layout. However, it's not visible in Geocortex Go. Is this something that's supposed to work and am I doing something wrong?
- The upload dialog in both the Mobile and Web desiger say 'Only one library can be used at a time'. What exactly does this mean, can an app only use a single custom library? What's the idea behind this limitation?
-
Hi Berend. Good questions! I'll try to help answer them:
1) Yes that is correct. You can upload libraries built using the Geocortex Web SDK to a Mobile app in the Mobile Designer. This library is used at design time, rather than at runtime on the device.
- The primary use case for this is to provide a configuration interface in the designer for your custom components and services you've built using the Geocortex Mobile SDK. This is a common pattern our professional services team can use to deliver an easy-to-use configuration interface for the custom components and services they deliver to their clients
- The library itself would typically consist of registering the "settings schema", which is used by the designer to present the configuration for a given component or service.
- We are working to add documentation and samples of settings schema to the Developer Center. In the mean time you can check out the TypeScript interfaces for designer settings related properties on the registerComponent and registerService APIs
2) The typical case for multiple libraries is when you have a "redistributable" or "shared" library used across multiple apps. These shared libraries may be handled differently somehow, rather than uploaded to each app individually. For example they could be distributed as npm modules. While you can upload one library to your app, it's actually quite easy to combine multiple libraries together! Our recommendation is to have the app's custom library reference the shared library in its entry point. This allows you to easily compose multiple shared libraries together on top of your app's library.
0 -
Hi Ian,
Thanks for the explanation.
The idea behind 2) is not completely clear to me yet, though. If I understand this correctly, the only way to load more than one library is to have one reference the other, is that correct? This would mean that even though two libraries could operate completely independently, I would still need to introduce a dependency between them.
And what if I initially have one custom library, and later I want to add another shared lib to the viewer, would I have to modify the code of the custom library to reference the shared one?
Or if I have one viewer that uses libraries A and B and another using A and C? Would I need to keep different copies of A, that reference either B or C?
0 -
Correct. To load more than one library you would need to reference the other library. Although we support uploading one custom library to a given app, what is inside of the library is completely up to you!
If I understand your example correctly where you have App 1 using A/B and App 2 using A/C, you could create a library for App 1 that imports and registers libraries A & B, and similarly create a library for App 2 that imports and registers libraries A & C.
If you had a specific use case in mind in we’d love to learn more about what you’re trying to accomplish and we can use that to see if there’s a way we can improve the experience.
0 -
Ok, let me give some more background. Our company has developed a number of generic libraries for GVH, which we are planning to port to Web. For instance a StreetSmart viewer, a profile tool and an 'image carousel' and so on. If a client decides to buy one, one of our consultants can simply add it to one or more viewers by modifying a configuration file. We also have a large number of 'tailor-made' libraries that are used by single clients. These also need to work in combination with the generic libraries.
From what I understand now, if a client wishes to add an additional library to an existing viewer (or remove one), we would then need to modify the code of one main 'loader' library first. This means that we could end up with an individual library for every combination of libraries.
Moreover, this is more than just configuration, a developer would have to modify the source code first, and then a consultant could upload it to the viewer. And even though this may not be that much extra work, it's still one extra step that we need to take.
I'm curious, could you explain what the reason behind the one library limit exactly is?
0 -
Thanks for the info Berend. Your use case totally makes sense.
When designing support for custom libraries in Geocortex Web, we anticipated use cases similar to what you've described. We implemented the configuration of an app to support a collection of libraries. If you were to inspect the item metadata of an app containing a custom library you will see the library stored in an array:
We haven't officially exposed this functionality through the designer interface or the SDK just yet. We want to make sure we understand the various use cases and ensure that we can provide a great experience from all aspects of the product when using multiple libraries.
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
5 commentaires