Does flex mobile supports In-App purchases, push notification etc that can run on all supported mobile platforms (iOS, Android, Blackberry playbook).
Thanks
Currently "all" native mobile features are "supported" via AIR native extensions.
You can read about AIR native extensions here
It is quite a new feature, but the point is, you can create bridge between native code SDK and your AIR application. It means, your application will be able to make calls to native SDK, and also receive events from native SDK.
Basically, if you want to present native feature in your Flex/AIR application, you create native code to achieve what you want (does require only little coding in most cases), bridge it with ActionScript interface, and package it as .ane (air native extension). This extension behaves like actionscript library you can then reuse for all your Flex projects if interested.
Link mentioned above also presents some examples - native notification is amongst them...
Since its fairly new feature, there are only few examples presented, but its not hard to code your own native extension for native feature you want - i did it myself and it worked... (here is simple native extension tutorial)
So the result is - you can present any native feature in your Flex app, as long as you have native extension for it...
Does flex mobile supports In-App
purchases,
Not integrated with the native store "procedures". I hear you can "build your own" using PayPal w/o much trouble; but It is not something I've personally investigated.
push notification
Yeah, it should. As long you're connecting to a server that supports push notifications. BlazeDS and GraniteDS use long polling to accomplish this. WebORB and LiveCycle use RTMP.
It's hard to quantify what "etc" may mean.
A note on Apple push notifications to clear up an apparent misconception from www.Flextras.com: Apple does not allow apps to bypass APNS and implement their own push notification service. Please see point 5.1 below.
From https://developer.apple.com/appstore/resources/approval/guidelines.html#push-notifications:
5. Push notifications
5.1 Apps that provide Push Notifications without using the Apple Push
Notification (APN) API will be rejected
5.2 Apps that use the APN service without obtaining a Push Application ID from
Apple will be rejected
5.3 Apps that send Push Notifications without first obtaining user consent will
be rejected
5.4 Apps that send sensitive personal or confidential information using Push
Notifications will be rejected
5.5 Apps that use Push Notifications to send unsolicited messages, or for the
purpose of phishing or spamming will be rejected
5.6 Apps cannot use Push Notifications to send advertising, promotions, or direct
marketing of any kind
5.7 Apps cannot charge users for use of Push Notifications
5.8 Apps that excessively use the network capacity or bandwidth of the APN
service or unduly burden a device with Push Notifications will be rejected
5.9 Apps that transmit viruses, files, computer code, or programs that may harm
or disrupt the normal operation of the APN service will be rejected
I am currently using this open source iOS ANE to implement in-app purchases in Flex:
http://code.google.com/p/in-app-purchase-air-ios/wiki/APIDescription
There is a push notification ANE (both Android and iOS) as well that I'm currently investigating, although it may not support remote notifications:
http://www.adobe.com/devnet/air/native-extensions-for-air/extensions/notification.html
This iOS-only ANE for push notifications is open source:
http://flashsimulations.com/2011/12/16/apple-push-notification-service-native-extension-for-adobe-air/
Related
I host a PWA website and I am trying to integrate push notifications to my users who may have the website open in a browser tab even if their phones are inactive. You notoriously can't send Push notifications to iPhones without using Apple Push Notifications service (APNs).
Seeing as the point of firebase cloud messaging (FCM) is to outsource the message handlers, I kinda assumed it would support sending push notifications to iPhones somehow via APNs, but the information here suggests you still can't do this from the web.
https://firebase.google.com/docs/cloud-messaging/js/client
Safari and iPhones don't support Push API.
According to this answer: https://stackoverflow.com/a/64576541/2116253
Option #2 may be possible if you know the device ID token, which is apparently very hard to get and perhaps not possible anymore because Apple are trying to make it harder to obtain due to security concerns.
I think the actual sending via APNs from server side is quite easy, the problem comes with the initial setup/registration and actually granting permissions that allow notifications to arrive.
So, in short, I don't mind registering my website with Apple, agreeing to terms and obtaining keys for the purpose of interfacing with APNs, but I don't want to make and distribute a whole native iOS app just to send notifications to devices about my website.
Does anybody know the correct way to achieve this in 2022 ?
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'm planning to add push notifications to my web app.
As far as I understand it, to push notifications to my users, I can either use a web push library and deliver the notifications directly, or use a push notification service such as OneSignal, Firebase Cloud Messaging, or Batch.com.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
If I'm focusing only on Web Push for now, is there any advantage I should be aware of, to use one of these services over a web push library directly?
Web Push is a standard which is still under development and subject to change. Also browser support is quite limited at the moment (see https://caniuse.com/#feat=push-api).
The advantage is: you have one API to rule all the supporting platforms (including desktop).
Disadvantage is: You have to be aware that not all platforms support the standard.
Using a notification SaaS solution to handle notifications enables you to handle all platforms. Sending out a notification from your backend will be a single call to your notification SaaS service, but you still have to be aware, when you want to have native notifications on Android, iOS and the browser, you will have to handle the integration of those platforms differently in your client apps (see example here using Google Cloud Message integration in an Android App: https://firebase.google.com/docs/cloud-messaging/android/client).
So your decision should be based on which platforms you have to support.
- If you get away with supporting Chrome, Firefox and Edge browsers on non-iOS-Devices (or handle iOS Notifications differently), you can use Web Push.
- Otherwise i would choose a Notification SaaS Solution.
The most important point for me personally when doing your own implementation is that you control everything. This means that your notifications don't fail when AWS loses a region or pricing changes and you can't afford it any more. Not any provider can ban you because of the content you distribute or the complaints from users. You can implement your own logic for showing the notifications on the front-end, like stacking them or having your own segmentation rules (paying users versus free tier, for instance). I'm not even speaking of the custom subscription UI. No weird copyright in your messages.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
When you've got the server logic to process the app events and send notifications in place, it shouldn't be really hard to extent it do work with mobile push notifications. The only thing that changes is the way you subscribe devices.
And the last, but not the least - it's fun to develop. This is more of a personal matter, I guess, but I like learning new thing :)
Hope that helps you to make a decision.
you can implement push notification to your website without using third-party libraries. You have required to get subscription token from the client and store this subscription token onto the server (Inside database). After when you want to send a push notification to the user then you have to just call endpoint (endpoint is mentioned in subscription token). That's it.
Due to security risk and managing subscription tokens, developers prefer to use firebase, AWS push notification or onesignal.com services. These services are optional you don't need at all.
Read links introduction to push notification and also the same lab code examples. Later I will update with simple working code for further reference to your question.
It depends on what you want. It‘s not possible to use iOS Safari for Web-Push. For notifications to iOS you have to use a service or build your own app.
I use Pushover for notifying myself from Scripts and Software. That may or may not be a solution depending on how much users you have, how many notifications you send and how willing your users are to use a web app like Pushover (or an app on iOS).
A service will keep notifications going when things change. So it should be less maintenance for you.
If you want to target iOS visitors also, this is not possible, as web push notifications are not supported by iOS.
To circumvent this, you need to use a third party service like Wise Notifications.
The alternative is to build an iOS app and send native push notifications.
I am building mobile apps for iOS and Android using PhoneGap Build. I would like to send push notifications to both types of device using the same server-side process. Is this possible?
Apple's certification process to enable push notifications is painful, much more so than anything available for Android. Do I have to use it?
GCM (Google Cloud Messaging) says it supports both operating systems, but the more I read about it - with respect to Phonegap - the less I see iOS mentioned! And sadly the GCM/Phonegap plugin doesn't support subscribing to a topic, which is a way of sending one message out to all devices in one go via a 'global' topic.
UrbanAirship and PushWhoosh seem to integrate with Phonegap, but I am forced to use their website to create my messages. GCM looks more attractive in this respect, because I can get our own ASP.NET server to talk to GCM via HTTP and thus control messages from our databases.
Main question: Are there any options for a single server-side option which can send push notifications to both iOS and Android via a single Phonegap plugin? (Ideally I would control messages from my own server, where one message can go to all Android/iOS devices in one go, and avoid as many Apple certificates as possible.~)
I want to create a chat application for ios, android and windows phones as well as it should work with browsers in the future. My search led me to using Signal R with Azure Mobile Services(AMS).
My questions:
1) SignalR uses Websockets under the hood. Is websocket supported in Android, IOS, windows phones and all mobile/desktop browsers??
2) If not, how will it effect using SignalR with AMS?
3) Or should I just use Push notifications supported in AMS?
4) Any sample app/code snippet you can share. Note that I will be using Xamarin for my app development.
5) Any advice you can give for same.
Azure Mobile Services has SignalR integrated, and Azure Mobile Services provide a SDK for client apps, I suppose it is provide out-of-the box
See
Real-time with ASP.NET SignalR and Azure Mobile .NET Backend
Master the Managed Azure Mobile Services Backend–Part Four
High value mobile backend capabilities included
You will find many capabilities included in Mobile Services and readily available for your Web API. Mobile push notifications, real-time notifications with SignalR (auto-scaled out), social auth for your consumer apps, offline data sync for occasionally connected scenarios, to name a few.
Samples:
https://github.com/gshackles/RealTimeGallery
Sample to help developers to implement Push Notification, through Azure Notification Hubs, in mobile applications.
Note:
Azure Mobile Service is based in WebAPI!
For that you want, you should not use only Push Notification because Push Notification in iOS could not be read by the application if the user ignore it, only in android or windows you can get and save it. Another thing that can be a problem is the fact if the app is running you should not show the push notification and you should show a pop up with the notification... and the push notification can have a delay from the Push Notification Service (Apple, GCM, WNS...). Push notification are a notification that something happened in the app when the user is not using it.
In my opinion you should use AMS+SignalR for realtime communication and then Push Notification for update the user then he not using the app.
Using SignalR is efficient to save yourself from hitting any push notification cap if you ant to limit your costs. But you'll need to either turn notifications on/off at the right time when the app becomes active or inactive, otherwise the app may go in the background and push notifications won't be sent.
You can use a pure push approach where notifications are shown when the app is inactive/in the background, and whenthe app is active, you simply intercept the notification in the app, consume it and cancel it so it doesn't get shown. I have written a blog post on this approach along with 3 samples in Github for iOS, Android and Windows Universal at http://www.ageofmobility.com/2014/10/06/azurechatr-building-a-cross-platform-chat-app-for-windows-ios-android/.