5 ms·

>> For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic base

>> For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) I disagree with most of this. Laying out views was a mess for a while but auto layout is easy to get right once you understand the fundamentals (especially when used in storyboards). Springs and struts is old pre-autolayout tech which shouldn't be used. CALayer is the lower level object that UIView is based on. Not sure what the complaint is here (they're mostly unrelated to autolayout/springs and struts). As for CoreData it's a pretty simple way to manage your data. When originally introduced to iOS it was a mess but I've used it extensively in the last few years, first through a higher level framework (MagicRecord I think?) and now directly and it providing you exercise some care around threading it performs very well, especially for something simple like offline data storage.

jakeva 9y ago
As a ten year vet of Cocoa and Cocoa touch, I agree with your counterpoints. A lot of stuff is simply legacy.
bsaul 9y ago
Ever tried to have 60fps on a tableview with constraint-based layout cells ? CALayer is definitely not legacy, it's often the only way to get smooth animation. Spring n struts is also sometimes the best way to get fast position for smooth scrolling. Ever had to deal with Core Data migration on an app that needs to evolve throughout the year ? Migration is a mess, and so is concurrency. My personal conclusion after having used Core Data on a pro application for 4 years, is that most of the time i really don't need a database and so i'm back to file-based backups for my app's data. Works well, no magic, and no performance or threading issue.
- saagarjha 9y ago
  > Ever tried to have 60fps on a tableview with constraint-based layout cells Yes. I've found AutoLayout to be acceptable in this case, provided you're not doing something awful.
  - melloclello 9y ago
    We ran some casual benchmarks on this at work once, and it's important to note that the performance of AutoLayout dramatically improves based on the degree of nesting you employ. If you have sixteen views on a cell and their locations all depend upon each other, it's going to take a long time to solve those constraints. But if you can break up the cell, say into four subviews with four elements inside them, it's likely to be faster (no guarantees, though)
    - throwaway91111 9y ago
      Yup, it's easiest if you understand what the solver is doing and help point it towards solutions/find them trivially. Unfortunately, i had to write my own constraint system and practice with it a lot to use AutoLayout with high performance where i was confident i was not introducing significant re-layout performance problems.
- LeoNatan25 9y ago
  > Ever tried to have 60fps on a tableview with constraint-based layout cells ? Yes, even on a 4S.
- mmargerum 9y ago
  I came to the same conclusion WRT core data. I'm caching data myself to files. I would use SQLite directly if I need a real data store before I would use code data again
aplummer 9y ago
Hey on the struct serialisation thing, try the new codable feature, it's so great. I can probably delete 20% of my code in swift 4!
acmecorps 9y ago
How in the world did you managed to use storyboard? I hate using it for moderate-complex UI apps. This guy say it better than me on why I hate storyboard (especially the first reason): https://www.youtube.com/watch?v=g6yz5oX5iWc https://www.youtube.com/watch?v=g6yz5oX5iWc FWIW, if you like and good at it, more power to you.
- k-mcgrady 9y ago
  I use it in combination with programmatic UI for more complex things but find it's so much easier and faster when doing auto layout to just use storyboards.
  - bsaul 9y ago
    The real reason for which i stopped using them is that it doesn't work well with git. As soon as you've got more than one people in the team, it's over.
    - acmecorps 9y ago
      Absolutely right. This right here is the killer for me.
    - jakeva 9y ago
      It is actually a solvable problem if you're willing to dig into the details of the file changes. It isn't pleasant, but welcome to life. Team members can make conflicting changes as long as someone is willing to dig through the mud to make them all agree with each other. I've been doing it personally for a long time, it isn't my favorite part of the job but it does enable significant parallel productivity.

jakeva 9y ago

As a ten year vet of Cocoa and Cocoa touch, I agree with your counterpoints. A lot of stuff is simply legacy.

bsaul 9y ago

Ever tried to have 60fps on a tableview with constraint-based layout cells ? CALayer is definitely not legacy, it's often the only way to get smooth animation. Spring n struts is also sometimes the best way to get fast position for smooth scrolling. Ever had to deal with Core Data migration on an app that needs to evolve throughout the year ? Migration is a mess, and so is concurrency. My personal conclusion after having used Core Data on a pro application for 4 years, is that most of the time i really don't need a database and so i'm back to file-based backups for my app's data. Works well, no magic, and no performance or threading issue.

saagarjha 9y ago
> Ever tried to have 60fps on a tableview with constraint-based layout cells Yes. I've found AutoLayout to be acceptable in this case, provided you're not doing something awful.
- melloclello 9y ago
  We ran some casual benchmarks on this at work once, and it's important to note that the performance of AutoLayout dramatically improves based on the degree of nesting you employ. If you have sixteen views on a cell and their locations all depend upon each other, it's going to take a long time to solve those constraints. But if you can break up the cell, say into four subviews with four elements inside them, it's likely to be faster (no guarantees, though)
  - throwaway91111 9y ago
    Yup, it's easiest if you understand what the solver is doing and help point it towards solutions/find them trivially. Unfortunately, i had to write my own constraint system and practice with it a lot to use AutoLayout with high performance where i was confident i was not introducing significant re-layout performance problems.
LeoNatan25 9y ago
> Ever tried to have 60fps on a tableview with constraint-based layout cells ? Yes, even on a 4S.
mmargerum 9y ago
I came to the same conclusion WRT core data. I'm caching data myself to files. I would use SQLite directly if I need a real data store before I would use code data again

aplummer 9y ago

Hey on the struct serialisation thing, try the new codable feature, it's so great. I can probably delete 20% of my code in swift 4!

acmecorps 9y ago

How in the world did you managed to use storyboard? I hate using it for moderate-complex UI apps. This guy say it better than me on why I hate storyboard (especially the first reason): https://www.youtube.com/watch?v=g6yz5oX5iWc https://www.youtube.com/watch?v=g6yz5oX5iWc FWIW, if you like and good at it, more power to you.

k-mcgrady 9y ago
I use it in combination with programmatic UI for more complex things but find it's so much easier and faster when doing auto layout to just use storyboards.
- bsaul 9y ago
  The real reason for which i stopped using them is that it doesn't work well with git. As soon as you've got more than one people in the team, it's over.
  - acmecorps 9y ago
    Absolutely right. This right here is the killer for me.
  - jakeva 9y ago
    It is actually a solvable problem if you're willing to dig into the details of the file changes. It isn't pleasant, but welcome to life. Team members can make conflicting changes as long as someone is willing to dig through the mud to make them all agree with each other. I've been doing it personally for a long time, it isn't my favorite part of the job but it does enable significant parallel productivity.