Posting this question with an answer so other's can find it.
We have an app on the store which records an activity's path. When we updated the WatchOS to version 4, our background gps updates stopped when the app transitioned into the background.
Some research found this link on Apple's Developer site that shows we need to set a new property in the location manager.
self.locationManager = [[CLLocationManager alloc] init];
self.locationManager.delegate = self;
self.locationManager.desiredAccuracy = kCLLocationAccuracyBestForNavigation;
if (#available(watchOS 4.0, *)) {
self.locationManager.activityType = CLActivityTypeOther;
self.locationManager.allowsBackgroundLocationUpdates = YES; // NEW!!
}
[self.locationManager startUpdatingLocation];
See the line marked "NEW!!" That's what allowed the app to receive background location updates again. You also need to have the properties set as mentioned in the link.
Apps that want to receive location updates when suspended must include
the UIBackgroundModes key (with the location value) in their app’s
Info.plist file and set the value of this property to YES. The
presence of the UIBackgroundModes key with the location value is
required for background updates
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.
Our company is migrating our help systems over to HTML5 format under Flare. We've also added Topic based access to the help systems using Flare CSHID's on the URI command line for accessing the topic directly, such as index.html#CSHID=GettingStarted to launch the GettingStarted.html help page.
Our apps are written in C++ and leverage the Win32 ShellExecute() function to spawn the default application associated with HTTP to display the help system. We've noticed that ShellExecute() works fine when no hashtag is specified, such as
ShellExecute(NULL, _T("open"), _T("c:\\Help\\index.html"), NULL, NULL, SW_SHOWNORMAL);
This function will launch the default browser associated with viewing HTML pages and in this case, the File:/// protocol handler will kick in, the browser will launch and you will see file:///c:/Help/index.html in the address bar.
However, once you add the # information for the topic, ShellExecute() fails to open the page
ShellExecute(NULL,_T("open"),_T("c:\\Help\\index.html#cshid=GettingStarted"),NULL,NULL,SW_SHOWNORMAL);
If the browser opens at all, you'll be directed to file:///c:/Help/index.html without the #cshid=GettingStarted topic identification.
Note that this is only a problem if the File protocol handler is engaged through ShellExecute(), if the help system lives out on the web, and the Http or Https protocol handler is engaged, everything works great.
For our customers, some of whom are on a private LAN, we cannot always rely on Internet access, so our help systems must ship with the application.
After some back-and-forth with Microsoft's MSDN team, they reviewed the source code to the ShellExecute() call and it was determined that yes, when processing File:/// based URLs in ShellExecute(), the ShellExecute() call will strip off the # and any data it finds after the # before launching the default browser and sending in the HTML page to open. MS's stance is that they do this deliberately to prevent injections into the function.
The solution was to beef up the ShellExecute() call by searching the URL for a # and if one was found, then we would manually launch the default browser with the URL. Here's the pseudocode
void WebDrive_ShellExecute(LPCTSTR szURL)
{
if ( _tcschr(szURL,_T('#')) )
{
//
//Get Default Browser from Registry, then launch it.
//
::RegGetStr(HKCR,_T("HTTP\\Shell\\Open\\Command"),szBrowser);
::CreateProcess ( NULL, szBrowser + _T(" ") + szURL, NULL, NULL, FALSE, 0, NULL, NULL, &sui, &pi);
}
else
ShellExecute(NULL,_T("open"),szURL,NULL,NULL,SW_SHOWNORMAL);
}
Granted there's a bit more to the c++ code, but this general design worked for us.
I tried WebDrive's solution and it didn't really work on Windows 10.
"HTTP\Shell\Open\Command" default value is set to Internet Explorer path, regardless of what my default browser setting. However, for Internet Explorer that solution DOES work.
Process to fetch default browser path on Windows 10 is a bit different (How to determine the Windows default browser (at the top of the start menu)) but even then the solution is not guaranteed to work, depending on the browser. E.g. for me it didn't work with Edge.
To get it to work with Edge I had to add "file:///" to the URL -- but that also makes the URL work with ShellExecute(). So, at least on Windows 10, all I needed to do was this:
ShellExecute(NULL,_T("open"),_T("file:///c:/Help/Default.html#cshid=1648"),NULL,NULL,NULL);
UPDATE:
The above stopped working months ago. What I eventually did was go through temporary file, as described here: https://forums.madcapsoftware.com/viewtopic.php?f=9&t=28376#p130613
Use FindExecutable() to get the default browser and pass the full help file path with its queries (?) and fragments (#) as the lpParameters parameter to ShellExecute(). They won't get stripped off there.
Then handle the case if it is a Store App (most likely Microsoft Edge).
Pseudo C code:
if (FindExecutable(_T("c:\Help\index.html"), NULL, szBrowser)
{
if (szBrowser == _T("C:\WINDOWS\system32\LaunchWinApp.exe"))
{
// default browser is a Windows Store App
szBrowser = _T("shell:AppsFolder\Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge");
}
}
else
{
szBrowser = szURL;
szURL = NULL;
}
ShellExecute(NULL, NULL, szBrowser, szURL, NULL, SW_SHOWNORMAL);
I solved the problem without using any method other than ShellExecute in a Qt Application
QString currentpath = QDir::currentPath();
QString url = "/help//html/index.html#current";
QString full_url = "file:///" + currentpath + url;
QByteArray full_url_arr= full_url.toLocal8Bit();
LPCSTR lp = LPCSTR(full_url_arr.constData());
ShellExecute(NULL, "open", lp, NULL, NULL, SW_SHOWNORMAL);
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