Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

Doctor w-rw-rw-: Jun 24, 2008

fleshweasel posted:

I don't know poo poo about this, do you mind pointing out some production apps that operate this way?

Facebook and especially Facebook Paper: https://www.youtube.com/watch?v=ZdiBPHpxGd0&t=390s

More stuff on how Paper was built: https://www.youtube.com/watch?v=OiY1cheLpmI

Been moving towards this pattern at work, too.

# ? Jan 6, 2015 05:42

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 18:15

Doc Block: Apr 15, 2003; Fun Shoe

Doctor w-rw-rw- posted:

False. I recently converted a text-and-image-rich storyboard-based UI that struggled on an iPhone 5s to one that barely dropped frames on a iPhone 4. That's a positively insane difference in performance.

Well, yeah, storyboards. Separate .XIBs are pretty quick in my experience. I don't use storyboards, so I don't really have that problem.

Doctor w-rw-rw- posted:

Exactly the opposite of my experience. Writing view models and tweaking the values is easy. I've been paired with a developer who swears by nibs and it is the worst. Not only is the xib file almost completely un-reviewable, it's also painful and tedious to create a consistent look and feel (i.e. with exact font sizes, colors, and faces inside other constant-sized UI elements). I'd only advocate for IB if your app is total poo poo, the design completely uninspired, or you don't mind having no taste whatsoever. Or if you're really quickly prototyping before you write something worthy of production.

I absolutely loving despise having to write view setup code. It's so tedious, error-prone, and seems pointless to me: I could spend what seems like hours writing UI setup and layout code, having to look up what the IB-equivalent properties and values are that I need to set, and tweaking the gently caress out of everything, or I could spend far, far less time creating the same thing in Interface Builder and then just using code for any special snowflake stuff my design needs.

Doctor w-rw-rw- posted:

Use FBTweaks. Not sure if they released the part that lets you tweak it remotely so you can see the changes while you're testing on the device, but live UI tweaking was a pretty useful thing while developing Paper.

I'd never heard of this. Still, I try to keep the number of external dependencies low for my projects. Less worry about breaking with OS updates, less to constantly try to keep updated. While I'm pretty good at avoiding Not-Invented-Here syndrome, I'm also not the kind of developer that thinks, "Well, I could write 50 lines of code to solve this, but instead I'll just pull down another 3rd party library. Let's see what CocoaPods has! :downsgun:

Doctor w-rw-rw- posted:

I can't imagine doing any significant amount of Autolayout, period.

While I was literally swearing at Xcode and autolayout last night while working on my OS X app, it has made certain things easier. And if I ever want to internationalize, I can't imagine the headaches of having to do a dynamic layout based on the content size of labels etc. in code.

Doctor w-rw-rw- posted:

On iOS, IB fights the developer more often than the developer fights it. It's terrible for merge conflicts when they happen, things are often over-constrained or ambiguous for any UI that's more than a little complex, and loading xib files and storyboards still crashes the gently caress out of Xcode. All. The. Goddamn. Time.

Can't really say anything about this. I'm a lone indie developer working on his own apps by himself.

Of course, that means anything that can save me time, like laying out interface elements visually and having a tool that knows what all the various properties are for each UIKit widget so I don't have to look them up is a big help.

Doctor w-rw-rw- posted:

Also, Autolayout is so so bad on iOS. Mobile devices still have nowhere near the resources desktops do, and the constraint resolution is trash for performance. Backtraces several tens of calls deep with nothing but constraint resolution showing up in Instruments and taking forever devastates performance.

With that said, nibs and Autolayout seem fine on OS X for other reasons, mainly because it's way more mature, computers are way less constrained, and in code you have to deal with AppKit's warts anyways (as opposed to UIKit, which is really clean).

No arguments here. It's pretty obvious that Autolayout was designed by the AppKit team (which is why it was implemented on OS X first), and a big part of its design seems to have been based around making it easier to have views resize/reposition intelligently when the window size changes.

# ? Jan 6, 2015 05:52

Doctor w-rw-rw-: Jun 24, 2008

Doc Block posted:

Well, yeah, storyboards. Separate .XIBs are pretty quick in my experience. I don't use storyboards, so I don't really have that problem.

Step 1 was factoring it out into xibs, actually. Not /as/ bad as storyboards, but bad enough.

Doc Block posted:

