We have a few cross-platform apps in development, for android setting up a CircleCI workflow to deploy to Firebase app distribution has been fairly straight forward, but for iOS I can't seem to find a good way to obtain the UUID for iOS testers that AppDistribution retrieves for us.
Is there any way to get a list of registered device UUID's?, I would rather not have to rely on parsing the email notifications.
Related
I have a fairly complex solution built upon Firebase including Firebase Auth, Firestore, Storage, Functions, FCM, and a few Google APIs. (This is a mobile application). A lot of my logic is in Functions, specifically notifications using FCM. I noticed a lot of errors in my logs when running locally. I don't think it's hurting anything, but I was wondering if there was a way in Functions if I could determine that I was using the local emulator suite and not run certain logic. Or better yet, if I could still use outside logic within the functions running locally. The biggest one being FCM. I also use some of the Google APIs, but I get an error because the Firebase Emulator Suite uses a different projectId.
We are developing large number of customized Android and iOS applications for our customers. We have used Fabric to manage the crashes and Google Cloud Messaging to send push messages for the applications. We have now migrated all those applications to Google Firebase.
We are using Firebase Management REST API to create the applications into Firebase enabled projects from our PHP backend. For Android apps we use methods projects.androidApps.create and projects.androidApps.getConfig to get access to the application google-services.json. We include that to the build, which passes without errors and the push messages work without a problem. However, the Crashlytics side does not get enabled. In Firebase console there is only a wizard to set up a new Firebase app. When running it, it gives impression that Craslytics will get enabled, when the app starts using Firebase, but it is not.
Is there an API to enable the Crashlytics for an app? We can use REST or PHP based API in the backend. Also, if there is a client side API to awaken Crashlytics, we can use that too.
This is currently not possible, though with the new Crashlytics SDKs we are looking at ways of changing this behavior. In the future, as soon as we receive a crash event we will enable the Crashlytics dashboard. The timeline for this though, is unknown.
I currently have two applications: A and B. In both there is a common functionality, a message box. When a message is sent to your mailbox, you receive a notification. If the message is sent from application A, it is sent a notification to application A of the destination. Otherwise, it is sent to application B.
The question is: it's better to have a firebase project for each of the applications or there is some way to have both applications in the same project and know which application each user has installed to send the corresponding notification.
All apps in a Firebase project share all resources of that project. So they all share the same Firebase Authentication users, the same (Firestore or Realtime) Databases, and the same Cloud Messaging keys and audiences.
Firebase projects are meant to host a single logical application. If you have an administrative app and an end-user app, a free and a premium version, and then have iOS, Android, and Web versions of all, you have up to 12 variants of the app inside a project, but they're really all just part of the same application.
There are also limits as to how many apps you can add to a Firebase project. The exact limits have varied a bit over time, but if you have more than 30 apps in a project Firebase may prevent you from adding more.
So: if you app A and B are variants of the same application, it's totally fine (and probably a good idea) to add them to the same project. If you have another use-case, keep the guidance above in mind.
Good afternoon,
I apologize in advance, as I know this is subjective. But, I'd very much love the opinion of a Xamarin expert.
I'm building a mobile application for a client using Xamarin targeting Android and iOS devices. We have a .NET Web API back-end application that is consumed by a MVC web application (hosted in Azure), and now our Xamarin application. Our API needs to send basic push notifications (to iOS and Android) when certain things happen.
I've configured push notifications (also targeting Xamarin projects) in the past, but it has been a few years. That configuration included Azure Notification Hubs and GCM (the GCM piece was recently updated to Firebase - still in combination with Azure Notification Hubs). All of that is working just fine.
After reviewing push notifications again, it seems as though Firebase has become something of a Notification Hub itself, handling both iOS and Android applications. There is plenty of documentation on setting up push notifications in a variety of ways, using just Firebase for both iOS and Android, using Firebase with Azure, using just Azure for iOS, etc.
So, my question is.. If you are a seasoned Xamarin developer creating a new iOS and Android targeted application with a .NET backend, would you use Azure Notification Hubs? Based on my reading, it seems as though the simplest approach would be to utilize Firebase for both iOS and Android, leave out the Azure Notification Hub piece of it, and use our back-end to make a single POST request to the Google API (i.e. https://fcm.googleapis.com/v1/projects/myproject-b5ae1/messages:send based on their documentation at https://firebase.google.com/docs/cloud-messaging/send-message) to send a new push notification.
However, that doesn't sit very well with me considering that Microsoft is behind both Xamarin and Azure. My gut is telling me that I should be using Azure Notification Hubs. Could someone please provide some guidance? I feel like I'm not understanding something that's preventing me from being able to come to a good conclusion on my own.
Thanks,
Chandler
This seems to be a problem with the software architecture. Technically, notifications can be done for both Azure and IOS/Android notifications. But from user data statistics and future data service analysis, you need to consider whether the notification service you used before can continue to provide services for you. At the same time, if you are ready to abandon the previous use, you can slowly split some users to use the new notification service. From my personal point of view, this is the safest.
I have created a mobile app for Android and iOS using Phonegap Build. Last year I had nearly finished writing code to use GCM (Google Cloud Messaging) for remote push notifications - which can go out via Apple's APNS too - but the project was shelved.
This year the project is resurrected and I find Google has changed everything to Firebase (FCM). I then read some enticing things about Amazon SNS handling notifications. Just when I started to think SNS might be a better option, I noticed you still have to set up GCM/FCM anyway, and pass all those details to SNS.
So is there any benefit to using SNS when I've got to do the full FCM setup as well?! Both services seem to offer the same features: interact with APNS if required, subscribe to topics, provide you with a nice API/SDK, etc. The app code, and the server-side code would be no simpler, as far as I can see. Why add another layer (SNS) on top of FCM?
(I'm trying not to let this be an opinion-based question: I want to know whether SNS is saving me any effort, giving me any advantage, or adding any features that FCM does not have.)
Just some thoughts.
If you are already using some mobile AWS SDK, then it's more convenient to use it for SNS too.
That also helps keep your app smaller.
And you're happier as a developer since API calls are somewhat unified.
If your backend is hosted on AWS infrastructure you can use IAM roles for EC2 instances (also Lambdas etc.) to make those call without access key/secret key.
You get metrics in your CloudWatch.
But Firebase Cloud Messaging is free :)
Let's answer a few questions first.
1.Do you want to develop, maintain and run the code to talk to GCM?
2.Do you wish to do the same for another platform (iOS, Kindle Fire), if you choose to develop your app for other mobile platforms.
3.Do you want to manage change of registration_id's by yourself?
4.Do you care if a notification is delivered to your users a few milliseconds later?
If you answered NO to any of the questions above, I recommend using SNS to deliver push notifications to iOS, Android and Kindle Fire devices.
SNS talks to GCM to deliver notifications to android devices. Here is what SNS can offer you.
Simple API to send notification to heterogeneous platforms.
Manages application registration_ids. As a developer you don't have to worry about change of registration_ids.
Scales really well. You don't have to worry about managing infrastructure if your app becomes super popular.
Can tolerate GCM downtime & throttling.