Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building iPad Pro features in Swift

swiftbysundell.com

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Building iPad Pro features in Swift

#41

Post by tluyben2 »

clay_the_ripper wrote: post #11

I just don’t see how an iPad Pro could ever really work as a computer replacement for true professional workflows. I’m talking about multitasking between final cut, building a website, creating assets in photoshop, taking screenshots, downloading things from an email...these are daily tasks for me. An iPad would struggle to do one of these at a time let alone all of them at once. iOS is just too limited to ever make…

It works fine for me besides having the right software. The multitasking actually works in my favor; I am more focused on the iPad and organize things differently (less messy) because I know multitasking is bad & buggy (switching between terminal programs and browsers often have buggy side effects, so I make sure I have what I need before I use the terminal and then only use the terminal until I'm done). It is far from perfect, but the Windows updates (how do they get away with it) and low battery life of laptops are worth it for most of my work.

Re: Building iPad Pro features in Swift

#42

Post by tluyben2 »

jbigelow76 wrote: post #2

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 freedom for devs to make better software. I do not read those features in the expected new features for iOS 13 but maybe I am reading the wrong posts?

Re: Building iPad Pro features in Swift

#43

Post by ncw96 »

saagarjha wrote: post #28
snazz wrote: post #12

Earlier quoted context omitted.

You can actually kind of fit three windows on an iPad: two in Split View and another one on top in Slide Over. Even if you can’t interact with the background windows when Slide Over is active, they continue to refresh their contents.

Fun fact: I believe you used to be able to interact with the split viewed apps in early betas of iOS, but then the feature was removed and restricted to only when you had one app open.

You can interact with two Split View apps and one Slide Over app at the same time, but this is limited to newer models (I believe 2017 iPad Pro or newer). If you are on an older iPad, it is as you describe.

Re: Building iPad Pro features in Swift

#44

Post by [deleted] »

yargg wrote: post #37
lilyball wrote: post #33

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…

How do you track the translation during the gesture if you use UILongPressGestureRecognizer? Do you have an example you can link too?

[deleted]

Re: Building iPad Pro features in Swift

#45

Post by saagarjha »

ncw96 wrote: post #43
saagarjha wrote: post #28

Earlier quoted context omitted.

Fun fact: I believe you used to be able to interact with the split viewed apps in early betas of iOS, but then the feature was removed and restricted to only when you had one app open.

You can interact with two Split View apps and one Slide Over app at the same time, but this is limited to newer models (I believe 2017 iPad Pro or newer). If you are on an older iPad, it is as you describe.

Yes, but this used to be enabled for all iPads. The feature was then removed, probably because older ones just couldn't keep all the apps running reliably.

Re: Building iPad Pro features in Swift

#46

Post by binomialxenon »

saagarjha wrote: post #24
kccqzy wrote: post #22

Earlier quoted context omitted.

GP is talking about how the design of iOS is preventing one from doing all those tasks in a satisfactory way, but not the hardware. For example I could be editing a movie and waiting for it to export. Then I switch to a different app and start editing my photos. There is a Task Completion background API to allow the former to continue to run, but there is no guarantee nor any notification when iOS decides my new phot…

As a workaround, you can put the app into split screen and the OS will keep it alive because it is still in the foreground.

Seems like trying to do anything serious on an iPad is a story of one workaround after another. Why would it be worth the hassle?

Re: Building iPad Pro features in Swift

#47

Post by ken »

saagarjha wrote: post #27
sxp62000 wrote: post #25

When it comes to programming, I just can't see myself typing thousands of lines of code on a tiny iPad screen, no matter how clever the gestures and multitasking in iOS gets. Maybe one day the iPad Pro + stylus will do wonders for visual programming languages like VVVV (can't think of any others).

> When it comes to programming, I just can't see myself typing thousands of lines of code on a tiny iPad screen iPad Pro has a 13 inch screen; that’s the same size as my MacBook Pro’s display. With a good keyboard, such as the one Apple sells, I don’t see why it should be difficult to write code in an iPad.

I find it difficult to write code on even a 15-inch MBP display. It feels very cramped to me. There's barely room for 2 adjacent windows, so I spend all my time scrolling and switching desktops and re-layering windows.

13" is barely bigger than the 12" display on my Apple IIgs (late 1980's), or my first laptop (mid-1990's). That was a perfect size for a VT100 emulator (it's the same size as the original 1978 VT100!), but that's not how I write software any more.

The same size screen is actually relatively worse than 20 years ago, because these days all documentation is online, so it has to share my screen.

Re: Building iPad Pro features in Swift

#48

Post by eridius »

yargg wrote: post #37
lilyball wrote: post #33

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…

How do you track the translation during the gesture if you use UILongPressGestureRecognizer? Do you have an example you can link too?

Admittedly you do lose the convenience methods from UIPanGestureRecognizer (sure would be nice if Apple would add them to UILongPressGestureRecognizer too), but you can recover translation just by grabbing the location of the recognizer in the associated view when the state moves to .began and then subtracting that from the current location on every subsequent .changed state callback. Calculating velocity is harder of course, but you could do it without too much difficulty by recording the previous location and timestamp and using that to calculate an instantaneous velocity (I'm not sure if this is what UIPanGestureRecognizer does or if it tries to smooth the velocity at all using multiple "frames").

I don't have any linkable examples offhand, but at a previous company one of our standard interview questions was to implement custom drag & drop of a view using a gesture recognizer, and our reference app used UILongPressGestureRecognizer because it let us do such nice things as visually "lift up" the view (scale it up slightly and add a drop shadow) the moment your finger touched it.

Re: Building iPad Pro features in Swift

#49

Post by saagarjha »

binomialxenon wrote: post #46
saagarjha wrote: post #24

Earlier quoted context omitted.

As a workaround, you can put the app into split screen and the OS will keep it alive because it is still in the foreground.

Seems like trying to do anything serious on an iPad is a story of one workaround after another. Why would it be worth the hassle?

It's thin, light, and has better specs than my laptop?

Re: Building iPad Pro features in Swift

#50

Post by erikpukinskis »

clay_the_ripper wrote: post #11

I just don’t see how an iPad Pro could ever really work as a computer replacement for true professional workflows. I’m talking about multitasking between final cut, building a website, creating assets in photoshop, taking screenshots, downloading things from an email...these are daily tasks for me. An iPad would struggle to do one of these at a time let alone all of them at once. iOS is just too limited to ever make…

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 dark age of UI.

People are doing weird pointless stuff in VR UI right now, so I think that might be where the ideas get worked out. That's how it worked before, we got out of the WIMP stagnation because a whole new paradigm (hypertext) emerged.

Post reply on HN