royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: Mobile vs Desktop diferences in components (Was: Re: Restarting contributions)
Date Thu, 02 Nov 2017 23:43:15 GMT
Alex,

for sizing and look and feel, yes, I propose media queries, I think this is
what makes usable to use the same button component (or checkbox, radio,
tooglebutton,....)
In the other hand there are other issues that should be managed with other
techniques. For example would tooltips be in desktop but no on mobile? Or
dateField would have a layout for desktop and other completly different
with some kind of spinner on mobile? For this kind of different behaviours
I think we would need (far beyond CSS media queries) logic and conditional
compilation.

That's my idea, but maybe other have other point of view

Thanks


2017-11-03 0:07 GMT+01:00 Piotr Zarzycki <piotrzarzycki21@gmail.com>:

> One thought which come up to my mind reading Harbs is - Maybe if adding
> touch  events natively its to hard or a lot of sacrifacies we should
> consider to find solid library for that purpose, but licensed under Apache
> License. Make it part of our effort.
>
> Piotr
>
> On Thu, Nov 2, 2017, 23:58 Harbs <harbs.lists@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 <carlosrovira@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 <aharui@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.rovira@gmail.com on behalf of Carlos
> > Rovira"
> > >> <carlos.rovira@gmail.com on behalf of carlos.rovira@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 <pent@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.rovira@gmail.com on behalf of Carlos
> > >>>> Rovira"
> > >>>> <carlos.rovira@gmail.com on behalf of carlosrovira@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 <yishayjobs@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=
> > >>>> http%3A%2F%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=
> > >> http%3A%2F%2Fwww.codeo
> > >>> 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=
> > >> http%3A%2F%2Fwww.codeos
> > >>> 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%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
> > <https://maps.google.com/?q=estinatario+y+puede&entry=gmail&source=g>
> > 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
> >
> >
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message