How do their APIs compare?

These two projects are fundamentally different in scope, so their "APIs" compare more like apples to oranges — one is a distributed workflow engine's execution/task API, the other is a single Android UI widget's view API.

conductor-oss/conductor: system task / workflow API

Conductor's API surface here is centered on workflow orchestration primitives — tasks that plug into a broader durable-execution engine:

• Tasks are implemented as Java classes extending WorkflowSystemTask and operate on TaskModel/WorkflowModel objects passed in by the WorkflowExecutor. For example, ListApiToolsTask fetches and parses API specs (OpenAPI/Swagger/Postman) with a defined JSON input (specUrl, headers) and JSON output (tools, baseUrl, format), documented directly in the class Javadoc [agentspan/src/main/java/org/conductoross/conductor/ai/agentspan/runtime/service/ListApiToolsTask.java:L32-L54].
• Similarly, PlanAndCompileTask takes a plan JSON (planJson, parentName, model, harnessTimeoutSeconds) and compiles it into a Conductor WorkflowDef, returning workflowDef, workflowName, error, warnings, stats [agentspan/src/main/java/org/conductoross/conductor/ai/agentspan/runtime/service/PlanAndCompileTask.java:L42-L69].
• Tool definitions (ToolConfig) are compiled into LLM-consumable tool specs via ToolCompiler, which maps SDK tool types (worker, http, mcp, agent_tool, human, generate_image, etc.) to internal Conductor task types like SIMPLE, HTTP, CALL_MCP_TOOL, SUB_WORKFLOW, HUMAN [agentspan/src/main/java/org/conductoross/conductor/ai/agentspan/runtime/compiler/ToolCompiler.java:L138-L152].

So the "API" is really a contract of structured JSON inputs/outputs per task type, invoked asynchronously by the workflow engine rather than called directly by a client — it's an internal execution API, not a UI API. It's designed for composability (tasks referencing other tasks' outputs via ${taskRef.output.field} expressions, as seen in [agentspan/.../AgentCompiler.java:L1538-L1544]).

romandanylyk/pageindicatorview: Android View API

This library exposes a much simpler, synchronous, imperative View API meant to be called directly from an Activity/Fragment:

• Core usage is two calls: setCount(int) and setSelection(int) on a PageIndicatorView instance obtained via findViewById [README.md:L41-L47].
• It also supports declarative configuration via XML attributes (piv_animationType, piv_dynamicCount, piv_selectedColor, piv_viewPager, etc.) [README.md:L50-L64].
• Optional integration binds directly to ViewPager.OnPageChangeListener, calling setSelection(position) on page change events [README.md:L92-L104].
• Internally, animation types (e.g. FillAnimation, WormAnimation) expose a fluent builder-style API like .with(colorStart, colorEnd, radius, stroke) that returns this for chaining and feeds a ValueAnimator [pageindicatorview/src/main/java/com/rd/animation/type/FillAnimation.java:L34-L39].

Comparison summary