http://cyrilwei.me/blog

The UIKit will render texts and standard views on the high-resolution correctly, and if the app provides the @2x files, the UIKit will display the high-resolution images too.

Instead of pixels, the Quartz and UIKit use points to measure distances. One point does not necessarily correspond to one pixel on the screen. In iOS 4, the UIScreen, UIView, UIImage and CALayer expose a scale factor that tells you the relationship between points and pixels for that particular object. This factor is set to 2.0 on iPhone 4, so the apps which think the screen as 480 by 320 points would work well.

But the coordinate system of iOS may make some troubles.

The origin in Mac OS X is located at the lower-left corner, but the coordinate system of iOS is different. Its origin is located at the upper-left. However, if you want to draw some bitmaps or PDFs on iOS, the origin will be located at the lower-left, just like the Mac OS X coordinate system. So, the only one different is the device coordinate system of iOS.

Actually, the default origin of iOS is lower-left too. If you use CGContextGetCTM(context) to get the default transformation matrix on the drawRect: method of your views, you will find that it’s not an identity matrix, which means the iOS has already done some translation on the coordinate system. Maybe this is for someone to port games from other platforms.

To make the custom drawing code more general, or just because the developers are more familiar with the lower-left corner, some of them would like to ‘reset’ the coordinate system by asking Quartz 2D to apply an inverse matrix to the current transformation. Like this.

CGAffineTransform t0 = CGContextGetCTM(context);
t0 = CGAffineTransformInvert(t0);
CGContextConcatCTM(context,t0);

Then the transformation will be reset, the context’s transformation matrix will be identity and the origins of everything are located at the lower-left now.

That sounds good. Everything is reset, including the scale transformation.

Before the iPhone 4, the default scale transformation is 1, which is harmless. But things changed. To avoid the custom drawing code in old apps making mistakes on iPhone 4, the iOS sets a scale transform whose value is 2 on the default transform matrix for the drawRect: method of your views. The code will reset it to 1, which means that all the custom drawing will be displayed in the lower-left quarter of the screen.

Like this.

To fix this bug, we can use the scale property of UIScreen which is 2 on iPhone 4 and 1 on other iPhones and maybe something else on some further devices.

Add 2 lines after the reset code.

CGAffineTransform t0 = CGContextGetCTM(context);
t0 = CGAffineTransformInvert(t0);
CGContextConcatCTM(context,t0);

CGFloat scale = [UIScreen mainScreen].scale;
CGContextScaleCTM(context, scale, scale);

This will reset the context to 480 by 320 points. Then all the custom drawing will be enlarged 2 times to fit the new screen’s resolution, but which means that the custom drawing cannot benefit too much from the high-resolution.

Actually, we want to use the high-resolution screen to get more beautiful pictures. So the custom drawing code should use the 960 by 640 screen sufficiently.

We can use the reset context directly, for it has a 960 by 640 points canvas. If you don’t reset the coordinate system, you can use the following code to set the scale of transformation to 1. Then we have 960 by 640 points too.

CGFloat inverseScale = (CGFloat)1.0/[UIScreen mainScreen].scale;
CGContextScaleCTM(context, inverseScale, inverseScale);

The next step to do is to modify the custom drawing code to use the more points. We could only multiply the position of drawing codes by 2, but maybe some lines will be too thin on the high-resolution screen.

A better way is to provide 2 different codes for different resolutions. Just like the images, we can provide an ‘@2x’ drawing code. When finding it the iPhone 4, the app will draw with the optimized code for high-resolution screen.

The best solution depends on the needs of the application. We should test some approaches before we choose.

For further information please refer to the iOS Application Programming Guide. There is a chapter discussing supporting high-resolution screens.

* The pictures was taken from Asteroids - a sample game from Beginning iPhone Games Development, which is a wonderful book for iPhone game developer.

Recently, I failed in a test case which I thought would have never failed because I just returned the parameter in the method…ok, well, i converted it. So, what do you think the output is

BigDecimal a = new BigDecimal(1.16);
BigDecimal b = new BigDecimal(100);
System.out.println(a.multiply(b).longValue());

It’s 115! Not the expected 116.

Oh, well, what’s wrong with it? It’s the precise, predictable and trustworthy BigDecimal. Don’t do that double things.

Well, double, yes, what’s the result of double?

System.out.println((long)(1.16 * 100));

Bingo! 115 too. So, maybe the BigDecimal translates the exact double value, with the unpredictable behaviors of double.

System.out.println(new BigDecimal(1.16));

The output is 1.1599999999999999200639422269887290894985198974609375. Yes, perhaps it’s the precise binary value of 1.16 in double.

To find the reason, I opened the Java SDK documents and, oops, there are some notes of the BigDecimal(double val) constructor.

Notes:

1. The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.
2. The String constructor, on the other hand, is perfectly predictable: writing new BigDecimal(“0.1″) creates a BigDecimal which is exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the String constructor be used in preference to this one.
3. When a double must be used as a source for a BigDecimal, note that this constructor provides an exact conversion; it does not give the same result as converting the double to a String using the Double.toString(double) method and then using the BigDecimal(String) constructor. To get that result, use the static valueOf(double) method.

Ok, yes, that’s right. Well, then, why haven’t anybody told me this?

So the BigDecimal is trustworthy still, but don’t use the untrustworthy double any more. Use the String constructor, they recommended that.

BigDecimal a = new BigDecimal("1.16");
BigDecimal b = new BigDecimal("100");
System.out.println(a.multiply(b).longValue());
System.out.println(a);

Very well, 116 and 1.16. But will you use String as number type in you applications? If you can’t, follow the 3rd note. The static method valueOf(double) will first convert the double to String and then use the String constructor.

Like this

BigDecimal a = BigDecimal.valueOf(1.16);
BigDecimal b = BigDecimal.valueOf(100);
System.out.println(a.multiply(b).longValue());
System.out.println(a);

Output 116 and 1.16 too.

Ok, I chose String in my application because my data is money. I won’t use double type to store money data forever.

Questions:
1. Why haven’t mark a 'deprecated' on the BigDecimal(double val) constructor?
2. What does the double.toString(double d) do to make the value reasonable?