There are several articles/videos out there on how to build/connect to Google Maps' API that walk through the process. I'm going to spend a little time here talking about some of the components within PowerApps that make this easier that you might expect.
The holy grail of device location in PowerApps really breaks down into three distinct functions:
- Location.Latitude
- Location.Longitude
- Location.Altitude
That is scary simple given the power it grants you. If you run any of these functions (say to assign them to a variable and/or pass to Google Maps), then PowerApps and your specific OS handle the permissions required and will prompt the user to grant the application access. Once the user hits OK, then that's it.
Example Application
In my example, I created a simple demonstration of an application for healthcare workflow from a patient's perspective.
Healthcare in the US is a complete train wreck for the patient. The questions of where to go, how much does it cost, who pays for what, etc. are unfortunately never really simple. Each provider within the chain might know it's own processes/costs very well, but they also tend to protect some of that information from others. This is due to the recognition of costs outweighing the benefits within the US market. That means unless you're the low-cost provider in your area, others will put pressure on you to lower your prices (so they don't have to lower theirs).
I recently had a surgery from a physician-owned facility that is fairly streamlined. However, they sent SMS messages from a non-affiliated number, referred to themselves by 3 different names, 2 of those names don't appear in Google Maps properly, and sent me bills from various random people involved in the procedure (e.g. anesthesiologist, surgeon and facility) making it hard to know if/when I was done paying.
Regardless of that mess, one of the first things needed for a patient is just picking a provider from an available list (likely provided by your insurer). In my example application, I assumed a user would probably like to call them to make an appointment (sure I'd like to do this for them - baby steps), then they would want to know how to get there. So I looked and discovered that this was fairly straightforward within PowerApps.
A basic framework |
The above is a screen shot from my Pixel 2 of the application after a user has selected a particular provider. It primarily grants them two functions:
- Call the provider
- Get directions to the provider
Making phone calls
This is so ridiculously easy. The following command is all you need:
- Launch("tel://xxx")
Just replace the xxx with whatever phone number you'd like to call and that's it. Best to use numbers only, but I'm fairly certain that it will just pass whatever you send it to your default dialer application. If it knows how to handle what you've sent, then you're good. Numbers will always work, but you could get creative w/ formatting and potentially pauses and carrier command codes.
That's it.
I told you it was simple.
Linking to Google's APIs (Static Image)
Of course I could have used Bing for this.
Stop laughing.
The portion of my example application is actually doing two distinct functions from Google:
- Provide a static image using my own Google API key
- Launch a URL to Google Maps for directions
One of these costs money. One doesn't.
The show a static map is actually just changing the image source similar to the image shown below:
The show a static map is actually just changing the image source similar to the image shown below:
Check the right-hand side for the image source and action on click |
To do this, first you'd need a Google API Key to generate your own static images. Again, this DOES COST MONEY. At least, if you roll this out to production and have thousands of people asking for the images each month.
The details on getting a key can be found here:
I already had an account so just generated a key and moved on. Easy peasy.
I dropped an Image container on my PowerApp and made the Image value equal to the following:
- "https://maps.googleapis.com/maps/api/staticmap?center=" & lAddress & "&zoom=14&size=600x600&markers=color:blue%7C" & lAddress & "&key=" & gGoogleAPIKey
I've highlighted the two distinct variables (one local, one global) that are getting assigned previously and then merged to form the URL to the Google API:
- lAddress
- UpdateContext({lAddress:EncodeUrl(orgAddress1.Text) & EncodeURL(orgAddress2.Text)})
- gGoogleAPIKey
- Set (gGoogleAPIKey, "The Key I copied from Google")
The one bit of strangeness in the assignments above is the EncodeUrl() function. It can be used for any string to format it properly for a URL (e.g. change spaces to %20, etc.). I'm using that to take the spaces out of the street and city/state address fields.
Linking to Google's APIs (Google Maps Directions)
The second bit I did was to make the map image clickable which would give the user directions using Google Maps itself (vs. embedding it). This is FREE, which shows you how you could use some of these functions w/o charge. For example, I could have not shown a map of the location above and simply given them a button tied directly to Google Maps. In many respects, Google isn't trying to get rich off of us as much as they are trying to encourage/discourage certain behavior.
So I altered the OnSelect event for my image above to be:
- Launch("https://www.google.com/maps/dir/?api=1&origin=" & Location.Latitude & "," & Location.Longitude & "&destination=" & lAddress.Text)
Again, the variable containing the URL-friendly Address is highlighted in yellow, but I've also highlighted the Location functions in green. These handle all the requests from the device for it's current latitude/longitude and send that along to Google Maps to process.
The beauty here is that this actually opens the Google Maps application on the device if it is installed or the URL via the browser if not. This works on any device and allows the user to interact w/ the maps just as they would normally.
Final Thoughts
There are of course risks that arise from relying on 3rd party applications and frameworks to deliver functionality for end-users. However, this is the kind of use-case that aligns with each vendor's primary goals. Microsoft wants to encourage the use of their tools for application development for mobile/desktop workflow integration. Google wants to get data on mapping/destinations and tie it to a specific user.
If you use these applications in a manner that aligns with these vendor's goals, then you are less likely to run into issues with them deprecating a particular feature.
No comments:
Post a Comment
Because some d-bag is throwing 'bot posts at my blog I've turned on full Moderation. If your comment doesn't show up immediately then that's why.
DIAF Visualpath team