Using the niddler IntelliJ plugin

Using the niddler IntelliJ plugin

Using the niddler IntelliJ plugin

For an introduction to niddler, please check the post Introducing Niddler.

This post is a guide to the niddler plugin, for instructions on how to setup the libraries, go check out the Introducing Niddler post.


Installing the niddler plugin

The niddler plugin is available for free from the IntelliJ plugin marketplace. Simply go to Settings → Plugins → Search for niddler



The plugin window currently has the following features:

  1. The list of requests/responses
  2. The details about the selected item in area 1
  3. The session starting/stopping toolbar
  4. Display options and other actions for the current session
  5. Filtering for the current session
  6. Toolbar for creating additional session and debugging options
  7. Status of the session


Screenshot of the niddler interface, annotated to include most important interaction areas Basic niddler interface


Step 1 — Connect to a niddler server

Use the play icon of the session toolbar to connect to a niddler server. This will bring up the connection dialog. The niddler libraries contain a discovery mechanism that allows the plugin to find active niddler sessions on attached devices. The plugin is capable of detecting sessions on your local device (localhost, including ios simulators), android devices connected via ADB and i-devices connected via USB or remote connections (anything libimobiledevice can find). The plugin tries to guess the location for adb and libimobiledevice binaries, if it can’t find them and you get warning messages in the connection window, please go to your IDE’s settings, search for niddler and update the paths there.
The stop action stops the connection with the current server, note that this does not wipe the locally stored data, this is kept in RAM until cleared via the trash action.
The debug action is described in more detail in <Niddler Plugin Advanced, coming soon>

If the plugin is not able to find the device or sessions on that device or you want to connect to a coworkers device that is not connected to your PC, you can choose to make a direct connection by entering the device IP and the port on which niddler is running. This port is setup by the library and can (in the case for the android library) be found in the notification on the target device.



Screenshot of the niddler connection dialog Niddler connection dialog


To further aid you in finding the right process to connect to, the plugin can display custom icons to help you identify processes. By default the following 4 icons (names) are supported by the plugin: android, apple, dart, flutter. To use custom icons, place them in the .idea/niddler folder (square 20x20 or 40x40 @2x) with the name of file denoting the name of the icon specified in the library.

Check the documentation for your specific library for information on how to set this up for your app (android and dart/flutter)


Step 2 — Inspect requests/responses

As soon as you are connected and your application is making requests (or has made requests that are available in the server memory buffer), you will now see these requests appear on the left hand side. The default view for this panel is ‘Timeline’, in this view, requests and responses are displayed in the order seen by the server (allowing for multi-threading to schedule multiple requests at the same time).


Requests and responses in timeline view


In this view you can see the following information

  • Timestamp: request/response timestamp (as reported by the device)
  • Direction indicator:
    - Up arrow is a request
    - Down arrow a response
    - Data returned from cache (eg http 304) and changed requests/responses get a special indicator
  • Method: The method of the request. Can be any string that makes sense for your protocol. For HTTP this is one of the HTTP methods
  • Request URI: If your requests all go to the same server, you can strip a part of the URI by right-clicking an item and selecting ‘Hide base urls’ from the context menu
  • Status code: Response status code
  • Body mime type: The plugin uses a best-effort way to determine the body mime type based on the content-type and/or based on the actual content

When the server is serving requests from its internal memory cache, it is possible that for some requests/responses the corresponding response/request is no longer retained. In that case the information displayed will be reduced to what is known. This is also the case for requests that are still in-flight, for those there is for example no status code yet.

Tip: pressing the ‘r’ key when an item is selected will try and select the corresponding request or response for the item

The right-click context menu of an item gives you access to a number of extra options:

  • Copy URL: If present, copy the request URL to clipboard
  • Copy body: If present, copy the request/response body to clipboard
    (Based on the data type this can be text, image, …)
  • Export cUrl Request: Generate a cUrl snippet representing the request and copy it to clipboard
  • Add request rewrite rule: Please refer to the <Niddler Plugin Advanced> topic
  • Hide/show base urls: Allows you to hide/show part of the URLs for similar requests in the UI


Step 3 — Request/Response details

When you have an item selected on the left side, the right side hows more detailed information about that item.

This information is divided into 2 tabs: details and body

