🔥v6 Notifications and Messaging Tracker Issue

[technoplato]

[Updated 2019/12/09] by @mikehardy & @Salakar - so don't blame @technoplato for these words :wink:

This issue is just to track the status of v6 notifications and messaging module.

Currently notifications is not available in react-native-firebase v6, and will not be. Why? https://github.com/invertase/react-native-firebase/issues/2566#issuecomment-541109278

You may not mix react-native-firebase v5 and v6, so if you want react-native-firebase notifications, you will not be able to use react-native-firebase v6.

This has the most current status: https://github.com/invertase/react-native-firebase/issues/2566#issuecomment-562700412

Options are:

• react-native-firebase v5
• react-native-firebase v6 + react-native-push-notifications (or other 3rd party) for free
• react-native-firebase v6 + recently announced Invertase licensed product "Notifee" which is approaching delivery but not ready yet

If you have any questions please read this thread. If your question hasn't already been answered please feel to raise it as an issue on the new Notifee repo.

Patience is always appreciated, and in the meantime react-native-firebase v5 continues to work and be updated.

[nuKs]

Hey!

Very impressed after seeing your tweet,

I was looking at how to test my notifications for android and seen this indeed is very specific. Wondering where that repo is, couldn't find the ongoing notification package folder. Would love to have a look at the code :)

I just stand my personal source code comments here in case anyone is interested.

// The only way to test notification integration effectively is through java
// UIAutomator. cf. `https://alexzh.com/2018/06/16/guide-testing-android-notifications/`.
// It is however difficult to change the time of the device programatically in
// order to set up the context for notification to happen cf.
// `https://stackoverflow.com/questions/17939572/how-to-set-time-to-device-programmatically`.
// It's possible outside tests through adb (and inside tests w/ appium
// cf. `http://appium.io/docs/en/writing-running-appium/android/android-shell/`).
// It seems possible to do it in tests through ProcessExecutor class but that seems
// unsafe `https://www.swtestacademy.com/adb-commands-java-device-manipulation/`
// and probably impossible with unrooted devices cf.
// `https://stackoverflow.com/questions/6584772/is-possible-to-set-system-datetime-from-my-android-app`.
// The only option that stands left is to set time through settings and use
// UIAutomator2 to do so automatically. Appium can't be used as it doesn't
// provide the underlying UIAutomator API (even though he uses it) to tests the
// notifications (as they appears outside of the app).
// `https://stackoverflow.com/questions/9434239/set-androids-date-time-programmatically/9434344`
// can help to launch the correct setting tab.

[mikehardy]

@nuKs your notes are incredibly thorough - nicely done. Just a question - in your research did you examine robolectric? I use it on a large android-native / not-react-native project to good effect. I've seen it enable just about every other bit of android testing (though obviously no iOS) I think including time travel, but you didn't mention it and I'm curious if you discarded it on purpose after examination or if it might be a new resource for you?

[nuKs]

Hi @mikehardy,

Using it as well ! :) Specifically for the testing of android app-level components in pure android/java setup.

From a theorical perspective

Coming from a non-mobile background, I've found the android doc to be misleading. Android app components' (services, content providers, activities, broadcast receivers, ...) individual lifecycle are never managed by the app code, but rather by the android system (hence the weird usage of singleton as the main pattern to access them). I think they should never be considered components in an OOP (thus architectural) sense, but only entry points (and above all, all the charge attributed to stuffs like service foreground priorities and stuffs like that are actually held at the process level and not at all at the class instance level nor at the thread one).

I find Robolectric to fit nicely with these components and their interactions. It mocks them at the most system level of android's java API. It's thus the only testing framework that provides pure deterministic testing over their lifecycle. Doesn't really matter in practice, but it makes tests so much more readable. On a slight down note, I find it to lack on the documentation side but since it's so well made and well though I love it :)

From a practical one

Pure java code execution, no android required !! I love how fast it is ! It's the most productive way I found to develop on android with the java's debugger.

In the case of notification testing

Robolectric mocks the whole android API. Thus I would bet my ass notifications never happen. This is the good thing about robolectric, you fully manage everything's lifecycle. On the other hand, system calls get trapped in the void.

Therefore, I feel like it doesn't allow to test interactions with notifications the way UiAutomator would.

