Wonderlinq support

Hi Menion,

I'm one of the developers of the WunderLINQ. The WunderLINQ is a combination of hardware and software. Our App is a hub of sorts that launches apps, controls devices like GoPros, shows performance data, etc. The hardware is essentially a Bluetooth keyboard.

Basically we need the following as map zooming already works with the WunderLINQ hardware.

• An intent to launch Locus without interrupting current navigation
• An intent to launch Locus and navigate to a lat/lon
• An intent to launch Locus and view a lat/lon

We also would need you to map the ESCAPE Keycode to launch our URL, or as we suggest in our documentation to add a calling app argument to your launch intent/URL then have ESCAPE call that.

Our developer documentation details a basic integration between our apps, we've described a way that other developers could use and wouldn't be specific to the WunderLINQ.

We have quite a few mutual customers and would be willing to help in any way I can.

Keith

Hello Keith,

nice to meet you and thanks for additional information.

Your three points should be already possible with basic intent system offered by Android, this should not be a problem. The question is if you are also able to add some Locus-specific features to your control software.

As I wrote in my previous post, Locus Map offers quite complex control over mentioned "Action tasks". Mainly for motorbike navigation, I may suggest quite a hidden feature quick_action_menu which is currently available only over this menu.

ESC key, I'll check it. Is there any method of how to test proper implementation without purchase your hardware?

Menion

Hi Menion,

Nice to meet you as well.

I must not be looking in the right place for the intent documentation? I also tested using the Android default URIs like "google-navigation:" and "maps.google.com" but can't seem to get Locus Map Pro to show up in the Android list of apps supporting those URIs. I did work out the ability to launch Locus Map without interrupting current Navigation worked out.

I'll look into what I can do with the quick_action_menu Action Task.

You can actually test with any keyboard, our device sends the following keycodes, UP, DOWN, LEFT, RIGHT, ENTER & ESCAPE

Thanks for your help!

Keith

Hello Keith,

"google.navigation" intent is not implemented in Locus Map. Based on these docs, I've added it for a query with defined coordinates. So will work in next Locus Map 3.41.0 version.

Support for ESC key: I just tried to add it, but seems that by BT keyboard send some weird ESCAPE key_event that cause that every app is minimized. So support for ESCAPE should be also since 3.41.0 working, but it needs test because I can't simply verify it's functionality.

Menion

Hi Menion,

Awesome, thanks for adding support for "google.navigation" Which intent/URL do I use to open LocusMap to just view a Lat/Lon passed to it?

Some older version of Android used the ESCAPE keycode as BACK keypress, is this what your seeing? I forgot to mention the WunderLINQ app is free in the app store. If you would like I could give you beta access so you could test the whole flow?

Thanks for your work on this!

Keith

Disregard my first question, I've worked viewing a waypoint out. :)

Hello,

glad you find a solution on the first point. Basic links like http://maps.google.com/maps?q=50.539097,13.784375 and similar should work (and many others).

ESC key ... it works more like a "HOME" button, completely in all apps. And the home button is "unstoppable" :). Anyway, best if you will be able to test it in the next Locus Map version. If there will be a problem, we may do one or more iteration steps of course.

Btw. if you want to speed it up, I'll be probably today publishing a new Beta version, so you may give it a try.

Menion

HI,

Weird, none of my test phones treat the ESCAPE key this way. Could you tell me the device and Android version your testing on?

Just signed up for the beta, I'll start testing.

Just tried the current beta passing it a point in the following format google.navigation:q=lat,long

Locus opened and searched but found no results for the point.

Hmm, how you test it? There should be no "search", just immediate display of "Navigate to" screen.

I'm testing it directly over ADB with the command:

adb shell am start -a "android.intent.action.VIEW" -d "google.navigation:q=50.1,14.2"

When I defined "Home" address, then why the app needs location permission when I click "Go home", when then immediately call public intent,

Anyway selecting Locus Map in the dialog with apps that are able to handle intent, Locus Map is correctly started and seems to handle received intent "google.navigation:q=50.0750555,14.4531749&navigate=yes" correctly, so it display "Navigate to" screen with coordinates predefined as target.

Thanks for your suggestions. I'm actually planning a permissions overhaul.

You can replicate what I'm seeing with the following command:

adb shell am start -a "android.intent.action.VIEW" -d "google.navigation:q=38.847021,-104.8236649999999&navigate=yes"

Using 50.1,14.2 works for me as well.

Negative coordinate numbers are always problems for people living in north-east part :).

Thanks, fixed.

Thanks, I'll watch for the next beta to test.

I had a question in regards to your ESCAPE key findings. None of my test phones treat the ESCAPE key this way. Could you tell me the device(s) and Android version(s) your testing on?

