I'm trying to figure out if this sort of thing is possible in iOS.
I'd like to have a UI where the user can drag "bubbles", each representing a noun, from a source pool into a destination panel. In addition, I'd like to be able to have another word pool of bubbles, each with adjective bubbles. These adjective bubbles could be dragged over noun bubbles already in the destination panel in order to modify them, making a combined bubble.
Mock-up of what I'm envisioning:
Is this possible in iOS (any versions)? Preferably using stock controls, but any way is fine. I will admit I have never worked with Objective-C or iOS dev before, but I am aiming for this sort of interface for my app, and want to see if it's at all possible.
Yes, this is certainly possible - but not something you could use 'stock' controls for. I would recommend learning about UIGestureRecognizer classes, try this tutorial for starters:
UIGestureRecognizer Tutorial in iOS 5: Pinches, Pans, and More!
Related
I'm currently trying to implement Drag&Drop in my app. I've watched this:
https://developer.apple.com/videos/play/wwdc2017/223/
(There's also a downloadable project that exactly showcases what I'm about to ask)
There's one thing I don't understand and that's this:
When I drag one item, I can drop it within the same collection view. However, that's not working anymore when I drag multiple items. No "gap" is created and when I drop the items, they just go back to their old positions.
Does this have any specific reason I'm not seeing? Because I'd love to have this feature.
I mean, I probably could implement the actual "moving the data" part (it's just a case that the demo project is not considering), but I see no way of adding this "gap" while hovering over the items.
Thanks for any advice :)
This is currently not supported with the latest set of APIs (as of iOS 13). It's possible to do by returning a proposal with intent .unspecified and drawing a drop indicator manually.
See tweet reply from Tyler Fox, Apple engineer.
I haven’t tried moving multiple items before, but the way you “create space” for a single item is by using collectionView.beginInteractiveMovementForItem(at: IndexPath) and it’s companion functions. https://developer.apple.com/documentation/uikit/uicollectionview/1618019-begininteractivemovementforitem
I have a screen with 1 button. When clicking that button, a list of items should be shown (in which the user can select multiple items).
On android, i would like to do this using a dialog. I create a "DialogService" that does this, no problem.
On iOS, however, it seems that the best practice is to display a fullscreen tableview, for example as a modalView. Is it possible to do this without using a custom viewpresenter (e.g. modalViewPresenter)? I would very much prefer to have identical navigation on both platforms and just have different implementations of "DialogService"
I think trying to make one platform look and act like another is generally not a great idea as things start to look weird for the users.
But if you want to do it anyway I would start by trying to do something like this https://stackoverflow.com/a/29910246/1107580 (it is in objective-c) then trying to bind to the tableview that is in the alertcontroller.
I am looking to implement a custom toolbar that sits above my keyboard for a text field with some custom values. I've found a ton of tutorials online but this question is for asking what's the best way to do this.
This tutorial here http://blog.carbonfive.com/2012/03/12/customizing-the-ios-keyboard/ provides the most common way I can see across many tutorials, with creating a new subclass of UIView and using delegates to get that information across.
That's the commonality. However, I came across this tutorial which in the view controller itself just creates the toolbar, assigns it to the textField inputAccessory and it's good to go. In fact, I tried out the code and without any effort, I have now a custom keyboard.
http://easyplace.wordpress.com/2013/03/29/adding-custom-buttons-to-ios-keyboard/
This just seems a bit too easy to me though and I'd think the proper, Apple recommended way would be to create that UIView subclass and use delegates so that the view controller with the text fields acts as that delegate.
I'm specifically targeting iOS 7 in my app.
What are people's thoughts on this? If the second easier link is supported and is likely to pass Apple's guidelines, it's a good starting point but if delegates are the way to go, I'd rather look into that from the start.
Your thoughts will be appreciated.
There is no 'Apple Approved' way to do this, and its hard to believe anything you do here would get your app rejected. The custom keyboard you reference in your post has the iOS6 look and will appear outdated in an iOS6 app. I'll mention some iOS7 suggestions shortly, but the constant danger of mimicking what the System looks like today is guaranteed to look outdated later. In Mac/Cocoa development, Apple use to say at the WWDC that if you did something custom, make it look custom, don't take a standard Apple widget and try to duplicate it. But that advice is mostly ignored.
For iOS 7, you can create buttons that appear just like the system ones do (not pressed), but of course when someone presses them, they won't act like system buttons (i.e. animate up and "balloon" out.
I'm currently using a fantastic add-on keyboard, my fork of KOKeyboard (which uses the buttons above). This is such a cool addition. While the buttons look like iPad buttons, each one has 5 keys in it. By dragging to a corner you select one of the four, and tapping in the middle gives you that key. This might be overkill for your app, but it really helped me with mine. It looks like this:
(the Key / Value is in the under laying view.) The center control lets you move the cursor - its like a joy stick - and can be used to both move and select text. Amazing class, I wish I'd invented it!
Also, for any solution, you want to use a UIToolbar as the view holding the keys, for the reason that it supports blur of the view it overlays, just like the keyboard does. You can use the UIToolbar with no bar button items in it (if you want), and just add subviews. This is a "trick" I learned here, as there is no other way to get blur!
David's KOKeyboard (er…, the one he used - see David's comment below) looks nice. I suspect that he is using the official Apple mechanism:
inputAccessoryView
Typically, you'd set that value on a UITextView, but it can be any class that allows itself to become the first responder.
The provided view will be placed above the default apple keyboard.
It is correct that there is no official mechanism (and it is suggested against) to modify any system provided keyboard. You can add to it, as above. You can also entirely replace it for with your own mechanism. Apply will forgo the keyboard setting on your view and use a custom input mechanism if you set
inputView
set it to any view - Apple will still manage its appearance and dismissal as it does the custom keyboards.
Edit: Of course, iOS 8.x added significant access to keyboards. (not mentioned here)
I'm in the process of developing an iPad-only survey-app using MonoTouch. With monotouch.dialog (mt.d) I found that building these interfaces can come quickly, which is awesome.
However... I also found that mt.d only does about 80% of what I want. Makes me wonder: should I invest in extending mt.d to my needs or should I choose something differently over mt.d?
Some of my requirements:
Radiogroups without transitions: I like the options to be
presented right away (there's more than enough space on the iPad
screen)
A rating UI control, such as
http://www.cocoacontrols.com/platforms/ios/controls/dyrateview
Mixed radiogroups: like 3 predefined elements and a fourth which
allows for manually added content
What are your thoughts on this? Can this be done easily (I'm a trained programmer, but quite new to both C# and iOS development)? Do you guys know of any online repositories of custom UI components with C#/MonoTouch bindings?
Thanks a lot!
This is of course a subjective opinion, but my take on it is that if you believe you can do your UI in UITableView (which MonoTouch.Dialog is based on), then you should go for MonoTouch.Dialog. If UITableView will not fit your needs, you should look for a different approach. MonoTouch.Dialog is quite flexible, and open-source, so if you need anything to be different you can just use the source code and modify it at will.
New to iOS, coming from the Java / Swing world, where I'm used to creating UIs programmatically, letting components size themselves and using various clever layout managers to arrange things.
It already seems clear that the iOS way is to make heavy use of Interface Builder, with a lot of fixed sizing and positioning. I'm not sure IB is ever going to come naturally, but I guess fixed layouts make sense given that you're working with limited space and a fixed window size.
It still seems like I'm writing a lot of boilerplate, though, and violating DRY, and so on.
Can somebody point me to a good primer on laying out iOS UIs, particularly programmatic UIs?
You don't really need to use IB to write MonoTouch apps. I almost never do. The CocoaTouch API is fairly simple and straightforward to develop on.
I haven't really found any writeup on UI development other than the apple documentation (which is really good, by the way, worthy reading), so here goes a couple of tips, based on my experience:
Inheritance is key to maintaining the code clean. You can inherit from basically any class in the API, like buttons, controllers, views, etc. Inherit and add your customizations in those classes. Don't shove everything in the AppDelegate like many examples show. You'll thank me later on.
Have I mentioned inheritance already?
The one thing iOS doesn't have is a layout manager, so if you're used to Java like you mentioned, this will sound a little strange. Different from what Java people think, this is not a big deal. UITableViews help tremendously with this (vide next point).
A lot of iphone apps are built on top of the UITableViewController, even apps that don't look like tables. It's a great framework to do anything related to scrolling. Learn to use it well. Almost anything that scrolls vertically is a UITVC. Follow the guidelines that define when you create and when you dispose cells and objects.
Be careful every time you add a Frame location in your control. Instead of setting hardcoded values, try using offsets from other locations (x+40, for example) whenever possible.
Make sure you add your views to the proper container as necessary. For example, if you're adding a global "Loading" view, add it to the Window object, while if you're adding a image on the left side of a table cell, use the ContentView. iOS changes those special views automatically all the time (resizing screen to fit "on call" bar at top, or rotating phone).
Miguel de Icaza has created a great framework for managing forms and tables, called MonoTouch Dialog. Take a look, and enjoy.