@DBear
As usual You create such elegant solutions: In a small bit of code the need for checking for mobile devices is removed; the scene notice (i.e. scene named “alert”) is far better than creating an extra layout per scene, or even (as I was going to suggest), using a persistent symbol for the warning.
There is one thing in your coding that I felt penalized viewers. If they are deep in the scene navigation and, for what ever reason, rotate their device to landscape - your code requires them to start from scratch. No matter of consequence if returning to the scene is a click away (e.g. a button~menu selection) but if it is a progressive endeavor, it might be frustrating. The attached example let’s the viewer return to the scene at which they rotated their device to landscape - otherwise everything else is your code.
Note: There is no "location.reload();" as in your code - I just return to the “var bookmarkScene” - (hypeDocument.showSceneNamed(bookmarkScene) which seems to work.
I am a “designer that codes” & I have read and plowed through a plethora of intricate~dense monographs over many years; but the concise, lucid way You present solutions I think is exceptional; might You possibly consider curating the knowledge You have shared on this Forum in (digital) book form?
It is not just a matter of knowing the code - it is the strategies - that take things to another level; and this is the type of insight that is so often the essence of the questions on this Forum.
Brilliant! very concise code that does so much. The idea of the incremental variable is cool. It takes care of the recursion issue. I just have one issue now - when there are more than one scenes then the location.reload() takes you to the first scene irrespective of the scene the user was on. See attached hype doc.
So I guess we might have to revert to storing the scene name. Or maybe there is another way?
Also wanted to know if “hype reflect” has an issue with the event listener. When i try it in larger projects with more scenes reflect’s screen turns blue and I have to test the site on safari for mobile instead. Anyone facing this issue?
I'll refer you to the post above as you may have missed it. I was just thinking of 1 page when I did my tweak but as @JimScott has done indeed you can use Hype's API to capture the scene name when it loads and instead of "re-loading" the entire document you can just show the same (or bookmarked) scene. Jim has given an example with the change
One thing to add and it's just to help with not having to add 2 functions in every scene and that is to condense it all into one.
So here is the final code Jim's addition all in one function you can run on scene load
// addition by @JimScott (http://forums.tumult.com/users/JimScott)
var bookmarkedScene = hypeDocument.currentSceneName();
var V=0;
// function for the check
var detect = function () {
if (window.innerWidth > window.innerHeight && window.innerWidth < 1200 && V==0) {
hypeDocument.showSceneNamed('alert');
V++;
}
}
// call this immediateley to check if user is already in landscape mode
detect();
window.addEventListener('orientationchange', function() {
// on orientation change take user back to the scene
hypeDocument.showSceneNamed(bookmarkedScene);
});
When we change orientation to landscape the alert scene does not get triggered. And it gets trigerred when we switch back to portrait! This happens when we start off in portrait mode.
And if we start of in landscape mode then it shows alert scene but if we switch orientation, the alert scene remains on scene.
Have you set your viewport width to "device width" in the document inspector?
BTW @JimScott it has been considered however time is the enemy of us all and I feel I haven't got the time to do that just now.
I am a "designer that codes" & I have read and plowed through a plethora of intricate~dense monographs over many years; but the concise, lucid way You present solutions I think is exceptional; might You possibly consider curating the knowledge You have shared on this Forum in (digital) book form?
It is not just a matter of knowing the code - it is the strategies - that take things to another level; and this is the type of insight that is so often the essence of the questions on this Forum.
Thanks @DBear
The script works on a test project but when we tried using it on a production site it had a serious issue. After three to four orientation changes the scenes start getting sluggish and the alert scene loads several seconds after the actual orientation change and the browser even freezes after that.
Any idea what could be wrong? Tried to remove event listener on scene unload but even that didnt solve the sluggishness that happens after orientation changes in 3-4 scenes.
Just wondering if the persistent symbol idea is easier.
This has a persistent symbol hidden on each scene.
The Symbol runs the JS function.
// call this immediateley to check if user is already in landscape mode
detect();
window.addEventListener('orientationchange', detect );
function detect(){
console.log("here");
var thisSymbol = hypeDocument.getSymbolInstanceById('alert');
if (window.innerWidth > window.innerHeight && window.innerWidth < 1200 ) {
hypeDocument.triggerCustomBehaviorNamed('alertShow')
} else {
hypeDocument.triggerCustomBehaviorNamed('alertHide')
}
}
To save messing about with getting a symbols instance I just created to two custom Behaviours alertHide, alertShow.
Which runs the symbols ‘alert’ timeline.
The timeline uses the display property to show or hide the alert rectangle.
@sgibm - Once You get us rollin’ there is no stopping us ;->
I did not have an issue with @DBear’s scene based approach to the rotation warning until I hit the 5th or 6th rotation in immediate succession which seems to be an excess unlikely to be done in “real life”. However…
As @MarkHunte suggested above, and I also mentioned in a previous post: using the persistent symbol.
I already created the following project yesterday, but when I read D’Bear’s post I felt it was a simpler implementation for the desired effect and so did not publish this example using a persistent symbol: orientationTest_JHSv3a.hype.zip (43.8 KB)
Mark’s version certainly does the job well. The version I have posted includes the visual block of the content underneath & does not use a timeline. I have given it the torture test rotating it from one orientation to another over 20 times in immediate succession using all three scenes in the project - and as with Mark’s there is no sluggish behavior.
@sgibm - hopefully You will find something in these posts that works for You!
Edit Note: Replaced the “working” project originally uploaded here with a new version (v3a) that has the code cleaned up and extraneous bits & pieces removed.
Thanks @MarkHunte Nice use of behaviors. One isse i noticed is that in the first orientation change on scene 1 the red alert box appears below the blue box and button but subsequently on further orientation changes to landscape it fills up the screen. Any idea why this could be happening?
I will test this concept on some production site with more scenes etc. and update…
Thanks @JimScott. Really appreciate your input, time and effort and of @DBear, @MarkHunte who have contributed so much. I have learnt a lot and have found all approaches useful. I will test this concept in a production site and update if there is any issue.
On testing some of the approaches above i noticed that chrome on ios had issues with proper triggering of the orientationchange event listener. I tried resize in its place and it worked but it created other issues on pages with forms etc which automatically resize.
Is there any other alternative to make orientationchange work in chrome for ios?
Another issue I hit was that the alert pages sometimes loaded automatically zoomed in and when the orientation was changed back to portrait the portrait scene was also automatically zoomed in and after that it freezes. This happens on chrome for ios again. Any ideas/solutions?
What would be great is if in the Layouts section, one could specify both a Portrait AND a Landscape layout per tagged breakpoint where each would be triggered based on device orientation. The transition between each orientation could in itself trigger a mini-scene. Also, with either layout, different content/user capability could be enabled.
To be concise, the behind-the-scenes orientation management should be handled by Hype, not the user/developer/designer.
Not easy to do, you should add media query by pixel ratio / pixel density and not only by length.
This mean a lot of combinations; not only the IOS family but at least 10 other android devices. Moreover the iPad Pro is an hybrid with size like a laptop. In IOS devices some functions are not the same as the desktop ( parallax, fixed positions and so on) .
...difficult to manage, sorry but I see it really impossible
For the next version of Hype, I have added an API to allow developers to override Hype's behavior and make their own decisions on which layout to show when. Maybe there will be a common solution that can be shared (and then I can think of how to add it to Hype). Part of the "not easy to do" has to do with there being so many decisions that code is sometimes the best representation. I'm not sure that is the case here, but for now it will be flexible to allow any behaviors.
