Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Conditionally require a NativeScript plugin when only a single platform is supported


    Sometimes a NativeScript plugin may only support 1 platform (iOS or Android). In these cases, we will want to conditionally require the plugin to ensure we don’t crash the other unsupported platform. Let’s consider view and service level implications for how best to handle these scenarios.



    Become a Member to view code

    You must be a Pro Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    orLog In




    If try to implement this EZAudio plugin into our project, with this plugin installed if we go to our app component, and make sure we've registered the element for this plugin using the register element API to register AudioPlot coming from the EZAudio plugin.

    We add that component to our view, and then run this against Android. You will receive a nasty crash. It says could not load view for AudioPlot with a failed defined module of the EZAudio plugin.

    If we look through the build of our app, we'll see that, in fact, it does output that NativeScript EZAudio is not supported for Android.

    In these cases, you will want to make sure that any time you require or import a module or plugin that is only supported on one platform, that you wrap this with a conditional for that platform only. Let's use the isIOS Boolean from NativeScript's platform module, and wrap the registration of this element in isIOS.

    In our view template, we want to make sure that this component is wrapped with the iOS node, to flag that this is only supposed to be shown on iOS.

    For Android, we could use the Android node and place a different component implementation. This could either be another plugin, or even a custom implementation using one of the layout containers like the grid-layout. For example, we'll just say label, and we'll put a todo here, and now when we run this on Android it runs without error.

    Just to elaborate, if you had an Angular service that needed to tap into platform specific classes, you would want to take the same thing into consideration. Take, for example, the EZAudio plugin, and the Audio plugin which is cross-platform compatible.

    If we wanted to use the EZRecorder and EZAudio player from this iOS-specific plugin, we could define these variables up top, and then assign them to the appropriate class that we require in.

    The downside is we do not get our types imported from the module, but this will allow you to get around a platform specific implementation.