I am trying to implement push notification for windows phone using IBM MobileFirst Platform Foundation 6.3.
I downloaded the push notification sample application from the ibm developer page here, and installed it on my device. I am trying to use unauthenticated MPNS.
I am able to send the notification to an Android app by calling the adapter but not to windows app. the MobileFirst Console shows the number of messages sent but none of them are received.
do i need to submit my app in the windows developer console to use unauthenticated push notification
Below is the log from the visual studio.
'TaskHost.exe' (CoreCLR: DefaultDomain): Loaded 'C:\windows\system32\mscorlib.ni.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'TaskHost.exe' (CoreCLR: Silverlight AppDomain): Loaded 'C:\windows\system32\System.Windows.RuntimeHost.ni.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'TaskHost.exe' (CoreCLR: Silverlight AppDomain): Loaded 'C:\windows\system32\System.Windows.ni.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'TaskHost.exe' (CoreCLR: Silverlight AppDomain): Loaded 'C:\windows\system32\System.Net.ni.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'TaskHost.exe' (CoreCLR: Silverlight AppDomain): Loaded 'C:\windows\system32\System.ni.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'TaskHost.exe' (CoreCLR: Silverlight AppDomain): Loaded 'C:\windows\system32\System.Xml.ni.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
MPNS notifications has 3 types -
1) raw
2) toast
3) tile
The application must be in foreground to handle raw notifications. Toast notifications are short, text-based messages that appear at the top of the phone's display. Tile notifications can modify the appearance of application tiles user has pinned to the Quick Launch area of their device.
The output JSON of WL.Server.createDefaultNotification() , contains a raw and tile payload and no toast payload. This is why you notice pushNotificationReceived() firing and see the push payload, when application is in foreground.
Since the default JSON does not contain a toast payload, you will NOT see a toast , when your application is in background. If you did have a tile pinned to your quick launch area, you should have seen the tile notification.
To get a toast notification modify the code slightly -
var notification = WL.Server.createDefaultNotification(notificationText, badgeDigit, {custom:"data"});
notification.MPNS.toast = {};
notification.MPNS.toast.text1 = "Toast title";
notification.MPNS.toast.text2 = "Toast content";
To see a tile notification , pin your application to the quick launch area , put the application to background and then try sending the notification.
API and output JSON details can be found here :
Related
Apple's documentation says this in the discussion section of the method description:
This method is called to let the
current process know that its counterpart session’s reachability
changed.
The description of the isReachable property says this: WatchKit
extension. The iOS device is within range, so communication can occur
and the WatchKit extension is running in the foreground, or is running
with a high priority in the background (for example, during a workout
session or when a complication is loading its initial timeline data).
I am assuming this would mean that if the watch moves out of or into range of the iOS device, the WatchKit extension would be launched and the WCSessionDelegate's sessionReachabilityDidChange() method would be called, and the WCSession's isReachable would be true if the iOS device just came into range and false if it just when out of range.
I have not found a way to verify this in xcode. For example I put a log message in sessionReachabilityDidChange(_:) and walked out of range, but xcode simply says the app lost connection with the iphone and can no longer debug it. Can someone verify this or point me to some documentation that better describes this?
I think you cannot verify this in Xcode.
I have an app on iOS and watchOS. To check this kind of situation, I can enable debug alerts on iOS and watchOS. When func sessionReachabilityDidChange(session: WCSession) is triggered, I display a debug alert.
Now, if I run (not under Xcode) my watch extension, and then switch off the paired iPhone, the debug alert is shown on the watch.
This shows that sessionReachabilityDidChange is actually called as expected.
Apparently, under Xcode a connected iOS device is always reachable.
EDIT:
To check the situation when the watch extension is not in foreground, I did the following:
Instead of showing a debug alert, I set now the complication to a unique value that is not possible otherwise. I launched the watch extension and put it into background by showing the watch face with the complication.
When I now switch off the iPhone, the complication is not updated.
This indicates to me that sessionReachabilityDidChange is not called in background.
iOS13 can't support the background update notification.Is this an OS-level bug?
And when app enter background,the Xcode warning shows:
Can't end BackgroundTask: no background task exists with identifier 1
(0x1), or it may have already been ended. Break in
UIApplicationEndBackgroundTaskError() to debug.
I have got the answer from the Developer Documentation:
https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns
apns-push-type
(Required when delivering notifications to devices
running iOS 13 and later, or watchOS 6 and later. Ignored on earlier
system versions.) The type of the notification. The value of this
header is alert or background. Specify alert when the delivery of your
notification displays an alert, plays a sound, or badges your app's
icon. Specify background for silent notifications that do not interact
with the user.
I currently trying out Amazon Device Farm and was able to get a dummy app to work.
However, when I tried getting the actual App I want to get working on Amazon device farm, I'm unable to do so. I'm able to upload the .ipa file, and zip up and upload the py.tests/appium tests with their dependencies, however the tests fail.
What I think might be happening is ADF is not recognizing some of the Desired_capabilities to autodismiss the Alerts for Notifications and GPS coordinates.
My setup is very similar to the setup I used with the dummy app in my initial tests. (these worked with amazon device farm)
https://github.com/dlai0001/appium-spike-running-tests-oncloud
Only thing that is really different is I'm using a real production app, where 2 alert windows popup upon launch. In Appium it will cause the test to crash if I don't have the autodismiss or autoaccept alerts enabled in the desired capabilities.
Harness 00:00.0 1295 Info Starting 00001 with device c00e8ab68437161b894395e438ba8935a672bac0
Harness 00:00.0 1295 Info Using test content version 0.1.0
Harness 00:00.1v1295 Info Using image version ami-778b7c17
I work for the Amazon Device Farm team.
It appears that you are relying on desired capabilities to dismiss the alert window. Currently, Device farm has support for a very limited set of desired capabilities namely app name, package name and osversion. These are available to the application without having the user required to set it.
Appium runs with autoAcceptAlerts=true on Device Farm. This should handle the alert windows, if any, unless it is a system pop up which autoAcceptAlert cannot handle. You should check if your tests can handle the alert windows using autoAcceptAlerts=true with Appium pre launch mode locally.
If it can handle it then device farm should behave the same way.
Sometimes it may be the case that the alert window appears before the appium session is established in which case adding a delay can help.
When you test is locally please use Appium version 1.4.16 since this is the version being used on device farm right now.
I am using Apigee BaaS and everytime I run the cordova app that consumes these apis I get this error message in an email
[org-name-app-name timeStamp Sat Dec 27 19:52:03 UTC 2014][ Tag : CRASH][ Device Platform : android][ Platform Version : android UNKNOWN][ Device Model : UNKNOWN][ Devicd ID :794DCBC2-4D1D-9EEC-A86560412878]Error:[object Event] for url:undefined on line:undefined
What exactly is this? Why do I get this?
Apigeee BaaS SDKs also include App Performance Monitoring (APM) functionalities. APM catches crashes in iOS and Android Apps. When it comes to JS, it captures all errors and will send email notification in group depending on how frequently errors/crashes are happening and some configuration parameters. If you don't want to get notification, then you can turn off entire APM or just crash notification. To disable monitoring completely, see http://apigee.com/docs/app-services/content/monitoring-app-usage-data . Just to suppress crash notification, see http://apigee.com/docs/app-services/content/monitoring-app-errors-and-crashes section "Disabling alert.."
I have an ASP.NET application where one of the pages hosts a 3rd party ActiveX control. A condition can sometimes occur with the ActiveX control that causes the following error message to be displayed in a Windows dialog box when Internet Explorer is closed:
Exception EIdWinsockStubError in module CADVIE~1.OCX at 0029A808.
Error on call to Winsock2 library function WSACancelBlockingCall:
Either the application has not called WSAStartup, or WSAStartup failed.
Without any intervention from the suppliers of the ActiveX control can I suppress this message.
EIdWinsockStubError is an exception thrown by the Indy library when it fails to dynamically load a WinSock function using LoadLibrary() and GetProcAddress(). In this case, something in the OCX is calling Indy's WSACancelBlockingCall() stub after Indy has already unloaded WinSock from memory. Indy itself does not use WSACancelBlockingCall() at all, so it has to be a bug in the OCX's own code.