In searching around, I have not been able to find information about generic support in Codename One for gestures generally, and swipe in particular.
I see I can easily set up swipe on a form to return to a prior form, and there is a way to create swipeable containers that work a specific way to rework the display of that container, but what if I just generally want to capture a swipe event - ideally on a container but if not that then on a form - and then take some specific action when that event occurs?
We don't support a high level gesture API. Most of those are inconsistent across platforms and pretty hard to work with so we never built one.
APIs such as tabs include the ability to swipe between containers, and image viewer allows swiping images. Those come up to about 90% of the use cases for swiping.
In other cases people just use a drag motion listener to detect the right level of drag and determine a swipe/pull.
Notice that drag and drop isn't swipe and we do support that with a special API.
Related
I followed the quick start for the dnd kit React library, and it lets me drag and drop just fine with a mouse. However, when I try to use the same page with Chrome on Android, I can't drag the item. It looks like it starts moving and then gets stuck as soon as my finger moves outside its original border.
I tried switching to the drag overlay, but that didn't seem to make any difference.
How can I support touch users with dnd kit?
It wasn't covered in the quick start, but I found the answer in the Draggable section's recommendations:
In general, we recommend you set the touch-action property to none for draggable elements in order to prevent scrolling on mobile devices.
I found that I could either set the CSS style on the draggable element itself, or on a parent element that contains several draggable elements.
However, when I started trying to drag items around within a list or grid of items, that stopped working. Eventually, I had to switch from using the pointer sensor to using the mouse and touch sensors, as described in the sensors section.
I really like the idea of StickyHeaders (https://www.codenameone.com/blog/sticky-headers.html), they're great for usability, but the CN1 implementation was never fully developed or included in CN1. Solutions exist for iOS and Android (https://github.com/emilsjolander/StickyListHeaders and http://applidium.github.io/HeaderListView/).
The two main features I'm missing in the old implementation are: that each header visually 'pushes' the previous out of the top of the screen (and vice-versa when scrolling down), and that the stickyheader which is 'stuck' at the top of the screen is the actual stickyheader itself, so that eg. buttons inside it will work.
Are there any plans to add this to CN1 sometime soon? Or anyone who has implemented a similar solution (I tried Chibuike Mba's alternative implementation mentioned on the original blog post but it doesn't cover the features I'd like)?
Alternatively, any pointers to how I might implement this myself?
I've already tried a couple of times, but given up since I don't master the details of CN1 graphics etc well enough. The approach mentioned here How to make sticky section headers (like iOS) in Android? sounds like a good approach (add a container on top for the stickyheader, scroll that container when the next stickyheader arrives), but then how to force the size and scrolling of such a container?)
This should be much simpler to implement today as we have two helpful features:
Scroll listener
Layered pane
You can use the scroll listener to detect the location of a header and appropriately place another component in the NORTH of a Container within the layered pane. Then as scrolling happens and you detect a new header is coming in you can just place it in an X/Y position below the existing component and use animateLayout to push it out.
I tried many libraries/solutions including ionic-scroll but it doesn't work out. I need something which is much similar to instagram/facebook zoom functionality on mobile view.
Every solution prevents vertical scroll if user want to move to second image under the first one.
I am using Angular 1 in my app.
Can someone suggest me so that I can implement the same?
new to codename one, and I'm looking to build a fairly robust app. I've read a lot of codename one documentation and have looked through many of the demos on git. My question is, what is the best way to architect the application?
Here are my basic requirements:
Splash screen
Lock screen (enabled/disabled by user)
Sliding (hamburger) menu
Contents of sliding menu will change based on current 'form'
Application settings
Based on this short list of requirements, would it better to make each different screen a form, and the sliding menu for each a different 'instance', or make a main form that contains the sliding menu (and just change contents of menu based on current screen) and make each different screen a component instead of a form?
Also, I was considering coding it by hand, and not using the gui builder.
Thank you.
Greg
I would go with separate forms mostly because of the hassle of updating the side menu for every selection you make. This would also make the general design more flexible.
We are building a Windows application in .NET and one of its requirements is touch screen monitor. Other than that, it's a normal windows form based application. But except for making UI items little bigger for touch, I can't find anything I as a developer need to do for the requirement since touch screen is basically mouse operations. Am I missing something?
No, you are not missing anything. Do get the actual hardware hooked up so you can test it, "little bigger" is invariably underestimating the problem of fat fingers. Everything should work from a single click, right-clicks are horribly impractical, double-clicks are best avoided.
The only other thing you'll want to do is go into the Control Panel + Display applet and change the size of standard Windows UI elements. Pick a large window caption font if you want to allow the user to drag or close windows. Make the scrollbars at least twice as wide. And the menu and message box font. Go in the Mouse applet to increase double-click range and time if you want to support that.
If you do not need touch-specific event handling I think it's all you have to do. But touch means more than that and you may want to support it in a better way: http://archive.msdn.microsoft.com/WindowsTouch/Release/ProjectReleases.aspx?ReleaseId=2127