The future of push-plugin

For some time now we have an internal discussion about the future of the push-plugin. Why we came to this?

The push-plugin uses some deprecated iOS APIs
Documentation is OK, but not great
Testing the demo (sending/receiving push notifications) depends on two different tools (Pusher app for iOS and Firebase for Android)
Some of the problems above generate support, slowing us down

Also, we considered that there is another heavily used push notifications plugin out there - nativescript-plugin-firebase. Documentation is superior, testing the push functionality relies on single tool/UI - Firebase. We could “join forces” to deliver a single plugin with better quality, and transfer what’s missing from push-plugin to nativescript-plugin-firebase. So, the following options are available:

[:+1:] Deprecate push plugin and migrate users to nativescript-plugin-firebase (all current features will be still available)
[:confused:] Wrap nativescript-plugin-firebase in push plugin (expose only push functionality, all current features will be still available)
[:thumbsdown:] The push-plugin lives on (nothing changes)

So what do you guys think? Let us know about any concerns you have with either outcome.

For me personally I'm using the push plugin together with my azure mobile apps which I use to send pushes. So options in order of preferences are 👎 😕 .
I do not want to be forced to install the full blown firebase plugin/aar/pods just to be able to obtain a push token...

@PeterStaev

@PeterStaev I'm pretty neutral in this discussion, but just to keep the discussion fair: AFAIK (at least for the Android side) this plugin requires the exact same amount of native libs as the Firebase plugin. This line drags in the core Firebase .aar as well.

And regaring the JS code that gets dragged in: if we go the 👍or 😕 route the Firebase plugin's Messaging features will be refactored so only Messaging features can be imported into your code, to keep the overhead as small as possible.

@EddyVerbruggen

