I'm experimenting with "Reachability" in Xmarin, using the Reachability class (sample here), but I cannot get the "IsHostReachable" feature to work.
I do realize that the Reachability class utilizes the NetworkReachability class but no matter which class I use the TryGetFlags() method always passes back the NetworkReachabilityFlags argument with a zero (0) value.
I started out using the Reachability class' method but while debugging I saw that the problem seems to originate in NetworkReachability. I tried the following code just to make sure:
using (var r = new NetworkReachability(host))
{
NetworkReachabilityFlags flags;
if (r.TryGetFlags(out flags)) // <-- flags is always 0 (zero)
return (flags & NetworkReachabilityFlags.Reachable) == NetworkReachabilityFlags.Reachable;
return false;
}
Like I said the flags variable is passed back with a zero (0) value, regardless of the device's current connection status. The host I'm testing against is a intranet web app that is only available when I'm on my company's WIFI. I have tested debuging the iPhone while connected and double checked by simply trying to browse to the host in Safari, which works.
The API is poorly documented but I'm suspecting I might need to initialize the NetworkReachability class somehow.
Any ideas?
Related
If the broadcaster app (Android) and client app(IOS and Android) are connected to wifi in the same network, everything works fine. But when the broadcaster app is connected to mobile data connection, client app (IOS) shows black screen but the Android still works fine. I have searched some work around with this and they suggest to add STUN and TURN in my peerConnection , but i had already added before . Seems not working when the communication is stablished on different network connection. This is how i setup my RTCPeerConnection.
var rtcIceServers: [RTCIceServer] = []
rtcIceServers.append(RTCIceServer(urlStrings: [turnUrl], username:"*****",credential: "*********"))
rtcIceServers.append(RTCIceServer(urlStrings: [stunUrl]))
let rtcConf = RTCConfiguration()
rtcConf.iceServers = rtcIceServers
rtcConf.tcpCandidatePolicy = .disabled
rtcConf.bundlePolicy = RTCBundlePolicy.maxBundle
rtcConf.rtcpMuxPolicy = RTCRtcpMuxPolicy.require
rtcConf.continualGatheringPolicy = RTCContinualGatheringPolicy.gatherContinually
rtcConf.keyType = .ECDSA
let mediaConstraints = RTCMediaConstraints.init(mandatoryConstraints: mandatoryConstraints, optionalConstraints: nil)
let pc = self.peerConnectionFactory.peerConnection(with: rtcConf, constraints: mediaConstraints, delegate: self)
the client app requires only to receive video track , no audio added in the mandatory constraints. Thank you
After few days of debugging and comparing my setup to other sources, i resolved the issue by applying the right parameters to my RTCIceCandidate before i add to my peerConnection. I mistakenly applied candidate value to sdpMid parameter and id value to sdp parameter. Since everything works if both clients are in the same network connection, i never suspect my parameters, not until i understand quite a bit about why i need to use IceServers when clients are not in the same network. So RTCIceCandidate value is not quite important and also these ice servers when clients are in the same network thats why it was working even if RTCIceCandidate has wrong parameters applied. My bad...
RTCIceCandidate(sdp: id, sdpMLineIndex: label, sdpMid: candidate)// wrong
RTCIceCandidate(sdp: candidate, sdpMLineIndex: label, sdpMid: id)// correct
I need to get the device IP of the WiFi interface.
According to several StackOverflow threads, we could assume that "en0" corresponds to the Wi-Fi interface name :
https://stackoverflow.com/a/30754194/12866797
However, this feels like some kind of convention, not a standard.
Is there any consistent/standard way to retrieve the WiFi interface or the device WiFi IP address, using the iOS SDK ?
It would be nice if the API is available starting from iOS 11 but I won't be picky.
My best attempt was to use NWPathMonitor (iOS 12+) and monitor network changes corresponding to WiFi interfaces (NWInterface.InterfaceType.wifi) :
- (void) MonitorWifiInterface
{
m_pathMonitor = nw_path_monitor_create_with_type(nw_interface_type_wifi);
nw_path_monitor_set_update_handler(m_pathMonitor, ^(nw_path_t _Nonnull path) {
NSLog(#"[NetInterfaceUtilies] Network path changed");
nw_path_enumerate_interfaces(path, ^ bool (nw_interface_t _Nonnull itf)
{
NSLog(#"[NetInterfaceUtilies] Name : %s , Index : %u", nw_interface_get_name(itf), nw_interface_get_index(itf));
return true; // In order to continue the enumeration
});
});
nw_path_monitor_start(m_pathMonitor);
}
But I am not happy with it for the following reasons :
NWPathMonitor is supposed to be used for monitoring network changes : I haven't managed to get network information whenever I wanted, but only when WiFi has been set on/off.
I only managed to get the network interface name. But I can combine this data with the network interfaces retrieved with getifaddrs() in order to deduce the correct interface and IP : it's a step forward ?
It's "only" available starting from iOS 12.
To start, here is my code:
var buffer = malloc(interop.sizeof(interop.types.UTF8CString));
var fillBuffer = mac.getBytes(buffer);
var bytes = new interop.Reference(interop.types.UTF8CString, buffer);
var hexMac = bytes[0];
The variable 'Mac' is an NSData objected retrieved from CoreBluetooth. It is the scan response from a BLE device, which contains the peripheral's MAC address (00:0b:57:a2:fb:a0).
This problem is linked to THIS question I had posted earlier.
The solution provided is great; however, I cannot seem to implement this in nativescript :
(instancetype)stringWithFormat:(NSString *)format, ...;
Intellisense tells me the method doesnt exist on type NSString.
Due to that issue, I decided to go another route (as you can tell). I am filling a buffer with the bytes of the MAC address. In the code above, bytes[0] equates to 0xb57a2fba0.
I am now trying to convert that (which is an interop.Reference) into a string that I can store on the back-end (preferably in the xx:xx:xx:xx:xx format).
I have been at this all weekend, and cannot seem to find a solution. I even broke down objc!foundation.d.ts to figure out if stringWithFormat was supported, to no avail.
The nativescript community slack was unable to provide a resolution as well.
Please help if you can!
I don't know anything about NativeScript at all, but given the other code you wrote, I assume you're calling +alloc first, and so mean to use -initWithFormat: (an instance method that initializes) rather than +stringWithFormat: (a class method which handles allocation and initialization).
I've tried several techniques to capture a screenshot of an app from within that app. None of the techniques appear to capture the status bar -- it ends up being black.
There apparently was once a way to do this, but that interface is internal and Apple will not let you use it.
Any ideas?
Note: This is an attempt to solve this problem, where I need to determine if airplane mode is on or off (and no, simply knowing if the network is reachable is not sufficient).
However, it would seem that this question is of more general interest, and is distinct from that question.
Your actual issue, determining if a network interface is active, can be resolved with BSD networking functions. BEHOLD.
#include <sys/socket.h>
#include <ifaddrs.h>
#include <net/if.h>
BOOL IsNICTurnedOn(const char *nicName) {
BOOL result = NO;
struct ifaddrs *addrs = NULL;
if (0 == getifaddrs(&addrs)) {
for (struct ifaddrs *addr = addrs; addr != NULL; addr = addr->ifa_next) {
if (0 == strcmp(addr->ifa_name, nicName)) {
result = (0 != (addr->ifa_flags & (IFF_UP | IFF_RUNNING)));
break;
}
}
freeifaddrs(addrs);
}
return result;
}
To use this function:
BOOL isWWANEnabled = IsNICTurnedOn("pdp_ip0");
BOOL isWiFiEnabled = IsNICTurnedOn("en0");
At this point it seems clear that there is no simple way to detect if Airplane Mode is enabled. Although you could probably infer it by looking at low-level network stack info or scraping status bar pixels, either method would be relying on undocumented behavior. It's very possible that on a future release of iOS or a future iOS device, the behavior will change and your code will generate a false positive or false negative.
(Not to mention that, on future devices, the interference may not even be there.)
If I were in your shoes, I would:
File a bug to let Apple know you want this feature.
Work the notice into the app, regardless of whether Airplane Mode is enabled. Yes, it might be kind of annoying to the user if it is enabled, but the overall harm is minimal. I would probably make this an alert that pops up only once (storing a key in NSUserDefaults to indicate whether its already been displayed).
If you want to get super-fancy, analyze the recorded audio and, if the buzz is detected, remind the user again to enable Airplane Mode while recording. You could do this in real time or after the clip has been recorded, whatever makes more sense for your app.
As an alternative solution, perhaps you could detect the connection type, similar to: https://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html . With some additional checking for the device type, you could then warn the user only in the case where they need to act.
Kind of a different approach, but you can also link to pages within the Settings application. You could perhaps link to the primary page and tell the user the changes you require.
There appears to be no way to do this.
I'm working on a little hack sending MIDI messages from an app using RtMidi as a wrapper for CoreMIDI on OS X. I use RtMidiOut::openVirtualPort("MyAwesomePort") so I can select my app as an input source in a DAW.
However, if my program closes and I open it again, my DAW does not recognize the input device as the same port, despite being given the same name.
I was originally using pyrtmidi, so went and verified the behavior writing in C++ directly with RtMidi. "My DAW" in this case is Reaper 4, but I've duplicated the behavior in Pro Tools, Logic, and MuLab.
I know it's possible to retain some uniqueness of a virtual midi port, since MidiKeys behaves just as I'd like my application to behave: my DAWs remember it even if MidiKeys closes and re-opens while my DAW is still running.
So I dug into the RtMidi source, and the CoreMIDI wrapper seemed straightforward enough. All that the MIDISourceCreate asks for is a string. The client parameter is (what I presume after browsing the docs) an identifier for my application, it being a client of the CoreMIDI services.
void RtMidiOut :: openVirtualPort( std::string portName )
{
CoreMidiData *data = static_cast<CoreMidiData *> (apiData_);
if ( data->endpoint ) {
errorString_ = "RtMidiOut::openVirtualPort: a virtual output port already exists!";
error( RtError::WARNING );
return;
}
// Create a virtual MIDI output source.
MIDIEndpointRef endpoint;
OSStatus result = MIDISourceCreate( data->client,
CFStringCreateWithCString( NULL, portName.c_str(), kCFStringEncodingASCII ),
&endpoint );
if ( result != noErr ) {
errorString_ = "RtMidiOut::initialize: error creating OS-X virtual MIDI source.";
error( RtError::DRIVER_ERROR );
}
// Save our api-specific connection information.
data->endpoint = endpoint;
}
So I looked at the MIDISourceCreate documentation, and read this:
After creating a virtual source, it's a good idea to assign it the same unique ID it had the last time your application created it. (Although you should be prepared for this to fail in the unlikely event of a collision.) This will permit other clients to retain persistent references to your virtual source more easily.
This seems like exactly what I'm looking for. Except I have no idea how to assign the source a unique ID. The out parameter for MIDISourceCreate is a MIDIEndpointRef, which according to the docs is just typedef'd to a UInt32 down the line. So I hypothesized that maybe I should keep track of this UInt32, but that seems like a bad idea.
After digging through all of this I feel like I'm hitting a bit of a brick wall. How do I retain the uniqueness of my MIDI port in between runs of my application?
According to the docs,
kMIDIPropertyUniqueID
The system assigns unique ID's to all objects. Creators of virtual endpoints may set this property on their endpoints, though doing so may fail if the chosen ID is not unique.
So maybe something like this:
// Try to set the ID if it's saved.
if (savedUniqueId) {
OSStatus result = MIDIObjectSetIntegerProperty(endpoint, kMIDIPropertyUniqueID, myUniqueId);
if (result == kMIDIIDNotUnique) {
savedUniqueId = 0;
}
}
// If not saved, record the system-assigned ID
if (!savedUniqueId) {
OSStatus result = MIDIObjectGetIntegerProperty(endpoint, kMIDIPropertyUniqueID, &savedUniqueId);
// Handle the error?
}
The unique ID is typedefed to a SInt32. I've made the assumption that 0 is an invalid unique ID, which is at least true for connections (the docs for kMIDIPropertyConnectionUniqueID say it's "non-existant or 0 if there is no connection").
I'm not sure how you maintain long-term uniqueness with only 32 bits, but it'll hopefully be sufficient for relaunches of your app.