The one *MAJOR* gotcha on mobile is that Android does not support standard
KeyboardEvents for soft keyboards (external keyboards work fine).
Working around this problem requires jumping through major hoops.
If your app does not need to deal with KeyboardEvents directly, this is not an
issue.
This is a problem to some degree on all browsers and this is not specific to
Royale. I do wonder if there’s some way to abstract the problem away (or
minimize it) in Royale.
Harbs
> On Nov 3, 2017, at 12:58 AM, Harbs <harbs.li...@gmail.com> wrote:
>
> FYI, My PrintUI app supports touch events.
>
> Eventually, we’re going to change the UI (i.e. simplify some things) for
> phones, but right now, the UI works fine for both desktop and tablets.
>
> The touch support was added by using hammer.js.[1]
>
> The basics for adding that support was basically:
>
> #1 detect whether the browser supports touch. (Non-touch displays are simpler
> and I’m enabling a couple of extra features):
> if (('ontouchstart' in window) || window["navigator"]["maxTouchPoints"] ||
> window["navigator"]["msMaxTouchPoints"]) {
> getHammer(background);
> } else {
> window.addEventListener('mouseup', handleMouseUp, false);
> background.addEventListener(MouseEvent.MOUSE_MOVE,handleMove);
>
> background.addEventListener(MouseEvent.MOUSE_DOWN,handleBackgroundMouseDown);
> background.addEventListener(MouseEvent.DOUBLE_CLICK,handleDoubleClick);
> }
>
> This sets up the touch events. “grubbyFingers” is to give the hammer events
> more “play” because fingers are less precise than mice.
>
> private static function getHammer(background:UIBase):void{
> background.element.addEventListener('touchstart',
> function(ev:Object):void {
> // the user touched the screen!
> trace(ev);
> grubbyFingers = true;
> ev["preventDefault"]();
> }, false);
> var hammer:Object = new window["Hammer"](background.element);
> var enable:Object = {"enable":true};
> hammer["get"]('pinch').set(enable);
> hammer["get"]('rotate').set(enable);
> hammer["get"]('press').set({"time": 0});
> hammer["get"]('pan').set({"direction":30});//Hammer.DIRECTION_ALL
>
> hammer["on"]("pan", handlePan);
> hammer["on"]("panstart", handlePanStart);
> hammer["on"]("panend pancancel", handlePanEnd);
> hammer["on"]("pinch", handlePinch);
> hammer["on"]("rotate", handleRotate);
> hammer["on"]("tap", handleTap);
> hammer["on"]("press", handleTouchStart);
> }
>
> That’s it. The rest is just handling the specific events.
>
> I was trying to consider how to add native touch events natively to Royale,
> but it seemed like a really hard problem and the hammer.js library solves it
> nicely.
>
>
> Harbs
> [1]http://hammerjs.github.io/ <http://hammerjs.github.io/>
>
>> On Nov 2, 2017, at 11:23 PM, Carlos Rovira <carlosrov...@apache.org
>> <mailto:carlosrov...@apache.org>> wrote:
>>
>> Hi Alex,
>>
>> my opinion here is different, since making different libraries for the same
>> purpose make the user task more complicated.
>> For example, for the case commented of touch vs mouse we could have only
>> one button component that will use conditional compilation to get mouse for
>> desktop and gestures for mobile. If not users ends with the need to create
>> different applications for each platform, and is in our hands to avoid that.
>>
>> Some cases are easy, the button case could have different representations
>> in size thanks to CSS, but others are more complicated. Is the case of
>> DateChooser vs DateSpinner, but I think we should get a Date component that
>> could get both behaviours depending on what platform targets without the
>> need for the user to have different applications or the need of declare
>> different components.
>>
>> Nowadays, to make an application to target different platforms and devices
>> is a nightmare, and if we make people to follow the same path we have in
>> Flex, we are not getting any improvement in that workflow. I think Flex
>> choose that path due to the implications already in place, the mx and spark
>> components where made before the mobile era, and was not prepared for that.
>>
>> We are planning the components in this days and we could change that.
>>
>> At least, for me this would be another key factor to choose Apache Royale
>> over other solutions.
>>
>> Just my 2cnts...
>>
>>
>> 2017-11-02 22:00 GMT+01:00 Alex Harui <aha...@adobe.com.invalid
>> <mailto:aha...@adobe.com.invalid>>:
>>
>>> I agree that some components in Mobile.swc could be moved elsewhere and
>>> used on desktops, but I thought there would be library of mobile
>>> components that default to different interaction models (gesture vs
>>> mouse). Flex had some mobile-specific components (ToggleSwitch,
>>> DateSpinner, etc). I thought their swipe interactions wouldn't work for a
>>> desktop with a mouse.
>>>
>>> Of course, I could be wrong...
>>>
>>> -Alex
>>>
>>> On 11/2/17, 7:46 AM, "carlos.rov...@gmail.com
>>> <mailto:carlos.rov...@gmail.com> on behalf of Carlos Rovira"
>>> <carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com> on behalf of
>>> carlos.rov...@codeoscopic.com <mailto:carlos.rov...@codeoscopic.com>>
>>> wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> thanks, I think would be great to have that in mind to avoid extra efforts
>>>> for users.
>>>> As applications are wired nowadays it would be bad for us if we have
>>>> separate component libraries
>>>> to target different devices. We should try to make differentiations in the
>>>> components and we have
>>>> varios tools here (CSS, AS3 logic, conditional compilation,...)
>>>>
>>>> Thanks!
>>>>
>>>> 2017-11-02 15:36 GMT+01:00 Peter Ent <p...@adobe.com.invalid
>>>> <mailto:p...@adobe.com.invalid>>:
>>>>
>>>>> (copied from another email thread; this one seems more appropriate).
>>>>>
>>>>> I created the Mobile kit. I did it separately because it was supposed to
>>>>> mimic how UINavigationController, UIViewController, and UITabController
>>>>> work on iOS (which I'm more familiar with than Android). But there is
>>>>> nothing specific in that kit (that I remember) which ties it to a mobile
>>>>> device. That's opposed to Storage kit, which is dependent on AIR to
>>>>> provide a file system on the SWF platform.
>>>>>
>>>>> I think once we look into refactoring the packages, a lot of Mobile
>>>>> could
>>>>> be moved out.
>>>>>
>>>>>
>>>>> ‹peter
>>>>>
>>>>> On 11/2/17, 8:48 AM, "carlos.rov...@gmail.com
>>>>> <mailto:carlos.rov...@gmail.com> on behalf of Carlos
>>>>> Rovira"
>>>>> <carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com> on behalf of
>>>>> carlosrov...@apache.org <mailto:carlosrov...@apache.org>> wrote:
>>>>>
>>>>>> Hi, I think we should not differentiate between desktop and mobile. We
>>>>>> should make components ready for both platforms and differentiate
>>>>> desktop,
>>>>>> web, mobile or tablets mainly with CSS for sizes and in some case with
>>>>>> code
>>>>>> (i.e: DateChooser use to behave differently in desktop than mobile)
>>>>>>
>>>>>> 2017-11-02 13:29 GMT+01:00 Yishay Weiss <yishayj...@hotmail.com
>>>>>> <mailto:yishayj...@hotmail.com>>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For now, we would like to have an Apache Royale "ViewStack"
>>>>> equivalent
>>>>>>> but
>>>>>>> we do not know where to start.
>>>>>>> What do you think the parent component should be ? Could you give to
>>>>> us
>>>>>>> some cues ?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> <https://na01.safelinks.protection.outlook.com/?url=>
>>>>> http%3A%2F%2Fabout.me <http://2fabout.me/>%2
>>>>>> Fcarlosrovira&data=02%7C01%7C%7Cf4ef6800329a4b7db4f608d521f0
>>>>> 21cc%7Cfa7b1b5
>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452237602199585&
>>>>> sdata=VJCP0F%2F%2BJ
>>>>>> Qg8fL0GOhl9VQNeocXe0y0flc2rpAYhgRI%3D&reserved=0
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>> <https://na01.safelinks.protection.outlook.com/?url=>
>>> http%3A%2F%2Fwww.codeo
>>>> scopic.com
>>>> <http://scopic.com/>&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d52200
>>> 8a29%7Cfa7b1b5a7b
>>>> 34438794aed2c178decee1%7C0%7C0%7C636452308073997718&
>>> sdata=AoQM%2FPoQcuzZB9
>>>> A8wnYhLM2zASMZJpD0%2BYrYgZt6Y44%3D&reserved=0>
>>>>
>>>> Carlos Rovira
>>>>
>>>> Director General
>>>>
>>>> M: +34 607 22 60 05
>>>>
>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>> <https://na01.safelinks.protection.outlook.com/?url=>
>>> http%3A%2F%2Fwww.codeos
>>>> copic.com
>>>> <http://copic.com/>&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d52200
>>> 8a29%7Cfa7b1b5a7b3
>>>> 4438794aed2c178decee1%7C0%7C0%7C636452308073997718&
>>> sdata=AoQM%2FPoQcuzZB9A
>>>> 8wnYhLM2zASMZJpD0%2BYrYgZt6Y44%3D&reserved=0
>>>>
>>>>
>>>> Conocenos Avant2 en 1 minuto!
>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>> <https://na01.safelinks.protection.outlook.com/?url=>
>>> https%3A%2F%2Favant2.e
>>>> s%2F%23video&data=02%7C01%7C%7Cbcb3ac6792ea438a74c208d52200
>>> 8a29%7Cfa7b1b5a
>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452308073997718&
>>> sdata=GUD86EBdmMhJ9Y
>>>> zcRriunwvdGrigIefR85kK2bydDx4%3D&reserved=0>
>>>>
>>>>
>>>> Este mensaje se dirige exclusivamente a su destinatario y puede contener
>>>> información privilegiada o confidencial. Si ha recibido este mensaje por
>>>> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>>>> proceda a su destrucción.
>>>>
>>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>>>> comunicamos
>>>> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>>>> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>>>> servicio o información solicitados, teniendo usted derecho de acceso,
>>>> rectificación, cancelación y oposición de sus datos dirigiéndose a
>>>> nuestras
>>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>>>> necesaria.
>>>
>>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira <http://about.me/carlosrovira>
>