Ah sorry. Most probably weird keyboard. Just checked it on the second device and the same result, so it seems not to be device-dependent. Anyway, it's most probably not important. Important is if currently implementation (in already published Beta version), correctly reacts on "ESC" event, so please test it. If not, I'll try to connect a different keyboard for the test.

Sorry for the delay I just tried with the current Locus beta and get no reaction from the ESCAPE keycode. I've tested the WunderLINQ and a couple of Qwerty US 101 keyboards.

I'm sorry, I have currently no idea how to do this. No matter what I do, app is never able to catch ESCAPE key code, it is just not delivered. Same as with for example "home" key.

Are you able to catch this event on your side? If so, what method you use? `dispatchKeyEvent` call is definitely not working.

So here is a snippet that works for me. I hope it helps. Thanks again for all your work on this.

@Override
public boolean onKeyUp(int keyCode, KeyEvent event) {
    Log.d("Keycode", "Keycode: " + keyCode);
    switch (keyCode) {
        case KeyEvent.KEYCODE_ESCAPE:
        // You’ll probably want to parse the argument with the return URL
        String callingApp = "wunderlinq://datagrid";
        Intent intent = new
        Intent(android.content.Intent.ACTION_VIEW);
        intent.setData(Uri.parse(callingApp));
        intent.setFlags(FLAG_ACTIVITY_LAUNCH_ADJACENT);
        startActivity(intent);
        return true;
    default:
        return super.onKeyUp(keyCode, event);
    }
}

Hello, thanks for the code. The result is unfortunately the same.I've anyway found a method over ADB which works perfectly, so definitely some problem with my BT keyboard.

adb shell input keyevent ESCAPE

Very cool. I'll check it out in the next beta.

I received the new beta this morning. Everything is working excellent!

I was wondering if I could trouble you with one last thing? Is there a way to tell Locus to just start routing and not preset navigation options like vehicle type? Or could you change the default focus to the start navigation button? That would allow the user to hit ENTER again?

Oki perfect.

About the new idea: I'm thinking about it and unfortunately, I do not see an easy solution to start navigation directly with the current mechanism. Locus Map offers too many choices so simple "car", "bike" does not properly fit to existing routing profiles.

I've added "requestFocus" call on the navigation button, but to be true, I do not have a good experience with focus handling, so do not quarantee it will work.

I totally understand. I'll test focus change on the next beta.

Thanks again for all your work!

Just tested with 3.40.2.3, the Car button has focus. Are you setting requestFocus in XML or programmatically? I've had luck in XML, but my layouts were simple.

Hello Keith,

not sure if something changed in the latest public version. I made a small change but did not tested if it helped.

Layout in the app is quite complex and most of it is generated dynamically in the code so XML does not work here. As I wrote before, I never fully understand how this focus system works, because it many times simply does not work as I expect. So it may be problem here as well ...

I'm happy to report the focus is now on the start button. I was wondering about one last thing :)

Would it be possible to change the default config.cfg to have the following mods:

hardware_buttons_action_map_zoom_in=81|24|s70|97|19

hardware_buttons_action_map_zoom_out=69|25|96|20

Thanks again for your hard work!

Hello Keith,

I'm glad (and little surprised), that focus works, perfect!

I saw the overcomplicated system described in your manual about "How to make Locus Map working". Agree that this is not a usable solution, anyway change of defaults is not a good solution. Firstly, current users won't receive this change and using A and B buttons may have unwanted side-effects.

I'll have to allow to change this over UI, but it will take some time as it does not have high priority. I'll let you know here once it's done.

Menion

Hi Menion,

Awesome, thanks for looking into it!

Keith

Hello Keith,

may you please write to me here your definition in config.cfg for all keys you want to modify? Or just mentioned zoom-in/zoom-out values above?

Hi Menion,

zoom-in/out is it.

Hi, oki, so something like this will be in next version (or Beta).

I believe it will be a lot better then current crazy system over config.cfg ;).

Menion

Very cool, I'll give it a try and update my documentation. Thanks again for all your hard work!

Keith

Hi Menion,

I've noticed a new behavior with some phones where the intent flag: FLAG_ACTIVITY_LAUNCH_ADJACENT is used regardless of the device is in a multi-window or not. A couple of our users have reported that the WunderLINQ app and Locus experience this issue. I was able to resolve this in our app by checking if we are in multi-window mode before setting the flag, snippet below. Please let me know if you have any questions.

if (android.os.Build.VERSION.SDK_INT >= 24) {
    if (isInMultiWindowMode()) {
        intent.setFlags(FLAG_ACTIVITY_LAUNCH_ADJACENT);
    }
}

Hello Keith,

oki, no problem, will be added in next 3.47.1 version, thanks.

Menion

Hi Menion,

Awesome, thank you.