Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


moOde 4.2 - iOS "App Mode" & 'Players' switching feature
#1
One nice feature of moOde on iOS is the ability to open the UI in safari and to "save to the home screen" so you get an independent instance of safari without address bar and the like. In effect a moode app! I've been using this feature since I started using moode and it is probably how I most often view the UI.

Another cool feature of moOde - which has become functional for me in 4.2 - is the "Players" feature which allows you to quickly switch to the UI of a different instance of moode on your network. This is very slick and a real time saving on occasion.

Now I have two permanent moOde players on my network (and a third occasional player) all v4.2. My two iOS (ipad mini 2, iOS 11.4.1) home screen icons have been there since moode 3.x and both have the older coloured play button moode icon. The other day I decided to delete one and remake it so it had the new icon and would therefore be quickly distinguished from the other. In doing so I uncovered something I think worth reporting.

If I open the player which was saved to home by moode 3.x (old icon) I can use the player switching in the slick manner I expect.
If however I open the player which was saved to home by moode 4.2 when I switch player it opens safari proper and opens a new tab and loads the selected player. A more time consuming and far less desirable action.
I played about and remade the "app" a couple of times but the behaviour was the same. Not good.

As a workaround I flashed a copy of moode 3.7 to an sd, booted it and saved it to the home screen. Lo-and-behold when boot back to 4.2 and use this icon to open the player switching works nicely without opening safari proper. So I have deleted the versions made with 4.2.

On my partners iphone we have one player saved to home from 3.x with the old logo and the other player saved from 4.0 or 4.1 (I can't saw which tbh). Both those behave nicely when using the "Players" switching function suggesting perhaps this is something to do with 4.2?

I can workaround this issue of course but I thought it worth reporting.

As an aside, though the UI has undergone many changes for the better and is clearly sleeker and more minimal now there was something charming about booting into the now seemingly chucky clunky 3.7 UI. Nostalgic!
Reply
#2
Huh, iOS must do some caching of the original page. Now I’m curious what all is in there but not enough to reinstall 3.x. Launching Safari is the default behavior with an anchor tag, but I think we can probably work around it.
Reply
#3
There could be some sort of issue with moOde 4.2 and Add to home screen...

I had created a set of home screen apps on my iPad back in the moOde 4.0/4.1 days (I think) and they have worked fine with 4.2.

Today though I deleted one of them and tried to re-add it and got the error below. I used the Develop feature in Safari to empty cache and reload the page on the iPad just to make sure stale cache was not a contributor.

I had to video the message cuz it disappeared quickly.

   

Maybe this weekend I can load a 4.0 or 4.1 image and see if problem follow the code or not.

-Tim
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#4
(07-28-2018, 01:37 AM)Tim Curtis Wrote: There could be some sort of issue with moOde 4.2 and Add to home screen...

...
-Tim

There's more than one thing going on here.

1. There's a difference between saving a shortcut to the home screen and switching players within the moOde UI. In the first instance, the OS (note that this can be done in iOS and in Android) creates some kind of browser launcher "invoker". Captured in it is the URL which was open at the time and also the site icon. This URL likely includes more than the base URL (see various peoples' cries for help on the Interweb). In the second instance, we are feeding the browser just the base URL.

2. There's a difference between opening the browser via the Home Screen shortcut and opening a new page via Tim's switcher code. I don't have the programming chops to say what that difference but from the Android docs, for example, "Each shortcut references one or more intents, each of which launches a specific action in your app when users select the shortcut." It's patently obvious that the intent referenced in our browser shortcuts isn't the primary action just by looking at the state of the browser when it opens. There's none of the regular interface. I don't know how the machinery works to get to the same state with the switching mechanism.

Not surprisingly, different browsers and different OSes yield different results.

I'm not going to try to reinstall earlier releases of moOde (not sure I still have any) but here's the results of some random tests with current moOde. 

On my iPad, using Safari I'm seeing the same "open new tab" behavior @FizzyTea reported when I switch players from within a moOde UI opened from a home screen shortcut. I can't figure out how to create home screen shortcuts with either Chrome or Firefox, but in each of them switching among players opens the new player's UI in the same tab.

On my Android tablet I get an interesting variation on a theme using Chrome. First I created a home screen shortcut for my primary moOde player. Then I open it. The primary player's UI opens in the restricted interface. Then I switch to a secondary player from within it. The secondary player's UI opens in the regular interface (but no new tab). Now comes the fun bit. If I switch back to the primary player from within moOde, the primary player's UI opens in the restricted interface again! This is true whether or not I also have already created a home screen shortcut for the secondary player.

On my Linux laptop with Chrome, switching among players occurs within the same tab.

Just my USD0.02 worth.

Regards,
Kent
Reply
#5
Hi,

It looks like some oddness in the favicons specified in /var/local/www/header.php.

Try commenting out the bolded lines below and see if it provides a fix on IOS. In my case after this change the "Add to home" popup offers the Add button and allows me to change the name and add it to the home screen :-)

<!-- favicons for desktop and mobile -->
<meta name="apple-mobile-web-app-capable" content="yes">
<link rel="apple-touch-icon" sizes="180x180" href="/v4-apple-touch-icon.png">
<!--link rel="icon" type="image/png" sizes="32x32" href="/v4-favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/v4-favicon-16x16.png">
<link rel="manifest" href="/manifest.json"-->
<link rel="mask-icon" href="/v4-safari-pinned-tab.svg" color="#5bbad5">
<meta name="theme-color" content="#ffffff”>

I use the site https://realfavicongenerator.net to generate the favicons and its producing a slightly different set now then when I last generated them.

Needs more testing...

-Tim
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#6
(07-28-2018, 02:08 PM)Tim Curtis Wrote: Hi,

It looks like some oddness in the favicons specified in /var/local/www/header.php.

...
Needs more testing...

-Tim

Didn't see that one coming Confused

Ok, so now Safari on iPad behaves as expected. Chrome on Android still behaves the way I described.
Reply
#7
I commented out those lines from /var/local/www/header.php

Opening in safari I noticed a white bar at the top of the page with a faint "www" in the left corner.
I saved the UI to the home screen.
I opened the UI from the new home screen icon. (No other home screen icons were saved for this moode)
It displayed the same white bar at the top.
Player switching worked as desired - completely within the restricted independent browser window.
I uncommented the lines from header.php
The UI now displays correctly - no white bar - and player switching still works as desired.

I uploaded a screen cap showing the white bar, it might be of interest.

[Image: B63_FFF25_DE76_4_CCB_87_CC_14_C32669_B2_E8.png]
Reply


Forum Jump: