iOS Managing drawing code

[dantastic]

I have just started using an app called PaintCode to generate drawing code from svgs. This works like magic, the app spits out a chunk of code that you stick in to the drawrect of a UIView subclass.

I've a whole bunch of images now that I need to move over to this new format and I'm not sure how to best manage this new method of working.

Up til now I would have an imageview and then I would load an image and put it into the imageview. Now I have a UIView subclass .h & .m file and all. I can of course create a UIView subclass for each image, that will work in IB and then in code I will have to import the UIView.h and draw it s a view.

As cool as this is it feels a bit unclean. I would like to have only one file and I don't want to import wherever just an image is needed.

Any suggestions how to manage this drawing code so it can be more used like an image would be? I realize I can render and save images but I want to avoid that.

 

[robbieduncan]

Render into an image on demand?

 

[dantastic]

Render into an image on demand?

The UIView subclasses feels like a better option. This opens opportunities to nicely animate images properly. As soon as you rasterize that goes out the window.

 

[robbieduncan]

The UIView subclasses feels like a better option. This opens opportunities to nicely animate images properly. As soon as you rasterize that goes out the window.

The UIView subclasses probably are a better option! But if you want something closer to using images you'll probably have to have images

 

[dantastic]

hehe, true!

I'm just trying to get my head around organizing this best in xcode and my project. It just feels a bit messy with this huge amount of UIView subclasses. I know that the end result is still less number of files (phone + pad * @2x) but still....

 

[robbieduncan]

hehe, true!

I'm just trying to get my head around organizing this best in xcode and my project. It just feels a bit messy with this huge amount of UIView subclasses. I know that the end result is still less number of files (phone + pad * @2x) but still....

I create a folder in the source tree in XCode for things like this so I could collapse it and make that complexity go away when I don't need to see it. You can create the folder at a file system level too if you like...

 

[dantastic]

Yes of course. I already do that, I keep the project organized in folders on the file system and then also in folders in xcode as well to match. Would quickly become a nightmare otherwise

Maybe this isn't a much of a problem after. The only thing really is I have to run a #import in each file where I need to use some image. Or maintain a header file for images.

 

[dantastic]

So in my viewcontroller I can do

ImgView *myView = [[ImgView alloc] initWithFrame:CGRectMake(0, 0, 400, 400) imageName:@"MyImageView"];
	[self.view addSubview:myView];

where ImgView is

@implementation ImgView


- (id)initWithName:(NSString *) imageName
{
	Class image = NSClassFromString(imageName);
	NSAssert(image, @"Missing %@", imageName);
	if (image) {
		self = [[image alloc] init];
	}
    return self;
}

- (id)initWithFrame:(CGRect)frame imageName:(NSString *) imageName
{
    self = [self initWithName:imageName];
	self.frame = frame;
    return self;
}

@end

Saves me from having to track imports manually.

 

[robbieduncan]

I'd worry about not calling the appropriate init methods in the superclass...

 

[dantastic]

super init is being called in the init of the actual image UIView subclass. So that should be alright. feels a bit hacky I agree and I'm not sure yet if I'm ok with it but so far I think it looks alright.

 

[robbieduncan]

super init is being called in the init of the actual image UIView subclass. So that should be alright. feels a bit hacky I agree and I'm not sure yet if I'm ok with it but so far I think it looks alright.

I see what you are saying and I agree. I doubt you should call super init twice so you should do it this way no matter how wrong it looks!