You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a couple of mails with @jamesgolick I understood that letting apns_connection processes die normally when they're disconnected from Apple is not the best idea. This is the final mail
Since my applications usually send packs of notifications (i.e. the same notification to a bunch of users instead of just one notification to some user)… I run this code right before trying to send each pack:
ensure_started() ->tryapns:connect(?APPLE_CONNECTION,
funhandle_apns_error/2,
funhandle_delete_subscription/1) of
{ok, _} ->
ok;
{error, {already_started, _}} ->
ok;
{error, Reason} ->
?THROW("Couldn't start APNS4ERL: ~p. Apple Push Notifications will not work until the admin fixes this~n", [Reason])
catch_:Reason ->
?THROW("Couldn't start APNS4ERL: ~p. Apple Push Notifications will not work until the admin fixes this~n", [Reason])
end.
After thinking about it for a while, I feel the right thing to do would be to keep apns_connection process running even when it was disconnected from Apple and then connect it again when it has a new notification to send… Most likely it would be a good idea to turn it into a gen_fsm… I'll probably implement that in the near future.
The text was updated successfully, but these errors were encountered:
After a couple of mails with @jamesgolick I understood that letting
apns_connection
processes die normally when they're disconnected from Apple is not the best idea. This is the final mailThe text was updated successfully, but these errors were encountered: