I have a collectionView with each cell showing an image. I want to implement a drag and drop. This will solve two purpose.
Rearrange cells.
When a image is dragged into other, it forms a collection (think of it as a group containing two or more images).
This behavior is inline with the home screen folder where app icon can be grouped into folders.
Please suggest how I can implement this.
This isn't trivial but it is not impossible either.
Reordering is simpler, and you can take advantage of UICollectionView's methods:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UICollectionView_class/#//apple_ref/doc/uid/TP40012177-CH1-SW67
Reordering Items Interactively
Collection views allow you to move
items around based on user interactions. Normally, the order of items
in a collection view is defined by your data source. If you support
the ability for users to reorder items, you can configure a gesture
recognizer to track the user’s interactions with a collection view
item and update that item’s position.
To begin the interactive repositioning of an item, call the
beginInteractiveMovementForItemAtIndexPath: method of the collection
view. While your gesture recognizer is tracking touch events, call the
updateInteractiveMovementTargetPosition: method to report changes in
the touch location. When you are done tracking the gesture, call the
endInteractiveMovement or cancelInteractiveMovement method to conclude
the interactions and update the collection view.
During user interactions, the collection view invalidates its layout
dynamically to reflect the current position of the item. If you do
nothing, the default layout behavior repositions the items for you,
but you can customize the layout animations if you want. When
interactions finish, updates its data source object with the new
location of the item.
The UICollectionViewController class provides a default gesture
recognizer that you can use to rearrange items in its managed
collection view. To install this gesture recognizer, set the
installsStandardGestureForInteractiveMovement property of the
collection view controller to YES.
To implement the "grouping" behavior, you need to define your cell in such a way that it can determine whether it is a single item and should just display itself, or if it consists of multiple items, in which case it should be able to pop up a view to act as a tray, possibly its own view controller to handle taps independently. This part is going to be hard as you'll need to implement reordering again, and dragging out, etc.
You might want to search Github and others to see if anyone has implemented a "Springboard" type of app that can get you started.
Related
I am looking for advice on how to make a scrollable list drawn with OpenGL into a CAEAGLLayer backed UIViews accessible with VoiceOver. Ideally, the scrollable list in OpenGL should behave just like a native UIScrollView:
When the user swipes left/right with three fingers I want to scroll up/down a page. This behavior is easily achieved by implementing the accessibilityScroll: method.
When the user swipes left/right with one finger to go through all items in the list and the accessibility focus moves to the last/first partially visible item of the list I want the list to scroll slightly to ensure that the newly focused item is fully visible.
When the user taps directly on the last/first partially visible item of the list to move the accessibility focus directly to it I want no scroll action to happen.
When the user continues to swipe left/right with one finger while the last/first partially visible item of the list is selected, I want the list to scroll up/down one page to reveal previously hidden items.
As I said above, I know how to implement item #1, but after extensively studying Apple's documentation I still have no idea how to make items #2 to #4 work with the iOS accessibility API. I do think that those items are important for a great accessibility experience, though.
Any advice is greatly appreciated. Thanks!
UIAccessibility is an informal protocol that vends the data necessary for accessibility clients such as VoiceOver to interpret and navigate a user interface. UIKit classes implement the full suite of methods in this protocol, rendering most views accessible by default. However, interface elements that aren't directly backed by a UIView, such as the view containing your CAEAGLLayer, must manually implement all relevant accessibility methods.
The best, and often only, way to render this content accessible is to implement a shadow hierarchy of UIAccessibilityElement objects corresponding to the content of the scene. To do so, you must declare the UIView in the UIKit view hierarchy to be a UIAccessibilityContainer. This is a two step process. First, you must ensure that the view backing your container is not, itself, an accessibility element, either by setting or overriding isAccessibilityElement to return false. Second, you must implement the four methods defined in the informal UIAccessibilityContainer protocol for accessing child accessibility elements:
func accessibilityElementCount()
func index(ofAccessibilityElement element: Any)
func index(ofAccessibilityElement: Any)
var accessibilityElements: [Any]?
In most cases, you will want to maintain an array of UIAccessibilityElement objects, each representing one component of your custom-rendered user interface. This array can be used to fulfill your backing view’s contract as an UIAccessibilityContainer. You can then extend elements to behave like scroll views, buttons, and other controls using methods in the UIAccessibility protocol.
To accomplish #1, you will want to implement accessibiilityScroll() on the an element in your accessibility hierarchy to respond to scrolling actions, returning true and posting a UIAccessibilityPageScrolledNotification with a string parameter describing the new scroll position. It sounds like you have this part working without issue.
Requirements #2, #3, and #4 all require programmatically scrolling your view when an element receives focus (or, in the case of #3, opting to do nothing). This can be accomplished using the UIAccessibilityFocus informal protocol. In particular, each element can respond to the func accessibilityElementDidBecomeFocused() and communicate its focus status back up to the object responsible for scrolling the view. If this triggers a paginated scroll, don't forget to post the page scrolled notification discussed, above.
i have a Collection view. I need to call web service when ever user swipes the collection view and reload the whole collection table from the web service response. Is This possible and a good approach. and if so can u tell me how to implement this.
Is This possible
Yes, it's definitely possible.
a good approach
Probably not. Network requests can have high latency, which means that you could end up with a delay between the swipe and the moment when the user sees new data. You'd probably have a better user experience if you loaded the new data before the user swipes, so that you'll have it ready to go with no delay.
how to implement this
Start by reading up on collection views. It's not feasible to explain everything you need to know here in one little answer, and Apple has already written an entire guide about it.
It's not clear from your question whether you mean for the swipe to be in the same direction that the collection view scrolls. Let's consider the two cases, then:
Swipe in same direction as scrolling: You don't need to do any work here to make the collection scroll -- collections are scroll views. You should have your collection view's data source load as much data as is reasonable. When the collection requests cells for which data isn't available (or when the collection view is merely close to needing cells for which data isn't available), the data source should request more data from the web service.
Swipe at right angle to scrolling direction: E.g. the collection view scrolls horizontally, and the swipe is vertical. You'd use a setup like this when you want the user to be able to swipe between different sets of data with a gesture. Use a gesture recognizer to detect the swipe, and use the gesture's action to tell the data source to switch data sets. Then tell the collection to reload its cells. You can use -[UICollectionView reloadData] method here, but you may also want to change the scroll position with -[UICollectionView scrollToItemAtIndexPath:atScrollPosition:animated:].
So we've all probably seen Facebook's method of removing messenger chat heads from the view, I want to implement a similar method of deletion, however to collection view cells within a collection view. When there is a long press on a cell, a box would appear at the bottom of the view and the user would be able to drag the cell to the box for deletion, or simply let go of the select cell and thus returning to it original position and state.
I am aware of two libraries that allow collection view cells to be dragged around and reordered and was going to attempt to use those to implement such a feature, however they allow complete reordering of cells within a collection view and I figured there may be an existing library for implementing my desired feature, or a simpler method.
So basically my question is, what's the best method of implementing this feature into a collection view and if you are aware of a library that allows this easily, it'd be great if you could share it.
Code examples are always welcome and make things a lot easier.
Collection view cell re-ordering libraries: LXReorderableCollectionViewFlowLayout and DraggableCollectionView
I understand how to go about deleting the collection view cells, i'm more interested in the method of deletion. *
I have implemented a scrollview that has dynamic content: multiple sub-views displaying photos of players with player names under. The flow is:
1. On the main window, a player is selected.
2. User launches another view to add a new player.
3. When the user goes back to the main menu, the scroll view is refreshed completely so that the new player photo and name is also displayed.
At this time, the scroll-view should still have the previously selected player in focus but instead it is showing it from the beginning.
So the question is: is there a method to automatically scroll to a specific position in the scrollview so the screen still has the selected player in focus?
Yes, there are two:
(1) scrollRectToVisible:animated:
(2) setContentOffset:animated:
You can read about both methods at UIScrollView Class Reference. Either way, you can use an instance variable to store the content offset or the visible rect when the user scrolls, and then use one of the methods I listed above to restore the scroll view position when the player data is updated.
Depending on what you are doing, you may find UITableView easier to implement because it is very customizable "out-of-the-box" and it has plenty of methods to help manage a list (including the ones I mentioned above, and more). If you're interested, have a look at UITableView Class Reference.
Simple, create a CGPoint and a BOOL that you can retain after the view change and set them when you initially navigate away from that page. Then in viewDidAppear you can check if the BOOL is YES and use:
[myScrollView setContentOffset:myCGPoint animated:YES];
Or, if you want the scroll view to appear already scrolled to the correct position, do the same thing except in viewWillAppear with the animated flag set to NO.
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.