Thanks for the explanation @EddyVerbruggen ! For android yes, I know FCM is already included. I more meant any additional AARs and pods/frameworks that are not required for push but are included in your firebase plugin (sorry haven't used the the plugin so not sure if there are any additional binaries added, it could be just the FCM AAR).
As long as there won't be much additional overhead in JS/binaries/permissions/etc. that are currently included in the firebase plugin but not required for the push plugin I'm full up to support 👍 !

Sorry, forgot to mention: during installation of the Firebase plugin you'll be prompted which features you'll be using.

Based on those answers only the relevant native SDK portions are selected.

@EddyVerbruggen

Hi guys, the recently released (great collaboration, @EddyVerbruggen 🤘) nativescript-plugin-firebase v6.7.0 adds:

interactive push notifications support for iOS (both button and input^* type)
areNotificationsEnabled() API for getting if user has enabled notifications. Supported in both iOS and Android^*.
documentation and examples of the above features

^{* not present in push-plugin}

With this, the Firebase plugin now beats push-plugin in everything. Feel free to test, and if you miss something in Firebase plugin, that is present here let us know. 😉

FYI, just added a guide on migrating an app using push-plugin to nativescript-plugin-firebase #245

Hi guys, the push-plugin is now deprecated. Feel free to use https://www.npmjs.com/package/nativescript-plugin-firebase from now on.

I just tried this in a demo project and I don't like how it works for iOS. I've answered only Yes for the messaging only. Yet, when I build the project I get tons of pods installed that are from Google/Firebase:

Installing Firebase (5.6.0)
Installing FirebaseAnalytics (5.1.1)
Installing FirebaseAuth (5.0.3)
Installing FirebaseAuthInterop (1.0.0)
Installing FirebaseCore (5.1.1)
Installing FirebaseInstanceID (3.2.1)
Installing FirebaseMessaging (3.1.0)
Installing GTMSessionFetcher (1.2.0)
Installing GoogleAppMeasurement (5.1.1)
Installing GoogleUtilities (5.2.3)
Installing Protobuf (3.6.1)
Installing nanopb (0.3.8)

I thought if I wanted to ONLY to use the functionality that is currently exposed by the push plugin, there will not be any additional pods added to the project? Like I'm using Azure as my push provider so all those pods are an over bloat to the final app. If this is how it is supposed to be working then definitely 👎 for me and I will be continue using the current push plugin in all my apps.

@PeterStaev

@PeterStaev I don't like all those deps either, but (just fyi) there's nothing the plugin can do to prevent that (in addition to making sure you don't get the pods you anwered 'no' to) as Messaging depends on those libs according to their podspec: https://github.com/CocoaPods/Specs/blob/master/Specs/2/d/6/FirebaseMessaging/3.1.2/FirebaseMessaging.podspec.json

But I'm not using Firebase as my push provider. In this case should I answer yes or no to the prompt that asks for FirebaseMessaging? If there is no way to avoid those deps if I'm using another push provider and ONLY want the functionality that the current push plugin provides (like obtaining push token, enable push, etc.), then this is a big no-go in my opinion and this plugin should not be depreciated.

@PeterStaev

@PeterStaev FirebaseMessaging is for the client, so indeed you'll need to answer yes even if you use a different push provider.

@EddyVerbruggen

@EddyVerbruggen 😢

@tbozhikov , in this case it is best you and the core team reconsider marking the plugin as obsolete. I think this will be a loss of functionality, or you need to sacrifice app size/having unused libs if you want to use the things the current push plugin provides.

@PeterStaev

@PeterStaev Upon closer look I think those 'auth' libs should not be installed in your case.

There has never been a question in the Firebase plugin to prompt the user whether or not he requires the authentication library because using Firebase without it doesn't make sense - unless (as I realize now) you only require Messaging.

I will address it later today in EddyVerbruggen/nativescript-plugin-firebase#904. That will remove at least these pods: FirebaseAuth, FirebaseAuthInterop, GTMSessionFetcher, and part of GoogleUtilities.

Not saying that's perfect, but it's all I can do.

@PeterStaev

Hi @PeterStaev, thank you for bringing the dependencies issue in the discussion. In this relation, I made a comparison between push-plugin's and firebase plugin's demo projects built for iOS device using:

tns build ios --forDevice --release

... and the resulting .ipa file sizes are:
push-plugin demo : 14.1 MB
firebase demo (using v6.8.0): 17.4 MB
firebase demo (using v6.8.1): 16.9 MB

NOTE: this is not the same project but the demo projects in each of the plugins. I assume that there are not significant size differences between each other and the result using the same project will be very similar.

So based on this comparison using the latest nativescript-plugin-firebase bits with optimised dependencies (thanks @EddyVerbruggen) the difference is <3MB in final download size of the app. Of course, we should strive for smaller packages, but the switch to nativescript-plugin-firebase means using of latest APIs (and not deprecated ones as push-plugin uses), more features, better documentation and this is worth paying the price of 3MB larger package.

Last but not least, deprecation of the push-plugin does not mean it is deleted. It is still out there, available to anyone who needs it, so feel free to continue to use it, fork & improve it, etc. Just keep in mind that in any moment the deprecated iOS APIs can stop working and so will the plugin.

@tbozhikov

@tbozhikov , size is just one of the concerns. Other include going through Pod file hell if you have other plugins that use Pod files and they use different swift versions. So for an end user that wants to use push w/o using Firebase can easily become a very complex thing to do, for a simple thing as push notifications.

And don't worry I will defo be forking the push plugin and if the iOS API becomes unavailable will see to get it updated and publish it as a separate plugin 😀

@PeterStaev

@PeterStaev I have some good news to share, and I must thank you for bringing this up. 🤝

As mentioned in EddyVerbruggen/nativescript-plugin-firebase#904 I wanted to investigate the possibility to not only remove the authentication Pod from the plugin, but also remove the Messaging framework (in case you're using a different push provider), and even remove the FirebaseCore Pod (which drags in 6 other Pods).

After hacking around in the plugin today I'm happy to report the next release of nativescript-plugin-firebase will support a Podless mode that will work with any push service (like the push plugin)!

I will also investigate which Android dependencies can be dropped, but it's less of a problem on the Android side anyway, as the Push plugin also requires Firebase.

There will be specific docs and a demo app for this scenario.

In case you're still open to switching to the Firebase plugin (and rather contribute new features/fixes there 😇, then feel free to follow this issue: EddyVerbruggen/nativescript-plugin-firebase#909

Wow, this is really good news Eddy! Thanks for this! Like I said at the start, have no problems switching plugins, as long as it provides the same functionality w/o adding unneeded deps. So I will definitely be using firebase plugin 7.0.0 in any future/updated apps that needs push 😉

Hallo,
Thanks for your efforts. In fact I am beginner and was going to use "nativescript-push-notifications" but since this is deprecated I will try "nativescript-plugin-firebase" instead. In fact I need Push notification to send some content (can be image or PDF or Text) via FCM to some displays ( android screens/monitors) remotely located from a web application. So from Webapplication Angular based to Android Monitors using NativeScript app. Is this possible through the new plugin to send rich content as notification message? or simply send the link to to the content as text?

Navigation Menu

Repository navigation

The future of push-plugin #230

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The future of push-plugin #230

Description

Activity

PeterStaev commented on Jun 29, 2018

EddyVerbruggen commented on Jun 29, 2018

PeterStaev commented on Jun 29, 2018

EddyVerbruggen commented on Jun 29, 2018

tbozhikov commented on Sep 3, 2018

tbozhikov commented on Sep 4, 2018

tbozhikov commented on Sep 13, 2018

PeterStaev commented on Sep 13, 2018

EddyVerbruggen commented on Sep 13, 2018

PeterStaev commented on Sep 13, 2018

EddyVerbruggen commented on Sep 13, 2018

PeterStaev commented on Sep 13, 2018

EddyVerbruggen commented on Sep 13, 2018

tbozhikov commented on Sep 14, 2018

PeterStaev commented on Sep 14, 2018

EddyVerbruggen commented on Sep 14, 2018

PeterStaev commented on Sep 14, 2018

jothmani commented on Oct 11, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions