Live data from Hacker News

Building iPad Pro features in Swift

swiftbysundell.com

61–70 of 73 posts

Re: Building iPad Pro features in Swift

#61

Using UIPanGestureRecognizer for gestures that should be recognized immediately on touch down is a common mistake I see a lot of people make. The problem is UIPanGestureRecognizer doesn't actually start recognizing until the touch has moved a short distance, and at this point, you can't recover the original touch location, only the location at which the gesture recognizer began recognizing. The solution is to use a U…

Why not just use touchesBegan/touchesMoved directly?

Re: Building iPad Pro features in Swift

#62

Earlier quoted context omitted.

And another reason to wait a year at least to buy a new iPad Pro if you already have one. Wait till A13x or A14x to see an iOS that can utilize it properly.

Yep, I have a feeling this will happen alot, even if Apple waits 18 months to refresh iPad hardware that's still only 4-6 months from iOS 13's release. And maybe some hardware criticisms, like only one USB-C port, will be addressed (probably not though)

> only one USB-C port, will be addressed (probably not though)

Apple shipped a laptop with only 1 USB port. I'm not holding my breath.

Re: Building iPad Pro features in Swift

#63

Earlier quoted context omitted.

Yep, I have a feeling this will happen alot, even if Apple waits 18 months to refresh iPad hardware that's still only 4-6 months from iOS 13's release. And maybe some hardware criticisms, like only one USB-C port, will be addressed (probably not though)

> only one USB-C port, will be addressed (probably not though) Apple shipped a laptop with only 1 USB port. I'm not holding my breath.

You can charge, or you can use a dongle for your USB key - but of course never both, unless you pay us $79 for the USB-A/VGA adaptor.

I used to love Apple, I really did.

Re: Building iPad Pro features in Swift

#64

Using UIPanGestureRecognizer for gestures that should be recognized immediately on touch down is a common mistake I see a lot of people make. The problem is UIPanGestureRecognizer doesn't actually start recognizing until the touch has moved a short distance, and at this point, you can't recover the original touch location, only the location at which the gesture recognizer began recognizing. The solution is to use a U…

Couldn't you also subclass UIPGR and override `touchesBegan`, etc? Gesture recognizers will receive the touches before the parent view does, so you can just saved the position when touch starts on it, and let it pick up from there.

Re: Building iPad Pro features in Swift

#65

Cool hardware, but there's no way I could justify the price to myself with the limited functionality of iOS as it stands today. A lot Apple tech writers/podcasters keep saying "just wait for iOS 13!", but the earliest a developer is going to see iOS 13 is 6 months from now at WWDC, the earliest the general public will get any additional functionality is 11 months from now. That's a LONG wait to see if any changes wil…

I did not hear "wait for iOS 13"; searching Google I see a lot of talk about features that do not seem very interesting. What would it be that we are waiting for? Only thing most (here and elsewhere) are looking for is better multitasking (rather; side by side 'anything', so the same app with different or the same docs open or different apps with different docs and then copy/paste + drag & Drop between them) and more…

The complaints I've heard:

- Lack of mass storage support through USB-C and the Files app (this seems like a comically boneheaded omission that Apple is going to dig their heels in until iOS 13 a year from now).

- No XCode

- No Final Cut Pro

- No Logic Pro

- No pointing device especially when used with an external monitor (I don't think anyone should their breath on this one though).

Granted, the audience for XCode is small, the audience for Logic Pro is small, people wanting a pointing device is small, etc... but taken in aggregate you end up with a large group that still can't call this iPad a "computer" the same way they can their laptop/desktop.

Re: Building iPad Pro features in Swift

#66

Using UIPanGestureRecognizer for gestures that should be recognized immediately on touch down is a common mistake I see a lot of people make. The problem is UIPanGestureRecognizer doesn't actually start recognizing until the touch has moved a short distance, and at this point, you can't recover the original touch location, only the location at which the gesture recognizer began recognizing. The solution is to use a U…

Why not just use touchesBegan/touchesMoved directly?

You could do that, but it's more work than using a gesture recognizer, and doesn't compose as well (for example, with the gesture recognizer approach, you can easily add in other behavior like conditionally enabling a tap gesture recognizer that has higher priority than the drag gesture recognizer, without even having to touch the code that implements the drag beyond having access to its gesture recognizer object).

Re: Building iPad Pro features in Swift

#67

Earlier quoted context omitted.

It always takes a few decades for UIs to catch up with new hardware. We still don't really understand how to design touch UIs yet. We basically just squish WIMP interfaces a little so you can fat finger them. There has been no radical reimaging of UI toolkits for touch yet. The software industry is so crippled by finance thinking right now anyway, everything research-y moves extra slow anyway. We're in the second dar…

I'm not sure why you'd expect a radical reimagining of UI for touch. Touch UIs look largely the same as WIMP UIs because there isn't a radically better way of presenting information and affordances on a screen.

How do you know?

Have you interacted with many professional UI designers? They almost universally have no time, they are forced to rush out mediocre work on a strict timetable.

Re: Building iPad Pro features in Swift

#68
post #56
post #51

Earlier quoted context omitted.

That’s an incredibly specific interview question... there’s a lot more to iOS development than drag and drop. How has it fared for you?

Actually quite well. The fact that it's drag & drop is pretty irrelevant, except in that it's not something the interviewee has likely done before because it's not a very common thing to interrupt. What's more important is that it's fairly basic usage of UIGestureRecognizer (which is a common thing to need, at least if you're doing any kind of UI development) as well as some basic management of state involving 2 view…

s/interrupt/implement/

Re: Building iPad Pro features in Swift

#69

Earlier quoted context omitted.

I'm not sure why you'd expect a radical reimagining of UI for touch. Touch UIs look largely the same as WIMP UIs because there isn't a radically better way of presenting information and affordances on a screen.

How do you know? Have you interacted with many professional UI designers? They almost universally have no time, they are forced to rush out mediocre work on a strict timetable.

I have a design background myself, and frankly, you're not going to do much better for flat screen-based UIs than buttons, scrubbers, tables, lists, scrollviews, etc. This has little to do with touch, and everything to do with 2D design for screens. Better/worse design will depend on how these idioms are used/organized, rather than a radical rethink of those idioms.

That's not to say there aren't good undiscovered idioms for 2D UIs, but there's no shortage of designers trying to find them, especially outside of their dayjob. Designers love trying to invent new and novel ways to interact.

It is, however, actually an advantage for touch UIs that they aren't radically different from WIMP, because users don't have to learn a completely different UI, at least in terms of visual organization/affordance.

You can also bet the Apple designers/engineers who were prototyping iOS UI idioms before the iPhone was released explored a range of different idioms, and they continue to do so.

Re: Building iPad Pro features in Swift

#70
post #66

Earlier quoted context omitted.

Why not just use touchesBegan/touchesMoved directly?

You could do that, but it's more work than using a gesture recognizer, and doesn't compose as well (for example, with the gesture recognizer approach, you can easily add in other behavior like conditionally enabling a tap gesture recognizer that has higher priority than the drag gesture recognizer, without even having to touch the code that implements the drag beyond having access to its gesture recognizer object).

Using an instant LongPress seems like sort of a hack though.

Interesting though, how do you transition from the instant LongPress into the "Pan" gesture? Or does the LongPress by itself also get the 'moved' events?

Post reply on HN