Hello I am new in craft and I would like to know if there is a possibility to change style or add class on scroll. For example I have fixed navigation and I would like to change a color when user is on 1000px scroll height. How I could do it ?
This has little to do with Craft since it's just a matter of adding some JavaScript code to your frontend. There are a couple of ways to achieve this. The classic way to perform some action on scroll is to use a scroll event listener. Inside the event listener, you can check the scroll position (see window.scrollY) and perform whatever logic you want. The downside is that scroll event listeners are bad for performance, since in theory they can execute many times in a row while scrolling. Some browsers throttle scroll events for this reason, so the event listener may be executed with some delay. You should try to avoid using scroll listeners where possible, or at least use passive listeners to improve performance.
headroom.js is a library specifically to modify sticky navigations depending on scroll position and direction, though it suffers from the same problem since it uses scroll event listeners.
If you can, see if your problem can't be solved using Intersection Observers, since their performance is much better.
Related
I have a scenario where I overlapped a view(pageViewController inside the view) with a uitableview with an offset of 130, and that uitableview is Transparent, only cells will be scrolled and visible.
My requirement is within this offset place of 130, I want to pass touch events to the view(pageViewController) which is below the uitableview and that view is not a superview(It is a sibling view) of table view but I overlapped it with tableview.
So is it possible to pass touch (Horizontal Swiping Event) to the view which is below the uitableview in the transparent area (Offset Area of 130); if yes, what I have to do for this?
There are lots of options for controlling how touch events and scrolling interact in iOS. You can override hitTest, you can use delegate messages sent to gesture recognizers to say which combinations of recognizers should fire when, etc. Without seeing your problem in detail it's hard to say which is best... and even then, you might say it's partly a matter of style. (At first blush, though, I'd guess that overriding hitTest to return different views at different times might be it.)
I'd recommend watching the WWDC 2014 video on Advanced Scrollviews and Touch Handling Techniques. That talk works through solving some problem that sound almost exactly like yours, so you'll almost certainly find a good solution in there. And lots of other tips that might be helpful elsewhere in your app. (Actually, if you have the time, I'd recommend watching the UIScrollView-themed sessions from the past several years' WWDCs... the so-called "Josh & Eliza Show" has always been full of cool demos and useful insights.)
I have a UITableView displaying a table of data with a somewhat large contentInset value. As a result, the user cannot trigger the UIRefreshControl because it expects them to scroll too far.
Basically, I'm wondering if it's possible to make UIRefreshControl adjust for contentInset values.
Edit: This question is mostly about curiosity, so I removed the extra details and rephrased the question to be more direct.
I think you're going about this a bit wrong. If you've encountered this issue because of the mechanism you've created to preload cells, you should think of a different approach for preloading them. If there's any content to be rendered / loaded / downloaded, you could be doing this in a background thread and leave a minimal amount of work for cellForRowAtIndexPath. If you insist on keeping this implementation, I'd suggest looking up a custom refresh control as there is no way to customize the build in UIRefreshControl in terms of content offset for refresh (AKA sensitivity). I believe this is ultimately a good thing - there should be consistent user experience across apps running on iOS which use a refresh control.
Using UICollectionView and excellent help given on here on StackOverflow, I've been able to build a "Gantt Chart" style control for my iPhone:
Cosmetics aside (I'm doing the functional right now, I've got a graphics designer on tap to look at colors and all that).
Background aside, the spans were relatively straightforward to do with a custom UICollectionViewLayout subclass. Each span is an item.
But I need to add some functionality, and am unsure how to proceed. Where I'm trying to go is illustrated roughly as:
Sketchy cosmetics aside, the point is that I want to "annotate" whatever the currently selected span is with additional information (I promise to find someone to help me look it pretty). And I want them to be active, I'm not sure if it brings up an editing control or does drag, but I want to be able recognize gestures on either the numbers or the bold lines and do things with them, distinct from touching on the span which drives selection.
I can think of (at least) 3 ways to try and implement this:
Use supplementary views. Cause selection to invalidateLayout, detect the selected state in my prepareLayout, and generate additional layout attributes for the two anchors. Implement a subclass of UICollectionReusableView which does the drawing, and adds touchable subviews (or its own gesture recognizers). This feels... wrong. I get the idea that supplementary views are more for headers and footers, not for controls that come and go as the selection state changes. But maybe it's an appropriate extension of the facility?
Use the backgroundView (or selectedBackgroundView, not sure it matters) of my current SpanCell class (which is a subclass of UICollectionViewCell). As long as I disable clipsToBounds, I can draw the annotation around the bounds of the span. I'll have to give it some knowledge of the big picture to find the endpoints, but that's not too offensive. I would just show/hide this view in response to selection changes. This seems like the best way to do it.
Do it in the main backgroundView of the entire UICollectionView. As shown, I've already got a specialized backgroundView which shows the the current time grid, strip style. I could further extend this view to draw annotations and manage touchable sub controls in response to selection changes. This would give me most direct implementation, but it feels like I'll end up with a big monster "doing too many jobs" object for the background.
Question then, for those who have more experience, is which route would you go? Would it be one of the above 3? Or something different? And why?
While your question is very technical with UICollectionView implementation, which I am not very familiar with, this seems like a job for the container (in this case, the collection view). Imagine you need your annotation to consider, in addition to the selected item, other items? Like for example, avoiding collision between annotation lines and another item?
For me, option number 3 seems like the most correct one. If you fear a large class, you can extern it to an annotation controller class, which should be notified whenever the annotations should be updated.
I'm building a native iOS app that will allow end users to build forms by dragging and dropping from a toolbox of custom controls. A typical scenario would be a power-user dragging some UILabels and UITextField representations around on a UIView. Groups of controls would be supported, allowing several controls to be visually contained within a section. The whole thing will probably be contained in a UIScrollView allowing horizontal scrolling between 'pages'.
'Normal' users will then use the form for data entry.
So, I have two related requirements: to allow different types of UIView/UITableView/UIImageView/UILabelView/UITextField etc to be laid-out and grouped (and probably contained within an outer UIScrollView), and to allow the layout to be adjusted/dragged/dropped by power-users.
My question is rather broad, but is essentially this: what is the most appropriate nested UIView hierarchy to support these two related requirements? Is a basic structure of UITableViews contained within an outer UIScrollView fundamentally sound if I want to drag-drop within nested views within the UITableView? Should I avoid UITableView because it will complicate dragging?
I appreciate this question is borderline subjective in scope, but I'd really appreciate some guidance from people who have tacked this sort of thing before and who have some words of wisdom for me.
Many thanks.
Sounds like an interesting app! I would say that using a UITableView would make the app horribly complicated. A UIScrollView would be a good base to drag and drop controls onto. Perhaps with an "add page" button, the user could tap this it required, and you could extend the contentSize of the UIScrollView to be the width of +1 pages, and then scroll it so the user can drag more controls onto that page.
To drag the controls around, you could use a UIPanGestureRecognizer attached to each control, and when triggered it changes the centre position of the control. You might need to turn off user interaction of some of these controls - e.g. for a UITextField the power user will want to drag it around but not want to enter a value into it.
For grouping controls, you could do something like this:
a "group mode", whereby the user taps a button to enter this mode, then taps a number of controls (would need some visual indication on them to show they are selected) and then taps done.
the selected controls are then be removed from the UIScrollView
a new UIView is created and positioned at the centre point of the selected controls, and is big enough for the controls to fit in at the same distances apart. It is added as a subview of the scroll view
the controls are all added as subviews of this view
the gesture recognizer is added to this view, instead of the individual controls. Then when dragging around, this group of controls will all move as a group with fixed layout.
If you have groups of controls that you think might be commonly used, you could even create them in advance, each in their own nib, and then allow the user to drag them onto the scroll view as a pre-made group.
What you might find, especially if some of your controls are quite large (e.g. I'd expect an image view to be significantly bigger than a label or text field), the pan gesture recognizer gets a bit limiting because when trying to drag views around you'll inadvertently pick the wrong one if they are positioned close together or overlapping. In which case, you might need the extra precision of handling all the touch events yourself - so when a touch starts, you test against all the controls (or groups) to see which has the closest centre to your tap position, and then as you get the touch moved events you can update this centre position.
I've not made anything quite as complex as what you're describing, but I did make an app where the user could drag small images onto a large image to apply as "decorations". They could drag on any number of these decorations, and also scale them with a pinch gesture. In this case, I had a UIImageView as a background which held the main image. Then the decorations were on the edge of the image, and a pan gesture recognizer was used to detect them being dragged onto the image. On drag, I'd actually create a new instance of the decoration (UIImageView) so that there was always another one left in the toolbox. A pinch gesture recognizer was used for the user to scale the decorations. For the user to move around a decoration they had already placed, I had to use manual touch handling to detect the right decoration (since they could easily be overlapping, and ones that looked round to the user are actually square in terms of UIViews, so it was easy for the user to accidentally drag the corner of one when they intended to drag a different one). Mixing an matching gesture recognizers and manual touch handling seemed to work out just fine, which was good because it's much easier to use the gesture recognizers for the more complex behaviour like pinching.
Back to your app, once your power user has set up everything, then when the normal user loads the app, you can just turn off any touch handling code (and remove or don't create the gesture recognizers) and they will get static forms as laid out by the power user. Then make sure user interaction is enabled on all of the controls (e.g. UITextField) and they will be able to enter data into them.
Doing all of the above with controls onto a scroll view will be complex enough I think, and you may end up having to deal with lots of niggly behaviour in trying to get it working nicely for both normal and power users. I think this would be 100x harder if you were also dealing with UITableViews and UITableCells at the same time.
Please let me know if you'd like me to elaborate on any aspect of the app I outlined above, as it does seem to have a fair chunk of functionality in common with your app. Hope to see/hear more about your app in the future!
EDIT
One more thing occurred to me - if you are keen to use a UITableView in your solution, then I would suggest that your power user lays out one UITableViewCell at a time. In fact, they would be dragging UILabels and other controls onto just a basic UIView, which when they've finished you then use to record the positions of the controls. You then use these positions when presenting those controls in a cell - in cellForRowAtIndexPath you would create and init all of the chosen controls, and position all of them in a newly created cell at the positions and layout the power user had chosen. The power user could also have a control to change the height of the cell they are laying out, for more flexibility. They would create a series of cell layouts one after the other (I guess each of these would be a "group" of controls), and then those cells would be presented in order in the table view. You could then give the power user some final tweaking control by letting them put the table into edit mode so they can reorder the cells (or even remove some).
Depending on the application, perhaps the user could also have these cell layouts they've previously created always available, so after they've built up a few common control groups, they can just keep reusing them to very rapidly build up a form. And then occasionally they would create a new cell layout when none of the ones they have created so far are suitable, and again it would be saved as a template for them to use again in future forms.
I would just make an EditView class that is just a UIView with some transparent background color. When you want to drag controls around, then set some type of edit mode where you overlay a bunch of EditViews on all the appropriate controls. The EditView would then support whatever gestures / touch handling you want to resize or move it. Dragging a view onto another view and releasing might prompt something like "Nest view A in view B?" which then you can make the related addSubview calls.
Nesting tableviews inside scrollviews won't be an issue, though I'm not sure what kind of behavior would be expected if you were trying to nest anything inside a tableview...that would have to be specified using standard UITableView methods.
For saving layouts and such, you might need to create your own pseudo-view hierarchy that contains various pieces of meta-data needed to recreate the final layout which you would then be able to store somewhere.
Ok. I HAVE seen a LOT of topics which are similar to what I'm trying to do here, but nothing that quite matches. Maybe my approach is way off base. Here's the deal.
I'm drawing a chart to my UIView subclass in drawRect:. I then use a UIPanGestureRecognizer to translate the chart's offset (internal, not in the view hierarchy) to the right/left. This works great, but my problem is that the recognizer's action gets fired with relatively low frequency. Specifically, the resultant panning is MUCH choppier than, say, in a scrollview or tableview. Particularly when the number of points in my chart goes up. Now, what I'd LIKE to do is not actually trigger drawing from the pan gesture's action, but have a timer firing at something like 30 times per second, interpolating the offset from the moment the pan fired to the current moment. However, this is getting more and more complicated.
Anybody have suggestions? Should I really just be doing this with a UIScrollView? The reason I'd prefer not to is that the data may extend quite far in either direction, and I'd like to not have to draw (or at least store) the whole path at once, but just do the section which is currently displayed. Should I be using CAShapeLayer? I'd like some input before I spend another day playing around with these possibilities...
Any input / experiences would by most welcome.
So, in the end, I DID end up putting these things in a UIScrollView. I had to do quite a bit of work to get this up and running, the complicated part being the creation of a series of PANES which would be added to the scrollview. Each pane asks a delegate for the data it needs to draw, and then they're all stitched together. Fortunately, everything worked great once I put these scroll views containing chart panes into a table view. Still haven't tackled scaling, but I've seen a few posts on here which should make it relatively trivial.
So that's the answer to my original question. DON'T try to pan and draw on each frame, it WILL be choppy, and baring some real hack, there's no good way I could find to smooth it out. Scroll view handles all these problems for you, as long as you can split your view up nicely. I guess I could have used one long view, but then when the data set gets large I'm in trouble.
Now I've got a related problem though -- when offscreen charts scroll into view (they're in UITableViewCells), there's a big hiccup as the new chart gets drawn. I think I will try drawing them into an image asynchronously, so that when the new row scrolls into view, I've already got the image.