I absolutely loving despise having to write view setup code. It's so tedious, error-prone, and seems pointless to me: I could spend what seems like hours writing UI setup and layout code, having to look up what the IB-equivalent properties and values are that I need to set, and tweaking the gently caress out of everything, or I could spend far, far less time creating the same thing in Interface Builder and then just using code for any special snowflake stuff my design needs.

Same but in reverse for me with regards to IB. Tedious, error-prone, and seems pointless to waste hours getting IB stuff pixel-perfect (mainly because Autolayout loves to decide to do things that don't look /anything/ like what IB shows me). While this would otherwise be a tie, the difference is that there's literally nothing the code can't do that xibs can, so getting comfortable with code pays off more in the long run. Also, Apple dogfoods the code approach. They aren't even huge into IB on iOS themselves.

Doc Block posted:

While I was literally swearing at Xcode and autolayout last night while working on my OS X app, it has made certain things easier. And if I ever want to internationalize, I can't imagine the headaches of having to do a dynamic layout based on the content size of labels etc. in code.

Set one of the translation languages to have all capital Ws instead of the normal letters for your first approximation of a worst case scenario. If you have variable-size text, size it and then measure (this is the "right" way to do it, but it can be slow and main-thread-blocking unless you're using AsyncDisplayKit).

# ? Jan 6, 2015 06:18

Doc Block: Apr 15, 2003; Fun Shoe

Doctor w-rw-rw- posted:

Same but in reverse for me with regards to IB. Tedious, error-prone, and seems pointless to waste hours getting IB stuff pixel-perfect (mainly because Autolayout loves to decide to do things that don't look /anything/ like what IB shows me). While this would otherwise be a tie, the difference is that there's literally nothing the code can't do that xibs can, so getting comfortable with code pays off more in the long run. Also, Apple dogfoods the code approach. They aren't even huge into IB on iOS themselves.

I'm a visual person. It's really, really hard for me to think of how something will look and how big it'll be just by looking at numbers stuffed inside CGRectMake(). I can have a notion of it in my head, draw it out on paper, and then when it comes time to plug the frame sizes etc. into the UI code the values will be way off.

Plus, having to actually look up the properties for various UI widgets makes it slower and even more tedious. And I'm bad at remembering them. Finding them via autocomplete in Xcode is manageable for UIKit, but often borders on impossible for AppKit.

Doctor w-rw-rw- posted:

Set one of the translation languages to have all capital Ws instead of the normal letters for your first approximation of a worst case scenario. If you have variable-size text, size it and then measure (this is the "right" way to do it, but it can be slow and main-thread-blocking unless you're using AsyncDisplayKit).

This isn't a good solution IMHO. Some languages are more terse than others, and phrases can be much longer (or shorter) if they have to be rewritten to make sense in the translation. The best solution is to figure out what size the text is going to be at runtime, and move everything around based on that, and that's the kind of thing autolayout is for.

As to Apple dogfooding the UI-in-code approach, Apple was pretty vocal about telling developers to get on the Autolayout train at the last 2 WWDCs. Now that they've come out with phones in different sizes, plus possibly having a new iPad screen resolution (if the 12" iPad Pro rumors are true), it's easy to see why. Plus, now they have kinda-sorta-but-not-really deprecated having different UIs for iPhone/iPad and introduced size classes (and totally done away with rotations in favor of just changing size classes, except on iPad where there's no size class change because gently caress You), it's only going to get harder to get away without using autolayout.

While I think it's really cool that Facebook has the engineering resources and talent to do stuff like AsyncDisplayKit, I'm one guy. I work on my apps in my free time, by myself. Anything that increases my productivity is gonna be big help.

Doc Block fucked around with this message at 09:31 on Jan 6, 2015

# ? Jan 6, 2015 07:36

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Doctor w-rw-rw- posted:

Facebook and especially Facebook Paper: https://www.youtube.com/watch?v=ZdiBPHpxGd0&t=390s

If anyone's looking at this and thinking "I'm not watching a long-rear end video just to see what the hell he's talking about", it's like 2min and is a good idea and you should watch it.

# ? Jan 6, 2015 08:55

Froist: Jun 6, 2004

Doc Block posted:

Plus, having to actually look up the properties for various UI widgets makes it slower and even more tedious. And I'm bad at remembering them. Finding them via autocomplete in Xcode is manageable for UIKit, but often borders on impossible for AppKit.

This applies the opposite way around too - as someone who knows the property names, it can be frustrating trying to find them in the IB UI (if they even exist).

Doc Block posted:

As to Apple dogfooding the UI-in-code approach, Apple was pretty vocal about telling developers to get on the Autolayout train at the last 2 WWDCs. Now that they've come out with phones in different sizes, plus possibly having a new iPad screen resolution (if the 12" iPad Pro rumors are true), it's easy to see why.

To me this was just posturing and/or accounting for developers who'd assumed there would only be one phone width and fully hardcoded the whole layout. My current company's main app is a complete code-based layout with no autolayout (as we still support iOS 5) yet it worked fine on the iPhone 6/6+ with no changes except dropping in @3x graphics. I can't claim any responsibility for that as it was written before I joined (and long before larger iPhones were even rumoured), but the notion that autolayout is required is false.

In the end I think it comes down to preference and how your mind works. If I'm making a quick test app to prove something I'll do it in IB just to create the controls quickly, but I've never used it for production. I must admit that I've never learned autolayout properly due to backwards compatibility requirements at the last two places I've worked, but equally given the above I don't see a huge value in investing the time to learn it either. As Doctor w-rw-rw- says, IB's also caused horrific merge conflicts in my experience and it's basically impossible to diff/version control.

Doctor w-rw-rw- posted:

The technique I use is layout specs - have an object whose only inputs are frames or other measurements directly relevant to layout (or states that are relevant to updating the UI), and whose outputs are the frames, etc. that you set directly into whatever views you're laying out. Then write a layout method that does all of the layout calculations for you. Your layout is now unit-testable and well-encapsulated. It's a simple manner to adjust it for different sizes as needed.

~~Have you got any links to examples of this pattern?~~ (edit: I took pokeyman's advice and see it was talked about in your linked video - sorry!)

I was working on a side project last year and thought I'd invented this design myself, but I didn't get it working quite right for some reason. Then I think I hit a stage in life where I lost interest in side projects and never finished it

. I still think it's a great, unique idea/style (as do the people I showed it to) but it's missing a core gameplay hook that would make it more "fun". Then again Papers, Please doesn't sound the most interesting concept, so maybe I should revive it..

Froist fucked around with this message at 09:08 on Jan 6, 2015

# ? Jan 6, 2015 09:05

Doc Block: Apr 15, 2003; Fun Shoe

Froist posted:

In the end I think it comes down to preference and how your mind works. If I'm making a quick test app to prove something I'll do it in IB just to create the controls quickly, but I've never used it for production. I must admit that I've never learned autolayout properly due to backwards compatibility requirements at the last two places I've worked, but equally given the above I don't see a huge value in investing the time to learn it either. As Doctor w-rw-rw- says, IB's also caused horrific merge conflicts in my experience and it's basically impossible to diff/version control.

Autolayout can be done in code. It's terrible.

# ? Jan 6, 2015 09:30

Doctor w-rw-rw-: Jun 24, 2008

Doc Block posted:

Autolayout can be done in code. It's terrible.

At one point a UI for something I was working on had xib autolayout, code autolayout, and Core Animation running an animation on a constraint - at the same time. :suicide:

# ? Jan 6, 2015 09:57

dc3k: Feb 18, 2003; what.

Doctor w-rw-rw- posted:

I can't imagine doing any significant amount of Autolayout, period.

On iOS, IB fights the developer more often than the developer fights it. It's terrible for merge conflicts when they happen, things are often over-constrained or ambiguous for any UI that's more than a little complex, and loading xib files and storyboards still crashes the gently caress out of Xcode. All. The. Goddamn. Time.

I have worked on several very large and complex apps, all using either xibs or storyboards and autolayout. Zero problems "fighting with IB", constraints are easy if you know what you're doing with them, terrible merge conflicts a thing of the past if you're at least a tiny bit careful, and the only time a storyboard has ever crashed XCode is when someone hosed up a merge conflict.

Storyboards and autolayout sucked rear end when they first came out, but I like them a lot now that they aren't awful and I learned how to use them. Writing layout in code is a gigantic pain in the rear end most of the time in comparison.

# ? Jan 6, 2015 15:23

Kallikrates: Jul 7, 2002; Pro Lurker

I see several people basically saying "storyboard and auto layout in interface builder are bad because I do those tasks in code". I have yet to see numbers showing storyboards/autolayout were ever the bottleneck that caused an app I worked on to drop frames. (and we have areas of our apps where async kit was not up to the task). I can say of the last 4 - 5 apps I've worked on performance bottle necks never benchmarked down to autolayout or storyboard loading.

The app I'm working on right now even lazy loads a whole storyboard from another (with navigation controller vc hierarchy + autolayout) in response to a continuous user gesture and drops no frames on the bottom end device range. The animation in response to the gesture is accomplished by modifying layout constraints.

The points I'll concede are source control, which can be totally removed by communication, and maybe reusable view components, which we tend to use xibs, or failing that custom UIviews in source. I can see the first point causing problems in large+ projects, but how many apps get that big? At that point you probably transcend the toolkit that is designed to handle the 95% cases.

Since when has a warty API stopped a cocoa developer?

# ? Jan 6, 2015 16:12

dc3k: Feb 18, 2003; what.

I half retract my statement about code crashing from IB. It doesn't often crash, but depending on controller complexity it takes an unreasonable amount of time to fully load. Stupid beach ball thing

# ? Jan 6, 2015 16:42

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Is there a name for this UI thing? "scroll view Parallax Header" and related is what I've been googling, but I get things related to making an image at the top of a table view large as you scroll down. Basically, you have a scroll view that the user can swipe between view left & right. To indicate that there are more views to the right, a bit of a header view from the next view is shown, and it moves into the center above the next view as the user scrolls to it. Here's a picture which hopefully makes sense:

Any suggestions on what this is called, and does anyone know of any libraries that do this already so I don't have to suffer through making my own with my rusty iOS skills?

# ? Jan 6, 2015 16:49

lord funk: Feb 16, 2004

I just like searchable views / layout objects and properties. IB always seemed to obscure target action connections and view properties. I don't like hunting for a bug only to find that a checkbox in IB was setting some tab bar to translucent or something.

# ? Jan 6, 2015 16:52

Kallikrates: Jul 7, 2002; Pro Lurker

Lumpy posted:

Is there a name for this UI thing? "scroll view Parallax Header" and related is what I've been googling, but I get things related to making an image at the top of a table view large as you scroll down. Basically, you have a scroll view that the user can swipe between view left & right. To indicate that there are more views to the right, a bit of a header view from the next view is shown, and it moves into the center above the next view as the user scrolls to it. Here's a picture which hopefully makes sense:

Any suggestions on what this is called, and does anyone know of any libraries that do this already so I don't have to suffer through making my own with my rusty iOS skills?

I don't think there is an out of box thing for this, Interactive transitions or push and pop transitions might get you close, but will require some custom work to get the navigation bar to do what you want.

# ? Jan 6, 2015 17:13

brap: Aug 23, 2004; Grimey Drawer

The sad part is that Facebook's engineers do so much to make things more efficient on iOS, but they just misuse the resources they get from that and in the end their app fucks up resource usage and battery life so badly that I just don't install it and use the mobile site instead.

Obviously xibs and storyboards involve some performance hit when views load but I don't believe that it can be the difference between an app being smooth and an app being slow and unpleasant to use.

I also don't understand why people are that interested in putting out updates to 1-3% of iOS users.

# ? Jan 6, 2015 18:05

TheReverend: Jun 21, 2005

Welp, I think I'm really hosed.

I wanted to start learning how to communicate via bluetooth.

We use a lot of sensors in my company that communicate over bluetooth with binary data. It's essentially bluetooth sockets.

I've done this before with Windows Mobile and Android.

But it looks like I'm maybe super hosed because there is no SPP for iOS: http://support.apple.com/en-us/HT3647

So how hosed am I?

# ? Jan 6, 2015 21:49

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

TheReverend posted:

Welp, I think I'm really hosed.

I wanted to start learning how to communicate via bluetooth.

We use a lot of sensors in my company that communicate over bluetooth with binary data. It's essentially bluetooth sockets.

I've done this before with Windows Mobile and Android.

But it looks like I'm maybe super hosed because there is no SPP for iOS: http://support.apple.com/en-us/HT3647

So how hosed am I?

Bluetooth LE is open and available to anyone. It should be very suitable for sensors assuming your sensors support it.

Regular Bluetooth requires membership in the MiFi hardware program and costs $$$.

# ? Jan 6, 2015 22:27

TheReverend: Jun 21, 2005

Ender.uNF posted:

Bluetooth LE is open and available to anyone. It should be very suitable for sensors assuming your sensors support it.

Regular Bluetooth requires membership in the MiFi hardware program and costs $$$.

The sensors are old and use RFCOMM regular assed bluetooth.

How much $$$ are we talking for MFI? Any idea?

# ? Jan 6, 2015 22:28

Dr Monkeysee: Oct 11, 2002; just a fox like a hundred thousand others; Nap Ghost

demonR6 posted:

Here is a stupid iOS question I have that I was hoping someone here could help with since our corporate IT is worthless. We use iPads for our sales staff and they have a number of pre-loaded apps and shortcuts to websites, everything is managed through MobileIron. The issue is with the recent update to iOS 8 the icons we were using for the bookmarks are all broken and look like the screen below, the bookmarks still work fine though.

I have people around me who think something is broken so naturally they delete the shortcuts but one of them happens to lead to the internal app store so now they are hosed and the only way to correct that is by re-enrolling their device in MobileIron so it pushes out all the shortcuts and apps to their devices again. Any insight would be appreciated, I would not be surprised if it is something simple but then again.

I've seen this happen with any bookmark icon after an OS update. In my experience opening the bookmark causes iOS to refetch the image (usually the site's favicon) and fix the bookmark icon automatically.

# ? Jan 6, 2015 22:39

demonR6: Sep 4, 2012; There are too many stupid people in the world. I'm not saying we should kill them all or anything. Just take the warning labels off of everything and let the problem solve itself.; Lipstick Apathy

I was just about to give an update. The update to iOS 8 included.. wiping the icons folder to install new icons thus everything we installed went poof!

# ? Jan 6, 2015 23:47

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

TheReverend posted:

The sensors are old and use RFCOMM regular assed bluetooth.

How much $$$ are we talking for MFI? Any idea?

No clue; it used to be a big-manufacturer-only and minimum six-figure thing but lately I see random startups with officially-licensed stuff. You'd have to contact Apple to find out.

# ? Jan 7, 2015 01:21

Doctor w-rw-rw-: Jun 24, 2008

Kallikrates posted:

I see several people basically saying "storyboard and auto layout in interface builder are bad because I do those tasks in code". I have yet to see numbers showing storyboards/autolayout were ever the bottleneck that caused an app I worked on to drop frames. (and we have areas of our apps where async kit was not up to the task). I can say of the last 4 - 5 apps I've worked on performance bottle necks never benchmarked down to autolayout or storyboard loading.

An engineer wrote a bar that turned red when frames had just been dropped and some metadata about the frame droppage. He was able to get a trace during the times frames were dropped and there was an autolayout resolution chain inherited from some Facebook app (the main one) over 40 calls deep. When that was eliminated, frames dropped less. I obviously didn't keep stuff from a year ago around, but autolayout was pretty much directly responsible.

By "async kit" do you mean AsyncDisplayKit? If you're dropping frames with ASDK, you're probably doing something horribly wrong, like redrawing a hierarchy on every frame, or using CALayer shadows, which would be a horrible mistake whether you did it with CALayers or UIViews, too.

Kallikrates posted:

The app I'm working on right now even lazy loads a whole storyboard from another (with navigation controller vc hierarchy + autolayout) in response to a continuous user gesture and drops no frames on the bottom end device range. The animation in response to the gesture is accomplished by modifying layout constraints.

And it'll probably be fine until you have analytics, Crashlytics, network requests, database, json parsing, image decoding, animation, and layout code all running at the same time. Throw in a web view, maybe. Rich media applications with a lot of stuff going on /will/ have performance issues on older devices, period.

Kallikrates posted:

The points I'll concede are source control, which can be totally removed by communication, and maybe reusable view components, which we tend to use xibs, or failing that custom UIviews in source. I can see the first point causing problems in large+ projects, but how many apps get that big? At that point you probably transcend the toolkit that is designed to handle the 95% cases.

Anecdotally: for three of my last four jobs, IB and vanilla UIKit has failed to completely rise to the challenge, requiring instead some creativity. The other job was me doing Android.

# ? Jan 7, 2015 06:35

brap: Aug 23, 2004; Grimey Drawer

I guess it's just sad to think that you have to work in a way completely different than what apple recommends if you want the best performance. But maybe that's the nature of software development.

What kind of learning curve do you anticipate for developers new to this style coming on to a project or for future maintainers after the original developers leave?

# ? Jan 7, 2015 06:44

Kallikrates: Jul 7, 2002; Pro Lurker

Doctor w-rw-rw- posted:

An engineer wrote a bar that turned red when frames had just been dropped and some metadata about the frame droppage. He was able to get a trace during the times frames were dropped and there was an autolayout resolution chain inherited from some Facebook app (the main one) over 40 calls deep. When that was eliminated, frames dropped less. I obviously didn't keep stuff from a year ago around, but autolayout was pretty much directly responsible.

We have the same thing, and all our "red bar moments" were traced to events triggered outside UIKit. UIKit chugging was just a symptom.

Doctor w-rw-rw- posted:

By "async kit" do you mean AsyncDisplayKit? If you're dropping frames with ASDK, you're probably doing something horribly wrong, like redrawing a hierarchy on every frame, or using CALayer shadows, which would be a horrible mistake whether you did it with CALayers or UIViews, too.

AsyncDisplayKit doesn't support enough text attachment options for us. Also what it does support needed to be a static known size calculable outside of UIKit both non-starters for us. We did like the idea of pre-calculating and caching attributed string layout for very long/complex attributed strings. I know it's your baby, but we didn't use it because it didn't gain us anything, not because we didn't want to write more code.

Doctor w-rw-rw- posted:

And it'll probably be fine until you have analytics, Crashlytics, network requests, database, json parsing, image decoding, animation, and layout code all running at the same time. Throw in a web view, maybe. Rich media applications with a lot of stuff going on /will/ have performance issues on older devices, period.

Yeah that's nice, we have all this stuff and 60ps even with fancy rich media I guess we are magic. We even have a few more processing intensive tasks not on this list. Most of the apps I've been involved with are very pull/consume interaction based but I don't thing that matters. You like to assume people in the thread work on toy apps with no users. Oh and gifs, we are trendy, we have those..

Doctor w-rw-rw- posted:

Anecdotally: for three of my last four jobs, IB and vanilla UIKit has failed to completely rise to the challenge, requiring instead some creativity. The other job was me doing Android.

I will say anecdotally that collection views and their varieties are probably bad for anything but very small collections/ very simple cells. Everything else has been perfectly serviceable. Apple really likes to push them and I fall for that trap every time. We've have some engineering challenges also brought up by ambitious designs but we've been able to make them work within UIKit and the apple toolset. But its fine that it doesn't work for some people.

# ? Jan 7, 2015 07:37

Doctor w-rw-rw-: Jun 24, 2008

Kallikrates posted:

AsyncDisplayKit doesn't support enough text attachment options for us. Also what it does support needed to be a static known size calculable outside of UIKit both non-starters for us. We did like the idea of pre-calculating and caching attributed string layout for very long/complex attributed strings. I know it's your baby, but we didn't use it because it didn't gain us anything, not because we didn't want to write more code.

To be clear, it's something I used and made some fixes to; not quite my "baby" (not that I'm not enamored with it, though - fair point).

I assume you're talking about Wash Post? I would be interested to know specifically what kinds of things you want to do that it doesn't support, so I can forward said issues to a dev actively working on it.

Kallikrates posted:

Yeah that's nice, we have all this stuff and 60ps even with fancy rich media I guess we are magic. We even have a few more processing intensive tasks not on this list. Most of the apps I've been involved with are very pull/consume interaction based but I don't thing that matters. You like to assume people in the thread work on toy apps with no users. Oh and gifs, we are trendy, we have those..

Again, assuming you're talking about Wash Post...
1. No you don't
2. As implemented I would call it a toy app if I were feeling charitable.

Wash Post looks very reasonable in quality at first glance, but the UI complexity is fairly low - not that low complexity is a bad thing or high complexity is a good thing . It's just not the kind of thing that should strain UIKit. It's also not a very dynamic UI (gestures, animations) at all; the navigation is totally bog-standard (which doesn't count against it).

There are a plethora of bugs, many of which I found minutes after launching it, and more which only revealed them as I started to dive a bit deeper.

Side-swiping on what I assume to be a UIPageViewController is noticeably slow - I can really feel the sluggishness when side-swiping through stories. On a 6+, being that slow is a sin. On older devices, your claims don't pass muster. I'm getting constant frame drops even on the simple table view on the app's home screen. Even after image loading + decoding the framerate is noticeably choppy on a bare iOS install on an iPod 5G on which no other apps are running. Scrolling is noticeably un-smooth until text rendering has completed. Resuming from sleep causes a notable multi-second delay during which an article isn't scrollable. The interactive pop gesture drops more frames than it keeps when stuff is loading. Scroll to top drops a ton of frames. The share dialogue has to actually load, which is baffling and a bad user experience. Your status bar in the photo mode in articles is transparent. Some identical photos show twice. Inline photos can't be expanded. The UI blocked for several seconds, then the app rating dialog box showed up and was totally unresponsive for multiple seconds and lots of furious pushing on the no thanks button.

It didn't even take long to find these (EDIT: as in, find in the app and take screenshots):

Also, the way 'more' is implemented to explore more sections and also in terms of expanding said categories, and also in terms of loading more stories in the table view - they're awkward to use and poorly designed. Also, videos don't play inline, they open the OS-default player - standard, but worse than many webpages.

Judging from what few screenshots I could find, I'm surprised that the design hasn't substantially changed in at least one, or possibly even two years, which would be okay if there were substantial feature work, which the iTunes version history seems to contradict. No wonder the entire mobile team was fired.

Kallikrates posted:

I will say anecdotally that collection views and their varieties are probably bad for anything but very small collections/ very simple cells. Everything else has been perfectly serviceable. Apple really likes to push them and I fall for that trap every time. We've have some engineering challenges also brought up by ambitious designs but we've been able to make them work within UIKit and the apple toolset. But its fine that it doesn't work for some people.

I was initially skeptical of collection views for similar reasons, but it's pretty manageable as long as you're not resizing / re-laying out and triggering a re-rasterization on each frame. That's a performance killer no matter when you do it.

Doctor w-rw-rw- fucked around with this message at 10:56 on Jan 7, 2015

# ? Jan 7, 2015 10:53

Kallikrates: Jul 7, 2002; Pro Lurker

Doctor w-rw-rw- posted:

Again, assuming you're talking about Wash Post...

Wrong assumptions again.

Of all our apps I'm least happy with the iPhone app, the bulk of it's code is years old and much of it was written by contractors. Even in it's state it has hundreds of thousands of sessions a day, but focus has been elsewhere (for better or worse). Alot of the bugs you mention are content issues or business requirements, another thing I wish we had was a better relationship between with the backend folks (garbage in...). For example we don't get pre shortened urls on some API so the share dialog has to hit a shortening service before loading for various reasons.

# ? Jan 7, 2015 14:01

Doctor w-rw-rw-: Jun 24, 2008

Kallikrates posted:

Wrong assumptions again.

Of all our apps I'm least happy with the iPhone app, the bulk of it's code is years old and much of it was written by contractors. Even in it's state it has hundreds of thousands of sessions a day, but focus has been elsewhere (for better or worse). Alot of the bugs you mention are content issues or business requirements, another thing I wish we had was a better relationship between with the backend folks (garbage in...). For example we don't get pre shortened urls on some API so the share dialog has to hit a shortening service before loading for various reasons.

In that case I'm actually looking forward to whatever you release after to see the build quality and how you built it.

If you do get buttery smooth media on vanilla UIKit it would be great to hear how you approached the more challenging bits for performance.

# ? Jan 7, 2015 16:53

mrbass21: Feb 1, 2009

Despite the arguments going on, how do I get this level of knowledge? Is it just through experience where you had to slam your face in a wall and overcome the inadequacies? Any resources I should read to be less dumb?

I've been doing iOS for a while now, but a lot of my UI is stock and without many (if any) animations, and I haven't really branched or have a great understanding of the foundations. Maybe the answer is as simple as "stop being a lazy jerk, and read Apples documentation".

# ? Jan 8, 2015 04:35

Doctor w-rw-rw-: Jun 24, 2008

mrbass21 posted:

Despite the arguments going on, how do I get this level of knowledge? Is it just through experience where you had to slam your face in a wall and overcome the inadequacies? Any resources I should read to be less dumb?

I've been doing iOS for a while now, but a lot of my UI is stock and without many (if any) animations, and I haven't really branched or have a great understanding of the foundations. Maybe the answer is as simple as "stop being a lazy jerk, and read Apples documentation".

That's one of the things you can do. Try re-implementing a useful library you're using, and see what kind of decisions went into it and what you could do better. Learn about the APIs it uses.

# ? Jan 8, 2015 05:01

lord funk: Feb 16, 2004

Doctor w-rw-rw- posted:

Try re-implementing a useful library you're using, and see what kind of decisions went into it and what you could do better. Learn about the APIs it uses.

I can second this. I've grown disillusioned about the usefulness of the stock UI elements, and reimplementing a few has given me some nice experience.

# ? Jan 8, 2015 13:55

Just-In-Timeberlake: Aug 18, 2003

As a beginner to this I've taken to looking at apps and trying to figure out how they do certain things. I'm currently trying to figure out how Shazam does it's display when it finds a song. So when it ids a song, it brings up a screen with the band picture up top (1/2 displayed, if you pull down the picture lightens up and slides down to reveal the whole thing), there's a "header" bar under that that slides up and docks to the top as you scroll down and a bunch of other items down below.

I'm most interested in the top part (band pic/header bar), is it some UITableView trickery or something else?

# ? Jan 8, 2015 19:04

dc3k: Feb 18, 2003; what.

Just-In-Timeberlake posted:

As a beginner to this I've taken to looking at apps and trying to figure out how they do certain things. I'm currently trying to figure out how Shazam does it's display when it finds a song. So when it ids a song, it brings up a screen with the band picture up top (1/2 displayed, if you pull down the picture lightens up and slides down to reveal the whole thing), there's a "header" bar under that that slides up and docks to the top as you scroll down and a bunch of other items down below.

I'm most interested in the top part (band pic/header bar), is it some UITableView trickery or something else?

You can do it with a UIScrollView + its didScroll delegate method. I did it recently with great results. I can post some sample code later tonight if you need something to work off of.

# ? Jan 8, 2015 19:49

Just-In-Timeberlake: Aug 18, 2003

status posted:

You can do it with a UIScrollView + its didScroll delegate method. I did it recently with great results. I can post some sample code later tonight if you need something to work off of.

That would be great, thanks.

# ? Jan 8, 2015 20:20

Kallikrates: Jul 7, 2002; Pro Lurker

More generally UIScrollviews are a good base for lots of interactions that take place with panning gestures. There are alot of delegate calls to listen to and build out, and they perform well. I think every year apple does a whole wwdc session about doing interesting with scrollviews.

# ? Jan 8, 2015 20:35

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Kallikrates posted:

I think every year apple does a whole wwdc session about doing interesting with scrollviews.

They do and they are excellent, watch them!

# ? Jan 9, 2015 02:34

brap: Aug 23, 2004; Grimey Drawer

I guess I'm skeptical about people saying you should reimplement fundamental features from scratch. That goes against conventional wisdom, that the standard library solution is likely to be more efficient than whatever you write.

# ? Jan 9, 2015 05:24

Doh004: Apr 22, 2007; Mmmmm Donuts...

Merely as an exercise to learn and practice. I don't think anyone is suggesting you write a replacement for UIScrollViews.

# ? Jan 9, 2015 05:30

Doctor w-rw-rw-: Jun 24, 2008

fleshweasel posted:

I guess I'm skeptical about people saying you should reimplement fundamental features from scratch. That goes against conventional wisdom, that the standard library solution is likely to be more efficient than whatever you write.

The point is to better understand the decisions made while building features, not to create something better.

# ? Jan 9, 2015 05:40

lord funk: Feb 16, 2004

Yeah but I wrote my own UIAlertView because I was tired of the uncustomizability of the thing, and the fact that I wanted it to visually match my app. Same with UIPopoverController, and I'm much happier for it.

If I get a chance, UITabBar - you're next.

# ? Jan 9, 2015 15:04

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 18:15

Doh004: Apr 22, 2007; Mmmmm Donuts...

Anyone super familiar with NSCalendar and NSDateComponents?

I'm trying to get the date of the Sunday from a specific week; however, it's returning the Saturday instead:

code:

NSDateComponents *nowComponents = [calendar components:NSCalendarUnitYear | NSCalendarUnitWeekday | 
NSCalendarUnitHour | NSCalendarUnitMinute | NSCalendarUnitSecond | NSCalendarUnitMonth | 
NSCalendarUnitWeekOfMonth | NSCalendarUnitTimeZone | NSCalendarUnitWeekday fromDate:december31];

NSDateComponents *lastSundayComponents = [NSDateComponents new];
[lastSundayComponents setYear:nowComponents.year];
[lastSundayComponents setMonth:nowComponents.month];
[lastSundayComponents setWeekOfMonth:nowComponents.weekOfMonth];
[lastSundayComponents setWeekday:1];
[lastSundayComponents setHour:0];
[lastSundayComponents setMinute:0];
[lastSundayComponents setSecond:1];

Calling

code:

[calendar dateFromComponents:lastSundayComponents];

Gives me the Saturday, December 28th 2014 instead of Sunday, December 29th 2014.

lastSundayComponents looks like this:

code:

<NSDateComponents: 0x17014e0d0>
    Calendar Year: 2014
    Month: 12
    Hour: 0
    Minute: 0
    Second: 1
    Week of Month: 5
    Weekday: 1

So everything looks in order, right?

Doh004 fucked around with this message at 20:12 on Jan 9, 2015

# ? Jan 9, 2015 19:46

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »