Develop Reference

Flutter Push notification to iOS & Android without firebase?

I wonder how to push notifications to my Flutter app users in both Android and iOS devices Without using any external service like Firebase or OneSignal?
I want to implement a code in PHP which can send push real time notifications to all/spesific users in my Flutter app which works in both Android and iOS.
I found some solutions like flutter_local_notifications with workmanger which can fetch the API in the background only minimum 15 minuts. Workmanger is Not good solution because its work only during 15 min and it will consume the battery and internet.
I need an efficient solution to my flutter app for both Android & iOS devices, which can listen on real time to the coming messages from the server even when the app is closed.
How to fix that? thanks

iOS
You will always need to integrate with Apple's Push Notification Server (APNS) if your app needs make API calls in the background. The reason is that once an app is put into the background, iOS will often put the app to sleep soon afterwards.
The correct approach to this is to use a silent push notification to wake up the app. When received, no message is shown on device but the app get's about 30 seconds in order to make API calls.
In your case, the app can make the API call and then schedule a local push notification to display your message.
Background updates via push notifications
Scheduling local push notifications
Android
It looks like WorkManager is your best bet. I don't see how it can affect battery.
FYI
You don't need to use Firebase or OneSignal for push notifications, silent or otherwise. They are simply 3rd party services that interact with the official Apple or Google Push Notification Servers.

Unfortunately, I think this is not possible. Even OneSignal uses the Firebase API to deliver the notifications, as you can see here. For all other solutions, you will have to balance the update frequency with internet use and battery consumption.

Is it possible to implement custom push notifications for mobile without the use of Firebase?

I am writing a mobile application in Flutter, which is Google's SDK for developing mobile apps.
Basically, I was researching into how to mobile push notifications and every source I could find would point me in the direction of Firebase, which is Google's mobile and web application platform. Firebase is extremely nice and makes it really easy to send push notifications from user to user,
but I would like to learn how to do it myself and I can not find documentation to do that.
All I could find was creating a Dart Isolate in the background of my application to solely listen for incoming notifications. The Firebase plugin for Dart, from what I can gather, does just that; creates an Isolate to listen for notifications, even when the app is closed/user has killed the app.
So my main question is, is it possible to create an Isolate in the background to keep a WebSocket connection alive at all times that would listen for data from a server, and then push that data to the screen in the form of a notification without the use of Firebase? (I have created a server in Node.js, and it would be cool if I could just handle all notifications from my Node server). Thanks!

Of course you can implement push notifications without Firebase. Do a web search for “list of push notification services” and you’ll see lists of a variety of services out there. And, on the iOS side, you can have your web service interact directly with the APNs, and have no third party service (such as Firebase’s FCM) involved at all. On the Android side, though, FCM is probably still the logical choice. It’s easy, scalable, and is free.
I would not suggest trying to keep a socket connection alive at all times, though (if that’s what you’re contemplating). First, you won’t even be able to do that on the iOS side when the app is not active. Second, these push notification services are designed to solve the problem that web sockets introduce, namely the user device resource drain and the cost of maintaining a scalable server to maintain all of those connections.
Sure, use sockets where you need them (e.g. near-instantaneous communication while the app is active, etc.), but it’s not the right solution when the app is no longer active.

For iOS side, I would love to point you to Send Push Notification Through APNs Using Node.js. I tried it with my own node server and found it super easy.

iOS Swift 3: implementing chain of notifications emulating Android's AlarmManager

