Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
samiamwork
Dec 23, 2006

rjmccall posted:

Lua isn't quite as insanely optimized on ARM as it is on (say) i386, but I don't think it's going to be prohibitively slow.

Lua is optimized for i386? I'm not aware of anything architecture-specific in Lua. Are there optimized branches somewhere or something?

Adbot
ADBOT LOVES YOU

samiamwork
Dec 23, 2006

rjmccall posted:

The trunk Lua implementation, no, but if you're interested in high-performance Lua there's LuaJIT, which has a very strong argument for being the best dynamic-language implementation in the world.

Oh, neat! Learn something new every day. I'll have to keep this project in mind. Thanks!

samiamwork
Dec 23, 2006

wellwhoopdedooo posted:

Is there a way to make things more ... complaney?

Judging by your "==" tests it looks like you might want to use "assert()"?. Sorry if I've misunderstood.

wellwhoopdedooo posted:

I'm creating an instance of a subclass of UIViewController I made inside my application:didFinishLaunchingWithOptions:, and initializing it with initWithNibName:, but as far as I can tell, it's just not loading the NIB. I made a UITabBarController in the XIB, and hooked it up to an outlet in my subclass, but I'm getting something like this:

Nibs aren't loaded on init. You have to call "view" on the controller to trigger nib loading. Your outlets and actions should be hooked up after that. I think that might be your problem.

code:
// This works just fine, even though it's nil. Argh! I get that properties
  // are implemented as messages, and sending a message to nil is allowable, but
  // is there a way to make this complain while I'm developing?
  vc.tbc.view == 0x0
I'm sure there's probably a way you could cause this to fail, but it would probably wreak all kinds of havoc as I'll bet all the Apple frameworks lean on this (including synthesized accessors).

samiamwork
Dec 23, 2006

wellwhoopdedooo posted:

Can anybody tell me why I have to do it this exact way, and (even better) how I could have told that this is the way to do it?

Reading the View Programming Guide and the docs for UIWindow should tell you what you need to know. But judging by your post you've already done that.

quote:

Is adding the tabBar itself as a subview right? It doesn't feel right, but it doesn't work without it. I've read that a UITabBarController needs to be the root view controller, and I suppose that's what I'm doing since a.) it's working and b.) I'm setting the property on the window, but am I actually doing this right?

I don't believe you need to do that. You're saying that if you don't have that addSubview: line that it doesn't work? What is "blah"? I would guess it's that your usage of "tbcvc.view" on that line is triggering the nib loading. When you comment out that line, your nib doesn't get loaded, and so your outlets are nil (this hinges on what "blah" is and I'm assuming that it's supposed to be "tbcvc"). If you replace that line with [tbcvc view] does it work? Assuming that MyViewCtrlSpec is a subclass of UITabBarController I think you should just be able to:

code:
self.window.rootViewController = tbcvc
According to the docs anyway. If my assumptions about the types and ancestry of objects is off, please correct me. That "blah" particularly has me puzzled.

I'm wondering why you're not leveraging nibs more, though. You should be able to have your UITabBarController nib reference your view controllers itself instead of doing it with code. Just drop a UITabBarController into your MainMenu.xib and customize it by dragging UIViewControllers into it. Subclass as needed.

quote:

Also, as I'm picturing it, if the code posted was exactly what was in my application:blahblah: function, I'd have three memory leaks, one for each view, since tbcvc is a local variable and the array calls retain on everything that's added to it. Is that right? And if it is (or even if it isn't) why does it keep working when I release tbcvc in the function--is it just that the program isn't complex enough yet? Would the MyViewCtrlSpec functions like didReceiveMemoryWarning: still work? And if so, how, since as far as I'm aware, it's retain count would be 0?

You're leaking four objects by my count: tbcvc, the two view controllers and the array. It still works when you add a release because you're not over-releasing, you're under-releasing. Adding a release just brings things into balance. I highly recommend that you read the Memory Management doc that Mikey-san linked earlier on this page. That should make things clearer.

