Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

Doctor w-rw-rw-: Jun 24, 2008

Good news, everybody! AsyncDisplayKit is now in pre-release beta!

I know some of you are already signed up for it, so check it out.

On that note, does anyone have a good understanding of how the math for sublayerTransform works? The -[ASDisplayNode convert{Point,Rect}:{from,to}Node:] methods (or more specifically, _calculateTransformFromReferenceToTarget and -[ASDisplayNode _transformToAncestor:] methods account for anchorPoint, bounds, position, and transform, but not sublayerTransform.

# ? Jun 27, 2014 19:07

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 13:49

Kallikrates: Jul 7, 2002; Pro Lurker

He means implementing the protocol so say:

Objective-C code:

//given:
@protocol Foo <NSObject>
@property NSObject *bar;
@end

//choose:  
//A. in .h file
@interface NSObject (Qux) <Foo>
@property NSObject *bar;
@end

// OR/AND

//B. in .m file
@interface Qux() <Foo>
@end

@implementation Qux 
@synthesize bar;
@end

Correct me if I'm wrong in interpreting the question.

If you chose something like A you don't have to do something like B it will autosynthesize
You can omit A, but you should do B (will raise a compiler warning).
Properties declared in protocols do not autosynthesize otherwise.

# ? Jun 27, 2014 19:15

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

Do like this:

Objective-C code:

//given:
@protocol Foo <NSObject>
@property NSObject *bar;
@end

//choose:  
//A. in .h file if protocol conformance is public
@interface NSObject (Qux) <Foo>
@property NSObject *bar;
@end

// OR

//B. in .m file if conformance isn't public
@interface Qux() <Foo>
@property NSObject *bar;
@end

@implementation Qux 
// identical in both cases
@end

# ? Jun 27, 2014 19:27

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Doctor w-rw-rw- posted:

Good news, everybody! AsyncDisplayKit is now in pre-release beta!

I know some of you are already signed up for it, so check it out.

Specifically, see the post at https://www.facebook.com/groups/551597518288687/permalink/593600997421672/ and apply to join the group. If your account looks like it might be fake :argh:

PM me and I'll make sure to approve it.

# ? Jun 27, 2014 19:42

Doc Block: Apr 15, 2003; Fun Shoe

Snapchat A Titty posted:

Do like this:

Objective-C code:


//given:
@protocol Foo <NSObject>
@property NSObject *bar;
@end

//choose:  
//A. in .h file if protocol conformance is public
@interface NSObject (Qux) <Foo>
@property NSObject *bar;
@end

// OR

//B. in .m file if conformance isn't public
@interface Qux() <Foo>
@property NSObject *bar;
@end

@implementation Qux 
// identical in both cases
@end

This is what I was talking about. Either way, the property gets auto synthesized and you don't need a @synthesize statement.

# ? Jun 27, 2014 20:50

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

I just found out that the guy that made iSub is no longer working on it

He released all the code though, hopefully somebody forks it and continues development: https://github.com/einsteinx2/iSub

I was trying to figure out why songs won't play for me anymore after clearing the cache, but I guess I'm SOL now.

# ? Jun 27, 2014 22:29

P0PCULTUREREFERENCE: Apr 10, 2009; Your weapons are useless against me!; Fun Shoe

fletcher posted:

I just found out that the guy that made iSub is no longer working on it

Any reason that you prefer iSub over SubHub? I like the interface on SubHub much better.

# ? Jun 27, 2014 22:52

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

P0PCULTUREREFERENCE posted:

Any reason that you prefer iSub over SubHub? I like the interface on SubHub much better.

Haven't heard of SubHub before, it looks really promising though, thanks for the recommendation. Giving it a whirl now!

# ? Jun 27, 2014 23:08

dukerson: Dec 28, 2012

Sorry if this is a particularly dumb question -- after messing around with the iOS stack for a while with a few apps comprised mostly of spaghetti code, I'm trying to force myself to actually conform to common patterns.

One of the big questions for me is how to gracefully handle UIView styling/reuse. For instance, in pretty much every view controller I apply the same styling and creation of very similar views that all are derived from models, but there's a lot of code duplication for each individual view controller, where I have the same dozen lines of code setting the parameters of each cell and applying fonts/colors/yadda yadda. What's the best way to handle this? Adding a category/extension to the models with an `asTableView` / `asLabel` / etc?

# ? Jun 29, 2014 21:20

dizzywhip: Dec 23, 2005

Have all of your view controllers derive from a base view controller class with the common functionality? Putting view code in the model layer, even through categories is bad MVC and kind of weird.

# ? Jun 29, 2014 21:51

haveblue: Aug 15, 2005; Toilet Rascal

"ViewController" is a terrible class name for MVC programming and probably confuses a lot of people when starting out.

# ? Jun 29, 2014 22:02

Doctor w-rw-rw-: Jun 24, 2008

dukerson posted:

Sorry if this is a particularly dumb question -- after messing around with the iOS stack for a while with a few apps comprised mostly of spaghetti code, I'm trying to force myself to actually conform to common patterns.

One of the big questions for me is how to gracefully handle UIView styling/reuse. For instance, in pretty much every view controller I apply the same styling and creation of very similar views that all are derived from models, but there's a lot of code duplication for each individual view controller, where I have the same dozen lines of code setting the parameters of each cell and applying fonts/colors/yadda yadda. What's the best way to handle this? Adding a category/extension to the models with an `asTableView` / `asLabel` / etc?

For things which are effectively constants, make categories. For example, -[UIColor at_skyBlueTextColor]. This is not just totally kosher, but IMO also a good idea. Same goes for fonts. When it comes to styling code, I tend to duplicate it since there are so many possible variations on any given default that project-wide methods to configure views end up having too many exceptions to be considered maintainable. What I *do* do, though is factor out the variables, i.e. font size, view measurements, etc. into structs for static values - so if I want to change some measurement, I just tweak the struct. When it comes to complex layouts, I create a view spec - i.e. for ATFooBarViewController I would call it ATFooBarViewSpec (but it's really up to you), which is an NSObject with input properties, readonly output properties, and a -layout method which calculates the desired geometry for a view controller's views. This is a particularly useful pattern when using dynamic animations (in my case with Pop), because the model layers and presentation layers are always in sync.

dizzywhip posted:

Have all of your view controllers derive from a base view controller class with the common functionality? Putting view code in the model layer, even through categories is bad MVC and kind of weird.

Don't don't don't don't do this. This is a bad idea. One I've done before, to be sure. A very bad idea. Subclassing for the purpose of adding functionality (rather than creating a semantic difference in behavior - also, frameworks excepted to some degree) is worse MVC by far than using categories. If the configuration or statefulness more than is appropriate for categories (and it is, often), use controller classes to do the configuration. Not UIViewController subclasses, but NSObject subclasses which wrap a particular range of behavior.

# ? Jun 29, 2014 22:47

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

dukerson posted:

Sorry if this is a particularly dumb question -- after messing around with the iOS stack for a while with a few apps comprised mostly of spaghetti code, I'm trying to force myself to actually conform to common patterns.

One of the big questions for me is how to gracefully handle UIView styling/reuse. For instance, in pretty much every view controller I apply the same styling and creation of very similar views that all are derived from models, but there's a lot of code duplication for each individual view controller, where I have the same dozen lines of code setting the parameters of each cell and applying fonts/colors/yadda yadda. What's the best way to handle this? Adding a category/extension to the models with an `asTableView` / `asLabel` / etc?

You can create your own views (controls). If you find yourself needing the same or similar table view cell, just create a new Objective C class, inherit from UITableViewCell (or whatever) and check the box to create a XIB. Put all your view logic in there. Create a delegate protocol that your view controllers can implement to interact with it. To do it manually, create a XIB, delete the initial view, then drag whatever your actual view will be to the canvas. Create your Objective-C class, set the view's class to that class name. For a standalone XIB/NIB like this, you won't have a File's Owner, you hook up your outlets (properties) and actions (methods) to the root view itself. For completeness, I usually setup a designated initializer like so:

code:

- (instancetype)init{
    if((self = [super initWithNibName:@"myxibfile" bundle:nil])) {
        //custom stuff here,
    }
    return self;
}
- (void)awakeFromNib {
    //got re-hydrated from a NIB file
}

I do a lot of composite control stuff that way to make re-usable components. Sometimes I skip the XIB entirely and just create it all in code. Table cells are easy, just call registerClass:forReuseIdentifier: or registerNib:forReuseIdentifier: and let it handle the work.

Second big area is UIAppearance protocol/proxy. I typically create an Appearance Manager that runs on startup and sets the various UIAppearance stuff to give controls the default settings I want. You can find a ton of stuff here about using UIAppearance. There are third-party libraries that give you CSS-type styling on UIViews, but I've never used them.

Third big area is if I need to display the same data in different locations with just minor adjustments then I make the ViewController itself re-usable so it can be pushed to the navigation stack, shown in a popover, or stuck in a container and it will generally do the "right thing". In some cases this is easy and not a big deal, but for some kinds of custom layouts it might be a huge PITA. If so, you can use the new-ish ability to have custom containers and abstract the re-usable bit into its own view controller.

Last but not least, there are still some really common boilerplate things that simply require a lot of boilerplate code. Setting up a CoreData stack and dealing with its insane anti-threading design was a huge pain in the rear end compared to anything I've used elsewhere, although now you can just push all operations to a private background queue, but of course you have to put a layer on top because God-forbid you pass an entity from one thread to another, so goes the object identifier dance (but MVVM might be helpful there). UITableView, for all it's wonderful capabilities, does require a bunch of boilerplate because you don't have CocoaBindings on iOS. Why do you have to manually copy a string from the model to the label? Because screw you, that's why.

There is two legit cases where I used a base view controller class:

1. ADBannerView - trying to make this play nicely with a UITableViewController was a huge PITA in the past so I wrote my own duplicate of UITableViewController, just so I could tell it not to take up the entire viewport and leave space for the banner. With container views, I think this would probably be simpler today.

2. CoreDataTableViewController - abstracted a ton of the boilerplate here. Derived classes just specify the entity model they want, cell style, and the fields that map to the different cell fields along with a few odds and ends like specifying an image or accessory triggered by different field values on the entity. Almost replicates CocoaBindings, but without editing. Ultimately I don't think it saved me that much effort.

# ? Jun 30, 2014 04:30

dizzywhip: Dec 23, 2005

Doctor w-rw-rw- posted:

Don't don't don't don't do this. This is a bad idea. One I've done before, to be sure. A very bad idea. Subclassing for the purpose of adding functionality (rather than creating a semantic difference in behavior - also, frameworks excepted to some degree) is worse MVC by far than using categories. If the configuration or statefulness more than is appropriate for categories (and it is, often), use controller classes to do the configuration. Not UIViewController subclasses, but NSObject subclasses which wrap a particular range of behavior.

Yeah, that's the better way to go actually. I don't really feel like subclassing is nearly as horrible as you're making it out to be in practice, but yeah, it can definitely cause problems. In my experience it works out fine most of the time, and it's simple and easy to understand, especially if you're new to this sort of thing, which seems to be the case for the question asker.

# ? Jun 30, 2014 09:29

Doctor w-rw-rw-: Jun 24, 2008

dizzywhip posted:

Yeah, that's the better way to go actually. I don't really feel like subclassing is nearly as horrible as you're making it out to be in practice, but yeah, it can definitely cause problems. In my experience it works out fine most of the time, and it's simple and easy to understand, especially if you're new to this sort of thing, which seems to be the case for the question asker.

It's the kind of pattern which is easy to get used to but sort of eats up better patterns until you have so much code written with the assumption that you're dealing with X Y and Z implicit functionality that you're never going to refactor it all away unless you've got an extremely good handle on everything your entire application is doing, which totally fails to scale up.

# ? Jun 30, 2014 16:15

Choadmaster: Oct 7, 2004; I don't care how snug they fit, you're nuts!

haveblue posted:

What's probably going to happen is that's not explicitly mandatory but once Apple expands the range of supported screen sizes, aspect ratios, and pixel counts the "manual code" portion of the old way is going to get so complicated that autolayout naturally becomes preferred.

Gul Banana posted:

rumour has it that the next iphone will introduce *two* new screen sizes, so that day could come quite soon

It seems pretty obvious to me that this is also targeted toward iPad multitasking. Once you have multiple apps on screen simultaneously, they need to be well able to support arbitrary sizes and shapes (and what's brilliant is if you for example "pin" - or whatever - an app to a small area along the bottom of your iPad screen, based on the size/shape it can give you the horizontal iPhone interface paradigm rather than trying to shrink or reshape an iPad interface to fit).

# ? Jul 1, 2014 20:40

Fate Accomplice: Nov 30, 2006

Is anyone going to the NSMeetup at Dropbox in SF tonight on Swift and the future of Objective-C?

http://www.meetup.com/nsmeetup/events/190270702/

If so we should meet up and say hi.

# ? Jul 2, 2014 20:14

bumnuts: Dec 10, 2004; mmm...crunchy

Can someone help me get my head wrapped around Core Data and migrations? I have a released app, and I made changes to the data model to support new features in the next version. Unfortunately I didn't read up on the migration process until after I had already made the changes, and so I didn't know to use Add Model Version beforehand. Can I pluck the released version's xcdatamodel from source control, add the new version, and then just overwrite the generated file with my already-changed one?

# ? Jul 2, 2014 20:17

lord funk: Feb 16, 2004

Malloreon posted:

Is anyone going to the NSMeetup at Dropbox in SF tonight on Swift and the future of Objective-C?

http://www.meetup.com/nsmeetup/events/190270702/

If so we should meet up and say hi.

Then you should report back here with what happened at your cool people special city meetup.

_{_{We don't have silicon in our valley. Mostly cows 'round here.}}

# ? Jul 2, 2014 20:19

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

lord funk posted:

Then you should report back here with what happened at your cool people special city meetup.

Seconded.

# ? Jul 2, 2014 20:26

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

bumnuts posted:

Can someone help me get my head wrapped around Core Data and migrations? I have a released app, and I made changes to the data model to support new features in the next version. Unfortunately I didn't read up on the migration process until after I had already made the changes, and so I didn't know to use Add Model Version beforehand. Can I pluck the released version's xcdatamodel from source control, add the new version, and then just overwrite the generated file with my already-changed one?

Yep. Then make sure to set the current version on the xcdatamodeld (note the d) and make sure you add the persistent store with the two lightweight migration keys.

Also start using git or something.

# ? Jul 2, 2014 21:13

bumnuts: Dec 10, 2004; mmm...crunchy

pokeyman posted:

Yep. Then make sure to set the current version on the xcdatamodeld (note the d) and make sure you add the persistent store with the two lightweight migration keys.

Also start using git or something.

It's in git now, which is where I'm going to pull the released version's model from.

# ? Jul 3, 2014 03:18

lord funk: Feb 16, 2004

Finally made the move to integrate CocoaPods. Really happy with it so far, and I'm really looking forward to easier updating of libraries.

Anyone use Uncrustify? I'm taking some time to clean up / document code, and I thought it might be a good time to try it.

# ? Jul 3, 2014 21:26

Doctor w-rw-rw-: Jun 24, 2008

lord funk posted:

Finally made the move to integrate CocoaPods. Really happy with it so far, and I'm really looking forward to easier updating of libraries.

Anyone use Uncrustify? I'm taking some time to clean up / document code, and I thought it might be a good time to try it.

I wanted to use clang-format, but it didn't handle blocks right so we disabled it. If you come up with a good uncrustify script, share it! Been meaning to try it.

I wrote a script that could probably be retrofitted pretty easily to run a sweep over your entire project(s). It runs the formats in parallel, which is kind of nice.

# ? Jul 3, 2014 23:57

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

bumnuts posted:

It's in git now, which is where I'm going to pull the released version's model from.

Oh ok, good. I couldn't tell from your wording how ad hoc it was.

# ? Jul 4, 2014 01:15

dc3k: Feb 18, 2003; what.

So I found a way to break a modal that uses an unwind segue by loving around with the interactivePopGestureRecognizer. Code here. You'll need a device to test.

Repro steps:

Launch and hit the button to push to the second view controller
With one finger, hold the "Modal" button
With another, start dragging back to the previous view controller
While part way through the back gesture, release the finger that was on the now off-screen button. Notice the console log
Return the back gesture to normal (ie don't actually let it send you back to the previous screen)
Hit the "Modal" button
Hit the cancel button in the modal. It does nothing. Normally it would dismiss via an unwind segue

How can I prevent this from happening? UIBarButtonItems don't have an exclusive touch property like UIButtons do, and I don't want to shut off the interactive pop gesture.

# ? Jul 6, 2014 03:53

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

An idea for a game occurred to me and I was thinking about tinkering with learning to make iOS games. But it seems like Apple wants you to own a Mac in order to develop for iOS, and I've never owned a Mac in my life, and have no inclination to spend money on one now just to dick around. For that matter I don't yet own a smartphone either, but I've been thinking about getting one at some point, so that's not a big deal.

There seem to be a few options for developing for iOS without owning a Mac, which appear to fall into two groups: run Mac OS on something that isn't a Mac (probably tedious to get working, and the result might be fragile) or use some kind of virtual machine service, of which there are a handful. Does anyone have any experience of developing without a Mac, and what would you recommend? (If the answer is "you absolutely cannot develop for iOS without owning a Mac you dummy, the internet has lied to you" then my response would be to say "oh ok then" and forget about the whole idea, not go out and grudgingly buy a Mac.)

# ? Jul 6, 2014 17:27

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

Try Android or Windows Phone? Learning to make a game is far more about learning how to build a decent architecture and work in the event-based, time-driven model of development that games require. The actual platform will wind up being somewhat immaterial once you get the specifics down, and unless you really really really want to use SpriteKit, the big game libraries run on at least Android as well.

As far as iOS specifically, a hackintosh built with known parts can be pretty solid (very few complaints with mine, although I have an actual Mac as well so no big loss if it breaks.) There's a thread in SH/SC on the topic, however acquiring OS X for you would be :filez:

.

Regardless, you will want a physical device for testing, as only iOS uses a simulator instead of an emulator and the simulator can be wildly different than an actual device, especially when doing games. So this may be a big issue in which smartphone to get. If you're absolutely set on an iPhone then by all means look into the hackintosh route but if not I'd really recommend a platform you can develop for with what you already have and saving up for the real thing later, if it's that important to you.

# ? Jul 6, 2014 17:37

kitten smoothie: Dec 29, 2001

E: f,b

You can try running OS X in a VM. While it may not be performant enough for "I am getting paid to do this and slowness or instability costs me money" but it'd be be good for goofing around.

Depending on the hardware in your PC a hackintosh may also be an option. The tools to take an OS X installer image and boot it on a PC are to the point now where it's basically a point and click thing. Getting it to dual boot is a little more work and might be on the order of a Sunday afternoon project.

Of course neither is technically legal; the EULA says you're only allowed to run OS X bare metal on a Mac, or within a VM that's hosted on a Mac running OS X.

# ? Jul 6, 2014 17:42

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

carry on then posted:

Regardless, you will want a physical device for testing, as only iOS uses a simulator instead of an emulator and the simulator can be wildly different than an actual device, especially when doing games. So this may be a big issue in which smartphone to get. If you're absolutely set on an iPhone then by all means look into the hackintosh route but if not I'd really recommend a platform you can develop for with what you already have and saving up for the real thing later, if it's that important to you.

Yeah, I realise that if I actually end up putting something together then I will want an actual device with a touchscreen in order to test it. I'm not envisaging trying to test an application using a mouse pointer as a touchscreen substitute, or anything dumb like that.

# ? Jul 6, 2014 17:51

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

I spent a few weeks using Xcode in a VM and it was basically fine. As long as you have a processor that supports hardware virtualization it's pretty easy to have a VM that's faster than a macbook air, and people use those for development all the time. I wouldn't consider it a viable solution for actually getting something in the app store, but it's quite sufficient for dicking around and learning to program for iOS.

# ? Jul 6, 2014 19:05

Doc Block: Apr 15, 2003; Fun Shoe

Seems like Android would be a major pain for a one man game developer, since there are so many different devices and OS versions to test on.

Whereas on iOS the users upgrade to the latest OS really quickly, so most are running the latest version. And there are a lot fewer device models that a developer will have to worry about for testing.

# ? Jul 6, 2014 19:21

Axiem: Oct 19, 2005; I want to leave my mind blank, but I'm terrified of what will happen if I do

Somewhere along the line, I ran across a developer who built their entire app using a Hackintosh using the simulator, and then they started a Kickstarter that was basically "I have a game, but I need a Mac Mini so that I can test it on a device and get it on the App Store". They easily met their funding goal, and did finish the game and release it. So there's that.

Personally, I think people should be getting Macs even if they're not developers, so that's my recommendation :v:

# ? Jul 6, 2014 20:30

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Doc Block posted:

Seems like Android would be a major pain for a one man game developer, since there are so many different devices and OS versions to test on.

Whereas on iOS the users upgrade to the latest OS really quickly, so most are running the latest version. And there are a lot fewer device models that a developer will have to worry about for testing.

That's true, though it's generally not as bad as it sounds. You can usually get away with using the emulator for spot checks and running on the most popular current devices, and if the LG DickButt 3X has big problems you can just block it as a distribution target.

Things have gotten a lot better as far as really dumb compatibility issues go, though they still exist.

# ? Jul 7, 2014 01:36

Doctor w-rw-rw-: Jun 24, 2008

The third wave of betas are out for Xcode6 / iOS 8 / Yosemite! :siren:

# ? Jul 7, 2014 19:41

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Is there a way to force a UIWebView to update during scroll?

I have the dark arts of detecting non-inertial scroll, and my JS is running during scroll, but the repaints aren't happening. I've tried forcing setNeedsDisplay on the webview's scrollview's subviews, but no dice. (It actually stays in no-update mode until the touch ends, even if the finger has stopped moving, which is especially sucky.)

# ? Jul 7, 2014 20:22

Doc Block: Apr 15, 2003; Fun Shoe

Doctor w-rw-rw- posted:

The third wave of betas are out for Xcode6 / iOS 8 / Yosemite!

There's a part of my brain that sees "Yosemite" and wants to pronounce it "Yoze Might".

# ? Jul 7, 2014 20:28

Doctor w-rw-rw-: Jun 24, 2008

Subjunctive posted:

Is there a way to force a UIWebView to update during scroll?

I have the dark arts of detecting non-inertial scroll, and my JS is running during scroll, but the repaints aren't happening. I've tried forcing setNeedsDisplay on the webview's scrollview's subviews, but no dice. (It actually stays in no-update mode until the touch ends, even if the finger has stopped moving, which is especially sucky.)

setNeedsDisplay will tell the scroll view that you want a repainting, but won't necessarily do it. If your performance can handle it, maybe try calling drawRect instead?

# ? Jul 7, 2014 20:57

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Doctor w-rw-rw- posted:

setNeedsDisplay will tell the scroll view that you want a repainting, but won't necessarily do it. If your performance can handle it, maybe try calling drawRect instead?

I'll try that! I think I can make the performance handle it OK, since I only need to trigger it when a new image comes onto the screen. Thanks.

# ? Jul 7, 2014 21:05

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 13:49

Doctor w-rw-rw-: Jun 24, 2008

Subjunctive posted:

I'll try that! I think I can make the performance handle it OK, since I only need to trigger it when a new image comes onto the screen. Thanks.

No promises - but if that doesn't work, I don't know what will - I generally treat anything that UIWebView doesn't explicitly expose as an API as voodoo to be avoided.

# ? Jul 7, 2014 21:37

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »