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.
Related
Working on a Project and stuck in an Issue:
Hardware Back Button Reloading Application (I am using Angular Router in this application).
My Code to Exit Application:
ionViewDidEnter(){
this.subscription = this.platform.backButton.subscribe(()=>{
navigator['app'].exitApp();
});
}
ionViewWillLeave(){
this.subscription.unsubscribe();
}
While same logic Working in other applications. but in this application its reloading the application not exiting it.
P.S: i have also tried it to put in platform.ready() but no luck.
With IONIC 4, there is new method subscribeWithPriority developed to handle race between soft & hard back button. Try modifying your code like below:
this.platform.backButton.subscribeWithPriority(1, () => {
navigator['app'].exitApp();
});
subscribeWithPriority() stops the propagation of the event after its execution and if we subscribe with high priority and execute our prefered navigation instead of default one then it is going to work as you want.
More reference docs for details:
https://github.com/ionic-team/ionic/commit/6a5aec8b5d76280ced5e8bb8fd9ea6fe75fe6795
https://medium.com/#aleksandarmitrev/ionic-hardware-back-button-nightmare-9f4af35cbfb0
UPDATES:
Try using this new version of exitApp cordova plugin. I haven't
tried myself but looks promising from popularity.
Also try to empty the page stack from Navcontroller or go to your home screen, seems like that's causing the reload for app with sidemenu's & tab pages... this.navCtrl.pop() / this._navCtrl.navigateBack('HomeScreen'), and then call exitApp.
NOTE: Tabs & SideMenu as those have its own routing module does create lot of complexity with app navigation.
Solved:
As Mention by #rtpHarry template of SideMenu / Tabs have History which leads application to Reload it self on root page. i was able to solve this by clearing History.
ionViewDidEnter(){
navigator['app'].clearHistory();
}
on Your Root Page just Clear your history and your Hardware Back Button will close the Application instead of Reloading it.
Do you have a sidemenu in your app? I'm just curious because this seems to be when I get this problem as well.
If you look in your inspector, you will see that window.history has a length of 1.
I don't see it in some of my apps, but the app that I have a side menu setup acts this way - on the homepage if you press back the screen goes white then it reloads the app.
Like I say, looking in the inspector shows that there is a history to step back to, which it is trying to do, and whatever that history step is, it just pushes it forward back to the homepage, which made me wonder if it was the sidemenu setting up its own control of the navigation system.
I've probably said some poorly worded terminology but as I haven't solved this myself I thought I would just let you know what I had found... hopefully it helps you move forward.
In my scenario, I wasn't even trying to do the exit on back code - I just noticed that the app would appear to "reboot" if I kept pressing back.
This explain the solution on Ionic 5 (and 4.6+ too I think).
private backButtonSub: Subscription;
ionViewDidEnter() {
this.backButtonSub = this.platform.backButton.subscribeWithPriority(
10000,
() => {
// do your stuff
}
);
}
ionViewWillLeave() {
this.backButtonSub.unsubscribe();
}
also keep
IonicModule.forRoot({
hardwareBackButton: true
}),
to true (default) in your app.module.ts
Sources:
https://www.damirscorner.com/blog/posts/20191122-CustomizingAndroidBackButtonInIonic4.html
The Doc
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).
Testing a Progressive Web Application.
When I start the app in airplane mode, I get an unexpected startup/splash experience (Android/Chrome).
Launch from Home Screen Experience
I see a white screen, followed by a brief flash of the "offline dinosaur" before the app successfully starts and all is well. The startup time is longer than I expected, especially after testing with Chrome Devtools on a laptop, where startup is near instant.
Since it is a little tricky to debug where this time is being spent (especially in the “service-worker-not-running” case), it would be helpful to have some baseline knowledge:
Launch from Browser Experience
Just a brief flash of the "offline dinosaur" before the app successfully starts. Starts much faster.
Questions
What is the expected startup time and experience on Android/Chrome?
Is the experience described above just the current state of things (11/2015)?
Is there any way to specify the startup (splash) experience for Chrome? (I'm aware of background color and 144x144 icon in app manifest for splash, but for Opera only)
First time PWA for me, so any information on this would be helpful.
My platform:
Samsung GS 5,
Android 5.0,
Chrome 46.0.2490.76
The reason for the existence of the splash screen is because on mobile it can take over a second to start the render process so we paint something (the background colour and icons) util you have a first paint generated by your app.
If you are seeing a white screen on startup it might be because you added to the homescreen prior to Chrome landing (46) the splash screen feature. Some things to lookout for:
Ensure your manifest has a short_name and name
Ensure your start_url is in the same scope as a SW that is registered on the page
Have good icons in the manifest ideally > 192px
Set background_color in the manifest to the color of your background on the page (ideally.) This will ensure that the splash screen is the expected colour of your site.
You shouldn't see the offline dinosaur at all, even when you are in aeroplane mode. Airhorner should represent the ideal experience: Blue splash screen with an icon that morphs into the display of the app.
re: Icons - I recommend actually 192px icon or higher.
Regarding the offline-dino flash:
I was using sw-toolbox and performing asynchronous work to setup route handlers at worker startup. This caused an offline dino flash when the application was offline and starting up.
To avoid that, set a sw-toolbox default handler that waits for the asynchronous route handler setup to complete.
var toolbox = require('sw-toolbox');
var setupPromise = someAsyncHandlerSetup()
.then(function () {
// make default handler temporary, allows other fetch handlers (like sw-precache, for example)
toolbox.router.default = null;
});
// until the async handler setup is done, provide a default handler
// to avoid an offline-dino flash when starting up while offline.
toolbox.router.default = function defaultHandler (request) {
return setupPromise.then(function () {
var handler = toolbox.router.match(request);
if (handler) {
return handler(request);
}
throw new Error('default handler could not handle ' + request.url);
});
};
I will try to explain this as clearly as possible. I have an android app using web view to basically load a webpage as my app. I have everything working great, however the back button seems to be an issue. I have set this page up all on one html page, it will load in a div when certain buttons are clicked to give the feel of a new page without actually having one. I basically want the back button (on the android tablet or smartphone) to load the previously loaded div, but I have no idea where to start with this. Here is what the content switching jquery looks like -
function contentSwitcher(settings){
var settings = {
contentClass : '.contentToLoad',
navigationId : '#sideMenu',
servFront : '#clickHomeHome'
};
//Hide all of the content except the first one on the nav
$(settings.contentClass).not(':first').hide();
$(settings.navigationId).find('li:first').addClass('active');
//onClick set the active state,
//hide the content panels and show the correct one
$(settings.navigationId).find('a').click(function(e){
var contentToShow = $(this).attr('href');
contentToShow = $(contentToShow);
//dissable normal link behaviour
e.preventDefault();
//set the proper active class for active state css
$(settings.navigationId).find('li').removeClass('active');
$(this).parent('li').addClass('active');
//hide the old content and show the new
$(settings.contentClass).hide();
contentToShow.show("slow");
});
}
contentSwitcher();
});
note: I've cropped out a bunch of it just to show how it works on a basic level.
Does anyone have any suggestions as to where to begin. I'd just like the back button function to be able to maybe check a started previous div name stored somewhere and load that.
thanks!
You can try using the History API. There are numerous tutorials on the web e.g. this one is quite good:
http://diveintohtml5.info/history.html
Basically this is how it works. When the user clicks the link for the div to show you push the state to the history stack.
history.pushState({<object with any information about state>}, pageTitle, newUrl);
This will push the state to the history stack meaning that when the user presses the back button on any modern browser like webkit it will take that state into consideration. When back action is taken it will then pop the state from the history stack. This action you have to listen to and handle in any way you see fit:
window.addEventListener("popstate", function(event) {
// event object contains the information from the pushed state
// do whatever needed to load the previous page here
});
The History API requires you to structure your code in a certain way for it to work well. For this I would recommend to use some existing framework that handle the back events for you e.g. Backbone.js. Hope this helps.
I am now working with Android UiAutomator on for UI Test on my Android app. My app has a function that requires the user to verify the email to continue, so I try to do it like this: after reach to that function -> getUiDevice.pressHome -> Browser -> try to log in email -> PressHome again -> Press RecentApps then I stuck here, I cannot press on my Apps to return to it again. I try another way by clicking on my App icon but it starts my app again, not at the state before. Can anyone suggest me a solution for this? Any help is appreciate.
Thanks in advance.
Try this :
UiObject appBackground = new UiObject(new UiSelector().description("ABC"));
appBackground.click();
It did not show any description through 'uiautomatorviewer' command but this worked for me.
I could manage to create this behavior with:
fun backgroundAndForeground() {
val device = UiDevice.getInstance(getInstrumentation())
device.pressHome()
// Pressing app switch two times makes the last app put on background come to foreground.
device.pressKeyCode(KeyEvent.KEYCODE_APP_SWITCH)
device.pressKeyCode(KeyEvent.KEYCODE_APP_SWITCH)
}
In this case, I think that android only resume app when clicking the recent app image. It does not work on clicking display text or app icon. So, we need to click image of your app in recent app list. At that time you need to write as below. I always do that for similar case.
// Take all image view by class type and click by instance no.
new UiObject(new UiSelector().className("android.widget.ImageView").instance(3)).click();
You need to count instance no of your recent app image view. Not app icon image in recent app scroll view. Please try this. Thanks.
I've spent half a day on this and concluded I needed to issue a device.click(). Since my use-case is that my app was the last one running (not switching to the browser like you), I can safely click the middle of the screen and it'll always work.
If you're the 2nd to last running app, you can probably do x: 0 and y: device.displayHeight/2.
I've not tested this on many operating systems, only 9.