To get sure you don't have false positive or missing pieces in your testing, you have to have a good grasp about how notifications work from beneath (just found this interesting link by the way https://gist.github.com/mooingcat/8ef7ea9957197b3cb5b3d444a4f19efd). I actually don't have much experience with notifications, so UiAutomator just seems easier to me (don't want to manually test my automated tests), but I find both solutions to be very solid.

[ollyde]

Hey guys is it possible to use this package yet, even in alpha? I don't see any documentation here: https://invertase.io/oss/react-native-firebase/v6/notifications

:-)

[lironsher]

if we take version 5, extract only notification module, create a new repo for it, will it play well with version 6?

[mikehardy]

@lironsher I explored this with @Salakar and @Ehesp - with the idea that with some v5 maintenance under my belt I might be able to do it at least as a bridge even if it was immediately deprecated. Here was their take:

Generally though, it's a lot of work. Mike [edited to explain: that's Mike Diarmid, not 
me Mike Hardy] started to do just what you explained but it soon turned into a mine 
field. Messaging may need to be kept in in some form, core still needs to be there etc.

In my experience these two are really good at programming in general, know the underlying APIs really well, and this was their own code they were working with, and they were telling me it was a very large effort.

So my take on that was "no", and I decided personally to hang up the idea and wait for a standalone from them

[mikehardy]

I should add they were supportive though - if you can make it work by all means do so, they just estimated it as a large task, so for me it was a no as a personal decision

[yash-atreya]

Is there any other way to install notifications in my app while using RNF V6 ??

[mikehardy]

@yash1511 https://github.com/invertase/react-native-firebase/issues/2566#issuecomment-541064938

[AfrazHussain]

@yash1511 You can also try https://github.com/zo0r/react-native-push-notification.

[AndrewEmad]

please Help .. How to integrate react-native 0.61 with firebase v5

[mikehardy]

@AndrewEmad that is very off-topic, but it is documented thoroughly on rnfirebase.io and demonstrated in a way you can check out and reproduce + see exactly what changes to make vs the react-native template here **https://github.com/mikehardy/rnfbdemo/blob/master/make-demo.sh

[HessiPard]

please Help .. How to integrate react-native 0.61 with firebase v5

Hi @mikehardy , First of all thanks for this great package and your hardwork. I think @AndrewEmad questions is not really off-topic... Would you tell me how can i use in-app-messaging module along firebase v5? is it possible? because in this guide there is no documentation about that and I need both in-app-messaging and notification packages together. thanks.

[mikehardy]

This thread is for status on v6 notifications. I will not respond.

[HessiPard]

I had firebase v5, then i needed in app messaging module, so installed firebase v6, then i realized it doesnt support notification module yet, then i headed to this thread ... i think answer of my question would be relevant and helpful for others who will face this problem.

[HessiPard]

@younes200 - you don't have to use v6. You can use v5 with RN .60 and .61 The difference is v5 is one huge package, v6 is splitted in several smaller packages. With v6 users will be able to only pull in the packages and parts of firebase they actually use. E.g. if you only use crashlytics and no notifications you can use v6. With v5 if you were using just crashlytics you would still pull in all other firebase packages, which would drive your bundle size up.

I want to underline again - v5 works with the latest version of RN.

I personally would love to use v6 because of the improvements to the stack trace in crashlytics, but can't because notifications are not ready.... So, we stay on version 5 and wait for notifications to catch up.

@compojoom Would you tell me how can we use in-app-messaging module along firebase v5? there is no doc about that and Most of the people want to use firebase v6 because of in-app-messaging module.

[VivienTournie]

Hello @Ehesp, @Salakar, I have a question, can we expect being allowed to create local notification with custom sound via URI ? (Using Spotify/SoundCloud API for example). This is for me a huge missing feature of other notification libraries.

[matt-oakes]

@VivienTournie This is missing because it's not possible given the platform APIs. For a React Native library to provide the functionality, it has to be supported by the native SDKs.

[VivienTournie]

I do get your point. But isn't it possible using things like AlarmManager for Android to do it, and his equivalent for iOS ? Why couldn't it be added to the new notification library ?

[zek]

Giving an ETA would be super cool. I believe most of the people including me who needs notification package ready to pay for it. We could even pay for early-access.

