• 1
  • 29
  • 30
  • 31(current)
  • 32
  • 33
  • 122
Beta Testflight access to beta version
Finally someone who uses the gesture zone pad. Smile
As I changed the gesture zone handling since the last builds: Can you try to install older TF builds and check if the issues — especially the last one — were introduced with a certain version? Of special interest is the transition from build 2661 to 2715.
Reply
No need to test on your side. I could check your observations this morning.
(2021-11-08, 01:00)amasephy Wrote: 1) Tap Remote control ...
This was already fixed with the change I provided two days back. It's just not provided in a TF build.
(2021-11-08, 01:00)amasephy Wrote: 2) ... trying to swipe it does not work.
Fixed this.
(2021-11-08, 01:00)amasephy Wrote: 3) ... So definitely wouldn't want this screen removed.
Good, nothing to do then. Smile
(2021-11-08, 01:00)amasephy Wrote: 4) I also found another inconsistency ... Its hyper sensitive.
This seems to be a common configuration inside the sliding view controller. I can try to figure out where this is done. Should both pan gestures behave same (e.g. only executing swipe when >50% of screen is already swiped)?
(2021-11-08, 01:00)amasephy Wrote: 5) I actually just tested this and it’s a major problem with the gesture pad being set as the default in the app settings. It actually doesn’t work!
Same as 1). Fixed, but not yet provided in a TF build.
Reply
@Buschel

For the swipe gesture I’m not sure what would work best. I think there are a few things to consider.

I compared swiping in Safari and there if you swipe slowly left or right you do need to hit that 50% mark for the gesture to pass through. This makes sense for slow swiping.

Most apps seems to allow flicking and in those cases requiring 50% is too strict. There must be some way to detect the acceleration of the swipe. I would say probably best to mimic what Safari uses as that has been my experience in most apps.

However, something else to consider. I noticed this before but didn’t think it that big of a deal but since you’re looking at this may as well bring it up.

Most apps require the swipe gesture to originate somewhere near the screen edge. This app however does not in certain spots. For example on the remote control view you can pretty much touch anywhere on the screen and swipe and the swipe gesture is activated. I’m not exactly against this but it’s also not my normal experience in other iOS apps. Maybe some tweaks could be implemented as a test to see how it feels with Safari style swipe gestures?

Another implication of swipe anywhere is you can degrade this apps performance by being in the remote control view and swiping left and right back and forth without letting go. For lack of a better term the app feels like it’s hiccuping while bringing up the left panel and the right settings screen in rapid succession. I bet this is because these screens are initialized freshly each time they’re viewed and there wasn’t ever a way to quickly and seamlessly bring up both screens from a single back and forth swipe gesture. So it wasn’t really designed to handle this.

Sometimes you can swing the remote control back and forth quickly enough you will find that it gets stuck in place and might not be able to slide all the way back to center itself until you let go of the screen.
Reply
The pan / slide view handling is done by a component named ECSlidingViewController. In fact, the swipe is not connected to how much you move the screen, but it is depending only on the velocity of the change. You can for example swipe very slowly from left to right more than 50% of the screen width and the screen will still snap back to the initial state. The reason why the same does not work properly when sliding from right to left is a simple wrong signedness when checking the condition to execute the swipe. This error in signedness causes the check to always result in performing the swipe even on minor movements/velocities. I can fix this to have a consistent behaviour when swiping left or right.
Reply
1.8.2 build 2834
Release Notes

This build mainly provides bugfixes of the issues reported in this thread earlier. @amasephy, @UlfSchmidt, would be great if you could check the problems you saw around pan gestures, unwanted round corners or year "0".
Reply
@Buschel,

I noticed this update just before you posted it here. I must be an addict.

So I’ve done a few quick tests and I’m noticing several things.

1) Main remote control - gesture zone enabled as default, swipe gesture is disabled now as you intend.

2) Quick remote icon remote control - gesture pad enabled, you are actually able to swipe back to the left pane. I don’t believe you intended for this. You are not able to swipe to the right “settings” pane. Honestly, I know you said someone said it conflicted with the gesture pad but I’m not seeing an issue. The gesture pad works fine. You only swipe back to the left pane if you start the swipe from the edge of the screen. Despite not being what you intend I honestly like it the way it is.

3) Any remote control view (main and the quick remote icon) - Gesture pad enabled, and you are on the settings pane on the right, you can’t swipe back left to the partially visible remote.

3a) If you are still on the settings pane and you tap “more” and then Done, you are now able to swipe back to the partially revealed remote control. It will continue to allow you to swipe back upon repeat settings pane views until you toggle the remote back to buttons and then back to gesture pad. Whatever setting is getting enabled after hitting “more” is being preserved until the remote type gets toggled.

4) The slide back behavior is now consistent between right and left swipes. However it looks like you have to actually “flick” the pane to pane to the left or right pane. I believe you were going to make it so even if you scrolled slowly left or right as long as it was scrolled over more than 50% it would swipe to the new pane.

5) Not sure if it was on the table but performance can still be degraded if you tap in the middle of the button view remote control and slide it left and right repeatedly revealing the left pane and right settings pane without letting go of the initial tap. The app chugs when revealing each adjacent pane while the remote slides between them.

6) The quirky “double scroll back” animation is fixed in both spots I encountered it.


That’s all for now. Will test more later. Things are looking better! Thanks for pushing out a new beta so quickly.
Reply
(2021-11-11, 21:08)amasephy Wrote: 1) Main remote control ...
6) The quirky “double scroll back” animation is fixed in both spots I encountered it.
Great, thanks Smile
(2021-11-11, 21:08)amasephy Wrote: 2) Quick remote icon remote control ...
Yes, I am aware of this. This works ok this way and I will leave it. The not supported swipe right (to settings) is not even intended. Overall I aim for getting rid of this special screen and just use the plain remote screen, like if you enter the remote from another menu.
(2021-11-11, 21:08)amasephy Wrote: 3) Any remote control view (main and the quick remote icon)
3a) If you are still on the settings pane and you tap “more"
Weird. Not sure why this is not working for the first time. I was sure I tested this up and down...
(2021-11-11, 21:08)amasephy Wrote: 4) The slide back behavior is now consistent between right and left swipes.
The behaviour for swipe from left to right is unchanged. No code was touched. I am just treating it the same for swiping right to left. I do not plan to change the code to support the swipe-when-moved-more-than-50% feature. This is not supported by the current code as far as I can see.
(2021-11-11, 21:08)amasephy Wrote: 5) Not sure if it was on the table but performance can still be degraded ..
Nope, was not on the table.
Reply
Sounds good. If I’m reading it correctly, the removal of that settings screen will get rid of a lot of kinks.

As for that scroll 50% behavior we talked about, I did just realize an inconsistency but maybe it’s intended.
If you are on the remote screen and you slowly swipe left or right and let go it slides back into place, as you said it would. However, once the remote is in a partially revealed state, like when viewing the left pane or the settings pane, even the shortest slow swipe to the remote and letting go will pull it back into focus. No flick needed. It’s nothing that bothers me at all, just pointing it out.
Reply
I found a way to get the swipe left to right working again when entering the custom button screen for the first time (your issue 3a). I really hope this is it and the behaviour is ok for users. This is a much less complex and simple solution with less logic. The solution is quite simple: Always allow the pan gesture for the full screen, but ignore panning attempts when the gestureZone was touched. This is similar to what the iPad handling looks like, and it allows to remove lots of the logic which handled the state of the remote screen. But I need to test this now before it is going into a build -- also on iPad. I do not expect any drawback as all the SlidingViewController stuff is related to iPhones only, but tests are needed now.

The swipe behaviour you describe is how it is implemented in the sliding view controller. It is just reading the acceleration of the last move before you release the touch. Therefore you can move it around slowly before without any impact. But a quick move at the end is then triggering the swipe.

I also found another weird behaviour which seems to be there forever (tested with 1.6 as well): If you enter the Remote screen or the NowPlaying screen from the main menu and then make a gesture starting left of the screen and only a very small part into the active screen, the App will jump back to main menu and select the menu item which was under the screen. Until now I have no idea where this is coming from. But: I will for now not bother too much about it. It is obviously there since ages.
Reply
@Buschel

I can test on iPad. I’ll install it on my iPad once you release the next beta.

As for the returning and selecting the main menu item, I couldn’t figure out how you trigger this bug.

I tried just slightly moving the remote to the right, thus starting to reveal the left pane menu and nothing unusual happens. Maybe I’m misunderstanding.
Reply
(2021-11-11, 20:31)Buschel Wrote: 1.8.2 build 2834
Release Notes

This build mainly provides bugfixes of the issues reported in this thread earlier. @amasephy, @UlfSchmidt, would be great if you could check the problems you saw around pan gestures, unwanted round corners or year "0".
Cannot talk about gestures, since I am still not using these. But I can confirm that the unwanted rounded corners are gone! Smile

With respect to year 0, it looks already much better but not everywhere:
Image

Maybe you can also suppress zeros in the lists and in the REGIE fields?
Thanks @Buschel for looking again into this!
Reply
(2021-11-12, 18:08)UlfSchmidt Wrote: With respect to year 0, it looks already much better but not everywhere:
Ok, I was only treating the "number" type and not the "string" type. I added this to an existing PR.
(2021-11-12, 18:08)UlfSchmidt Wrote: Maybe you can also suppress zeros in the lists and in the REGIE fields?
Yes, I can. Also added to an existing PR (the REGIE field is now even completely removed, if no proper data is provided like in your "- (0)" case).
Reply
@Buschel

I thought I was going crazy while looking at this this morning only to realize a new beta was installed without my knowledge while I was testing!


So my previous #2 where the gesture pad enabled and swiping back to the left main menu pane - this is now disabled from yesterday’s beta. I thought I read you wanted to keep it as it was but it changed from yesterday.

For #3 and 3a) This is exactly the same as it was on yesterday’s beta. Still seems to be broken.
Reply
(2021-11-12, 17:56)amasephy Wrote: I tried just slightly moving the remote to the right, thus starting to reveal the left pane menu and nothing unusual happens. Maybe I’m misunderstanding.
You just let go before the screen is starting to move. But maybe this is just working in my simulation with the precise mouse movements, and it doesn't happen in real life with real fingers. Smile
Reply
(2021-11-12, 18:53)amasephy Wrote: For #3 and 3a) This is exactly the same as it was on yesterday’s beta. Still seems to be broken.
Yes, the changes are in an open PR and not merged or released yet.
Reply
  • 1
  • 29
  • 30
  • 31(current)
  • 32
  • 33
  • 122

Logout Mark Read Team Forum Stats Members Help
Testflight access to beta version0