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

51–60 of 73 posts

Re: Building iPad Pro features in Swift

#51

Post by dangwu »

eridius wrote: post #48
yargg wrote: post #37

Earlier quoted context omitted.

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 o…

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?

Re: Building iPad Pro features in Swift

#52

Post by miguelrochefort »

clay_the_ripper wrote: post #35
djrogers wrote: post #20

Earlier quoted context omitted.

> An iPad would struggle to do one of these at a time let alone all of them at once. You haven’t touched a modern iPad, have you? Not only do they not ‘struggle’ to do one of those at a time, they’re butter smooth at it. The workflow/task juggling aspect is definitely an issue, but there is nothing preventing an A10x or A12x iPad from doing any of those things with all the performance you’d expect from a $3k+ MacBook…

I own an iPad Pro for reference. I should have been more Clear: while the iPad can do some of those things and certainly the hardware is good enough, iOS dowsnt fit my use case well (doing lots of things at once).

Pro-tip: Don't do lots of things at once.

Re: Building iPad Pro features in Swift

#53

Post by dieterrams »

erikpukinskis wrote: post #50
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 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.

Re: Building iPad Pro features in Swift

#54

Post by pjmlp »

jbigelow76 wrote: post #10
giobox wrote: post #5

Earlier quoted context omitted.

I think given the specifications of these devices, the pricing, while definitely high, is not completely unreasonable for what the hardware can do - these iPads do things no currently shipping Mac notebook can - 120hz refresh, 240hz touch/pen tracking, FaceID, performance in similar ballpark to a $3k MacBook Pro while passively cooled (!) etc etc. It’s just such a shame iOS isn’t quite ready yet to provide the kind o…

I think given the specifications of these devices, the pricing, while definitely high, is not completely unreasonable for what the hardware can do - these iPads do things no currently shipping Mac notebook can - 120hz refresh, 240hz touch/pen tracking, FaceID, performance in similar ballpark to a $3k MacBook Pro while passively cooled (!) etc etc. Totally agree, and if they had XCode or a decent native C# IDE on ther…

Regarding C#,

https://itunes.apple.com/us/app/continuous-net-c-and-f-ide/i...

Re: Building iPad Pro features in Swift

#55

Post by thirdsun »

saagarjha wrote: post #34
rangibaby wrote: post #32

Earlier quoted context omitted.

> My only complaint is that Safari requests mobile sites instead of desktop sites. That is super annoying. I have a desktop-sized screen and a keyboard. Give me the desktop version. Hold the refresh button you can reload the page as the desktop version

This doesn't always work, because many websites use ways other than the User Agent to customize their websites (e.g. @media queries).

Which is a good thing. Adapting layouts to all those different, wildly varying screen sizes is essential and responsive webdesign is solving this problem.

Re: Building iPad Pro features in Swift

#56

Post by eridius »

dangwu wrote: post #51
eridius wrote: post #48

Earlier quoted context omitted.

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 o…

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 views (the view being dragged, and the destination view it's dropped into).

Re: Building iPad Pro features in Swift

#58

Post by saagarjha »

thirdsun wrote: post #55
saagarjha wrote: post #34

Earlier quoted context omitted.

This doesn't always work, because many websites use ways other than the User Agent to customize their websites (e.g. @media queries).

Which is a good thing. Adapting layouts to all those different, wildly varying screen sizes is essential and responsive webdesign is solving this problem.

That's fine, but what I don't like is when websites make certain features unavailable on their mobile websites and provide no way of getting around this restriction.

Re: Building iPad Pro features in Swift

#60

Post by arvinsim »

ken wrote: post #47
saagarjha wrote: post #27

Earlier quoted context omitted.

> 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!)…

Same here. It's painful to write code in the 13" screen that I always connect to an external display if one is available.
Post reply on HN