|
Toady posted:It's not proper design to treat the app delegate as an Everything Container, but it's common anyway. Yeah I'm guilty of this, but my rule of thumb is that stored objects have to be related to the app lifecycle in some way. So my audio engine is housed there because it is turned on / off for app state changes. Same with my CMDeviceMotion instance and master UITabBarController. The header gets peppered with a bunch of readonly properties and a few on / off switch methods related to those objects, but it's not that unreasonable. edit: oh and my open UIDocument. No idea where that would be better stored.
|
#
?
Mar 18, 2015 22:23
|
|
|
|
| # ? Jun 8, 2024 01:49 |
|
|
I'm cool with a core component of the application living there as long as a ton of logic doesn't exist in the actual app delegate.
|
|
#
?
Mar 18, 2015 22:47
|
|
|
It's reasonable to have top-level components that are tied to the application's life cycle or don't have any other owner. The problem is treating the delegate as an application-wide storehouse that everything goes through +sharedApplication to access, which can be difficult to maintain and refactor. iOS developers are notorious for this.
|
|
#
?
Mar 18, 2015 23:25
|
|
|
The strategy we are using at my day job is that we have an ApplicationDependencies object. This is initialized as a result of the ApplicationDelegate. The job of the ApplicationDependencies on initialization is to initialize all of the various things like the database connection, and so on. The ApplicationDelegate tends to be passed to the main View Controllers, but when anything is instantiated, it is just handed what things in the ApplicationDependencies it needs. From a testing perspective, each object only knows about the dependencies it has, and those can be easily mocked. Though aside from a logger, there are very few things your entire application actually needs, and if you're thinking of making say, your database connection a singleton, you may want to reconsider your architecture from an MVC/MVP perspective. When you build the model, pass in the database connection object (or better, a facade for the things you need to do with the database). That facade can be built up in the ApplicationDependencies. While at a certain point I'm not entirely happy with the ApplicationDependencies strategy (still feels too much like a singleton), it works pretty well so long as you keep your classes small. (And if you don't keep your classes small, then I have no good advice for you, because large classes are in my opinion generally antithetical to good code).
|
|
#
?
Mar 19, 2015 00:10
|
|
|
Snapchat A Titty posted:What's wrong with this snippet? No idea, but a couple points: - you need an auto release pool. @autoreleasepool { } around the outermost scope in your main() function. - have you tried printing out the library object? NSLog(@"%@", library);
|
|
#
?
Mar 19, 2015 01:25
|
|
|
geera posted:Is it generally considered OK to use the app delegate as a universal holding area for objects you might need to access anywhere in the app (like a database connection, logger, etc)? Are singletons a reasonable alternative for some of those shared purposes? I've tinkered with iOS development and I've been wondering where people put commonly-used objects like that. I use a different pattern, where I have a Session Service, Session Provider, and Session object. The Session object can only be created by the Session Service, and can only be accessed from a Session Provider. The Session Provider is instantiated by the owning scope, i.e. whatever retains it, like a UIViewController or a UIView. When it's initialized, it subscribes to the Session Service; when it's dealloc'd it unsubscribes (aka RAII). That's how I've managed to not need any global state (on a language/ObjC runtime level) except for the Session Service (which is set up by the app delegate). I've also made it so that the initializer for the provider has an update block, so when someone i.e. logs in / logs out, literally everything that cares will be triggered by the login and update itself. But as a convenience, you can just access the .session property on the provider. You can also create one temporarily to only last until it falls out of (lexical) scope and gets cleaned up. When the view or the view controller dies, so too does its subscription, wherever it is. Been working fantastically for me so far. Doctor w-rw-rw- fucked around with this message at 02:00 on Mar 19, 2015 |
|
#
?
Mar 19, 2015 01:57
|
|
|
I'm going to break a bit of NDA to say that installing 10.10.3 seed broke my code signing process, which was to build everything without signing as an archive, then my update script would run codesign --force --deep on the whole bundle after copying it to a temporary location. Now codesign crashes itself on that. It also revealed a lot about my project that was broken when I was attempting to fix it. First I enabled code signing on release builds for all of my frameworks and bundles, and manually signed all of the third party .dylib files I use. Then I noticed a bunch of the original PlugIn .bundle projects I imported when I originally took over the project were spuriously copying headers into the .bundles, which is a no-no, because headers can only be signed in frameworks. Then I noticed the third party framework I was using for Growl, supplied by the official developer, had an obsolete and therefore broken signature on it, so I replaced the signature with my own instead. Then I changed my update script, which modifies the main .app bundle's Info.plist to insert the Mercurial revision number and short hash string into the version string for the application, so that it merely shallow force resigns the bundle, instead of attempting the crashable deep sign. Also, because my original signing practice used a signing script that force resigned the whole app bundle if spctl -a failed, without any limit for failures, due to a deep signing issue I already had in the past (lovingly called fucking_sign_it.sh) it would crash in the middle of the signing, dropping a .cstemp file in a random place where it failed, then it would try to sign and fail somewhere else, dropping another .cstemp file somewhere. Resulting mess would spill about five or six temp files across the bundle, then hang on the last attempt. Oh well, it's probably for the better that I do it this way anyway.
|
|
#
?
Mar 19, 2015 05:58
|
|
|
Doc Block posted:No idea, but a couple points: I've found this, appears I need to sign the app. Maybe some other day  http://stackoverflow.com/questions/16597284/using-new-ituneslibrary-framework-to-access-itunes-library-on-mac-os-x
|
|
#
?
Mar 19, 2015 16:13
|
|
|
Dumb question, but if you go with Metal for graphics, you're only supporting A7 chips and higher. What happens in the store if someone gets your app with an <A7 device? Can they download it? Are you supposed to gracefully switch to OpenGL for them?
|
|
#
?
Mar 22, 2015 21:31
|
|
|
You can put in Info.plist that your app requires Metal. You could also only ship a 64-bit binary, since Metal isn't supported on 32-bit devices. But it'd sure be nice if your app didn't require Metal just yet. Which means failing over to OpenGL if it can't initialize a Metal context (which would only happen on an unsupported device).
|
|
#
?
Mar 22, 2015 23:16
|
|
|
Doc Block posted:You can put in Info.plist that your app requires Metal. Doc Block posted:But it'd sure be nice if your app didn't require Metal just yet. Which means failing over to OpenGL if it can't initialize a Metal context (which would only happen on an unsupported device). Of course, but with limited resources the idea of using only one GPU framework is attractive. Plus I'm always looking at a long development period, so given a bit more time it wouldn't sting as much.
|
|
#
?
Mar 22, 2015 23:28
|
|
|
Maybe, but people keep their iPads way longer than they keep their iPhones.
|
|
#
?
Mar 23, 2015 03:52
|
|
|
Doc Block posted:Maybe, but people keep their iPads way longer than they keep their iPhones. If making a Metal-only app gets just one of them to burn their iPad 3, then it will all be worth it.
|
|
#
?
Mar 24, 2015 00:42
|
|
|
I still use an iPad 3 
|
|
#
?
Mar 24, 2015 00:57
|
|
|
Doc Block posted:I still use an iPad 3 I own and use a launch week iPad 1. as far as I'm concerned, Apple canceled iOS after 5.1.4, and we're all better off for it.
|
|
#
?
Mar 24, 2015 01:06
|
|
|
I'm not thrilled about all of it, and iOS definitely needs a Snow Leopard-style polish release (including a revisit of some of the My First User Interface Design and My First Adobe Illustrator Project stuff that came in with iOS 7), but iOS 8 is pretty good. Plus, as a developer, things are vastly better than the iOS 5 days in almost every respect.
|
|
#
?
Mar 24, 2015 02:29
|
|
|
Snow Yosemite is needed as well.
|
|
#
?
Mar 24, 2015 05:46
|
|
|
Is there a way to retrieve standard iconography? Specifically I want to grab the texture for the "share" button and load it into an OpenGL texture. Or am I better off just taking a screenshot and faking it?
|
|
#
?
Mar 24, 2015 09:53
|
|
|
UraniumAnchor posted:Is there a way to retrieve standard iconography? Specifically I want to grab the texture for the "share" button and load it into an OpenGL texture. Or am I better off just taking a screenshot and faking it? I've not seen a way of grabbing the image at runtime, but I've used iOS Artwork Extractor which will dump all the image resources from the simulator. This way you can at least bundle the real image with your app rather than relying on screenshots.
|
|
#
?
Mar 24, 2015 10:12
|
|
|
Doc Block posted:I still use an iPad 3 What I would really like to see is the Mac equivalent of this graph. Like using an iPad 3 would be the same as using a Powerbook G3 or something.
|
|
#
?
Mar 24, 2015 15:21
|
|
|
lord funk posted:What I would really like to see is the Mac equivalent of this graph. Like using an iPad 3 would be the same as using a Powerbook G3 or something. It's probably not that accurate, but Mactracker has the iPad 3 Geekbenching 760, which is first beaten by a 1.5 GHz Powerbook G4 (807).
|
|
#
?
Mar 24, 2015 15:29
|
|
|
carry on then posted:It's probably not that accurate, but Mactracker has the iPad 3 Geekbenching 760, which is first beaten by a 1.5 GHz Powerbook G4 (807). Right but the difference between the iPad 3 and the Air 2 is around 1/7 to 1/10 according to this. So I want to know which laptop is 1/10 the speed of the new Macbook Pro, for example. edit: and the Mac chart doesn't seem to go that low.
|
|
#
?
Mar 24, 2015 15:39
|
|
|
Anyone else use Xcode server and bots to run CI? If so, anyone know how to get environment variables in the trigger? I want to get a variable from a config file in the repo into the script.
|
|
#
?
Mar 24, 2015 16:16
|
|
|
Anyone else going to f8 tomorrow? Excited for the iOS talks.
|
|
#
?
Mar 25, 2015 07:17
|
|
|
TC-11 2.0 released today!       Some codes so you guys can check it out.  ARAJFTRW6YW6 7HNAKXFKLRAT LPFPLHNYXMW6 R6FMJ3PRPE9X N6RH4FT7KXH4
|
|
#
?
Mar 25, 2015 20:09
|
|
|
Congrats! Will play with it later tonight.
|
|
#
?
Mar 25, 2015 22:25
|
|
|
Doctor w-rw-rw- posted:Anyone else going to f8 tomorrow? Excited for the iOS talks. I'm assuming you're quite pleased about this one? quote:To tackle this challenge, we wanted a better abstraction. We drew inspiration from React and its functional reactive programming model for building UI and made a native, Objective-C++ library called ComponentKit which is now used to render News Feed in the Facebook iOS app. https://code.facebook.com/posts/1415586422080360/introducing-componentkit-functional-and-declarative-ui-on-ios
|
|
#
?
Mar 26, 2015 00:30
|
|
|
^^^ oh my god this would completely solve all of the problems I'm currently having with scroll performance via overly complicated UI components written by assholes
|
|
#
?
Mar 26, 2015 00:50
|
|
|
Is it really necessary to use "Objective-C++" because that sounds like some wacky poo poo. edit: this page explains it http://componentkit.org/docs/why-cpp.html but I still kinda wish they had built it for swift or something, even though swift's short existence and quirks so far can be difficult-- they've precluded swift interop by incorporating c++. brap fucked around with this message at 02:46 on Mar 26, 2015 |
|
#
?
Mar 26, 2015 02:34
|
|
|
lord funk posted:TC-11 2.0 released today! Claimed the last one, as I was feeling lazy and didn't want to have to enter more than one. I've been meaning to check this out for a while!
|
|
#
?
Mar 26, 2015 03:53
|
|
|
fleshweasel posted:Is it really necessary to use "Objective-C++" because that sounds like some wacky poo poo. That's the biggest disappointment; the platform language is Objective-C, not Objective-C++. All of the things they cite have clear alternatives or workarounds that are idiomatic. I think the people leading the project just like C++ and decided to use it, then came up with a post-hoc rationalization. To my knowledge no one has come up with a decent implementation for doing powerful animation with React-style UI frameworks and it doesn't look like they solved that problem here either. edit: I like the framework OK and I like React a lot too; they just feel like stepping stones toward a much better UI framework design that we haven't reached yet.
|
|
#
?
Mar 26, 2015 04:38
|
|
|
fleshweasel posted:Is it really necessary to use "Objective-C++" because that sounds like some wacky poo poo. For a project that prioritizes predictability, performance, and stability, and wants to reach the maximum number of devices (note that they mentioned Feed at 60fps on iPhone 4), Swift was, is, and will remain a terrible choice up until the point that a stable version of it can run well on the oldest iOS device supporting the current OS revision minus 1. Don't get me wrong, I like the language, but the merits of Swift do not yet outweigh its lack of ubiquity and C++'s decades of improvements. Ender.uNF posted:That's the biggest disappointment; the platform language is Objective-C, not Objective-C++. All of the things they cite have clear alternatives or workarounds that are idiomatic. I think the people leading the project just like C++ and decided to use it, then came up with a post-hoc rationalization. Stack allocated objects, syntax, and type-safety. Stack allocated objects is a big deal. Objective-C++ was already used in several places in the fbios codebases. I occasionally use it in mine. If you can do Objective-C, you can do Objective-C++, and while there may be zero pressing need to use it, there's no good reason to totally avoid it except in the case that your codebase is so large it would blow up compile times by a noticeable number of minutes. Avoiding it means you're avoiding good poo poo to help you program better. Personally (and to harp on this yet again), the argument that I accept most quickly as to why it uses C++ is that it can then stack allocate class instances. A small stack allocated C++ class vs. a NSObject is a no-brainer if you're making and destroying butt-tons of small classes all the time. Doctor w-rw-rw- fucked around with this message at 05:17 on Mar 26, 2015 |
|
#
?
Mar 26, 2015 05:14
|
|
|
Cool, React Native released too: https://github.com/facebook/react-native
|
|
#
?
Mar 26, 2015 19:49
|
|
|
|
|
#
?
Mar 26, 2015 21:58
|
|
|
As true a point as that is, is it this steve streza speaking? 
|
|
#
?
Mar 26, 2015 22:10
|
|
|
No idea. I just thought it was a funny, relevant thing that I only saw because Marco Arment retweeted it. I have no idea who the guy in the picture you posted is, either.
|
|
#
?
Mar 26, 2015 23:13
|
|
|
ASDK is /probably/ dead, dying, or if it's neither, in limbo, so that leaves React Native and Components. I'd take Objective-C++ over Javascript in a heartbeat. Seems like an easy choice - if you don't like using/want to use Javascript, use Components. Also, declarative layout FTW, so you kind of win either way with React Native or Components.
|
|
#
?
Mar 27, 2015 06:15
|
|
|
Is there some display controller out there that will allow me to display big files? I have a ~270 MB PDF that I'm trying to display for the user and my applications memory usage is low (20 MB or so), but as the UIDocumentInteractionController loads the PDF, I get memory warnings, and then the controller stops loading the PDF (but doesn't crash). The file opens while running in simulator, but that uses system memory. I tried in GoogleDrive and Dropbox to see if other programs had trouble with it. GoogleDrive crashes trying to open it, and DropBox actually does display the file. Is there some controller out there that can handle really large files, or did DropBox just write their own?
|
|
#
?
Apr 1, 2015 17:27
|
|
|
I would say that it's more a function of the view displaying the PDF than the containing controller. For something that large I would make sure it's a CATiledLayer Backed view, theoretically it should do the work for you of only reading the visible chunks into memory. if not there is an api for digging into that.
|
|
#
?
Apr 1, 2015 21:14
|
|
|
|
| # ? Jun 8, 2024 01:49 |
|
|
Kallikrates posted:I would say that it's more a function of the view displaying the PDF than the containing controller. For something that large I would make sure it's a CATiledLayer Backed view, theoretically it should do the work for you of only reading the visible chunks into memory. if not there is an api for digging into that. I need users to be able to open many file types (iWorks, MS Office, PDF, Pictures, anything iOS supports). Will that approach work for all files? It seemed like for the CATiledLayer to work I had to write some code to handle a PDF and it might not work for everything. Is that accurate or "Google harder, my son"? I assume for PDFs and Images, I could take that approach, but all the others would need custom controllers to display them? The project is in it's early phase and I just need something that will work for the majority of cases as I go. I can come back to work on "What if the user tries to view a file that's stupid large". mrbass21 fucked around with this message at 22:22 on Apr 1, 2015 |
|
#
?
Apr 1, 2015 22:12
|
|