I am not sure about the how much it should be, I know that 50$ is not much in your country but in countries like mine, 50$ makes 300 TRY (minimum wage is 2000 TRY btw).

I guess different pricing for each country is not possible. So that would be cool if you guys can find a price that will not hurt us and gratify your great work.

We all appreciate for your amazing work 👍

[CochiorasBogdan]

Hey all,

Firstly we really appreciate the passion going on in here, it's awesome to see such hunger for something we're developing. Let me just give an update on where we are at, and what our current thinking is:

• As mentioned above, Local Notifications isn't a Firebase product, it's functionality built into Android/iOS.
• Notifications is one of the most used "modules" of this library (according to documentation traffic), also its API surface area is almost the same size as all the others modules combined.

• Most of the open issues on this repo are notifications. Please remember part of OSS is also managing issues (which is incredibly time consuming). Why are there so many notification issues?

  • The documentation is poor - lacks examples, lacks detailed descriptions of APIs.
  • Notifications are untested (see below).
  • They're complicated.
  • The API surface area is huge.
  • Each device & API version has differing functionality.
  • There are two platforms to support, both with totally different APIs / functionality.

This library is one of the largest externally maintained libraries for React Native, from a downloads/stats and size point of view, and we've kept it actively maintained for almost 5 years - when others would have been abandoned by now. Documentation alone is a huge effort to keep up to date - the v6 documentation site has hundreds of pages of docs. Not only do we have to work on Notifications, we also have to support all of the other Firebase services - as you can imagine that's no small feat.

We are a small company maintaining this and we're not (and don't want to be) VC funded, and; like all companies we also have financial costs that need satisfying - so we can't be working on this full time all the time (even though we pretty much have for the last year) - its not sustainable as a business.

With these points in mind, we have decided moving forwards we're going to move the Notifications library of React Native Firebase into its own library. Why are we doing this?

• Other Notifications libraries for React Native are either unsupported, or missing features. We want to allow other developers not using React Native Firebase to also use a well supported library.
• React Native Firebase is setup to play well with Firebase. We've built a testing integration suite with over 1000 tests so far. Notifications does not fit in well. Testing Notifications has historically been a manual job (hence why it's currently untested). For the new Notifications package we've had to build custom tooling to enable testings. This allows us to actually ensure the code we ship if quality and working well. Currently on v5 notifications, we have no idea if a change actually works work.
• Documentation is the most important aspect of any library. The scope of Notifications is so broad, in order for it to be usable, the docs need to be in-depth and explicit. This is a time consuming job.
• With every Android and iOS update, there is usually new notification features. We want to ensure we're in a position to keep up-to-date with new features on new and old devices. By breaking the package out we can release package updates without impacting React Native Firebase.

The other topic we've been discussing, as a business, is the sustainability of OSS. We love OSS and we invest a huge chunk of our time into OSS, but free software doesn't pay the bills. We're a small company and need to ensure we stay afloat - we've also started working on private/internal projects to ensure this happens but this cuts into the time we can spend on OSS.

To ensure that a new Notifications library is well supported going forwards, we have recently come to the decision to make the new Notifications package a paid/licensed package for a very small fee, however; it will be free to use in development, free to use for React Native Firebase core contributors, free to use for non-profits, free to use for early testers/alpha testers and free to use for fully OSS apps (e.g. https://github.com/devhubapp/devhub).

This decision wasn't taken lightly and we've had many long discussions about it, but the goal here wasn't to make a quick buck but instead provide the financial means to keep the project well maintained and supported for the foreseeable future. If your thoughts on this decision are negative, we hope you understand however that there are free alternatives as listed above & v5 notifications is still available to use.

This new library is not aimed at being port of v5 notifications; everything has been re-written from the ground up to be well tested, cover most of the available APIs and be extremely well documented with step by steps guides & illustrations on all the notification features/APIs. As of right now, we're making good progress. Android is 75% complete (our primary focus) and the documentation is coming along well too. We're not in a position to give a date anymore, because honestly we have no idea given the scale of the project now. Guesstimates would be mid-November for an alpha release.

If you're interested in Alpha testing, please fill out this form and we'll be in touch once we're ready for testers: https://forms.gle/6huxd2ffgT4TBeXo9

Are there any pricings established?

[johanschram]

Hey !

First of all, thank you for the amazing work you did over the years ! I was patiently waiting for notifications support to upgrade to V6, but from what I see, that's not going to happen (the notifications in V6). Anyway, I totally get it and definitely fine paying for it. Any plan to release a beta version we could try soon, or not so soon ?

[nuKs]

I've built some helper class to set the time for notifications using UIAutomator, only works with english android and only tested w/ android v28.

(not sure if it's any helpful and where I can share this).

Maybe there a way to fit that in barista framework. Barista seems interesting for this use case because it's a helper framework built on top of both espresso and UiAutomator.

Checkout source code here: https://github.com/AdevintaSpain/Barista/issues/324

[Ehesp]

@zek Giving an ETA would be super cool. I believe most of the people including me who needs notification package ready to pay for it. We could even pay for early-access.

We are aiming for an alpha type release of probably Android first mid-November. The link I posted in my large reply above is the one we'll use for contacting folks about "early access".

I am not sure about the how much it should be, I know that 50$ is not much in your country but in countries like mine, 50$ makes 300 TRY (minimum wage is 2000 TRY btw).

We're trying to price it fairly, our aim is to keep it low enough for as many people as possible including solo developers and other locations (we're from the UK, so it's hard for us to gauge a reasonable price for other countries with varying levels of income).

Our current plan is to support a subscription based model and a flat fee model, so it'd be up to you how you want to purchase. Both include forever updates and of course we'll be managing issues as usual. It would also only apply for production/release apps so it can be tested/developed with for as long as required.

We're thinking $10-15 per month/app (Android + iOS) - would be good to get feedback on this from the community from various locations.

@lironsher if we take version 5, extract only notification module, create a new repo for it, will it play well with version 6?

We actually started to do this a while back before the v6 release, however as @mikehardy mentioned, it became a painful task. It's very much baked into RNFB right how (when it has no reason to be), so moving it out also requires extracting parts of core & messaging.

[SudoPlz]

I hate subscriptions, please use the flat fee thing.

[Salakar]

I hate subscriptions, please use the flat fee thing.

I agree subs are not for everyone; what we're saying above is that both a subscription model and a flat pricing model would be supported so it'd be up to you which one you choose.

Our reasoning for additionally supporting a subscription model was that we thought a smaller outgoing cost that you could cancel at anytime would be better for some compared to a higher one-off non-recoverable cost upfront for an app that may or may not be successful for example - if this logic even makes sense 😅

Thoughts? Very much asking for suggestions here and feedback.

[mi5ha]

Keep in mind that local notifications are just small, important but small part of the whole app. So costs should not be near as big as monthly subscription for Firebase for example or similar.

[mi5ha]

Btw, just local notifications will be commercial? Firebase server notifications are part of the v6?

[Salakar]

Keep in mind that local notifications are just small, important but small part of the whole app. So costs should not be near as big as monthly subscription for Firebase for example or similar.

Agree it's a small but vital part of an app. Its just the API surface area that is not small though, Android alone has 100s of variations/features that change across multiple API levels.

Btw, just local notifications will be commercial? Firebase server notifications are part of the v6?

Correct, just local notifs. messaging()/FCM in RNFB will remain where it is but will also additionally play nicely with the new local notifications package.

[CochiorasBogdan]

@zek Giving an ETA would be super cool. I believe most of the people including me who needs notification package ready to pay for it. We could even pay for early-access.

We are aiming for an alpha type release of probably Android first mid-November. The link I posted in my large reply above is the one we'll use for contacting folks about "early access".

I am not sure about the how much it should be, I know that 50$ is not much in your country but in countries like mine, 50$ makes 300 TRY (minimum wage is 2000 TRY btw).

We're trying to price it fairly, our aim is to keep it low enough for as many people as possible including solo developers and other locations (we're from the UK, so it's hard for us to gauge a reasonable price for other countries with varying levels of income).

Our current plan is to support a subscription based model and a flat fee model, so it'd be up to you how you want to purchase. Both include forever updates and of course we'll be managing issues as usual. It would also only apply for production/release apps so it can be tested/developed with for as long as required.

We're thinking $10-15 per month/app (Android + iOS) - would be good to get feedback on this from the community from various locations.

@lironsher if we take version 5, extract only notification module, create a new repo for it, will it play well with version 6?

We actually started to do this a while back before the v6 release, however as @mikehardy mentioned, it became a painful task. It's very much baked into RNFB right how (when it has no reason to be), so moving it out also requires extracting parts of core & messaging.

What about for Web push notifications, would that be a separate subscription?

[Salakar]

What about for Web push notifications, would that be a separate subscription?

This is local notifications on Android & iOS using the platform native APIs, nothing to do with Firebase or FCM or web. The messaging/FCM module in RNFB will remain where it is here in the library - free & OSS - as mentioned above; no Firebase packages in RNFB will ever be moved out/paid and will always remain open source.

[dorklord23]

@yash1511 You can also try https://github.com/zo0r/react-native-push-notification.

Has it been tested?

[blastering66]

Hi all.... i saw Elliot's Tweet. Great Teaser 'bout v6 !!! Good Job... Cant wait to use the 'Group' parameter !!!

But any updates about issue of Chinnese Rom that SwipeUpClean Our apps, that caused FCM Service is killed. So my app cant get the notification. My user is mostly Oppo, Vivo, Xiaomi, and other chinnese Rom. And notification is crusial to deliver the status of our user payment.

:(

[mikehardy]

@blastering66 that's not really on-topic, but https://dontkillmyapp.com

[xxRockOnxx]

@dorklord23

@yash1511 You can also try https://github.com/zo0r/react-native-push-notification.

Has it been tested?

I think given it has 4.3k stars as of this moment, a lot of people have been using it and so has tested it.

I'm on v6 too and use it and ditched rn-firebase's messaging also because you can get the senderID by using firebase.app().options.messagingSenderId instead.

[pie6k]

I'd prefer to pay like 100$ or more and have access to it forever than pay subscriptions. I have way too many of them already. I could also pay for major upgrades, but no monthly payments pleeease.

[jsina]

Hi @HessiPard just like you I've got surprised after updating to v6. btw now I'm using react-native-fcm although is does not supported yet but It's works fine with rn 0.60>

[firofame]

@jsina I think OneSignal is a much better alternative than react-native-fcm since it is actively maintained & they have a free plan.

[sv1226]

I have migrate the firebase from v4 to v6 but now website is showing no notifications module available right now. Now how will i continue with the v6 and RN 0.60.

[cxrod]

@sv1226 last version of v5 is compatible with RN 0.60

[mikehardy]

Yep - I'm still making sure v5.5.x tracks recent SDK releases. I'm on latest of everything (Pods 6.11, Android BoM 24, react-native 0.61.2) and it works - but you will want to depend on the v5.x.x branch like this as there are a couple unreleased changes that are important but we can't release because CI on v5.x.x is not cooperating - #2473.

If you want extra dependability you can depend on the commit hash exactly (and move it forward over time) so you know for sure your builds are reproducible and no change will flow through without explicitly moving the hash.

The v5.x.x code is fine it's just not officially released and with v6 notifications coming soon I/we haven't found the motivation to fix it - it's working fine but doesn't seem to justify investment beyond critical fixes

If something does break be assured I/we will continue making sure it works though, including things like forward-porting so we can continue to deploy updates to the app store / play store

Cheers

[hopewise]

@sv1226

do you mean 5.5.6 ? I tried to install it, but I got error:

 No matching version found for @react-native-firebase/app@~5.5.6.

[Ehesp]

@hopewise please see https://rnfirebase.io/ for v5.

[hopewise]

@mikehardy as for v5.x.x can you please tell me how to link it in Android and xCode? as I am using react native 0.61.2

I get firebase app has not been initialized! when I try to register listener at firebase.notifications().onNotification

[euharrison]

https://rnfirebase.io/docs/v5.x.x/getting-started

[dan-fein]

Is it possible to get an ETA that we won't hold anybody to? Like is this 6 months out?

[AfrazHussain]

@danielfein Please refer to https://github.com/invertase/react-native-firebase/issues/2566#issuecomment-545148427

[meftunca]

please post alpha version for notifications

[Ehesp]

Our plan is to roll out an Android version first - the documentation will still be a work in progress but the core will be available.

Make sure you've filled out the form above, as thats where we'll be looking when getting people to test an alpha version.

[mikehardy]

For me, the form was collapsed in hidden comments, here's the link again: https://forms.gle/6huxd2ffgT4TBeXo9