In the details tab you get an overview of parameters associated with the request or response. This is usually split up into 3 blocks:

  • General: Contains generic information about the request or response such as timestamp, method, execution time, …
  • Headers: Contains information about the headers sent as part of the request or in response from the server. Headers are marked with a * in front if they are headers added by a deeper layer running after niddler (eg: okHttp adds some headers in the network interceptor layer that are invisible to the application interceptor layer).
  • Stacktrace: When the library has been configured to include request-site stack traces, these will be placed in this panel. If possible, these stack traces are clickable if their implementation can be found in the current project.


Screenshot of niddler plugin detail panel Detail panel


ip: Most items are not selectable but you can use right-click context menu to copy key and/or value

The body panel contains a representation of the request/response body if available. The exact representation options is determined by the body, eg:some data such as json has a structured representation, data such as images do not.

In the body panel, a maximum of 3 visualisation options are present:

  • Structured: For data which has a structured representation such as json/xml, a tree-like view of the data. Supports copying using regular copy shortcut or via right-click context menu
  • Pretty: For data which has a pretty-formatted representation, this will be rendered here. Eg: pretty-formatted json or images
  • Raw: The only option always present, a raw view of the data as sent by the server. For textual data this is a textview, for binary data that cannot be represented as text, this shows a simple hex viewer

The panel also includes a save button that allows you to save the body to a file.


Screenshot of structured json in tree-view Structured view — json


Screenshot of pretty view json representation Pretty view — json


Screenshot of pretty view showing image of a cat Pretty View — Image


Screenshot of binary hex viewer Binary hex viewer


Session action panel

The session action panel contains some actions related to the displaying/exporting of currently viewed data.


Screenshot of session action panel actions Session action panel


These actions are, from top to bottom:

  • Timeline: View data in timeline view (default)
  • Linked: View data in linked view (WIP). In this view, requests and responses are shown linked together in a tree view. When the library is capable of determining that the actual network request is different from what the app has seen, it will also expose these requests here. Useful when inspecting 304s with okHttp as these are reported as normal 200s with data to the application layer
  • Auto-scroll: Automatically scroll the view when new items are available
  • Trash: Clear session RAM in the plugin. This does not clear the storage on the server, only what the plugin has seen. Reconnecting to the same server will retrieve all data stored on the server again
  • Save: Export the current RAM data to the HttpArchive v1.2 format(.har) which can be viewed in your browser or using compatible tools such as Charles Proxy



On the right side of the window, an input field allows you to filter the current view based on URI matching. Only requests with a URL containing the value will be displayed in the data view.
Note that all data is still being saved to RAM, clearing the filter will show them again.

Tip: Confused why there is no data showing even though you are connected and you are sure requests are being made? Check if you did not forget to clear the filter!

The save action can take this filter into account when exporting. If you have an active filter when triggering a save, the plugin will ask you if you wish to save the data with the filter applied, or all data.


Other options

On the far left action panel, two actions can be seem:


  • New session: Open a new tab to start another niddler session. Tabs are fully separate and keep their own data in memory
  • Debug configuration: Configure rewrite rules for the current project. For more information see <Niddler Plugin Advanced>



The niddler plugin comes with a number of configurable settings. These can be accessed from the IDE settings.

Global settings: General niddler settings, not specific to the current project. These settings are used to configure the path to the different tools in use by the plugin eg: adb, libimobiledevice. A restart may be required after setting the paths.

Per-project settings: The plugin has a feature where it can listen to when you start your application by using the IntelliJ run configurations and automatically connect to the niddler server of the newly started process. This can be enabled/disabled per-project. In addition to enabling/disabling this option, you can choose wether the plugin needs to create a new session tab to connect in or of it can re-use a session tab with a non-connected session.

Note: Automatically connecting uses the log output of the application (eg logcat) to get connection information. In some cases, a crashing application can trigger the OS to restart the app, this will also cause the niddler server to automatically reconnect, potentially losing the previous session if the option has been configured in settings to re-use idle session tabs.

Note 2: Since the plugin keeps the received items in ram, using automatic connections in combination with not re-using idle tabs, a large number of tabs can be open and adversely affect the memory utilisation of the IDE.



Development of the plugin happens on github right here. If you have feature requests, issues etc, please let me know!