1. Home
  2. Docs
  3. AndroidBridge
  4. Introduction
  5. Limitations of current approach

Limitations of current approach

By default Unity developers have to resort to using different plugins in order to access any platform specific APIs that are not provided by Unity. This approach presents different challenges of its own:

  1. Although there are plugins for many different APIs but there is still a lot that is not covered simply because of the lack of enough demand to warrant a plugin development for that specific API that you need. In that case you have to either invest resources to develop the plugin on your own and/or outsource and/or let go of that platform specific feature.
  2. If the plugin exist it simply might not be cost effective to invest in buying plugins for every other API required for various projects.
  3. Whenever new features are added or previous APIs deprecated you have to wait for the plugin developers to update to latest version or fix any broken API calls.
  4. Inconsistency in documentation and implementation of various plugins also means that a coherent process is not followed since every plugin developer has a unique way of packaging and presenting API calls in Unity.
  5. By default Unity only supports the “communication” with Android on its main thread thus limiting any implementations that require multithreaded approach either be it for a single plugin or different plugins thus blocking any new calls unless a previous has returned.
Was this article helpful to you? Yes No

How can we help?