I'm implementing an app with an internal calendar, fetched from a remote web service. I want to send a local notification to the user when an event of interest is scheduled in the calendar, at a specific time chosen by him. Just like the iOS calendar app, when you can create an event and ask to be notified X hours/days before it happens. The main difference is that you can't create events: they are downloaded from a pre-populated remote calendar.
In Android I've solved the problem by using AlarmManager, while in iOS with Swift 3 the closest I've got to porting the same solution was via opportunistic background data fetch. The main difference between the two solutions is that background data fetch doesn't work when the app has been killed.
It would be really important for me that local notifications worked even when the app is killed. I think users expect apps notifications to work even when the app is closed, like it happens with WhatsApp or Facebook. I know that those notifications are triggered by someone writing something and therefore they are Push Notifications, but the average user just expects notifications to keep working even when the app is closed.
What would be the most elegant solution to "emulate" the behaviour of Android's AlarmManager in iOS?
Scheduling a bunch of notifications in advance hoping that the user will eventually open the app before all of them are dequeued looks a badly designed solution.
Also, delegating all the work to the server and push the notifications to the subscribed devices looks quite bad too as it requires much more work on the server side. Plus it requires a server which is able to awake itself to send push notifications, which is something that I don't have. I only have a simple webserver which answers to HTTP requests.
EDIT : The ideal solution I'm looking for isn't any of the previous 2 options, since I find them more like workarounds than actual elegant solutions to what I perceive being a fairly common problem. There has to be a third option...

In iOS there is no way to achieve this. Looking at the documentation of application(_:didReceiveRemoteNotification:fetchCompletionHandler:), it states that
the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
You can receive push notifications, but no code will be executed until the user launches your app. So unless you are sending remote push notifications from a server, you cannot set up new local notifications until the user opens your app.

Android push notification without Google service

I am from Apple world, so I don't have much experience with Android.
But what I am looking is a way that Android devices receive push notification, without using any third party servers. Notification need to be standard Android notification (look and feel)
The reason I need this is, because I would need this in a room that does not have access to outer world. (can't connect to any server) But I have my own WiFi so users can receive push notification from my server via my wifi.
I know that on iOS this is not possible, what about Android?

it is possible using Service left running in system (background) after app exit. some samples HERE, you should be interested in START_STICKY flag
you have to keep some connection (socket?) or interval requesting (not so well, but possible) inside your Service. Google Services (including Firebase) does that by itself and "redeliver" received push messages to properly declared (in manifest) app

Firebase Background Data Sync

I have an Android GCM based Alarm Clock application that, for our specific industry use case, works great.
Here’s how it works now: A back-end system sends a GCM message to the phone. A BroadcastReceiver starts the Alarm Clock Activity which overrides volume settings, plays the alarm, turns on the back light, displays a full screen UI over the lock screen, and communicates (via upstream GCM) to the back-end when the Alarm is dismissed. The phone can be restarted, the app not launched by the user, and the Alarm Clock will still get launched when the back-end pushes the GCM message.
Programming design question: What is the correct way to replace this with Firebase?
Approaches I have tried out:
Simply replace GCM with FCM (not using a Firebase Realtime database)
Start a Service at boot (and within onCreate) that keeps a reference to a Firebase Realtime database. (https://gist.github.com/vikrum/6170193)
Both of those approaches work. Certainly replacing GCM with FCM is straightforward. Is keeping a Firebase reference alive in a Service the right architecture for processing an Alarm? Doesn’t feel right.
I have not yet coded with keepSynced(true). Perhaps that is what I should be using. I’m looking for a design that uses Firebase data synchronization instead of having to deal with the FCM RemoteMessageBuilder layer directly - I'll be able to retire a lot of XMPP code, a Windows Service, etc..
What’s the correct way to implement my Alarm Clock using Firebase?

This guidance from Doug Stevenson on Quora is the best I've found:
The big difference between Firebase Cloud Messaging and Firebase Realtime Database is this: With messaging, you will be able to wake the device from sleep even while the app is not running. The database can only receive updates to registered listeners while the app is currently running, and if the device is not in doze mode (for Android M).
Use Realtime Database when users are in your app and actively interacting with its data.
Use Cloud Messaging for times when you don’t know if the user is in your app, but you want to get them into your app (or make your app do something at a particular moment that you decide).
Messaging also has very restricted payload sizes (4k). With Database, you can read as much as you want from any node in your structure.
I’m speaking here in a general sense for all of Android, iOS, and Chrome. Each platform has their own particular ways of handling messages, but the semantics are similar.