iOS2012. 10. 9. 11:32


iPhone5와 iOS6가 나오면서 개발자들은 iPhone5의 더 길어진 스크린을 지원해야 한다. 이에 대해 잘 설명해 놓은 아래 사이트의 글을 정리하여 보았다.

http://redth.info/get-your-monotouch-apps-ready-for-iphone-5-ios-6-today/

새로운 해상도는 640x1136이다. 

1. splah/default screen의 이미지 파일의 네이밍은 Default-568h@2x.png이다. 사이즈는 640x1136 픽셀이어야 한다. 파일을 프로젝트에 추가하고 Build mode를 Content로 맞추어야 한다. 이 파일을 추가하지 않으면 위아래가 44픽셀씩 잘려서 표시되고 추가하는 순간 화면의 기준점이 구석으로 간다.



2. 다른 이미지리소스들은 불행하게도 -568h@2x.png라는 형식을 사용할 수 없다. 뷰에서 커스텀백그라운드 이미지를 사용한다면 해당 해상도에 맞는 이미지를 별도로 작성해야 하고 각 이미지를 사용하는 부분에서 적절히 구분하여 사용해야 한다.

예를 들어 4인치가 아닌 앱에서 다음 두개의 이미지가 있다고 하자.

 ㄱ. Images/TableViewBackground.png - 320x358

 ㄴ. Images/TableViewBackground@2x.png - 640-716

새로운 해상도에서는 3번째 이미지가 필요한데 여기서는 -568h@2x.png 형식을 사용하겠다(물론 애플에서는 싫어하겠지만)

 ㄷ. Images/TableViewBackground-568h@2x.png


3. 이제 iPhone5를 감지하여 새이미지를 사용하도록 코드를 수정해야 한다. 아래 iPhone5인지 감지해주는 샘플코드가 있다. 

  1. public static bool IsTall
  2. {
  3. get
  4. {
  5. return UIDevice.CurrentDevice.UserInterfaceIdiom
  6. == UIUserInterfaceIdiom.Phone
  7. && UIScreen.MainScreen.Bounds.Height
  8. * UIScreen.MainScreen.Scale >= 1136;
  9. }
  10. }

다음 코드는 IsTall을 이용하여 이미지를 단말을 구분하여 Image객체를 리턴해주는 코드 예이다.

  1. static UIImage tableViewBackgroundImage = null;
  2. public static UIImage TableViewBackgroundImage
  3. {
  4. get
  5. {
  6. if (tableViewBackgroundImage == null)
  7. tableViewBackgroundImage = IsTall
  8. ? UIImage.FromFile("Images/TableViewBackground-568h@2x.png")
  9. : UIImage.FromFile("Images/TableViewBackground.png");
  10. return tableViewBackgroundImage;
  11. }
  12. }

이 예제에서 single static instance를 통해서 여러 뷰컨트롤러에서 사용해도 인스턴스는 하나만 유지하도록 하였다.

다른 고려할 사항은 세로길이를 계산하는 로직이 있거나 뷰를 임의크기로 생성할때, 이런식의 코드를 작성해야 한다는 것이다. UIScreen.MainScreen.ApplicationFrame이나 UIScreen.MainScreen.Bounds를 길이나 Y좌표를 계산하는데 고려해야 한다.

다음코드는 좀더 쉽게 이미지를 얻어내는 코드예이다.

  1. private static string tallMagic = "-568h@2x";
  2. public static UIImage FromBundle16x9(string path)
  3. {
  4. //adopt the -568h@2x naming convention
  5. if(IsTall())
  6. {
  7. var imagePath = Path.GetDirectoryName(path.ToString());
  8. var imageFile = Path.GetFileNameWithoutExtension(path.ToString());
  9. var imageExt = Path.GetExtension(path.ToString());
  10. imageFile = imageFile + tallMagic + imageExt;
  11. return UIImage.FromFile(Path.Combine(imagePath,imageFile));
  12. }
  13. else
  14. {
  15. return UIImage.FromBundle(path.ToString());
  16. }
  17. }




Posted by 삼스
Android/App개발2012. 8. 14. 08:59


JellyBean(4.1) WebKit은 ICS대비 변경 없음

ICS(4.0) Webkit

  • WebKit updated to version 534.30
  • Support for Indic fonts (Devanagari, Bengali, and Tamil, including the complex character support needed for combining glyphs) in WebView and the built-in Browser
  • Support for Ethiopic, Georgian, and Armenian fonts in WebView and the built-in Browser
  • Support for WebDriver makes it easier for you to test apps that use WebView

HoneyComb(3.1) WebKit
  • File scheme cookies
    • The CookieManager now supports cookies that use the file: URI scheme. You can usesetAcceptFileSchemeCookies() to enable/disable support for file scheme cookies, before constructing an instance of WebView or CookieManager. In a CookieManager instance, you can check whether file scheme cookies is enabled by calling allowFileSchemeCookies().
  • Notification of login request
    • To support the browser autologin features introduced in Android 3.0, the new methodonReceivedLoginRequest() notifies the host application that an autologin request for the user was processed.
  • Removed classes and interfaces
    • Several classes and interfaces were removed from the public API, after previously being in deprecated state. See theAPI Differences Report for more information.


