What we don't want to do - I think - is to have say <js:DateChooser> loaded with every possible bead and then, at runtime, unload the beads that aren't needed for the platform.
The media query or building separate targets with source+CSS for the target seems like a better, PAYG way. —peter On 11/2/17, 10:00 PM, "Alex Harui" <[email protected]> wrote: >Hi Carlos, > >Because we use CSS to choose beads, I think it might be possible to choose >different views, layouts, etc based on media query. >If there is some other popular way of reconfiguring layouts in JS we can >certainly try to leverage that as well or instead. > >Of course, I could be wrong... >-Alex > >On 11/2/17, 4:43 PM, "[email protected] on behalf of Carlos Rovira" ><[email protected] on behalf of [email protected]> wrote: > >>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 <[email protected]>: >> >>> 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 <[email protected]> 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]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhamme >>>r >>>js.github.io%2F&data=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7 >>>b >>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452630304478314&sdata=j5qU10z8 >>>6 >>>J%2FqdEBGY4Y%2F9GVxJL7Kn5fLXTWDBlG%2FHE8%3D&reserved=0 >>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhammerj >>>s >>>.github.io%2F&data=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7b1 >>>b >>>5a7b34438794aed2c178decee1%7C0%7C0%7C636452630304634559&sdata=%2BPUw7Bj4 >>>v >>>CMpq5YgtSN9Wi5%2Fe5SwlRpXPwvvpZ%2BKBvs%3D&reserved=0> >>> > >>> > > On Nov 2, 2017, at 11:23 PM, Carlos Rovira >>><[email protected]> >>> > 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 <[email protected]>: >>> > > >>> > >> 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, "[email protected] on behalf of Carlos >>> > Rovira" >>> > >> <[email protected] on behalf of >>>[email protected]> >>> > >> 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 <[email protected]>: >>> > >>> >>> > >>>> (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, "[email protected] on behalf of >>>Carlos >>> > >>>> Rovira" >>> > >>>> <[email protected] on behalf of [email protected]> >>> 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 >>><[email protected]>: >>> > >>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.g >>>o >>>ogle.com%2F%3Fq%3Destinatario%2By%2Bpuede%26entry%3Dgmail%26source%3Dg&d >>>a >>>ta=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7b1b5a7b34438794aed >>>2 >>>c178decee1%7C0%7C0%7C636452630304634559&sdata=nE6sUAuzYrTb4dlckHHX4dHyDY >>>O >>>TRsq%2FceE3Nmo564M%3D&reserved=0> >>> > 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 >>> > > >>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me >>>% >>>2Fcarlosrovira&data=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7b >>>1 >>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452630304634559&sdata=HFbKMmSwH >>>w >>>YbWUluHvtEiHqlJbes1zPeNYMkyK2Ojyw%3D&reserved=0 >>> > >>> > >>> >> >> >> >>-- >>Carlos Rovira >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me% >>2 >>Fcarlosrovira&data=02%7C01%7C%7C973d42c862f248f8472308d5224b909d%7Cfa7b1b >>5 >>a7b34438794aed2c178decee1%7C0%7C0%7C636452630304634559&sdata=HFbKMmSwHwYb >>W >>UluHvtEiHqlJbes1zPeNYMkyK2Ojyw%3D&reserved=0 >
