As my app's UI grows in complexity, I'm finding it tedious exporting all the graphics for things like buttons. For instance with toggle buttons: up, down, disabled, on, off * 5 buttons * 2 for retina = 50 graphics which need exporting! Is it a viable strategy to do as one does in CSS and make a sprite sheet? If so, might you point me in the direction of a snippet or two on how to handle loading and displaying the appropriate subsection?
You could use a sprite sheet, and a way to do that is here:
http://www.danielsefton.com/2012/07/texture-atlases-for-uikit-with-texturepacker/
As an alternative to sprite sheets, PaintCode is a great option from the Mac App Store. It makes it very easy to update graphics, simply copy and paste code. Unfortunately it's relatively high-priced.
If you need to create images that Paint Code can't handle, consider using a Mac app to automatically duplicate & resize the artwork, this way you only have to create it once. There are several on the Mac App Store. Some are free and others are paid. But if you want high quality resizing, it's best to use the tool you made the art with to do the downsizing (such as PhotoShop).
Related
I'm making a tile-based adventure game in iOS. Currently my level data is stored in a 100x100 array. I'm considering two approaches for displaying my level data. The easiest approach would be to make an SKSpriteNode for each tile. However, I'm wondering if an iOS device has enough memory for 10,000 nodes. If not I can always create and delete nodes from the level data as needed.
I know this is meant to work with Tiled, but the code in there might help you optimize what you are looking to do. I have done my best to optimize for big maps like the one you are making. The big thing to look at is more so how you are creating textures I know that has been a big killer in the past.
Swift
https://github.com/SpriteKitAlliance/SKATiledMap
Object-C
https://github.com/SpriteKitAlliance/SKAToolKit
Both are designed to load in a JSON string too so there is a chance you could still generate random maps without having to use the Tiled Editor as long as you match the expected format.
Also you may want to consider looking at how culling works in the Objective-C version as we found more recently removing nodes from the parent has really optimized performance on iOS 9.
Hopefully you find some of that helpful and if you have any questions feel free to email me.
Edit
Another option would be to look at Object Pooling. The core concept is to create only sprites you need to display and when you are done store them in a collection of sorts. When you need a new sprite you ask the collection for one and if it doesn't have one you create a new one.
For example you need a grass tile and you ask for one and it doesn't have one that has been already created that is waiting to be used so it creates one. You may do this to fill a 9 x 7 grid to fill up your screen. As you move away grass that gets moved off screen gets tossed into the collection to be used again when the new row comes in and needs grass. This works really well if all you are doing is displaying tiles. Not so great if tiles have dynamic properties that need to be updated and are unique in nature.
Here is a great link even if it is for Unity =)
https://unity3d.com/learn/tutorials/modules/beginner/live-training-archive/object-pooling
I have been interviewing for an iOS job and have been getting a lot of questions about custom UI, and more specifically custom UI buttons. I started trying to read up about it and found that Core Graphics is used to make these custom buttons.
I was wondering what the advantage of using custom buttons made with corE graphics is over using a UIImage, and images created on adobe or sketch, and then putting a UI button over that. Is there any specific advantage other then more customization over the process?
As an aside I was wondering if there were any good core graphics (Quartz 2d) tutorials out there for obj-c, I have found a good amount with swift, but not so many with obj-c.
It's interesting that it's an interview question!
You can design buttons in PaintCode which converts your drawings into code. Supposedly with Core Graphics, the performance is better, and it should look good regardless of the size of the device. PaintCode says about the Benefits: "Resolution independence & other benefits No more #2x resources. Future proof. Creating dynamic, parametric drawings is easy."
For the details, I would check out the FAQ, Question 2. Here are the first few paragraphs:
Using PNG images to draw user interfaces is tedious. PNG images are
not resolution-independent, so you have to provide many variants for
all kinds of displays. Some effects are also difficult (if not
impossible) to achieve using raster images. For exampe, you might want
to draw something with complex resizing behavior, or you might want to
alter the color of the drawing based on some outer conditions.
A better approach than using images is to use Objective-C or Swift
code to draw the user interface. The code is resolution-independent
and very flexible, so it works really well on all kinds of displays.
On a side note though, I find that it is a lot easier to use images rather than PaintCode. The positioning of elements, taking into consideration the insets in the image itself vs the inset in code causes a bunch of problems in practice. And PaintCode uses springs and struts as well to help with the sizing of images on different devices, but you have to be careful with when combining that with layout constraints in storyboard. There are things you can do in PaintCode to make your life a bit, but it takes some practice to really get the hang of it. Making the #2x and #3x versions of images is really not that bad - so if you can avoid PaintCode, I would just to avoid the headache.
I am creating a kind of 'map' in my app. This is basically only viewing an image with an imageView/scrollView. However, the image is huge. Like 20,000x15,000 px or something. How can I tile this image so that it fits? When the app tiles by itself, it uses way too much memory, and I want this to be done before the app I launched, and just include the tiled, not the original image. Can photoshop do this?
I have not done a complete search for this yet, as I am away, and typing on an iPhone with limited network connection..
Apple has a project called PhotoScroller. It supports panning and zooming of large images. However, it does this by pre-tiling the images - if you look in the project you will see hundreds of tiles for various zoom sizes. The project however does NOT come with any kind of tiling utility.
So what some people have done is create algorithms or code that anyone can use to create these tiles. I support an open source project PhotoScrollerNetwork that allows people to download huge jpegs from the network, tile them, then display them as PhotoScroller does, and while doing research for this I found several people who had posted tiling software.
I googled "PhotoScroller tiling utility" and got lots of hits, including one here on SO
CATiledLayer is one way to do it and of course the best if you can pre-tile the images downloading them from the internet (pay attention on how many connection you are going to open) or embedding them(increasing overall app size), the other is memory map the image on the file system (but an image with that res could take about 1GB), take a look at this question it could be an intersteing topic SO question about low memory scenario
I would like to create custom tabbar items similar to the ones shown here:
I assume these have to be designed and created first in Photoshop or a similar application. Are there any resources or tutorials available that demonstrate the creation of such items in Photoshop and how these are then used in MonoTouch?
Creating and bundling bitmaps is one option - and likely the most common one (for which googling should turn up several tutorials). Now in order to get optimal quality you need to supply multiple sets for the old iPhone/iPod, the newer retina iPhone/iPod, the iPad (1,2) and the retina iPad 3. This can takes a lot of space to cover each case with beautiful icons (or it won't look as good).
An alternative is to create the bitmaps at runtime, e.g. using the CoreGraphics API. This might seems counterproductive (and can surely be in many cases) but it has the advantage of requiring less (storage) space and/or getting better quality (see note).
Why ? because if you create them at runtime then you'll only create the ones for the specific device you're executing on. You can even cache them and re-create them when missing (e.g. if iOS flush your application cache).
If you're not an artist (and I'm not) you might want to look at easily licensable vector icons. The ones from your screenshot looks monochrome and could even use (bundle or extra the outlines from a) custom font - like the one provided by FontAwesome (CC BY 3.0) or similar sources.
Note: Maybe you noticed (I know I did) that some iPad applications looked beautiful (compared to others) on the iPad3 even if they were released months before the hardware become available. Vector graphics wins ;-)
UPDATE: Someone already made a script to convert the FontAwesome characters to iOS tab bar icons. However since it's done outside the app you'll need multiple versions of each bitmap to get the best look on every devices.
I've been looking at a lot of iOS user interfaces that have been customized. I wonder, is it better to customize the UI using images or using libraries like CoreGraphics and Quartz, or is it on a per case basis, as in I use libs for some elements and images for others?
It is very hard to guess your particular situation. I can state that iOS gives us a lot of leverages to make any custom interface. I would use:
images for complicated graphic elements, buttons, icons, arrows, etc.
images + stretching to get complicated backgrounds/elements
custom drawing all that contain lines, ellipses, squares, lineral and/or circular gradients, simple image preprocessing, etc.
The key idea is - to find balance between memory usage and processing time. Note: from my experience - interfaces based on images which created by professional designer looks awesome.
Case-by-case basis. Images can be drawn more quickly but use more memory; custom drawing, whether via Core Graphics or Quartz, uses less memory but takes more time.
Case by case. If you want a lot of complex graphics that aren't lines and don't change much, use images. If you just need lines/gradients, or if you want things to move and morph, you'll need to use quartz.
It depends on you, as well. Would you rather write code for quartz for an hour and debug it, or would you rather spend an hour in photoshop? How fast are you at PS? Do you already know Quartz?
It depends on a lot of things, so "case-by-case".
Determine the complexity of each approach. (nontrivial) Icons are a good example of an image, while large gradients are a good use for drawing. Drawing can take some time/experience to get right, compared to graphic assets, but you can reuse that implementation later and use less memory in many cases (images can also use less memory - depending on what you're drawing). Complex static images can take time to render if drawn so... there are a number of things to consider in order to achieve the best balance. Using the gradient vs. image example, quality and time are also factors -- resizing/scaling a simple image can take a lot of CPU or have artifacts a rendered gradient would not have. Much of it comes down to experience, knowing the implementations you use well, and a lot of sampling/profiling to determine what is simple/complex/consumes a lot of memory, and so on.