samiamwork
Dec 23, 2006

NOG posted:

I want an NSMutableArray as a property made in a class to use in another class, is this okay?

I'm not really sure what you mean by that, but that code won't work. If you assign a new value to the heroCollisPushPoints property you'll leak your original array and when you dealloc the object you'll crash when you over-release the second array you were given. If you don't want to allow other objects to give heroCollisPushPoints a new value then you probably want readonly.

wellwhoopdedooo posted:

Sure. link

Right now I'm trying to figure out how to put the tabBarItem that's associated with a view in that view's XIB.

The reason I'm going to all this trouble is partially that I don't understand the stuff, and partially because I want to be able to pull a particular module out or put a new one in and only have to edit the code in a single place. I don't know how the in-app purchases thing works yet, and very likely won't end up using it, but I'd like to build the app in a way that it'd be easy to start using that as well if I do decide to go that way.

Thanks for posting the source. The reason it doesn't work without the addSubview: is because you're inadvertently loading the nib when you pass self.moduleSelectorViewController.view as a parameter. Replace that line with [_moduleSelectorViewController view] and it works.

samiamwork
Dec 23, 2006

NOG posted:

Thanks for your insight. So if I'm making the right sense out of what you're saying, I should set that property to readonly instead of assign and get rid of the dealloc method since my other class will be deallocing the class object, which should dealloc that mutable array along with it.

It depends on what you're trying to do, but if both objects need it then both should retain it (unless it would cause a retain cycle). So keep the dealloc but also make sure your other object retains the array and releases it when it's done with it.

samiamwork
Dec 23, 2006
So I'm an idiot and created an app in iTunes Connect with the wrong App ID. I deleted it before I submitted anything but still it looks like the app name is gone forever. Is this really true? I've got an email out to the only iTunes Connect info I could find but maybe someone here has info. This seems really stupid.

Also, "Contact Us"?! Wow. They might as well just call that page "Do Not Contact Us".

I really hope I don't have to pick a new name. But I probably will, rather than wait forever for a response.

Edit: reading the dev forums it looks like *other* people can use my name but *I* can't? How does that make sense?

samiamwork fucked around with this message at 05:13 on May 15, 2011

samiamwork
Dec 23, 2006

Sewer Adventure posted:

It's gone. But who cares? it's an app id, nobody sees it anyway.

Sorry I wasn't more clear, I'm not complaining about the App ID. I'm complaining that I lost my app *name*.

samiamwork
Dec 23, 2006

LP0 ON FIRE posted:

I'm using ColorBGView and calling methods inside of it to make gradients. But if I attach two to my layer, it overlaps everything else I attach afterward, and I don't understand why.

code:
        ...
I've tried -insertSublayer:below: which makes the first sublayer be on top of everything.

I don't know how subviews interact with sublayers hierarchically, but have you tried setting the zPosition property of your sublayers/view layers instead of inserting them at specific indices?

samiamwork
Dec 23, 2006

ultramiraculous posted:

Isn't Lion at OpenGL 3.2? I tried running glGetString(GL_VERSION) in Mountain Lion and 2.1 came back, which doesn't seem right...not really the savviest in OpenGL. I remember reading theories that the hardware incompatibilities in Mountain Lion were supposed to be for machines that didn't have 3.x support on their GPUSs.

Lion does have 3.2 but because GL 3 breaks legacy GL apps you need to specifically request OpenGL 3 when you create your context. Otherwise you get a legacy context.

samiamwork
Dec 23, 2006

Doc Block posted:

Also, package-on-package memory is used mostly to save space. Despite what the article says, there's no limitation in ARM that requires it; Apple could totally use separate memory modules if they wanted to.

Isn't that pretty much what he said?

The Article posted:

What I don’t know is why, in the face of these problems with PoP, manufacturers continue to use package-on-package delivery for system memory. I haven’t found an ARM engineer who can explain it to me yet. Perhaps one will show up in the comments. It may be that we could move away from PoP architecture and toward separate memory modules like you have in computers. But I suspect that it is not feasible, for the simple reason that breaking the memory into separate modules would almost certainly be cheaper to manufacture than bigger chips or process shrinks, yet every single manufacturer keeps doing process shrinks or bigger chips rather than moving memory modules off the die.

