|
Zhentar posted:Also their code example showing how much easier it's supposed to be compares to ridiculously roundabout, obfuscated code. They just copied the code from this blog post. They probably copied that code into their framework too, and stuck it in that method call. You know, like any sane person would do anyway.
|
#
¿
Apr 5, 2011 21:21
|
|
|
|
| # ¿ Apr 29, 2024 14:44 |
|
|
UraniumAnchor posted:Yeah the guy I was talking to said he was under the impression it was too slow for game logic on an iOS device, but if Angry Birds uses it extensively then maybe he misheard. Or maybe the person he talked to was just a bad programmer. There are apps that have DLC with code included in the download (C64). You'd be fine. The restrictions exist to prevent you from providing an interface to the scripting engine to the user.
|
|
#
¿
Apr 9, 2011 06:24
|
|
|
Sir Davey posted:Is this the place to ask about AppStore rejection? While this isn't the most helpful to you now, in the future your contract should stipulate that if the app is rejected due to policy (as opposed to bugs or using private APIs) you aren't responsible for the work necessary to fix the design and are still supposed to be paid. If your finished code fits their spec it isn't your problem if the spec isn't an allowed app. That said, I think you are right that more non-advertising content is probably what's necessary here. But you should make sure that any future work you do on this is paid and try to get them to agree to pay you regardless of the acceptance status. I did a contract app and when we had finished the app it came out that Apple didn't want to allow that entire class of app. Him not paying me there would have been a huge dick move.
|
|
#
¿
Apr 24, 2011 02:23
|
|
|
I have written three separate UITableView interfaces in my app to do the Most Common Thing in iOS programming. I've done it three different ways and I still have no idea what the best one is (but it's almost assuredly none of the ways I've done it). I can't find any reasonable article on StackOverflow or the rest of the internet that gives me some good guidelines. Basically, I want a table view that lets me tap an item to do something to it, or bring up a details page (maybe I will make long-press do the other thing, I'm kind of wobbly on this aspect) and tap an edit button to let me rearrange, delete or insert things, as well as editing rows when tapped. Bonus points if I can figure out how to customize the behavior of swipe-to-delete to offer some other button in there, too, or maybe detect the swipe from the other side. I'm using FetchedResultsControllers for all these screens - My first crack at this, I just stuck a "New" button up there in the navigation controller and implemented canEditRowAtIndexPath to get swipe to delete; I add a long-press gesture recognizer to cells as I prepare them for reuse (which seems like an awful hack, but maybe I just don't have the ObjC idioms implanted in my brain yet). I ended up using separate view controllers for the new item and the edit page, which is ugly but I haven't gone back to unify them and I still don't know a good way to do it anyway. My second try, I didn't need an entire screen for new/edit, so I just used a UIAlertView for that. I implemented it with an Edit button and adding an insertion row at the bottom. And that thing is temperamental as gently caress. First of all the apparently idiomatic way you implement these things feels like an awful hack by itself. Yes, let's add 1 to the count and make that a special row but only in edit mode. Wait, sometimes the table doesn't go into full edit mode - when you swipe to delete - but it still sends setEditing. So now when you swipe to delete a New Item row rocks on in, "Hi guys, what's up? I'm just down here waiting to crash you if you dare touch me." How the hell do you fix this? More on that later. Tapping the New Item brings up a UIAlertView with text input so you can name it. Name is the only user-editable property right now for these so I'm fine with that. It works, but I'm not happy with it, and that New Item thing is just awful. My third try, I needed an edit screen again, so I decided to try and take everything I've learned from these and put it together. Edit button with New Item thing showing up. In edit mode we tap to edit items, outside edit mode tap to buy the item. Swipe to delete still makes that New Item appear! So let's try to fix it... iOS calls willBeginEditingRowAtIndexPath/didEnd.. when this thing happens, so theoretically I just need to set a bit in there that says "don't add the insert row" and clear it in didEnd. Except that doesn't actually work, because the Edit button is still there, and now when you tap the Edit button who the hell knows what will happen? (The answer is crash.) I won't even get into how to make an edit item view. That's next, I'm still figuring that one out (although I have learned that static TableViews are amazing. Except when, apparently, they require being children of TableViewControllers, but only when compiled on SDK 7.1 or I assume basically any SDK other than 7.0, which is what I started this app on. Whoops guess you're spending a couple hours rewriting that edit view because you depended on a nested static table view and now it's a compile error.) I know that a lot of this is difficult only because it's actually easier to do interesting things with the API once you've gotten over those initial hurdles, but for being what seems like the most-used UI element in iOS, UITableView sure is a gigantic pain in the rear end. Hell, in the SDK documentation it talks about how to implement editing in a UITableView, and then it basically just punts and goes "You could implement it with a New Item row and an insertion control but instead let's do it this other way and never speak of that again." I can only assume that they were embarrassed at how ugly that code is and didn't want to draw attention to it. I can't wait to see what this app looks like in six months - five failed experiments in the wrong way to do everything and then whatever the last couple of screens I've coded are are the ones that actually look like they were written by someone who knows what she's doing. Dessert Rose fucked around with this message at 04:57 on Mar 18, 2014 |
|
#
¿
Mar 18, 2014 04:50
|
|
|
Ender.uNF posted:Let's complain about LLDB again: quote:
It's clearly printing self.view. Note "bounds = CGRect (0 0; 320 568);" which is the proper value of bounds that you discover later. quote:
I wouldn't expect that to work, either, because "po" didn't, but we're already in super-inconsistent land... quote:But what drives you really crazy? The inconsistency: I think I'd rather the debugger work as best it can when it can. Of course I'd like it to be better, but I'll take inconsistency from my debugger over inconsistency in the actual language. Xcode's interface over top of it is getting better, though. Those new visualizers for views and colors are sex. I'd really prefer that they put a UI over it so that I never have to drop to the CLI; I know three different ways to get the value of an object from the CLI, and as you point out, they're all slightly different. It'd be neat if I could have a text box that I just start typing an expression in and I get a visualizer window underneath that shows me the value of that expression. Bonus points if I can have a bunch of floating windows (or docked to the UI, whatever) that watch these values. I imagine just executing a bunch of expressions willy-nilly could be dangerous, though.
|
|
#
¿
Apr 6, 2014 21:14
|
|
|
Ender.uNF posted:Know how many times Visual Studio has failed to immediately show me *all* values of an entire object graph in the past 10 years? Zero. I have *never* had to fiddle with the debugger to get it to spit out values. Even for object, it inspects it and understands the real runtime type, shows me the inheritance chain, the properties on that object, and the properties inherited from the superclass (recursively). Let me guess, you never write native code. This is true of managed code, but I often have to fight VS's debugger in order to get it to work properly for C++. Compared to that, LLDB is... Well, not exactly a dream - as you say, it needs work - but it's pretty good.
|
|
#
¿
Apr 7, 2014 17:54
|
|
|
Kallikrates posted:sure you can, https://gist.github.com/zwaldowski/955123  Why is this a category on NSObject? Why are there identical instance and static versions of it? Why is the code clearly just copy pasted four times with minor tweaks to the "with an object" versions? He didn't even make the instance versions pass in the object it's being called on. And why is there a comment calling this a "nice clean implementation"??? God forbid you just define your own object. Oh wait he did but it isn't actually declared anywhere, instead he's abusing a closure as an object (see: closures are a poor man's objects, I guess) I bet he's so proud of how clever this implementation is. Dessert Rose fucked around with this message at 02:57 on Apr 11, 2014 |
|
#
¿
Apr 11, 2014 02:54
|
|
|
I'm writing an app that wants to play an alarm sound through silent mode even after I switch away from the app. I have this specific feature working through a combination of local notifications with a sound attached (for when despite all my efforts, my app is terminated), and background audio, creating an audio session and playing a silent sound through it until it's time to play the alarm sound. So far so good. But now that I've implemented this, I notice that when I open or switch to my app, it kills any other app that's playing music at the time, even if I'm not setting up to play an alarm. Ideally it wouldn't do that ever (or it would only when playing the alarm sound) but at the very least I don't expect it to happen when I'm not going to play an alarm. I only open my audio session when I'm preparing to play an alarm, and I close it when I'm not. Is there something I'm missing? edit: Okay, by setting the category in my didFinishLaunching method to AVAudioSessionAmbient I can at least avoid killing other apps' audio when switching to my already-running app, but it still does it on launch. I feel like there has to be a way to avoid it entirely. edit 2: I've come to the compromise of just setting my session to AVAudioSessionPlayback with MixWithOthers in my launch method. If I'm going to kill audio in other apps, I might as well do it as little as possible. Still looking for a way to not do it at all until the user asks for an alarm, though. Dessert Rose fucked around with this message at 03:33 on Jun 11, 2014 |
|
#
¿
Jun 10, 2014 19:26
|
|
|
I definitely cause other apps to stop playing audio on a fresh launch with that code and the audio UIBackgroundModes key. Maybe it's a bug?
|
|
#
¿
Jun 11, 2014 04:07
|
|
|
The 7 beta was what made me stop installing beta OSes on "production" devices.
|
|
#
¿
Jun 16, 2014 20:01
|
|
|
lord funk posted:It's enough to do this (t=0:16): Yeah, a naive player isn't going to see much benefit at first, but once you realize what it's actually keying off of (hit area size) it's a much better way to encode velocity than the previous y-position. I look forward to this showing up in iMaschine  The eraser is what blows my mind. Also, that was really fast. Dessert Rose fucked around with this message at 01:12 on Jun 19, 2014 |
|
#
¿
Jun 19, 2014 01:10
|
|
|
Speaking of stopping audio when starting, I finally found and fixed my bug with that - it turns out that I was calling prepareForPlayback in the init method of an object that one of my view controllers makes. That was preemptively starting my audio session and stopping everyone else. I only figured this out by following the apple bug report guidelines of making a small test app and noting that it worked there, then setting break points everywhere to see that hey, what do you know, didFinishLaunchingWithOptions is not even close to the first bit of my code that gets called on startup.
|
|
#
¿
Aug 6, 2014 21:53
|
|
|
kitten smoothie posted:Maybe so. They said you're subject to the same guidelines as App Store stuff so I assumed they were applying the same stringency. It says you have to go through a "beta app review" which I would assume is much lighter than a release app review.
|
|
#
¿
Sep 23, 2014 00:56
|
|
|
lord funk posted:This sounds like a Text from Xcode. "YOU SHOULD KNOW ALREADY jeez." Thank you for reminding me that I haven't looked at that site in a couple of years. So much queued up hilarity. It was very cathartic after dealing with Xcode suddenly deciding that my app identifier having capital letters in it meant I needed to either recreate my app ID on the portal or manually migrate all user data to the lowercased version, despite it having been totally fine since February. Dessert Rose fucked around with this message at 06:13 on Oct 19, 2014 |
|
#
¿
Oct 19, 2014 06:04
|
|
|
No, Xcode, you're right. Those simulators were just a waste of space. Also, definitely don't bother actually creating new ones when I ask. I'd rather stare at a beach ball.
|
|
#
¿
Oct 19, 2014 22:03
|
|
|
Cool Xcode UI design feature: Send Xcode into fullscreen mode. Note the location of the "Build and Run" shortcut (the far upper left) Now move your mouse into the upper left hand corner. Notice what is now in that location. If you bounce your mouse off the top of the screen and then click the button, you'll close the window, even if the animation hasn't finished yet.
|
|
#
¿
Oct 20, 2014 22:38
|
|
|
Doh004 posted:Just got put onto a completely differnet iOS project that's been in the works for ~4 months now by developers who have never done iOS development and they went full on with nibs and storyboards. I've never used either in our enterprise app over the past 2 plus years. This poo poo is bananas. I don't get why everyone hates storyboards, they seem to work great for me. Am I going to find out in some horrible way in a year or something?
|
|
#
¿
Oct 21, 2014 23:23
|
|
|
Glimm posted:Just don't dump the entire app into a single storyboard. I've seen some monster sized (30 controller) storyboards that are just insanely hard to deal with. I try to keep mine small as much as possible (5 controllers or so being larger storyboards). Ah, that makes sense, and also means I need to do some work splitting the elements of my tab view controller into separate storyboards sooner rather than later. It is getting a little bit unwieldy. I just kind of liked having a big overview of the entire app's flow in one document, but obviously that won't scale.
|
|
#
¿
Oct 22, 2014 02:33
|
|
|
Is there some sort of trick to signing into a new iCloud account in the simulator? I've tried it with three - my own (fails because I have two-step verification enabled), a foreign app store account, and one I just created today with its own email alias on my domain. I get "user name or password wrong" for the latter two. I want to be able to use a separate account for development, but it seems to be rather difficult. edit: Looks like I had to log into iCloud.com and agree to the terms to get it activated. That was totally obvious from "your username or password is invalid". 
Dessert Rose fucked around with this message at 03:32 on May 1, 2015 |
|
#
¿
Apr 30, 2015 06:37
|
|
|
The irrational desire to fill those three circles is the only "killer app" I need.
|
|
#
¿
May 28, 2015 16:47
|
|
|
Wow, that might get me off of IB. The layout(view1, view2, view3) { view1, view2, view3 in stuff is kind of gross though. I guess you could just use $1, $2, $3. Dessert Rose fucked around with this message at 19:52 on Jun 17, 2015 |
|
#
¿
Jun 17, 2015 19:50
|
|
|
Just stopping by to say GameplayKit is incredible and if you want to run my new game on iOS 8 you can go to hell. Being able to say: code:All my previous attempts to write games ground to a halt when I tried to shoehorn my entities into a single-inheritance hierarchy. I had read about Entity-Component, planned on implementing it in my next attempt, and oh look! All the busywork is already done and I can just work on actually breaking my concepts into components. I haven't even dug into state machines but those look pretty amazing too.
|
|
#
¿
Sep 24, 2015 20:32
|
|
|
Martytoof posted:Trying to renew my dev account. They definitely were gating it on App Store submissions as well, though I don't know if the second wave included people who didn't have them. (I have an app in the store, but it wasn't cool enough for wave 1. Got it on wave 2 though!)
|
|
#
¿
Oct 5, 2015 18:03
|
|
|
I ordered mine from mono price (along with a couple lightning cables to make shipping worth it) the same day I got the "you got into wave 2!" mail and my cables arrived the day before the devkit did. But yeah if you already have your devkit it is going to be an eternity.
|
|
#
¿
Oct 21, 2015 19:20
|
|
|
Doc Block posted:Do people actually use SpriteKit? I found it lacked too many features to be useful. I've been using it to develop a side-project game and haven't found it to be bad. What do you think it's missing? Also, GameplayKit is fantastic.
|
|
#
¿
Oct 22, 2015 19:21
|
|
|
You can definitely use storyboards with Swift view controllers. You need to tag the instance vars @IBOutlet and the functions @IBAction. Adding those tags will provide a little handle in the gutter of your code editor which you can drag to various corresponding elements in the storyboard. This worked as of 9.0, anyway, and I don't see it changing anytime soon, it's how IB has worked since it got integrated with Xcode.
|
|
#
¿
Nov 17, 2015 21:08
|
|
|
Accessibility is just too much work, we'd rather work on features everyone wants?
|
|
#
¿
Dec 7, 2015 20:00
|
|
|
Here is my two word review of UIStackView: It's good.
|
|
#
¿
Jan 2, 2016 22:33
|
|
|
I'd been dreading redoing a custom table cell I had because I'd changed some underlying mechanics, and it turned out to be basically trivial to just make it a big vertical UIStackView with smaller ones when I needed to line up a couple elements horizontally. It makes basic property/edit pages take the amount of time/effort I expect such things to take for how much thought needs to go into them. I can lay out things that go like label-text box-label-textbox-button without a million trips to the constraint edit panes getting them to line up properly. I don't consider myself a good designer by any means, and maybe a Real Designer would want to do much more custom layout than I'm doing. But when I just want to whack together the face to a bunch of backend code I wrote, add a single element to a settings page or whatever, I can now do that without expecting it to be an hour+ part of implementing the feature. It's the sleeper best feature of iOS 9.
|
|
#
¿
Jan 4, 2016 00:38
|
|
|
Currently doing some stupid debugger tricks. I want to log the time a breakpoint was hit, but also the hit count. so I'd like to see "at 2:33: hit 5". I know I can execute NSLog(), and I can also just print a message with the hit count, but I don't know how to combine the two. I can't use %H in an expression. Is there a simple way to do this, or do I just have to log the hit count and then call NSLog with some placeholder to get the timestamp? e: Hm, if I break into the debugger from where my breakpoint is, I get EXC_BAD_ACCESS on NSLog, but if I do it earlier in the app, it works fine. Not sure what's up with that. Guess I'll have to live with no timestamps. Dessert Rose fucked around with this message at 22:20 on Jan 18, 2016 |
|
#
¿
Jan 18, 2016 22:00
|
|
|
I wondered this when you posted in the c++ thread, but is there a reason you're doing this in C++? It seems like once you're making an OS X GUI app you should also think about writing it in Swift or something. Unless it's a project to help you learn C++, in which case that's fine and I would look into Objective-C++ and hitting the Cocoa APIs from there. How are you currently building your C++ app?
|
|
#
¿
Jan 31, 2016 05:55
|
|
|
lord funk posted:
You should submit this to Texts from Xcode. He's been hurting for material recently.
|
|
#
¿
Feb 5, 2016 11:32
|
|
It's right here!
|
fleshweasel posted:Speaking of, what are people's solutions for versioning APIs? Do you have some URL path component to indicate the version of the API you're trying to use? This is usually what you do. /api/v1, /api/v2, etc.
|
|
#
¿
Apr 26, 2016 19:07
|
|
|
|
| # ¿ Apr 29, 2024 14:44 |
|
|
I really need to get out of storyboard land for my app, it seemed like such a good idea when I started and now it's just ... nope. Speaking of which. I've been punting on this for a while because it sounds like such an ugly problem to solve, but here I am at the point where I've written all the placeholder code for this app and now I'm designing/implementing actual features, so this big feature I've been punting because it seems hard is ... well, actually hard. I'm using Core Data, and I want to implement a rules engine in it. Specifically, I want to generate "reminders" based on the state of the world: if I enter a predefined region, my app wakes up and reads out all of its rules, then schedules a bunch of local notifications based on them. So if "this item has not been completed yet today", and I'm at "work", then schedule a notification for an hour from now (or the time I first showed up at work today, or whatever). This naturally decomposes into Conditions and Actions, which have various fields containing constants and pointing at objects. Where I'm stuck is designing a schema for this that won't turn into a giant mess. I've seen similar systems implemented by just having five or so fields of a few useful data types and a type field which determines what those are even used for. That seems like the path of least resistance here; Core Data is totally fine adding new optional fields to a schema without having to write a migration. So that's one way to go. But is that my best option? Other options that I've considered: - Instead of generic fields, every time a new rule comes along, add all of its fields to the object, and leave everything else null - Instead of monolithic "Condition" and "Action" entities, make a new entity type for every single new rule type, then depend on inheritance elsewhere to make sense of the hierarchy - comedy "just serialize JSON into the DB" option Neither of those seem really any better than the monolithic entity approach, which has the advantage that implementing new rules may not need any DB schema modification whatsoever. Any other ideas? Has anyone designed anything like this before and done something that turned out well, or poorly?
|
|
#
¿
Jun 12, 2016 22:10
|
|