Services like Uber provide users with masked phone numbers so that they can communicate directly with one another without exposing their actual phone number. It seems to me a form of network address translation?
Does anyone have services, OSS, API/code examples or SDK links that one might use to set up a similar system?
Primarily this would entail mapping/translating a generated phone number to a user's actual number (behind the scenes), but telemetry style analytics would also be desirable.
Preferably Node Javascript, C#, or Java... but anything is better than nothing!
Many thanks
Ricky from Twilio here.
We put together a tutorial on how to build masked phone numbers with Node.js, C#, Java, Python or Ruby:
https://www.twilio.com/docs/tutorials/walkthrough/masked-numbers/node/express
In this Node.js example, here's the block of code that masks a phone call:
router.post('/use-voice', twilio.webhook({ validate: false }), function (req, res) {
from = req.body.From;
to = req.body.To;
body = req.body.Body;
gatherOutgoingNumber(from, to)
.then(function (outgoingPhoneNumber) {
var twiml = new twilio.TwimlResponse();
twiml.play('http://howtodocs.s3.amazonaws.com/howdy-tng.mp3');
twiml.dial(outgoingPhoneNumber);
res.type('text/xml');
res.send(twiml.toString());
})
});
The gatherOutgoingNumber function uses the phone call from and to to determine who the user is intending to call, once that number is found this code forwards the call to the correct phone number.
It's MIT licensed and hopefully can help you get started.
I found what Uber uses... Twilio! So that's one option at least
Related
I'm using the NuGet package Plugin.BluetoothLE v6.3.0.19 and I can scan for nearby devices but mostly the names are blank. A few devices show their names but most do not. I also cannot see the mac address of the device I'm looking for.
The scenario is that I know the device name but need to look up the mac for connecting.
As I check the devices I need to check the device.name to see if it matches the device I'm looking for. If found it will attempt to pair and connect.
I'm thinking this LE (Low Energy) version does not get the names from every device unless it broadcasts it. So maybe I need to request more info? If so I don't know how to do that with this plugin.
var adapter = CrossBleAdapter.Current;
adapter.ScanExtra(new ScanConfig { ScanType = BleScanType.Balanced });
var scanner = CrossBleAdapter.Current.Scan().Subscribe(scanResult =>
{
var x = scanResult.Device;
System.Diagnostics.Debug.Print($"{x.Name} - {x.Status} _ {x.ToString()}");
});
I am not very familiar with the BluetoothLE, but I found a course about the problem. I hope this can help you.
In addition, you can put the issue on this git. People who know the problem may help you.
Working with Evernote IOS SDK 3.0
I would like to retrieve a specific resource from note using
fetchResourceByHashWith
This is how I am using it. Just for this example, to be 100% sure about the hash being correct I first download the note with a single resource using fetchNote and then request this resource using its unique hash using fetchResourceByHashWith (hash looks correct when I print it)
ENSession.shared.primaryNoteStore()?.fetchNote(withGuid: guid, includingContent: true, resourceOptions: ENResourceFetchOption.includeData, completion: { note, error in
if error != nil {
print(error)
seal.reject(error!)
} else {
let hash = note?.resources[0].data.bodyHash
ENSession.shared.primaryNoteStore()?.fetchResourceByHashWith(guid: guid, contentHash: hash, options: ENResourceFetchOption.includeData, completion: { res, error in
if error != nil {
print(error)
seal.reject(error!)
} else {
print("works")
seal.fulfill(res!)
}})
}
})
Call to fetchResourceByHashWith fails with
Optional(Error Domain=ENErrorDomain Code=0 "Unknown error" UserInfo={EDAMErrorCode=0, NSLocalizedDescription=Unknown error})
The equivalent setup works on Android SDK.
Everything else works so far in IOS SDK (chunkSync, auth, getting notebooks etc.. so this is not an issue with auth tokens)
would be great to know if this is an sdk bug or I am still doing something wrong.
Thanks
This is a bug in the SDK's "EDAM" Thrift client stub code. First the analysis and then your workarounds.
Evernote's underlying API transport uses a Thrift protocol with a documented schema. The SDK framework includes a layer of autogenerated stub code that is supposed to marshal input and output params correctly for each request and response. You are invoking the underlying getResourceByHash API method on the note store, which is defined per the docs to accept a string type for the contentHash argument. But it turns out the client is sending the hash value as a purely binary field. The service is failing to parse the request, so you're seeing a generic error on the client. This could reflect evolution in the API definition, but more likely this has always been broken in the iOS SDK (getResourceByHash probably doesn't see a lot of usage). If you dig into the more recent Python version of the SDK, or indeed also the Java/Android version, you can see a different pattern for this method: it says it's going to write a string-type field, and then actually emits a binary one. Weirdly, this works. And if you hack up the iOS SDK to do the same thing, it will work, too.
Workarounds:
Best advice is to report the bug and just avoid this method on the note store. You can get resource data in different ways: First of all, you actually got all the data you needed in the response to your fetchNote call, i.e. let resourceData = note?.resources[0].data.body and you're good! You can also pull individual resources by their own guid (not their hash), using fetchResource (use note?.resources[0].guid as the param). Of course, you may really want to use the access-by-hash pattern. In that case...
You can hack in the correct protocol behavior. In the SDK files, which you'll need to build as part of your project, find the ObjC file called ENTProtocol.m. Find the method +sendMessage:toProtocol:withArguments.
It has one line like this:
[outProtocol writeFieldBeginWithName:field.name type:field.type fieldID:field.index];
Replace that line with:
[outProtocol writeFieldBeginWithName:field.name type:(field.type == TType_BINARY ? TType_STRING : field.type) fieldID:field.index];
Rebuild the project and you should find that your code snippet works as expected. This is a massive hack however and although I don't think any other note store methods will be impacted adversely by it, it's possible that other internal user store or other calls will suddenly start acting funny. Also you'd have to maintain the hack through updates. Probably better to report the bug and don't use the method until Evernote publishes a proper fix.
My app uses Xamarin.Forms.Maps to display a map and also for geocoding. The map is displayed on a separate page when the user navigates to it from the main page. I use the geocoder to reverse geocode the current location so that I have the address. This is done from various places other than the map page.
When I run the app on a device (even in debug mode) the geocoder works right away in iOS and Android, but does not work in UWP. After I navigate to the map page and display the map, then go back to a different page to use the geocoder it starts working.
I saw a thread about the map not working with release build so I added the following code:
var laRendererAssemblies = new[] { typeof(Xamarin.Forms.Maps.UWP.MapRenderer).GetTypeInfo().Assembly };
Xamarin.Forms.Forms.Init(e, laRendererAssemblies);
//Xamarin.Forms.Forms.Init(e);
Xamarin.FormsMaps.Init("MyBingMapsKey");
This has not helped the issue with the Xamarin.Forms.Maps.Geocoder. I also tried creating an instance of Xamarin.Forms.Maps.Map in my main page, but that did not help either. Is there a way to prime the map component so that the Geocoder will work on a device? (My test device is ARM, but it happens when I run on Local
Machine (Win 10) too)
Following is a snippet of the call to the Geocoder (which works fine once the user has navigated to the Map page and back - and it works fine in iOS and Android - and as such I don't believe it is a problem with the code, but here it is):
public static async Task<Plugin.Geolocator.Abstractions.Position> Geocode(string address)
{
try
{
var loGeocoder = new Xamarin.Forms.Maps.Geocoder();
System.Diagnostics.Debug.WriteLine("Get Lat/Lon");
var lcolPositions = await loGeocoder.GetPositionsForAddressAsync(address);
if (lcolPositions != null)
After doing some research and ensuring that your geodecode class being static wouldn't mess with the async/await pattern in the UWP build. I've come across a few references to this particular problem with the built in Forms.Map geodecoder elsewhere, not just for UWP it has also been noted for android‡.
I took some time to have a look at one of our current cross-platform applications that we have in the app stores, and according to our internal documentation we switched out both the xamarin.forms map, and the geodecoder for custom ones.
The plugin that we use for our cross-platform application is the 'GelocatorPlugin' created by james montemagno, and can be found here.
It can be added to your project as a Nuget package if you prefer, and the implementation of it is very similar to the default one, so there's very little code to change. The primary benefit is that the UWP element of the geodecode plugin has been modified to take into account windows advanced tracking scenarios (details found here).
It should be a lot more stable than the one your using, once installed you simply use it like so:
Reverse Geocoding
Based on a location that is passed in, thi swill grab a list of
addresses.
UWP requires a Bing Map Key, which you can acquire by reading this
piece of documentation.
try
{
var addresses = await locator.GetAddressesForPositionAsync (position, string mapKey = null);
var address = addresses.FirstOrDefault();
if(address == null)
Console.WriteLine ("No address found for position.");
else
Console.WriteLine ("Addresss: {0} {1} {2}", address.Thoroughfare, address.Locality, address.Country);
}
catch(Exception ex)
{
Debug.WriteLine("Unable to get address: " + ex);
}
‡ Links to similar problems - Link 1, Link 2
resolved after added following lines in APP.xaml.cs (UWP project)
Xamarin.FormsMaps.Init("bingmapkey");
Windows.Services.Maps.MapService.ServiceToken = "bingmapkey";
Today my app got reject i don't understand problem.
Rejected because:
10.6 - Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good, it may be rejected
With comment:
10.6 Details
Your app’s location feature is not integrated with the built-in mapping functionality, which limits users to a third party Maps application.
Next Steps
Please revise your app to give users the option to launch the native Apple Maps application.
What i need to do? I should add Apple Maps in my app and give the user a choice?
Why they do not require such other applications.
A few words about my application: It’s social network that displays the users on map
You can see main screen with Google Maps
they say:
"to give users the option to launch the native Apple Maps..."
what you can do is show an action sheet with 3 options:
google maps
waze
maps
the user will choose ...
one of the option shoukd be maps of Apple
implement the maps option as follow:
let regionDistance:CLLocationDistance = 100
let coordinates = CLLocationCoordinate2DMake(lat, lon)
let regionSpan = MKCoordinateRegionMakeWithDistance(coordinates, regionDistance, regionDistance)
let options = [
MKLaunchOptionsMapCenterKey: NSValue(mkCoordinate: regionSpan.center),
MKLaunchOptionsMapSpanKey: NSValue(mkCoordinateSpan: regionSpan.span),
MKLaunchOptionsDirectionsModeKey: motType = MKLaunchOptionsDirectionsModeDriving
] as [String : Any]
let mapItem = MKMapItem(placemark: MKPlacemark(coordinate: coordinates, addressDictionary: nil))
mapItem.name = placeName
mapItem.openInMaps(launchOptions: options)
Inside iTunes Connect, I simply questioned the rejection, asking them why this was required, and stated that I have business logic related to Google Maps. After two days the app got accepted.
The adobe documentation says that when listening for a keypress event from a phone you should listen for Key.Down, however when I trace the Key.getCode() of keypresses I see a number not the string "Key.Down". I am tesing this locally in device central and do not have a phone to test this with at present. Here is my code -
keyListener = new Object();
keyListener.onKeyDown = function() {
switch (Key.getCode()) {
trace(Key.getCode()) // outputs 40
case (Key.DOWN) : // according to the docs
pressDown();
break;
}
}
My question is - is this simply because Im testing in device central and when I run it on the phone I will need to be listening for Key.Down? or is the documentation wrong? Also is the numeric code (40) consistent across all devices? What gives adobe?
thanks all
Key.Down is equal to 40 so it will recognize it as the same. So you can use whichever one you prefer, however, I would recommend using Key.Down because it will be easily recognizeable for those who dont have Key Codes memorized (most of us).
These are the Key Code Values for Javascript. However, I think they are pretty much universal