And then he quotes two people on the issue who know more than he does.

samiamwork
Dec 23, 2006

Doc Block posted:

Not really. He's talking about PoP like it's a bad thing and an arbitrary ARM limitation. My point was that it has nothing to do with ARM, and that while Apple could move the RAM to separate modules like the author wants, they don't because there isn't enough room.

He's not really saying that it's necessarily bad, but he's arguing that, given PoP, memory improvements are tied to process improvements or a larger die size. As far as PoP being an arbitrary ARM limitation, in the first sentence of the bit I quoted he says that he doesn't understand why they only use PoP given that it would be easier and cheaper to manufacture by using modules. So its not that he thinks it's an intrinsic property but all the designs he's seen use it. He does admit ignorance about the advantages but there are quotes to fill that in. (of course as pointed out in the comments the iPad 3 has separate memory modules, going by ifixiit anyway)

Not trying to be antagonistic. I can definitely see how it could be read the way you did given what he wrote a few paragraphs above that bit, but taken as a whole, I think he was clear about what he did and didn't understand and was right about what he did understand (with respect to memory anyway).

Anyway I guess I'm sticking up for the article because I wish there were more blog posts this well argued (whether or not I agree with the conclusions). But maybe I'm a weirdo for thinking that. Sorry for the derail.

samiamwork
Dec 23, 2006

Doc Block posted:

I don't think it's all that well argued, even though I agree with his ultimate conclusion (native mobile apps are faster and generally superior to mobile web apps or some Phonegap-like hybrid). The article is generally poorly written, and is badly in need of structure; it's less an article and more a sea of words. His poor choice of color and font don't help, either.

I thought it had good structure, but I don't want to argue about that here. I agree with you on font and color though.


quote:

And then there's the fact that he's just plain wrong about some things. Framing mobile vs desktop CPUs as ARM vs x86 instead, for one.

That's not how I read it, but that's okay. We cool.

quote:

Lastly, the iPad 3 can have separate memory modules because the iPad has plenty of space for them. The author really doesn't understand this. Great, he's got some quotes from Intel engineers saying that PoP memory has lower latency, and completely ignores the space issue. Have you ever seen the inside of an iPhone? The logic board is a good deal smaller than the actual phone and is packed.

I'm not sure why you're telling me this. Actually it's probably because I just plopped that comment in a parenthetical without much explanation. I just pointed it out because I thought it was amusing that his area of expertise is iOS and yet he didn't even know that even apple has used separate memory modules in their ARM stuff. It's not like it's some obscure Chinese Android device. Yeah, he totally misses the space issue, but my original point was just that he understands that PoP is not an ARM arch requirement.

samiamwork
Dec 23, 2006

Peanut and the Gang posted:

If I have a long title on a navigation bar, it cuts off the back button's text to only show the chevron. Is there a way to force iOS to clip more off the navigation bar and show the full text of the back button?

Totally untested and not sure this is exactly what you want, but you might be able to do something like this:

code:
UILayoutPriority priority = [navbar.backbutton contentCompressionResistancePriorityForAxis:UILayoutConstraintAxisHorizontal];
priority--;
[navbar.titlelabel setContentCompressionResistancePriority:priority forAxis:UILayoutConstraintAxisHorizontal];

Adbot
ADBOT LOVES YOU

samiamwork
Dec 23, 2006

Peanut and the Gang posted:

Sadly I think the back button doesn't extend from UIView in iOS 7. So something like that won't work out. :(

I'm fairly sure it's descends from UIView (I can see all the subviews when I walk the navbar's view hierarchy) but it appears that it's not as easy to get to the actual button's view as I assumed. You'd probably have to do some things that Apple would frown on which ends up having the same sad outcome. =( Sorry for the distraction.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply