Making HTTP calls from mobile apps

OK so quick disclaimer: I’m not using Expo so not 100% how or if this will work.

BigInt should be available on iOS (at least iOS 14), but the issue is Android. The problem is that the default JSC bundled with an Android RN app doesn’t support BigInt AFAIK. I’m currently using v8 instead of JSC for Android. Make sure you enable JIT if you care about performance (see the docs).

You’ll probably hit errors with BigInt syntax for iOS and/or Android:

  1. The exponentiation ** operator might not be supported. You’ll have to manually patch the @dfinity/agent library to replace the ** code (in 6 files) with hardcoded static values.
  2. The BigInt ...n literal syntax (e.g. 128n) might not be supported. You’ll also need to replace that with the BigInt constructor (e.g. 128n becomes BigInt(128)).

Some of these errors only happened when I built my RN app in release mode, so you might not see them initially… but they are there.

Oh yeah, after you solve BigInt, you’ll need to deal with WebAssembly. :sweat_smile:

2 Likes

Thank you. Trying to implment this in expo.

For some more discussion: Module Namespacing Support for Packages · Issue #161 · expo/snack · GitHub

1 Like

Somewhat unrelated, but does anyone know the best way to debug WebAssembly (called from JavaScript)?

I’m trying to get the BLS signature validation wasm code working in React Native on Android v8 (using react-native-v8). If this works, it would make agent-js viable on RN without needing a separate Rust native module, which would be huge for the ecosystem.


So I’m running it on v8 version 9, so WebAssembly is supported. When I call WebAssembly.validate on the wasm byte buffer, it returns true so good so far.

But when I call await WebAssembly.instantiate on the same buffer, it hangs and never completes. I’ve tried replacing the wasm with a super short buffer (i.e. just two instructions) but it also hangs. await WebAssembly.compile hangs as well.

No error message, no debug log, nothing.

To any WebAssembly experts, how would you debug this? Have you possibly seen anything like this before?

Thanks!

1 Like

At the moment, has anyone tried to port the agent to kotlin or java? Is there an example of what you are doing? I am faced with a similar task. Need a working agent on Android.

There was this some time ago, from @senior.joinu : GitHub - seniorjoinu/candid-kt: Lets you write Kotlin apps which interact with the Internet Computer

1 Like

I promise, I’ll update it to current version of the IC one day.

There is just too much other work :c

1 Like

It is not even possible to build it yet. All because of the version of better-parse:0.4.0. It has been removed from the maven. I tried it on the versions above, but it falls into errors.(Exception in thread “main” java.lang.NoClassDefFoundError: com/github/h0tk3y/betterParse/grammar/Grammar). I made a request to the author to add version 0.4.0 to the maven. This version was in jcenter as an artifact, but there are problems with it.

Latest update is that WebAssembly is now supported on Android with some caveats. See here for details.

Hey man, before all thank u so much for taking the time for that excellent and detailed explanation. Right know with my team we are trying to use agent-js on RN and we already fixed every problem you mention but we are keep having problems with WebAssembly. We are aiming to iOS 14+ so we should be able to run WebAssembly without problem BUT we didnt have any luck. It works on the simulator with iOS 15.2 without problems, but when we test it on iPhone with iOS 15.0 we are getting ReferenceError: Can't find variable: WebAssembly Before this we tried use wasm2js but again, for the simulator it works just fine, but into the iPhone it takes an eternity, almost 5 minutes. Do u have any idea or tip to give us? Did u try it on iPhone already?

1 Like

Hmmm that’s really weird. WebAssembly should definitely be supported in the JSC that ships with iOS starting from v14. Should also be supported in v15…

I’ve only tried on my iOS 14 iPhone device… haven’t tried on iOS 15 yet.

Are you sure you’re using JSC, not Hermes? Can you also share your RN version?

Hey, thanks for your answer, about Hermes I am sure we are no using it because I have this line into Podfile :hermes_enabled => false and I understand that if we are not using hermes by default we are using JSC, right?

We are using version 0.66.3 of RN

That’s really weird. It should be using JSC then.

If it works on your iOS 15 simulator but not your iOS 15 device, then I can’t think of what could be the reason for the discrepancy. It should work on both device and simulator. Do you have another iPhone you can try it on? Maybe double check the WebKit version on your iPhone? (No idea how to do that myself)

Yep, we are exactly in the same mood right know. We only can think in an error on project configuration, but we don’t know why in the simulator run. Maybe is something related with react-native command vs xcode I don’t have any idea

I reported the same issue to the guys over at distrikt:

maybe @awrelll knows how to solve this?

While using WebAssembly in mobile apps is a good workaround , I believe native libraries are way to go. Simplifies entire development process. We developed native Java Agent. IC4J · GitHub. But to make it complete we will also need IOS counterpart. Any kick ass Swift/ObjectiveC developer up for that? I know from my experience it’s not easy task, I basically spent weeks in Rust debugger to understand ICP protocol, debugging Rust Agent code. So I can provide help if needed (while I did some work with Swift I do not feel competent to write professional library). We received grant for our project from Dfinity, so there is a good chance to receive one for iOS native library. We are also working on professional documentation and more samples, so that can be eventually reused.

1 Like

Are you still facing this issue with iOS 15?

I took a look, and I believe it might be due to Apple banning JIT on native iOS apps (WebView and Safari are exceptions). Why it was allowed in iOS 14 but not iOS 15 I have no idea.

I think we might need to go without WebAssembly for BLS signature validation. I spent an hour or two over the weekend doing some research, and I think the process is more straightforward than I had thought:

  1. Take BLS Rust code from agent_dart (same code used by agent-js), and compile it into a .a (or .so) library using cargo build --lib
  2. Create a native module in RN that exposes a JavaScript interface that when called will call the compiled BLS library in native side
    a. In Android, use Java Native Interface (JNI) to load the .a or .so library so it can be called by Java code
    b. In iOS, no need for this because Objective-C can call C directly without any special setup
  3. Patch the agent-js library to remove the BLS wasm code and instead call your newly created native module’s JavaScript interface

It should be no more than a day’s work, but I’ve never actually done something like this before, so there are probably a bunch of hidden gotchas.

2 Likes

FYI I tried this for Android earlier today and it works. This means I can do BLS signature verification on React Native + Android using Rust and without going through WebAssembly. It’s also faster than with WebAssembly.

I’ll try with iOS tomorrow.

EDIT: It works for iOS too. Was quite painful not gonna lie…

4 Likes

See plug’s mobile app repo, they use agent-rs directly. Maybe it’s another choice

2 Likes

Hi Neeboo,

We have been using agent_dart for our Flutter mobile application, which worked like a charm until recently.

We are aware of the recent changes for calling API endpoints and verified that we are using URLs as advised in the below post i.e. “.ic0.app”

Our API calls are throwing the below exception. Any pointer on what can be the potential fix?

Exception has occurred.
"Server returned an error:
Code: 307 (Temporary Redirect)
Body:

307 Temporary Redirect

307 Temporary Redirect


nginx/1.21.3