Making HTTP calls from mobile apps

I am building a native iOS app, and am very interested in using IC. So far I could not find a straightforward way to communicate from my frontend interface to the canisters on IC. I’ve tried sending an http request based on the document describing the HTTS interface (The Internet Computer Interface Specification :: Internet Computer), but there are some ambiguous points. Is this http interface meant to be used within the agnet-js client only? Is there a working example of how to construct an http request? I strongly believe that supporting mobile development is critical to the success of IC!

2 Likes

Agreed on the last point!

I’m trying to use the agent js library with React Native. Apparently it should work. That code is open source on github so you could take a look at how it constructs the actual HTTP request (that wraps the Candid function call).

Have you had any luck using the js library with React Native? I’m hoping to avoid using React Native, but I would resort to it if it’s the only path to communicate with the IC canisters.

I’ll let you know once I try (in a couple weeks or less). Apparently, Flutter works too if you don’t like RN.

1 Like

For flutter devs, you can try our library

agent_dart

It’s in alpha stage, but you can try anyway. All the apis are similar to agent-js,
documents are coming! Stay tuned

2 Likes

I’ll give it a try for sure although I have no experience with Flutter!

For native coder, I think we have to wait for swift/kotlin library published somehow

I have some examples of sending raw ingress message through http POST ic-qr-scanner/bare-agent.js at main · ninegua/ic-qr-scanner · GitHub

It is quite simple actually if you know how to craft an ingress message before sending it.

3 Likes

Thank you for the example! I’ve tried constructing an http request in Swift in a way similar to your example, but on a local host and with an anonymous sender. I got a reject error concerning not finding the canister. My guess it’s because the request expects the canister_id to be a blob. Not sure how to retrieve the canister_id as a Principal type outside agent-js.

So I’m trying the @dfinity/agent JS library with RN right now and I’m running into an issue. Documented in @dfinity/agent not working with React Native.

1 Like

Fwiw, I track work for agent-js in GitHub, and React Native support is an open task for me. Issues · dfinity/agent-js · GitHub. I’ll respond to the other thread directly though

Sounds good. Is there a place I can list all the issues I’ve encountered so far?

Yes, you can create new issues directly in that GitHub page. I’m also happy to review and approve pull requests from the community, if you’re feeling generous :blush:

1 Like

OK I finally got the @dfinity/agent JS library working with React Native for both iOS and Android (at least for the emulators).

The process is quite involved, so it’s definitely not a straightforward integration like it is for web.

There are two core issues with using the agent JS library with RN:

  1. RN doesn’t provide direct access to the underlying byte stream for HTTP responses. Since canister responses are CBOR-encoded and therefore binary, reading those responses in JS land isn’t supported by RN out of the box.
  2. The agent JS library relies on a bunch of JS APIs that aren’t available in the default JS implementation shipped with RN apps. This is complicated by the fact that RN apps running on iOS actually use a different JS engine than RN apps running on Android.

Problem 1 can be solved by replacing the default fetch() implementation with the one offered by react-native-fetch-api. (rn-fetch-blob does not work.) You’ll then need to patch both that fetch library as well as the @dfinity/agent in your node_modules to configure it to work correctly, since it won’t work off the shelf. Basically, you need to make the fetch library pass base64-encoded bytes instead of blobs over the RN bridge.

Problem 2 is solved once these JS APIs are made available:

  • TextEncoder
  • ReadableStream
  • Buffer
  • BigInt
  • WebAssembly

The first two can be polyfilled using react-native-polyfill-globals, which incidentally is also the same library that polyfills the Fetch API implemented by the aforementioned react-native-fetch-api.

Buffer can be polyfilled using buffer and an explicit global.Buffer = buffer assignment.

The last two are the trickiest and the biggest pain in the ass. You could polyfill them using standard JS libraries like big-integer and webassemblyjs, but it won’t work because they’ll be too slow (or throw some cryptic errors). I’ve tried a bunch of polyfill libraries and none were performant enough for the BLS signature validation that is necessary for processing IC canister responses. (The one exception is JSBI as a polyfill for BigInt, which ran fast but required me to literally rewrite huge portions of the @dfinity/candid source. So not technically a drop-in polyfill.)

One thing I forgot to mention is that both BigInt and WebAssembly are supported on iOS but are NOT supported on Android. This is because RN uses the JavaScriptCore that ships with iOS devices, but RN bundles an older version of JavaScriptCore in the app itself for Android devices. And Apple pretty diligently updates their JavaScriptCore with new features on a regular basis. To get around this, I bundled a relatively new version of v8 instead of RN’s default JSC for Android, since v8 supports BigInt and WebAssembly if you use the JIT-enabled v8. Here is the catch: it executes wasm too slowly. The BLS signature validation wasm module hung for a few minutes before I killed it. I don’t know why v8 executed it slowly but iOS’s JSC was able to run it fast (under a second). To get around this, I manually converted the wasm bytes into JS code using wasm2js and patched the @dfinity/agent library again to run that JS code in lieu of wasm for validating BLS signatures. This reduced the execution time to under a second for Android, matching iOS. Now, update calls takes <5 seconds on both of my emulators, which I can work with.

Feel free to DM me if you’d like more details on how to get a RN mobile app set up to communicate with IC canisters. Hope this helps (if it hasn’t scared you away already).

6 Likes

This is marvelous work.

This is really fantastic, @jzxchiang! I’d like to work with you to avoid needing to modify node_modules anywhere, and maybe we can release a package with the necessary polyfills and setup groundwork to make this easier for everyone

3 Likes

Awesome work! I was able to get React Native work on the iOS side with using Buffer and react-native-polyfill-globals with patch-package. I tried following this approach to access the @dfinity/agent via JavaScriptCore in iOS, but was not successful. I used webpack to bundle the packages and loaded the bundled file with JSCore. I’m not sure why, even though React Native also uses JSCore. I would much rather access agent-js library this way than via React Native. I have no use for React Native. Any suggestion on getting JSCore to work?

Are you using the agent-js lib in a mobile web app, if not RN? What’s the error you’re seeing?

I’m trying to use agent-js lib in a native iOS app. JavaScriptCore library allows you to evaluate JavaScript code from within Swift based apps. I created a simple JS file that imports @dfinity/agent to be my API gateway. I bundled that file with webpack as I’ve mentioned. The error I see is:
ReferenceError: Can’t find variable: self"
and the stackt race info:

webpack_require

./node_modules/iso-url/index.js

webpack_require

./node_modules/borc/src/decoder.js

webpack_require

./node_modules/borc/src/diagnose.js

webpack_require

./node_modules/borc/src/index.js

webpack_require

./node_modules/@dfinity/agent/lib/esm/request_id.js

webpack_require

./node_modules/@dfinity/agent/lib/esm/auth.js

webpack_require

./node_modules/@dfinity/agent/lib/esm/agent/http/index.js

webpack_require

./node_modules/@dfinity/agent/lib/esm/agent/index.js

webpack_require

./node_modules/@dfinity/agent/lib/esm/actor.js

webpack_require

./node_modules/@dfinity/agent/lib/esm/index.js

webpack_require

Hi
Thanks for great answer. Can you elaborate on what was your final workaround for BigInt issue and the whole connection between mobile app and canister? I am on the same boat and do not want to re-invent the wheel as it seems you got it working