The toolbar hack as a background is undesired about sdcalertview

[Clstroud]

Haha no, no way I could have pulled this off just doing things blindly. I had a method set up with local variables that captured all individual views in the hierarchy so I could inspect them. In the future, I might create a Debug category on UIAlertView or something that makes all of this a little easier.

Are you familiar with using Cydia Substrate? After I get past my exam I'm going to switch from using my slow iPhone 4 test device over to using the simulator. This would make your life much easier. The learning curve is a bit terse since it's sparsely documented… but it's really not that bad. If it helps, I gave a talk back in October on reverse engineering apps that would probably give you enough background info to get started.

That is, of course, assuming you haven't used it before… which I wouldn't be surprised if you have.

No idea. Maybe the methods you were looking at hadn't changed, but there surely were some changes in _UIModalItemsCoordinator. I don't think I noticed any changes in UIAlertView itself actually. This only came up recently when I decided that a coordinator class was appropriate.

Yeah I don't think it needs to change all that much. Mostly implementation details on the back-side that were wobbly.

The name of the class may indicate otherwise (probably for backwards compatibility), but UIAlertView is a model class. It never makes it into the view hierarchy. The alert calls out to the coordinator, who calls out to _UIModalItemsPresentingViewController, which initializes a _UIModalItemRepresentationView. This view has a _UIModalItemAlertContentView subview for displaying the alert's contents, and a _UIModalItemAlertBackgroundView.h for the background. And sure enough, _UIModalItemAlertBackgroundView.h does have a forward declaration (and instance variable) to _UIBackdropView.

Makes sense… but should probably be converted to a UML diagram or something so it's easier to understand those relationships. It gets a little complicate as-is.

It also has a _fillingView property which, I assume though haven't confirmed, is the radial image. The method _gradientImageForBoundsSize:withInnerColor:outerColor: is a little disconcerting, as SDCAlertView just uses one image, regardless of the alert's size...

That method is what I dumped my version of that background image from. I think it's fairly reproducible in CoreGraphics so I can handle that if your "CG-foo" is less than desirable in that department. Heck, I can probably even do that in PaintCode (MacHeist Bundle was well worth it!).

Anyway, that (and by inspecting the view hierarchy) is how I know it uses _UIBackdropView, and why I assumed its purpose is to apply a blur. Turns out it doesn't actually blur, but it still provides a background that I haven't been able to reproduce yet. If you want to take a crack at it, feel free.

Gotcha. I think some simplified version of _UIBackdropView will be made public in iOS 8, and on top of that, it would be a massive undertaking to reconstruct a halfway-decent version of that…. so I vote we don't focus on reconstructing that whole class. We only need a stand-in replacement that:

• has the correct background color + alpha
• has the radial gradient generated correctly for its bounds

Why not just have that in a single class that manages itself? I have yet to see other UIAlertView examples that diverge from what I demonstrated in the other thread.

[sberrevoets]

Are you familiar with using Cydia Substrate? After I get past my exam I'm going to switch from using my slow iPhone 4 test device over to using the simulator. This would make your life much easier. The learning curve is a bit terse since it's sparsely documented… but it's really not that bad. If it helps, I gave a talk back in October on reverse engineering apps that would probably give you enough background info to get started.

That is, of course, assuming you haven't used it before… which I wouldn't be surprised if you have.

I have not actually worked with this before, but it doesn't sound interesting! I'll check out your talk, sounds like I could pick up a lot from that.

Makes sense… but should probably be converted to a UML diagram or something so it's easier to understand those relationships. It gets a little complicate as-is.

It's not too complicated. There's a representation view that encompasses the background view with the backdrop, and the content view that contains labels, buttons, etc.SDCAlertView mimics that with SDCAlertViewBackgroundView and SDCAlertViewContentView (which I'm giving going to give a makeover soon).

That method is what I dumped my version of that background image from. I think it's fairly reproducible in CoreGraphics so I can handle that if your "CG-foo" is less than desirable in that department. Heck, I can probably even do that in PaintCode (MacHeist Bundle was well worth it!).

Unfortunately I'm not very well-versed in Core Graphics (I'm not a graphics wonder in general), so if this will be easy for you, go for it. I'd compare the radial images for two alerts with completely different bounds first, just to make sure they are indeed different.

Gotcha. I think some simplified version of _UIBackdropView will be made public in iOS 8, and on top of that, it would be a massive undertaking to reconstruct a halfway-decent version of that…. so I vote we don't focus on reconstructing that whole class. We only need a stand-in replacement that:

has the correct background color + alpha
has the radial gradient generated correctly for its bounds
Why not just have that in a single class that manages itself? I have yet to see other UIAlertView examples that diverge from what I demonstrated in the other thread.

That seems like a good approach, I think SDCAlertViewBackgroundView would be the perfect candidate for that. It sounds like your skills in Core Graphics (or PaintCode) are more in line with what's required, so it'd be great if you could get the ball rolling on this.

[sberrevoets]

This is fixed in #17