Dispatcher worker for push notifications.

If your push workers are relatively static, it is encouraged to follow the adapter guides. For other use cases, such as supporting dynamic configurations, dispatchers can be started and stopped as needed.

Using Dynamic Dispatchers

# FCM as an example, but use the relevant options for your push type.
opts = [
  adapter: Pigeon.FCM,
  auth: YourApp.Goth,
  project_id: "example-project-123"
]

{:ok, pid} = Pigeon.Dispatcher.start_link(opts)
notification = Pigeon.FCM.Notification.new({:token, "regid"})

Pigeon.push(pid, notification)

Loading Configurations from a Database

defmodule YourApp.Application do
  @moduledoc false

  use Application

  @doc false
  def start(_type, _args) do
    children = [
      {Goth, name: YourApp.Goth},
      YourApp.Repo,
      {Registry, keys: :unique, name: Registry.YourApp}
    ] ++ push_workers()
    opts = [strategy: :one_for_one, name: YourApp.Supervisor]
    Supervisor.start_link(children, opts)
  end

  defp push_workers do
    YourApp.Repo.PushApplication
    |> YourApp.Repo.all()
    |> Enum.map(&push_spec/1)
  end

  defp push_spec(%{type: "apns"} = config)
    {Pigeon.Dispatcher, [
      adapter: Pigeon.APNS,
      key: config.key,
      key_identifier: config.key_identifier,
      team_id: config.team_id,
      mode: config.mode,
      name: {:via, Registry, {Registry.YourApp, config.name}}
    ]}
  end

  defp push_spec(%{type: "fcm"} = config) do
    {Pigeon.Dispatcher, [
      adapter: Pigeon.FCM,
      auth: String.to_existing_atom(config.auth),
      name: {:via, Registry, {Registry.YourApp, config.name}},
      project_id: config.project_id
    ]}
  end
end

Once running, you can send to any of these workers by name.

Pigeon.push({:via, Registry, {Registry.YourApp, "app1"}}, notification)