HoneyComb(3.0) Webkit
  • New WebViewFragment class to create a fragment composed of a WebView.
  • New WebSettings methods:
    • setDisplayZoomControls() allows you to hide the on-screen zoom controls while still allowing the user to zoom with finger gestures (setBuiltInZoomControls() must be set true).
    • New WebSettings method, setEnableSmoothTransition(), allows you to enable smooth transitions when panning and zooming. When enabled, WebView will choose a solution to maximize the performance (for example, the WebView's content may not update during the transition).
  • New WebView methods:
    • onPause() callback, to pause any processing associated with the WebView when it becomes hidden. This is useful to reduce unnecessary CPU or network traffic when the WebView is not in the foreground.
    • onResume() callback, to resume processing associated with the WebView, which was paused during onPause().
    • saveWebArchive() allows you to save the current view as a web archive on the device.
    • showFindDialog() initiates a text search in the current view.
안드로이드 버전별 WebKit버전
3.0 - AppleWebKit/534.13
2.3 - AppleWebKit/533.1
2.2 - AppleWebKit/533.1
2.1 - AppleWebKit/530.17

Posted by 삼스
카테고리 없음2012. 8. 9. 13:02



WebKit2 - High Level Document

WebKit2는 분리된 프로세스모델을 지원하기 위해 고안된 새로운 API Layer이다.

Why is it named WebKit2?

오리지날과 호환되지 않는 API변경이 있기 때문에 이름이 다르다. 이 라이브러리는 /System/Library/WebKit2.framework 위치에 설치될것이다.

C API

WebKit2는 C-based non-blocking API를 제공하며 대부분 플랫폼을 구별하지 않는다.  non-blocking API를 지원하기 위해 몇가지 기술이 사용되는데 다음과 같다.

  • 통지형태의 클라이언트콜백 : 무언가 이벤트가 발생하였음을 알린다. ex: didFinishLoadForFrame
  • 정책형태의 클라이언트콜백 : 어떤 동작에 대한 정책을 정할 수 있게 해준다. ex: decidePolicyForNavigationAction
  • 정책 설정 : 콜백없이 미리 정의된 정책을 지정할 수 있게 해준다. ex: WKContextSetCacheModel, WKContextSetPopupPolicy
  • 추출된 코드 : 다른 옵션이 실패하는 경우 WebProcess에 로드될 수 있는 코드이며 DOM에 접근하고자 할 때 유용하다. 아직 계획중이며 구현은 안되어 있다. ex: WebBundle

주요한 API 클래스들은 아래와 같다:

WKContextRef

  • 모든 페이지들에 대해 캡슐화를 제공한다. 하나의 Context의 모든 페이지들은 동일한 방문링크셋, 로컬스토리지, 그리고 프리퍼런스들을 공유한다.

WKPageNamespaceRef

  • 서로 스크립트할 수 있는 모든 페이지들.Encapsulates all pages that can script each other.

WKPageRef

  • 브라우징 기본 유닛, Basic unit of browsing. Stays the same as the main frame changes.

WKView[Ref]

  • 플랫폼툴킷에서 훅킹하는 네이티브뷰. 윈도우에서는 HWND, 맥에서는 NSView에 해당한다.


Port-Specific APIs

포팅에 국한된 API들이 있을 수 있다. 이 경우 기존 포팅에는 영향을 받지 않도록 한다.

Process Architecture

WebKit API Layer내에서 프로세스관리메커니즘을 빌드하는 스택을 변경한다.

다음은 전통적인 웹킷포팅 아키택쳐를 보여준다.

mac-webkit-stack

모든것이 하나의 프로세스안에 있다. 그리고 application과 WebKit API간의 경계가 있다. 이는 단순하고 재사용면에서도 편리하다.

다음은 WebKit2의 구성이다.

webkit2-stack

이제 하나의 프로세스 경계가 있다. 그리고 API 경계가 자리잡고 있다. WebKit의 일부는 UI Process에서 동작하는데 application logic이 살아 있다. WebKit의 나머지는 WebCore, JS Engine과 함께 WebProcess에 살아 있다. Webprocess는 UI process와 분리되어 있다. 이는 응답성, 견고성, 보안성 그리고 멀티코어에 적합하다. 

How is This Different from Chromium WebKit?

크로미엄은 멀티프로세스에 다르게 접근한다.

Notice that in this case, the the process boundary is *above* the API boundary. Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblazing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.

That was an understandable choice for Google - Chrome was developed as a secret project for many years, and is deeply invested in this approach. Also, there are not any other significant API clients. There is Google Chrome, and then there is the closely related Chrome Frame.

WebKit2 has a different goal - we want process management to be part of what is provided by WebKit itself, so that it is easy for any application to use. We would like chat clients, mail clients, twitter clients, and all the creative applications that people build with WebKit to be able to take advantage of this technology. We believe this is fundamentally part of what a web content engine should provide.

Internals

There are two key subsystems that support the process division :

  • CoreIPC - an abstraction for general message passing, including event handling. The current implementations use mach messages on Mac OS X, and named pipes on Windows.
  • DrawingArea - an abstraction for a cross-process drawing area. Multiple drawing strategies are possible, the simplest is just a shared memory bitmap.

There are two other important abstractions, which may be pushed down to WebCore or WTF over time:

  • Run Loops
  • Work Queues

Current Status

WebKit2 should be considered an early technology demo. It is not yet production quality. But it's possible to try it out and see how it works at this early stage.

How to try it Out

build-webkit의 맥과 윈도우버전은 이제 WebKit2를 디폴트로 빌드한다. WebKit2는 Safari에 탑재되지 않았다. WebKit2를 테스트하려면 Tools/MiniBrowser로 해야 한다.

How to run layout tests

WebKit2를 테스트하려면 layout test에 "-2" 또는 "--webkit-test-runner" 옵션을 주어 다음처럼 실행한다.

run-webkit-tests --debug -2

많은 테스트가 무시될것인데 지속적으로 그 수는 줄어들것이다.


Posted by 삼스