added HapticFeedback

[dimonovdd]

Description of Change

Added support for" HapticFeedback " for iOS, Android, and UWP.
But I couldn't test on UWP because I don't have a device that supports " HapticFeedback"

I hope I have correctly created a pull-request

[msftclas]

All CLA requirements met.

[Redth]

Hey @dimonovdd this is a good looking addition. Are you willing to add tests and docs for this?

[jamesmontemagno]

One question I have is how different is it from "Vibrate" api.

[mattleibow]

I am thinking the same as @jamesmontemagno... Maybe it might be better to merge this?

Also, UWP is using the same named device, but a different entirely. The one we have is from phone and this one is from UWP general. I think we should keep both, or even drop phone since that is dead now.

[Redth]

I think it makes sense to bring this into the Vibrate class perhaps as:

public static class Vibration
{
    public static void HapticFeedback(HapticFeedbackType type = HapticFeedbackType.Click)
}

[dimonovdd]

@Redth @jamesmontemagno @mattleibow
I believe that vibration and hapticFeedback are different things and should not be merged. But I can trust your experience and do that.

I will write the documentation this weekend, but there is a problem with the tests, I have never written them, but I will try.

Tell me what else needs to be done.

[mattleibow]

@dimonovdd I think what we are more saying is that "vibrate" and "haptic feedback" are not the same, they are similar enough for the simplicity of Essentials.

I think it is fine to have Vibration.Vibrate(TimeSpan) AND Vibration.Vibrate(HapticFeedbackType) in the same place. Effectively, the same motors do the thing. And, this will give use the opportunity to "fake" the feedback on platforms. For example, this is only a think in iOS 13, but what happens on iOS 12? Should we fall back to a 500ms "normal" vibrate? I think this is maybe a bigger issue. We MUST merge the ideas because already UWP is broken on non-mobile devices - it can't vibrate because there is no API.

That is why I think not just because they are similar we should merge, but just because we actually need to. When a user does HapticFeedback.Execute() on iOS 12, what should happen? And, when a user does Vibration.Vibrate() on UWP, what should happen? I think there should be a fallback to the same "vibrate a bit".

Any thoughts on that? Anyone?

[dimonovdd]

@mattleibow

I think that the Vibrate Vibrate(HapticFeedbackType) should not be made because it deludes. On iOS and Android the vibration and haptic feedback are absolutely different things, and even if it should be merged, it should not confuse.

on iOS the HapticFeadBack is supported only on devices that support iOS13 starting from iPhone. I haven't found any better way of checking than checking the iOS version which is why I left it that way for now. This is the link of the article

https://stackoverflow.com/questions/41444274/how-to-check-if-haptic-engine-uifeedbackgenerator-is-supported

We'll return to UWP later when we find a more correct way of merging those Vibrate and HapticFeedback

Actually I thought and realized that it's worth writing a method that will determine whether Haptic Feedback is supported on a particular device. I'm going to work out this issue in the nearest future

[dimonovdd]

An example of HapticFeadback is a response when you tap on the keyboard of iOS and Android devices, and if HapticFeadback did not work, in this case the vibration should not be called and even more a vibration for 500ms, the developer himself should decide

[mattleibow]

Looks really good. Just have a few comments, but nothing too big.

[dimonovdd]

@mattleibow @Redth @jamesmontemagno @rookiejava

I apologize for the big amount of text

Now implemented are only the following types of HapticFeedback

Platform	Click	LongPress
Android	ContextClick	LongPress
UwP	Click	Press
iOS	UIImpactFeedbackGenerator Light	UISelectionFeedbackGenerator
Tizen	Tap	Hold

But the platforms have many other different types of response. How do you think which of them we should add to xamarin essentials

Android:

• LongPress
• KeyboardPress
• KeyboardTap
• ClockTick
• ContextClick
• KeyboardRelease
• VirtualKeyRelease
• TextHandleMove

UWP:

• BuzzContinuous
• Click
• Press
• Release
• RumbleContinuous

iOS:

UIImpactFeedbackGenerator :

• Heavy
• Medium
• Light

UINotificationFeedbackGenerator :

• Success
• Warning
• Error

UISelectionFeedbackGenerator

Tizen:

• Tap
• SoftInputPanel
• Key0
• Key1
• Key2
• Key3
• Key4
• Key5
• Key6
• Key7
• Key8
• Key9
• KeyStar
• KeySharp
• KeyBack
• Hold
• HardwareKeyPressed
• HardwareKeyHold
• Message
• Email
• WakeUp
• Schedule
• Timer
• General
• PowerOn
• PowerOff
• ChargerConnected
• ChargingError
• FullyCharged
• LowBattery
• Lock
• UnLock
• VibrationModeAbled
• SilentModeDisabled
• BluetoothDeviceConnected
• BluetoothDeviceDisconnected
• ListReorder
• ListSlider
• VolumeKeyPressed

[mattleibow]

Looks good!

[mattleibow]

@dimonovdd

which of them we should add to xamarin essentials

I think for the first run, lets just keep the two. Once it is merged then we can decide. Unless @Redth or @jamesmontemagno has another opinion?

[dimonovdd]

@mattleibow
I agree.
I can create a issue on this topic.