|
Having never done sotryboards yet (new things scare me!) I have a question about handling transitioning to views works. I have an app with a "main screen" and you can select an item from several categories, and you go to a details screen for the item. The item has a relationship to other items that is shown on the detail screen that they can tap on to view details on *that* item, which may or may not be in the same category. If it's in the same category, I can just stay on the same view controller and swap out the item. If it's in a different category, I need to bring up a different kind of view controller. Since the user can in theory do an "endless" chain of views (picks an item of type A, then on it's details screen picks item of type B, then on the new details screen picks item of type C, then picks item of type B, etc.) I want to avoid a UINavigationController since I could get hundres of views on the stack. So, my question is if I have transitions / segues to these new views without a UINavigationController, will they "replace" one another, or will I be building up a huge stack of view controllers if the user follows a chain of 100 items?
|
#
?
May 31, 2012 20:56
|
|
|
|
| # ? May 16, 2024 21:21 |
|
|
ManicJason posted:I didn't see anything in leaks at a glance and didn't expect to since this was a circular reference, not a leak. The object never deallocating when I freed my one strong reference was the problem. Hmm, no, you're right. You do this through Allocations — if you can find the allocation, there should be an arrow to the right of the address, and you can click through that to find the alloc/retain/release history. It doesn't seem to be any different in ARC.
|
|
#
?
May 31, 2012 21:57
|
|
|
Outside of Apple's documentation, are there any guides/resources of particular use involving storyboards and custom transitions, perhaps with some sample code? As far as I can tell, you're supposed to create a custom class that inherits from UIStoryboardSegue and override the perform method, but in doing some quick Google searches, I didn't seem to find any completely up-to-date guides. e: Sorry if this is a dumb question; I'll keep reading up in the meantime. double sulk fucked around with this message at 05:37 on Jun 1, 2012 |
|
#
?
Jun 1, 2012 05:19
|
|
|
So I wanted to get peoples opinions on this route for getting into iOS programming, as well as some suggestions. I do a lot of graphic design work and I really want to go from misc. art to actually producing something someday, and I'm not afraid to take the long route if I have to. First my goal: I would love to produce a mobile game. Its not about making money, as much as being able to work on something as a hobby, and eventually putting out a product I can say "wow I made that!" I'm not looking to turn this into a career. I started by learning a little c, and now that I am on a mac I went through BNR "Objective-c programming" which was an awesome book (a lot of outside tutorials I read were confusing, or simply omitted information at the whim of its author). I got done, looked to get into something simple right away and realized the book only covers some fundamentals, and there is still a giant world of skills and concepts left over! my first question: what are some simple projects I can put together to help strengthen what I already know? Now, my next question is about where I should go next. I was considering picking up the iOS book that BNR puts out, but I wanted to see if there were any other recommendations that might be better before I drop the cash. I was also considering grabbing wenderlich's book on cocos2d if the price was right - again wanted to see if its worth the moola. I guess my fear right now as a novice is that I'm learning the code I read in the book, and why I used said code, but I'm not learning to apply what I've learned in a new/creative setting.
|
|
#
?
Jun 1, 2012 07:28
|
|
|
Has apple given any indications if and when they are going to start restoring save location dialogues to things? Months and months after I first started complaining about not being able to find the iphone simulators screen shot location (its not on the desktop, and its not in the ~/Library/Application Support/Developer/Shared/Xcode/Screenshots location either) I *still* cant figure out where they are going. This business about not letting people save/name files is a total loving useability nightmare. I had to talk my father out of selling his mac over the stupid missing save dialogues because he just doesn't believe its apropriate for serious use anymore if he's not allowed to file things as he likes it anymore. I tend to agree, and when we discussed the issue at the perth Useability SIG pretty much everyone else agreed that its a disaster of an idea. And in this case a total show stopper.
|
|
#
?
Jun 1, 2012 07:34
|
|
|
Coldrice posted:So I wanted to get peoples opinions on this route for getting into iOS programming, as well as some suggestions. I do a lot of graphic design work and I really want to go from misc. art to actually producing something someday, and I'm not afraid to take the long route if I have to. Let me just chime in to say that Ray Wenderlich's Cocos2D book is terrible. Do not under any circumstances pick it up. I literally had to stop reading it because it was so awful, and I kept thinking, "There has to be a better way to do that..." at the code samples. It's bad, don't read it. Just remember to start small. Do your best to get a good grasp on C, Objective-C, and general programming concepts. Don't make your Big Idea your first project. For iPhone-specific programming, I got started by reading one of the earlier editions of Beginning iOS 5 Development.
|
|
#
?
Jun 1, 2012 07:51
|
|
|
rjmccall posted:Hmm, no, you're right. You do this through Allocations — if you can find the allocation, there should be an arrow to the right of the address, and you can click through that to find the alloc/retain/release history. It doesn't seem to be any different in ARC. I know exactly where you are describing, and I have seen retain and release statements there before under non-ARC several months ago (the last time I had a similar memory issue). Only alloc and frees show up at the moment. If I have time I may dig around to see if this is ARC-related or just yet another outright broken feature in the newest XCode to go along with both gimped debuggers. Coldrice posted:First my goal: I would love to produce a mobile game. Its not about making money, as much as being able to work on something as a hobby, and eventually putting out a product I can say "wow I made that!" I'm not looking to turn this into a career.
|
|
#
?
Jun 1, 2012 17:06
|
|
|
duck monster posted:Has apple given any indications if and when they are going to start restoring save location dialogues to things? The hierarchical file system is a relic and it's only going to get more obscure and special purpose from here on out. If anything, the success of iOS has shown that the vast majority of users don't want to know anything about files. There are vastly superior ways to organize the things most people care about than a tree of directories with files at the leaf nodes.
|
|
#
?
Jun 1, 2012 20:11
|
|
|
I tried it and it saves the screenshots to my desktop. Also, there's always Edit->Copy Screen.
|
|
#
?
Jun 1, 2012 20:45
|
|
|
the talent deficit posted:The hierarchical file system is a relic and it's only going to get more obscure and special purpose from here on out. If anything, the success of iOS has shown that the vast majority of users don't want to know anything about files. There are vastly superior ways to organize the things most people care about than a tree of directories with files at the leaf nodes. Says loving who? "Save everything in a random pile" is not superior in any known regard to "organizing poo poo". Apples experiment with removing save dialogues have pretty much proven this, and honestly the lack of file organization on ios is whats stopped me from being able to use it for anything serious outside of "testing poo poo for my clients". The thing is you can't just remove file locations and not replace it with anything!
|
|
#
?
Jun 2, 2012 02:33
|
|
|
Doc Block posted:I tried it and it saves the screenshots to my desktop. Yeah it doesn't save it to my desktop, or in the library /app support/blah location either. I have a feeling it might just be silently failing out.
|
|
#
?
Jun 2, 2012 02:35
|
|
|
Go to Utilities->Console and see what if it says anything when you try to save a screenshot. When taking screenshots of the actual computer, they get saved to your desktop. It only makes sense that the simulator would also save them to the desktop. It even uses a similar naming convention ("iOS Simulator Screen Shot Whatever Date.png"). Chill out. edit: I'm not aware of Apple removing save dialogs from any of their OS X applications. Pages still has it, so does Numbers, TextEdit, even Preview. Create a new document and when saving Pages will let you put it wherever your OCD heart desires. Open an existing one and instead of "Save As..." you get "Duplicate", which just makes the purpose more obvious, so that users aren't always hitting "Save As..." instead of "Save" and getting 5 different copies of the same document unless they actually want to do that. Doc Block fucked around with this message at 04:10 on Jun 2, 2012 |
|
#
?
Jun 2, 2012 04:04
|
|
|
I think I read someplace that one of the Xcodes has a bug that it doesn't actually save screenshots. I forgot which one though.
|
|
#
?
Jun 2, 2012 04:05
|
|
|
duck monster posted:Says loving who? Having layered folder structures is already just a more clumsy way of doing this.
|
|
#
?
Jun 2, 2012 04:08
|
|
|
That's not Duck's objection though. We had this argument I think earlier in the thread, and philosophically I agree a whole lot with Apple in that users should not have to give a poo poo about files. They don't really need to know what the gently caress is going on outside whatever app they're using. But also, developers do have to give that poo poo, and if the iOS simulator saves the screenshots in some random location without feedback, thats bad design. Actually thats bad design whether or not its a dev thing.
|
|
#
?
Jun 2, 2012 04:19
|
|
|
I'm pretty sure you can run iosnoop in terminal and just filter by pid, but that's really hacky.
|
|
#
?
Jun 2, 2012 04:41
|
|
|
Carthag posted:That's not Duck's objection though. We had this argument I think earlier in the thread, and philosophically I agree a whole lot with Apple in that users should not have to give a poo poo about files. They don't really need to know what the gently caress is going on outside whatever app they're using. If you only use all those files in one app, sure. What if I want to e-mail a document and a spreadsheet to someone? Then those files can't be locked in to their respective apps. The other problem is that we're all used to files now, and messing with that paradigm without replacing it with something better really breaks things for people. On topic: Anyone taken the Big Nerd Ranch class? Was it worth it? Khelmar fucked around with this message at 04:45 on Jun 2, 2012 |
|
#
?
Jun 2, 2012 04:41
|
|
|
I can see both sides of the argument. That said, it feels like we've been cut off cold turkey.
|
|
#
?
Jun 2, 2012 04:47
|
|
|
Khelmar posted:If you only use all those files in one app, sure. What if I want to e-mail a document and a spreadsheet to someone? Then those files can't be locked in to their respective apps. I guess there's three levels to this. End users who don't need to know anything and basically should be locked down in a parent filter. "Power" users who need/want to look at files and so they should be able to get at those through some setting. And devs, who basically have to look at the files, it's our job. If it would all work as it should (and right now it does not, but still, the idea of it), end users would not have a problem. Even files of different formats would be ready to open by whatever apps recognized their types, like in the old days with the 4-letter codes on an SE/30, when any app would just know that the file was a PICT or whatever. And I also think right now, I'm in the dark. Hopefully WWDC will clear all this up. People are freaking out on the cocoa-dev list too a bit.
|
|
#
?
Jun 2, 2012 05:34
|
|
|
This all belongs in a separate thread, but the vast majority of developers have serious blinders on when it comes to the file system. The file system api is literally just two methods, GET and PUT. While this simplicity is alluring for developers and implementers, it has serious flaws when it comes to consumers. Almost every traditional 'desktop' OS application punts when it comes to dealing with the complexities of where to keep files. Most provide a single default location to store ALL files generated by the application. You can sort by date of creation, date of last access, date of last modification, or name (in a single flat namespace) but nothing else without a separate store of metadata. Any sort of organization is punted to end users. Users are asked to organize and provide metadata with no tools other than the file's path and name. Developers work around this problem with conventions (like rails app layouts, the unix filesystem hierarchy standard and metadata stores built on top of the file system like git) and tools (like grep and find). The average user maybe uses directories or file names as primitive tags but mostly has to rely on their own memory or a lot of hunting for half remembered files. Meanwhile, the technology exists to allow for queries more complex than `GET /pictures/myexgirlfriends/sarah/naked/3.jpg`. What if you want to see all the naked pictures of all your exgirlfriends? Or all naked pictures you have? Or just the ones taken at the beach? Or just the naked pictures of your exgirlfriends taken in 2007 and 2010-2012 but not 2008 and only the pictures from 2009 that feature girls who weren't killed in a gruesome car accident? Good luck expressing that with GET and PUT. Apple's implementation of new APIs for what we call files is still primitive and has it's own issues (like convoluted shared access amongst users/applications), but at least they're a step towards something better. Finally, the best and most compelling reason the file system is dumb and should be abandoned for better, richer abstractions is this: You can emulate hierarchical file systems on top of virtually any database with almost zero effort, but you can't emulate a database on top of the file system without literally writing your own database implementation.
|
|
#
?
Jun 2, 2012 07:24
|
|
|
Khelmar posted:If you only use all those files in one app, sure. What if I want to e-mail a document and a spreadsheet to someone? Then those files can't be locked in to their respective apps. If you want to email a document, just email it. This is already possible and always has been. There's also a facility in iOS to open a file with any application that's registered to handle it. The only drawback is that, currently, those applications have to save copies, they can't overwrite the file they are handed. This will almost certainly change. We replaced files with something better decades ago. They're called databases.
|
|
#
?
Jun 2, 2012 07:27
|
|
|
A flat database of files where every file must be correctly tagged is still putting a lot of the organizational burden on the user. Sure, some tags can be auto generated, like pulling date and time from JPEG EXIF data (assuming you trust that the user has the correct date set on their camera). Anything that can't be automatically generated will have to be typed in by the user, and typing in a long list of tags sucks and is something most people won't do (or will only do sparingly). And good luck if they mistyped a tag.
|
|
#
?
Jun 2, 2012 12:36
|
|
|
I'm trying to add a setting in my app to override the system language and set it to English. That is to say, it is a properly localized app, but some users would prefer to have the app in English without having to set their entire iPad to English. What I don't understand is why setting the NSUserDefaults like this: Objective-C code:Objective-C code:
|
|
#
?
Jun 2, 2012 22:10
|
|
|
So I can't seem to find a proper answer on this storyboard segue stuff, and while every single thing I can find seems to indicate that all data passing occurs from within - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender, I'm using that and it doesn't seem to even be able to get current values from items I have. It really seems like no one has a single clue about how storyboards are supposed to actually work, or that no one wants to use them and there isn't much information out there about how they work. I'm not 100% certain whether or not you need to write a subclass of UIStoryboardSegue if you want to write any custom segue that consists of anything more than push a button and a new view shows up. I know the option is there to select a custom segue in IB's inspector, but it then assumes that you have written a UISS subclass. Based on everything I've read through various searches, you're supposed to do something like the following (the game is a basic Hiragana/Katakana memory thing): Objective-C code:It just seems like no one uses storyboards and they're a horrible waste of time, because no one has their information straight, and even Apple's documentation seems kind of scares regarding them. Update: Solved the issue, sort of. It seems that the easiest solution was to create a variable string which is set in the prepareForSegue method, after which point is used in the "game" view to initialize objects based on what was selected prior. Perhaps a bit hacky, but at least it functions as it should, for now. double sulk fucked around with this message at 06:08 on Jun 3, 2012 |
|
#
?
Jun 2, 2012 23:15
|
|
|
lord funk posted:I'm trying to add a setting in my app to override the system language and set it to English. That is to say, it is a properly localized app, but some users would prefer to have the app in English without having to set their entire iPad to English. Maybe it first checks to see if the "AppleLanguages" NSUserDefaults key is set, and if not it falls through to whatever the system-wide preferred language is.
|
|
#
?
Jun 3, 2012 00:44
|
|
|
For downloadable content via in-app purchases, I had anticipated just downloading the content from a server. However, security is a concern. Is there a commonly used method for securing the content so it's not pirated? Naturally, it would seem that the content wouldn't do a user any good if they can't get it into the app itself or force the app to install the content in sqlLite- but still. Has anyone encountered this concern? Also, I'm making an app in which levels are comprised of what you might expect, an xml file with loads of small graphics. Does it make sense for the downloadable content to be zip files that are unpacked inside the app or would it be best to download the files separately?
|
|
#
?
Jun 3, 2012 05:02
|
|
|
Download them in a ZIP, to save download time and bandwidth. You could even use PhysFS or zziplib to just read the files out of the ZIP without having to unpack them (though it's slower). IIRC StoreKit has some kind of authentication mechanism that can be used by 3rd party servers for exactly this purpose. Instead of just directly downloading the content, send the authentication receipt or whatever to a script on your server, and have the server only send the content if everything is A-OK, otherwise send back 404 status or something. Don't do the verification on the device. To stop pirates from having one person buy it and everybody else copying it to the app's DLC folder, don't assume the presence of your DLC means it's OK to use it. Instead, when the user buys it, save something somewhere (and not just an sqlite database; somewhere a cracker will have a harder time modifying) that says they bought it. Maybe in the keychain or something. And don't be lame and require a check every time the game is run. If the content is present, and whatever record of the purchase you've saved says they bought it, let 'em use it. Obviously, you'll also have to check for purchases when the app is run. So that if they remove your app but later re-install it, or buy the DLC on another device, they don't have to buy it again. (remember to update your purchase records in the keychain or whatever) Doc Block fucked around with this message at 05:30 on Jun 3, 2012 |
|
#
?
Jun 3, 2012 05:27
|
|
|
Good advice. I was planning on saving an index of the content in SqlLite so if they put the info in the DLC folder they still wouldn't be able to run it unless the content was obtained properly.
|
|
#
?
Jun 3, 2012 14:33
|
|
|
Doc Block posted:Maybe it first checks to see if the "AppleLanguages" NSUserDefaults key is set, and if not it falls through to whatever the system-wide preferred language is. I guess, but how then could I get the system language preference? Without that, I don't know if I can implement a settings toggle in my app to switch back and forth from English.
|
|
#
?
Jun 3, 2012 16:34
|
|
|
klem_johansen posted:Good advice. I was planning on saving an index of the content in SqlLite so if they put the info in the DLC folder they still wouldn't be able to run it unless the content was obtained properly. SQLite databases are trivially easy to modify, though. There are a number of programs for opening and modifying SQLite databases. The SQLite source code even comes with a command line app that will let you open a database and run SQL commands on it. And since the cracker will almost certainly have a terminal app or an SSH daemon installed, they don't even need to copy your database to their computer to modify it. That's why I suggested storing it in the keychain instead.
|
|
#
?
Jun 3, 2012 17:17
|
|
|
Doc Block posted:SQLite databases are trivially easy to modify, though. There are a number of programs for opening and modifying SQLite databases. The SQLite source code even comes with a command line app that will let you open a database and run SQL commands on it. And since the cracker will almost certainly have a terminal app or an SSH daemon installed, they don't even need to copy your database to their computer to modify it. Good idea. Thanks.
|
|
#
?
Jun 3, 2012 17:31
|
|
|
This morning I was playing my game in bed. I fumbled my phone, it hit my face, and I lost. But then I eventually secured ultimate victory by adding a shake-to-pause feature (which I wrote about in more detail).
Filburt Shellbach fucked around with this message at 23:59 on Jun 3, 2012 |
|
#
?
Jun 3, 2012 23:57
|
|
|
Can I record audio to a file in ObjC? I don't know C++, so CoreAudio is a mystery to me.
|
|
#
?
Jun 4, 2012 03:30
|
|
|
Filburt Shellbach posted:This morning I was playing my game in bed. I fumbled my phone, it hit my face, and I lost. But then I eventually secured ultimate victory by adding a shake-to-pause feature (which I wrote about in more detail). That's a cool idea. Gonna have to use it when I do a game. Also, discovered a bug in an update that has been sitting in review for a week. Figures  Here's to another week+ in review.
|
|
#
?
Jun 4, 2012 06:37
|
|
|
Sinestro posted:Can I record audio to a file in ObjC? I don't know C++, so CoreAudio is a mystery to me. Yes. AVFoundation. It's been a looong time since I used it but the solution will probably have something to do with AVAssetWriter and stuff. If I recall you basically hook up the way the data will flow, then you kick it and it starts funneling the outputs into the data inputs you give it. One such output is the AVAssetWriter. I think you can save it as a file, or straight to the user's library, or something - though I only ever used it with movie files, not audio-only files, so I could be totally off base here.
|
|
#
?
Jun 4, 2012 11:41
|
|
|
Doc Block posted:Maybe it first checks to see if the "AppleLanguages" NSUserDefaults key is set, and if not it falls through to whatever the system-wide preferred language is. This is correct - just checked. If you set the NSUserDefaults @"AppleLanguages" to nil before pinging the NSLocale, it resets. Works as expected now!
|
|
#
?
Jun 4, 2012 17:00
|
|
|
Sinestro posted:Can I record audio to a file in ObjC? I don't know C++, so CoreAudio is a mystery to me. You don't need to know C++ to use Core Audio, it's a C-based API. You should use something higher level if possible though, which I'm certain you can for such a simple operation. I'm not familiar with AVFoundation but that sounds like it'll work.
|
|
#
?
Jun 4, 2012 21:56
|
|
|
Doc Block posted:For iPhone-specific programming, I got started by reading one of the earlier editions of Beginning iOS 5 Development. Matt Neuburg's Programming iOS 5 is excellent too, I've nearly finished it. Learned a bunch from it, probably will learn more on a second read-through. It starts assuming no knowledge of anything and teaches you basic C, then basic Objective-C, and it's a good few chapters before you run your first iOS app. Worth a look even if you (think you) already know what you're talking about.
|
|
#
?
Jun 5, 2012 05:33
|
|
|
How do you guys deal with the ios5 data storage guidelines? Between the tech QA1699, QA1719 and the various guidelines, there seems to be partially conflicting information. What's the best way to store these kinds of data (directories and flags):
Bonus question #1: Now also consider supporting iOS 5.0 and iOS 4.2 Bonus question #2: Does file sizes make a difference? 1 megabyte vs 100, for example. For example, QA1699 hints that an app may create folders with custom names under Library, while other guides seem to point only to Library/Application Support or Library/Cache. And Documents should only ever be used for data created as a "document" on-device?
|
|
#
?
Jun 5, 2012 20:00
|
|
|
|
| # ? May 16, 2024 21:21 |
|
|
What are you stuck on? QA1719 seems to lay it out nicely for you. Everything in your list needs to be backed up and kept under low storage conditions, so that means ~/Documents. If you can live without the data being backed up, Library/Private Documents with the extended attribute set.
|
|
#
?
Jun 6, 2012 05:41
|
|