[FREE] NexGemini - Use Gemini AI Models API in your applications

NexGemini — Kodular Community Documentation

Hi, This new Kodular/MIT App Inventor Extension is a very simple way to connect Gemini API to your app projects to let your app support Gemini AI inside the application. For now, the extension supports text only.

Installation: Place the NexGemini.aix extension into your Kodular project via the Extensions > Import extension (.aix) option.

Permissions: The extension requires the INTERNET permission to call the Gemini API. Kodular will add this automatically when you call network APIs.

Quick Setup

  • Add the extension to your project.
  • Set your Gemini API key using the ApiKey property before calling GetResponse - in the properties panel ( the panel on the right in design mode when you add the extension to the screen).
  • Use GetResponse(prompt) to send prompts; handle the GotMessageResponse and ErrorOccurred events.

Blocks Reference

Here are the blocks and their functions :

Set API Key :

  • Set - ApiKey - to (Property — Set): Set your Gemini API key (String).
    • Purpose: Authentication for requests to Google’s Gemini REST endpoint.
    • Usage: Call once during app startup (or when the user enters an API key, if your app uses custom user added API key).
    • Example: Set ApiKey to YOUR_API_KEY_HERE.

Get API Key :

  • ApiKey (Property — Get): Returns the currently set API key (String).
    • Note: For security, avoid hardcoding production keys inside the app.

Set and Get Gemini AI Model :

  • Model (Property — Set): Set the Gemini model to use (String).
    • Default: gemini-3-flash-preview (unless changed in the extension source).
    • Usage: Use to switch models if you have access to multiple models.

  • Model (Property — Get): Returns the active model string.

Send Messege to Gemini (Get Response) :

  • GetResponse(prompt) (Function)
    • Parameters: prompt (String) — the user prompt to send to Gemini.
    • Behavior: Asynchronous call. The extension performs an HTTP POST to the Gemini REST endpoint and parses the returned text.
    • Returns: Nothing directly. Results are delivered via the GotMessageResponse event, or ErrorOccurred on failure.
    • Notes:
      • Always ensure ApiKey is set before calling this function.
      • The function runs on a background thread; UI blocks remain responsive.
    • Example block sequence:
      1. Set ApiKey to user-provided key.
      2. Call GetResponse with a prompt string.
      3. In GotMessageResponse, display the response in a Label or Notifier.

  • GotMessageResponse(response) (Event)
    • Triggered when the Gemini API returns text.
    • Parameter: response (String) — the text returned by the model.
    • Example: When NexGemini.GotMessageResponse do set Label1.Text to response.

  • ErrorOccurred(errorMessage) (Event)
    • Triggered when any error occurs (network, parsing, or configuration).
    • Parameter: errorMessage (String) — diagnostic message.
    • Example: Show errorMessage with a Notifier.ShowAlert or log it for debugging.

Example Kodular Flow (step-by-step)

  1. Place NexGemini extension in the Designer.
  2. Add a TextBox for user prompt and a Button to send.
  3. Add a Label to show the AI’s response.
  4. Blocks:
    • On Screen.Initialize: set NexGemini.ApiKey to a stored key or blank until user inputs it.
    • On Button.Click: call NexGemini.GetResponse(TextBox1.Text).
    • When NexGemini.GotMessageResponse: set Label1.Text to response.
    • When NexGemini.ErrorOccurred: Notifier.ShowAlert(errorMessage).

Response Format

  • The extension extracts the primary text from the Gemini response and supplies it via GotMessageResponse. The returned response is plain text.

Error Handling Recommendations

  • Validate prompt is not empty before calling GetResponse.
  • Use ErrorOccurred to surface issues to users and to retry or fallback gracefully.
  • Consider rate-limiting requests from the UI (debounce buttons) to avoid hitting API limits.

Known Compilation Issue & Workaround

Some Kodular projects may fail to compile when an extension bundles classes that collide with Kodular/App Inventor internal classes. If you experience a compile-time error mentioning conflicts with com.google.appinventor.components.annotations.DesignerComponent or similar, use one of the following approaches:

  1. Recommended quick workaround: Append -d8fix to your app’s Version Name in Kodular. Example: if your Version Name is 2.0.0, change it to 2.0.0-d8fix.

    • How to set in Kodular: Open Project Settings → Version Name → append -d8fix and re-export.
    • Effect: Kodular’s builder applies an internal workaround to avoid the D8 conflicts and lets the app compile.
    • Caveat: -d8fix is a workaround and may have edge-case behavior in some projects; prefer removing conflicting classes when possible.
  2. Long-term fix: Ensure the extension package does NOT bundle App Inventor runtime/annotation classes. The extension should only include its own code and rely on Kodular’s built-in runtime. If you build the extension locally, remove any annotations.jar or runtime.jar from the extension deps before packaging.

Security & Privacy

  • API keys: Treat Gemini API keys as secrets. Do not hardcode production keys in public projects. Prefer providing keys via secure backend or user input.
  • Data: Prompts and responses travel over HTTPS to Google’s Generative Language endpoint. Handle sensitive data according to best practices.

Support & Troubleshooting

  • If GotMessageResponse is not triggered:
    • Confirm ApiKey is set and valid.
    • Check network connectivity and that INTERNET permission is present.
    • Inspect ErrorOccurred messages for HTTP codes or parsing errors.
  • If compilation fails with D8 conflicts:
    • First try the -d8fix Version Name workaround.
    • If that is unacceptable, rebuild the extension without bundling App Inventor runtime/annotation JARs.

DOWNLOADS


2 Likes

Thank you for you’re contributions.

Can you explain why do we need to add this in the package name? Which libraries are used in this aix? Though with web component we can also be able to performe this function.

??

the extension jar that was packaged in the .aix contained a copy of com.google.appinventor…DesignerComponent (and originally a bunch of other App‑Inventor runtime/annotation jars). Kodular itself already has those classes built in, so they collide.

Kodular’s build pipeline has a little “hack” to work around exactly this sort of conflict; when you append ‑d8fix to the version name the builder adds an extra step that strips duplicate classes / applies a tiny proguard rule before dexing. It’s not magic – it’s just a convenient flag you can flip from the project settings instead of rebuilding the extension without the offending jars. The flag is recognised by the build tools because the version name is passed all the way through the packaging scripts; they look for that suffix and, if present, run the fix‑up.

So the reason you “need” to add ‑d8fix is solely because the .aix you imported still contained one of those App‑Inventor annotation classes.

We are going to fix this issue ASAP. For now, this -d8fix doesn’t show up in the version name in your device where you install it, it is just inside kodular. So, there will not be any problem from the user side, and the extension works perfectly fine. You can check out the .aia sample app where you can upload it to your kodular and add your own Gemini API key and test the extension.

And these are the libraries we used :

  • java.net (HttpURLConnection, URL, etc.)
  • org.json
  • Android SDK classes (android.os, java.io, etc.)
  • App Inventor/Kodular extension API packages (com.google.appinventor.components.*)