I’m new to Ionic and have read some documentation to decide whether to give it a try or not for a project.
Since i could not easily find an answer to my remaining main question i have decided to cast it here directly.
Here is a brief description of my project:
I want to create a mobile native application than run on both iOS and Android. So the question of using an hybrid framework like Ionic make sense. But one of the core feature of the application will need to use Zoom for audio & video communications between users.
Zoom provides several SDK to connect to their services: iOS, Android and Ionic SDKs. I clearly don’t want to use the Ionic SDK (because it’s not really well maintained on Zoom side, it’s clearly not their priority, it’s not working with latest version of iOS and Android, it’s using an old version of Ionic, etc.)
So i’m stuck with using the platform native SDK of Zoom.
Note: since the API is different between their Android & iOS SDKs, i will clearly need to create a module on my code base to abstract/interface in a generic way with the Zoom part.
Question
Since Ionic generate native code at compile time (correct me if i’m wrong), is it possible to:
have platform specific includes on the code base (that would then be used at compile time)
customize the compilation to include either the android or the iOS SDK in the compiled sources / dependencies ?
do you think it would works ? (since Zoom SDK are purely native and call native functions directly - it would not use Ionic bridge) In this end my question is similar to whether we can make direct native calls in an Ionic application without passing by Ionic as a bridge.
I could be misunderstanding what you’re saying, but I suspect this is wrong.
Ionic applications run in a JavaScript engine inside a browser. The code is interpreted at runtime. Although there is “compilation” in a sense, I’d call it more “transpilation”, because in the end, it is all still JavaScript.
What “Ionic” really is today is a set of UI components that are designed to be pleasing and functional, with primary focus on running on iOS and Android devices, but also deployable in desktop browsers and shrink-wrapped browser PC applications (like Electron).
Also developed and released by the same people behind Ionic is Capacitor, and this is likely to be the part you’re particularly interested in. Capacitor provides, in the spirit of the original PhoneGap-which-became-Cordova, a bridge between JavaScript code running in a browser and native code. The Capacitor documentation can do a better job of explaining the details than I can here, but what I see in your future is basically creating a Capacitor plugin that interacts with the Zoom SDKs (assuming somebody else hasn’t already done this).
As far as I can read it seems to me the angular sdk runs with late version of ionic and seem to be part of something official (their marketplace) . And they cleaned the github, so maybe not abandonware
Only downside is that it isnt capacitor and if u want something else then angular or ionic, u need to dive in the code. Both seem doable to me
@Tommertom
Yes there have an Ionic SDK as they call it, but it’s not using Capacitor and it’s a community project with almost nobody working on it. In addition it’s bugged and not updated to their latest SDK features.
I used to participate in community projects by the past but do not have time anymore unfortunately, this is also the reason i don’t want to go for that option.
Thank you very much for clarifying how Ionic works. I will have a look at the option you mention about creating a plugin which interact with the zoom native SDK.
From my understanding this is exactly what Zoom did (according to their description) with their Zoom Ionic SDK, but using version 3 of the framework. Plus as @Tommertom also mentioned, using the Zoom Ionic SDK force us to use angular, which i don’t want.
Just between you and me and the wall over there, I doubt that’s actually true. The interesting part will all be on the native side of the bridge, which couldn’t care one whit what the framework looks like on the JS side. Zoom is probably just not motivated enough to bother writing JS-side shims for React or Vue or whatever framework you do like, but that part is usually quite easy, especially if their Cordova plugin works with Capacitor (as most do).
There are a lot of reasons to be concerned about how much work this endeavour will entail, but I would rank “ZOMG must use Angular” way down the list of them.
I think the point being made is that the most efficient way is to take the code from the community project (you dismissed) as it likely contains 90% of the (native and bridging) code you will have to write anyway.
Unless of course, you can put forward a new concept of a wheel?
Good luck with the project and thanks for showing some interesting features of Zoom
