In the HERE SDK user guide there is a screenshot showing the next maneuver. See:
https://developer.here.com/mobile-sdks/documentation/android-hybrid-plus/topics/map-guidance.html
Is this something that is provided by the SDK or is the developer expected to render this manually?
Here is the navigation code I am using:
Route route = list.get(0).getRoute();
map.setMapScheme(Map.Scheme.CARNAV_DAY);
map.getPositionIndicator().setVisible(true);
map.setTilt(45);
map.addMapObject(new MapRoute(route));
manager.setRoute(route);
manager.setTrafficAvoidanceMode(NavigationManager.TrafficAvoidanceMode.DYNAMIC);
manager.setRealisticViewMode(NavigationManager.RealisticViewMode.DAY);
manager.setMap(map);
NavigationManager.Error simError = manager.startNavigation(route);
if(simError != NavigationManager.Error.NONE) {
Log.e(LOG_TAG, "Error" + simError);
}
Maybe a bit late, but for the others who are having the same question,
You can use the HERE Mobile SDK UI Kit (MSDKUI) which provides a highly customizable user interface components that can be used on top of the HERE SDKs.
Here is the repo on Github:
https://github.com/heremaps/msdkui-android
Some things are rendered automatically by the HERE SDK, mainly things that are directly tied to the map rendering (like navigation arrows on the street when doing guidance), but most UI things you have to do on your own since most users want to have their own look&feel and UI.
So, yes the maneuver icons are something you have to provide and render in your UI manually (or the other way around: you have the full freedom to decide how it should look like).
Related
I am searching for hours and wondering if it is possible to use the old navigation and the shell navigation in one Xamarin APP.
Background:
The reason for that is, that I am maintaining an old app with 40+ sites - with different Navigation through the sites and sometimes complex data passing through them.
Try to achieve:
Now I've to implement some new sites and just wanted to put them into the Shell-Navigation. Those "Shell-Sites" should also be available in the "old navigation".
So yes - I could try to put it all to shell, but don`t have the resources yet AND: never touch a running system...
Yes, its possible.
First, understand that AppShell starts up by doing this in App.xaml.cs:
MainPage = new AppShell();
To reach individual pages from AppShell, see:
XF Shell Navigation / Register detail page routes.
To navigate away from AppShell into old-style navigation, do either:
Application.Current.MainPage = new SomePage();
OR
Application.Current.MainPage = new NavigationPage();,
depending on how your old navigation was done.
To return to AppShell, do:
Application.Current.MainPage = new AppShell();
To return to a specific page within AppShell, I'm not sure the exact details. Maybe after setting MainPage to appshell, execute a shell "Route".
CAVEAT: When you think through the above, you'll soon realize that you can't leave the old pages "completely" untouched. You need to decide what user will do to go "back and forth". Then decide how to only include that in the "AppShell" version of the code. But that is no longer an AppShell-related topic. Its a standard c# .net build question, plus making some UI decisions.
On Xamarin iOS, it is possible to make a VoiceOver announcement for example when a background operation has completed, see here. This announcement is not dependent on the appearance of any UI control.
On Xamarin Android on the other hand, the accessibility developer documentation only gives an example where the TalkBack announcement is enforced for a specific UI control, see here.
As an attempted workaround I programmatically created a simple UI control ctl and called ctl.AnnounceForAccessibility("My announcement") but no announcement could be heard. Presumably because the control is not in the visual tree?
Is there any way to make a TalkBack announcement on Android without the involvement of a (visible) UI control?
With inspiration from this StackOverflow answer, I implemented the following workable solution:
var manager = (AccessibilityManager)Application.Context.GetSystemService(Context.AccessibilityService);
var accessibilityEvent = AccessibilityEvent.Obtain(EventTypes.Announcement);
if (manager != null && accessibilityEvent?.Text != null)
{
accessibilityEvent.Text.Clear();
accessibilityEvent.Text.Add(new Java.Lang.String(myDotNetString));
manager.SendAccessibilityEvent(accessibilityEvent);
}
I am successfully showing a spherical image using the Google Panorama API
I am using the same code as most tutorials do:
#Override
public void onConnected(Bundle bundle){
Panorama.PanoramaApi.loadPanoramaInfo(GOOGLE_CLIENT,Uri.parse(url)).setResultCallback(
new ResultCallback<PanoramaApi.PanoramaResult>(){
#Override
public void onResult(PanoramaApi.PanoramaResult result){
if (result.getStatus().isSuccess()){
Intent intent = result.getViewerIntent();
if (intent != null){
startActivity(intent);
}
}
}
});
}
Actually, I do not only have one sphere but around 5. I would like to be able to switch between the images clicking on menu items overlayed over the images.
Since the actual activity showing the sphere is not defined by me but started through an intent received in the success callback I have no idea how I can achieve this and the API does not seem to offer much more possibilities.
I guess I can not even show a dialog on top of the sphere.
Does anybody have any ideas for me? I'd appreciate it a lot
Note: This question purposely is phrased very similarly to this SO post.
Solution: Switch to the more recent Google API – Google VR – with which it is possible to embed spherical 360° images in a view instead of starting an activity through an intent, which one has no control of.
Note: The API is still labeled experimental but being part of the VR API this looks like the library being actively developed.
Another advantage: This is open source while the older Google Panorama API is part of google play services, which is not.
PS: Before I looked into these libraries I tested PanoramaGL and OpenPanodroid. Both libraries are not maintained for years and it was no big suprise the results could not keep up with the Google libraries.
thanks for checking my question out!
I'm currently working on a project using Qt C++, which is designed to be multi-platform. I'm a bit of a newcoming to it, so I've been asked to set up the ability to take screenshots from within the menu structure, and I'm having issues with the Android version of the companion app.
As a quick overview, it's a bit of software that send the content of a host PC's screen to our app, and I've been able to take screenshots on the Windows version just fine, using QScreen and QPixmap, like so:
overlaywindow.cpp
{
QPixmap screenSnapData = screenGrab->currentBackground();
}
screenGrabber.cpp
{
QScreen *screen = QGuiApplication::primaryScreen();
return screen->grabWindow( QApplication::desktop()->winId() );
}
Unfortunately, Android seems to reject QScreen, and with most suggestions from past Google searches suggesting the now-deprecated QPixmap::grab(), I've gotten a little stuck.
What luck I have had is within the code for the menu itself, and QWidget, but that isn't without issue, of course!
QFile doubleCheckFile("/storage/emulated/0/Pictures/Testing/checking.png");
doubleCheckFile.open(QIODevice::ReadWrite);
QPixmap checkingPixmap = QWidget::grab();
checkingPixmap.save(&doubleCheckFile);
doubleCheckFile.close();
This code does take a screenshot, but only of the button strip currently implemented, and not for the whole screen. I've also taken a 'screenshot' of just a white box with the screen's dimensions by using:
QDesktopWidget dw;
QWidget *screen=dw.screen();
QPixmap checkingPixmap = screen->grab();
Would anyone know of whether there was an alternative to using QScreen to take a screenshot in Android, or whether there's a specific way to get it working as compared to Windows? Or would QWidget be the right track? Any help's greatly appreciated!
as i can read in Qt doc : In your screenGrabber.cpp :
QScreen *screen = QGuiApplication::primaryScreen();
return screen->grabWindow( QApplication::desktop()->winId() );
replace with :
QScreen *screen = QGuiApplication::primaryScreen();
return screen->grabWindow( 0 ); // as 0 is the id of main screen
If you want to take a screenshot of your own widget, you can use the method QWidget::render (Qt Doc):
QPixmap pixmap(widget->size());
widget->render(&pixmap);
If you want to take a screenshot of another app/widget than your app, you should use the Android API...
I'm using Cordova 3.5 to build an app which contains a menu with pretty standard items in the list (home, contacts, etc.), and I want to use the native menu icons whenever possible. I believe those icons are already on the device as part of the OS, but I don't know if Cordova gives me a way to reference them.
I suppose I'd need to write a Javascript function to choose the right file name based on the platform, e.g.:
// this is pseudocode
var icon = '';
if (platform === 'android') {
icon = 'some/path/home.png';
} else {
icon = 'other/path/icon.home.png';
// or maybe a function such as the following exists:
// icon = cordova.getNativeIcon('icon.home.png');
}
$('.selector').css('background-image', icon);
Alternatively, I may be able to make do by referencing the files in CSS, e.g.:
.android .home-icon {
background-image: url('some/path/home.png');
}
.ios .home-icon {
background-image: url('other/path/icon.home.png');
}
So, how do folks handle this sort of thing in Cordova? Is there a function I can use to access native icons? Are folks just copying them into their projects? What's the best practice?
If you're working with Cordova, then you'll be working inside a web view provided by the host OS and you won't have direct access to any artwork. I've found that using icon fonts and CSS "themes" to work well enough, but that approach will replicate artwork already provided. There's extra work involved with theming for iOS 6 vs iOS 7 or 8, for example, but it's not as bad as it sounds.
IBM does have an article on partitioning your view between native and web controls, but it sounds a bit cumbersome. More details here: https://www.ibm.com/developerworks/community/blogs/worklight/entry/ios_combining_native_and_web_controls_in_cordova_based_applications