laravel-notification-channels/ionic-push-notifications
Send Ionic push notifications from Laravel through a dedicated notification channel. This package integrates the Ionic Push service so you can deliver messages to your mobile app users with a clean, familiar Laravel notification API.
This package is archived (last release October 2017) and targets Ionic Push, a service Ionic shut down — treat this as a migration/reference exercise, not a greenfield choice. If you inherit a codebase using it, the steps below are how you get oriented.
Install (only on a legacy Laravel 5.x app):
composer require laravel-notification-channels/ionic-push-notifications
Laravel 5.5+ auto-discovers NotificationChannels\IonicPush\IonicPushServiceProvider. On older versions, add it to config/app.php providers.
Credentials. Add your Ionic API key to .env and wire it into config/services.php:
'ionic' => [
'api_key' => env('IONIC_API_KEY'),
],
Check the service provider in src/ for the exact config key it reads — some channel packages use a dedicated published config file instead of services.php.
Ionic dashboard setup. You need a security profile configured in the Ionic dashboard (this is where your FCM/GCM server key lives). Without it, Android pushes are accepted by the API but never delivered — the single most common "it worked in staging" failure with this channel.
Client side. Register the device with the Ionic client SDK to obtain a push token, then persist it on your user (e.g. ionic_push_token column or a device_tokens relation).
First notification.
php artisan make:notification OrderShipped
public function via($notifiable)
{
return [\NotificationChannels\IonicPush\IonicPushChannel::class];
}
public function toIonicPush($notifiable)
{
return \NotificationChannels\IonicPush\IonicPushMessage::create('Your order has shipped')
->title('Order #1234')
->badge(1)
->sound('default');
}
And on the notifiable:
public function routeNotificationForIonicPush()
{
return $this->ionic_push_token;
}
Then $user->notify(new OrderShipped($order));
Where to look first: src/IonicPushChannel.php for the HTTP call and error handling, src/IonicPushMessage.php for the fluent API surface, and the service provider for the config key and any bindings.
Multi-device routing. Return an array of tokens from routeNotificationForIonicPush() and the channel fans out in one API call. Store tokens per device (a device_tokens table keyed by user is the sane model) so you can prune dead ones independently.
Message builder. The fluent IonicPushMessage is the primary abstraction. Typical chain:
IonicPushMessage::create($body)
->title($title)
->badge($count)
->sound('default')
->payload(['route' => '/orders/1234', 'type' => 'order']);
The payload array is what your Ionic client app reads for deep links and in-app routing — keep it small, stable, and version it if the mobile app ships at a different cadence than the backend.
Guard the channel in via(). Don't send to a user with no tokens:
public function via($notifiable)
{
return $notifiable->ionic_push_token
? [IonicPushChannel::class]
: [];
}
Otherwise you get API errors or silent no-ops buried in logs.
Queue it. Any real volume means the channel's Guzzle call sits in your request cycle. Add implements ShouldQueue to the notification, or send from a queued job. The notification channel contract composes fine with ShouldQueue.
On-demand notifications. Most channels of this vintage read routeNotificationFor() under the hood, so Notification::route('IonicPush', $token)->notify(...) typically works for one-off sends (test pushes, transactional messages before a user is logged in). Verify against the channel source before relying on it.
Testing. Use Notification::fake() and assertSentTo($user, OrderShipped::class, fn ($n) => ...) to assert routing/conditions without hitting the network. If the package uses Guzzle 6 directly rather than Laravel's Http facade, Http::fake() won't intercept it — mock the Guzzle client or bind a fake channel implementation in the container instead.
Migration path. For anything new, replace this channel with laravel-notification-channels/fcm (FCM v1) or a direct APNs channel, and keep your own toFcm()/toApns() message classes. The Notification + NotificationChannel shape transfers one-to-one; only the message builder and credentials change.
via()/toX() conventions, Symfony/Guzzle major bumps, container resolution changes). Don't attempt to composer require it into a modern app and expect it to resolve.profile() setter, set it explicitly per environment (dev/prod credentials differ).CouldNotSendNotification. The channel throws this on non-2xx responses. Don't swallow it blindly — log the response body, which carries per-token rejection reasons that tell you which device tokens are stale.device not registered-style errors and re-register on app launch; otherwise a single dead token can make a whole batch look broken.payload, and be aware newer Android versions require a notification channel to be created client-side or nothing renders.php artisan config:cache in production, changes to IONIC_API_KEY need a cache clear. Classic first-deploy footgun.src/IonicPushChannel.php; the 2017-era API expected { tokens, profile, notification: { title, message, payload } }. If your messages look malformed, the message class's toArray() is the place to inspect and override.IonicPushMessage builder pattern but swap the transport for Laravel's Http facade — that buys you retries, timeouts, Http::fake() testability, and events, none of which the original Guzzle call offers.How can I help you explore Laravel packages today?