반응형



폰갭 phoneGap 용 MIT 라이센스 달려나온 push notification 입니다.

하지만 iOS 용만 사용하면 될것 같아서, 참고해 보려고 합니다.


https://github.com/phonegap-build/PushPlugin.git


소스 테스트 이후, git hub 에 따로 iOS 용 공개하려고 합니다. 위의 링크 소스와 같을 듯 싶지서도.. :)


반응형
반응형


Failed to build gem native extension


아이폰 개발을 하다보니, 요즘 이쁜 오픈소스 UI 들을 사용하려고 하는데, cocoapods 라는 Gem 을 설치 해야 해서, 사용하고 있는 OS X Mountain Lion (이하 마운틴 라이온) 에 설치하려고 하니 오류가 났습니다. 


Failed to build gem native extension


해결책은 : http://www.zlu.me/blog/2012/02/21/install-native-ruby-gem-in-mountain-lion-preview/ 잘 나와있습니다.


1. xcode 에서 Command Line Tools 를 설치 한다. 




아래 내용은, 터미널 로그를 그대로 스크린 샷을 떴는데요, 

처음에 sudo gem install cocoapods 를 했을 시 나오는 오류입니다.


2. 터미널에서 아래의 명령어를 실행해 줍니다.

ln -s /usr/bin/gcc /usr/bin/gcc-4.2

gcc-4.2 의 sym 링크를 만들어 주는 명령어 입니다.


3. sudo gem install cocoapods 명령어를 재실행 하면 재대로 설치됩니다.




반응형
반응형

The current deployment target does not support automated __weak references


iOS 5.0 이상에서 지원하는 ARC 를 사용하여 어플을 만들다 보니 ARC 는 무척 편하더군요. 근데 iOS5.0 이전 버전들을 지원하려면 어떻게 해야 할까 고민하다 인터넷을 뒤져보니.. 어느 멋진 분이 벌써 만들어놨네요. 


PLWeakCompatibility 를 다운받아 압축을 풀고



  1. PLWeakCompatibilityStubs.m 이 파일을 프로젝트에 넣어주세요 (전 h 파일도 같이 넣어줬어요)
  2. 그리고 xCode Target Settings 에 있는 Other C Flags 값을 -Xclang -fobjc-runtime-has-weak 로 바꿔주시면 됩니다.



타겟 클래스에 -release 와 -dealloc 을 적절히 섞어 넣어 주는 형식이라고 합니다. 디폴트로 PLWeakCompatibility 는 __weak 핸들링을 위해 MAZeroingWeakRef 를 사용합니다. MAZeroingWeakRef 를 사용하고 있다면, 있는걸 쓰겠지만, 없다면 내부적으로 알아서 처리하기 떄문에 뭐 그것도 상관은 없다고 하네요.


테스트 해보니 일단 위의 오류들은 깨끗하게 없어지네요. 작동을 잘 한다는 뜻이겠지요?


반응형
반응형

UXMagazine : 5 Ways to Create Better iPad Applications

(더 나은 UX를 가진 iPad 어플 만들기 위한 5가지 방법)


iPad 호환 어플을 만들기 위해 시작하기 전에 좋은 내용이 있어 개인적으로 정리도 할꼄, 팀과 공유도 할꼄 UXMagazine 의 글을 정리해 봤습니다. 


iPad 가 출시되어 마켓에 소개된지 2년이 지났습니다. App Store 엔 200,000개의 iPad 전용 어플리케이션들이 올라오고 있습니다. 지금이 iPad 전용 어플리케이션들의 UX 에 대해 이야기해 볼 많한 적절한 시기인 듯 싶습니다.

여기 적혀진 아이디어들은 iPad 만이 아니라 다른 태블릿에도 반영되며, 5가지 인터페이스 가이드라인을 공유하여 iPad 어플의 UX 와 디자인 제작 시 도움이 되었으면 합니다.


1. Retiring the TabBar (탭바 사용안하기)



TabBar (이하: 탭바) 는 iPad에서는 사용하지 않아도 되는 구식 디자인 입니다. 아이폰에서 할일 위주로 "빠르게 넣고 빼기" 식의 탭바는 빠른 네비게이션으로써는 무척 유용합니다. 하지만 편안한 자세에서 사용되는 iPad 에선 그다지 추천되는 UX가 아닙니다. 아이폰 어플과는 달리 iPad 사용 시 사용자들은 더 많은 시간을 더 편안한 상태에서 사용되기 때문에, 항상 빠르게 뷰를 바꿔줄 수 있는 네비게인션, 즉 탭바가 필요하지 않기 때문입니다.


큰 스크린에서 또한 탭바의 사용 효율성도 떨어집니다. 아이폰에서의 탭바들은 엄지손가락으로 닿을 수 있는 거리에 있지만, iPad 같은 큰 스크린에서는 엄지손가락으로 닿을 수 있는 거리에 있지 않을 뿐더러 보기에도 좋지 않습니다. 



디자인을 겸비한 탭바 라면 Facebook 어플에서 사용한 Slide-Out 탭바 라든지, Paper 에서 사용된 gesture-based 탭바거나 USA Today 에서 사용된 컨텐츠 중심의 네비게이션을 추천합니다. 사용하기에도 편하지만, 미적으로도 눈이 즐거운 UX 의 조합으로 New iPad 의 레티나 디스플레이에 어울리는 UX 를 만들어 보십시오.





2. Stop Pinching Me (제스처 사용 시 유의할 점)


터치패드를 장착한 모바일 기기들에서 사용되는 Gesture(제스처:몸짓) 기능은 어플 사용 시 사용자들로 하여금, 어플이 직관적이며, 재밌고,  "내 것" 이라는 느낌을 제공하는 아주 특별한 기능입니다. 


하지만, 이런 유용한 제스처들도, 직관적이지 않거나, 일관성이 수준미달이라면, 사용자들에게 짜증만 제공 할 뿐입니다. 

더욱이 한가지가 아닌 여러 종류 (multi finger taps, pinches, swipes) 의 제스처를  사용한다면 iPad 어플 내 제스처들의 일관성 있는 사용 도입을 더욱 신중히 고려해야 합니다.


iPad 어플 제작 시 제스처를 도입할 경우


1. 사용자의 한손은 대부분 기기를 들고 있다는것을 잊지 말아야 하며

2. 사용자에게 관습적이지 않은 제스처에 대해서는 어플 사용 시 꼭 소개 하도록 하며

3. 2번의 제스처에 대해 애니메이션이나 시각적으로 한번이 아닌 여러번에 걸친 반복학습을 통해 어플 내 제공되는 제스처를 익힐 수 있도록 해야 합니다.

4. iOS 레벨 제스처들은 어플 내 사용을 피하도록 합니다. (Four-Finger Swipe up, Five-Finger Swipe Left/Right, Five Finger Pinch)



3. Over-Heightened Realism (과장된 현실주의)


과장된 현실감이나 오버된 인공적인 디자인은 iPad 가 처음 출시 했을때 매우 인기 있어서, Mac 에서의 어플리케이션에도 영향을 끼칠 정도였습니다. Human Interface 가이드라인을 통해 애플은 


어플리케이션 내 가상 객체들과 행동 패턴들이 현실에서의 객체들과 행동 패턴들과 흡사하다면 사용자들은 어플의 사용법을 빠르게 흡수할 수 있을 것이다


라고 적어놨습니다. 이론상으론 맞는 말이긴 하지만, 사실상, 그렇지 않습니다.


이유는 

첫번째로, UX 디자이너가 현실에서의 객체를 사용하는 방법이 어플을 사용하는 사용자들과 다를 수 있기 때문 입니다. 

두번째로는, 모든 현실적인 행동패턴 들을 녹여 넣지 않는다면, 어플리케이션에서 원치 않은 행위들이 발생하기 때문 입니다.



예를 들면, 애플 iPad 의 Notes 만 봐도 문제가 심각하다는 것을 알 수 있습니다.  Notes 어플은 가상의 전형적인 노트패드로 디자인 되어 있지만, 페이지들을 뒤로 넘길 수 있지 않습니다. 새로운 페이지를 시작하려면 "+" 버튼을 눌러 시작해야 하며, 사이드에 있는 네비게이션을 통해 적어 놓은 노트들을 훑어 볼 수 있습니다. 정확히 말해서, 어느선까지 현실의 노트패드와 같이 동작을 해야 하는지, 어느 선까지 어플에서 기능으로써 제공을 해야 하는지 불분명합니다.


이런 문제들 때문에, 과장된 현실감이나 오버된 인공적인 디자인에 대해서는, 가급적 사용을 피하라고 말하고 있습니다. 

또한 멀지 않은 미래에 어플리케이션의 인터페이스가 사용자들과 어플과의 상호작용 모델로써 더욱 보편화 될것이라 생각되므로 iPad 어플리케이션의 UX 에서는 현실감이 과장되거나 오버된 인공적인 디자인은 필요치 않다고 봅니다.



4. Split Views


아이폰에서는 없었지만, Split Views(이하 스플릿뷰) 는 iPad 와 함께 탄생 되었습니다. 그래서 그런지, 네비게이션이 들어가 있는 거의 모든 어플리케이션들의 가로모드에서 사용 되고 있을 정도입니다.




스플릿뷰의 예로는, iPad 의 Mail 어플입니다. 이 스플릿뷰를 아주 유명하게 만든 어플 당사자 이기도 하지요. 작은 메뉴바가 좌측에 위치하고, 넓은 상세 뷰가 우측에 위치하여 내용을 보여줍니다. 스플릿뷰는 Mail 에서만이 아니라 애플의 iPad 어플리케이션들 (Mail, Notes, Messages, Reminders, Settings) 을 보면 일반적으로 사용되고 있어 가로모드로 사용될 땐 기본적으로 볼 수 있는 뷰라 느껴질 정도입니다.


이러한 스플릿 뷰의 가장 큰 단점은,  복잡하며, 집중 하기 힘든 스크린 을 만들어 냅니다. Setting 정도의 어플리케이션에서는 문제가 없지만, Mail 같은 어플리케이션에서는 사용자들이 항상 email 들을 읽고 답장을 하거나, 지우거나 하는 작업을 해야 하는데, 작업을 위해 집중 하려고 세로모드 스크린으로 바꿔야 한다는 점은 무척이나 불편한 점입니다.


스플릿 뷰는 빠른시일내에 없어지거나 하지 않겠지만, 스플릿뷰의 사용을 줄일 수 있는 방법을 제시해 봅니다:


1. 아무런 생각없이 iPad 에서의 가로모드를 기본적으로 스플릿뷰로 정하지 않았으면 합니다.

2. 애플에서는 권장하지 않지만, 메뉴바를 숨기는 방법을 택하는것도 하나의 방법입니다. 좀더 나아가서는 가로모드에서 팝오버를 이용하는 방법도 있습니다. (예: iA Writer)





3. 리스트 뷰가 필요치 않지만, 네비게이션이 보여야 한다면, sidebar 나 toolbar 의 이용을 권합니다. (예: PBS)





5. Think Different, Think iPad


마지막으로 iPad 용 best 어플들을 살펴보면, 넓은 iPad 스크린을 하나의 빈 캔바스로 보며 새로운 사용자 경험을 새로 만들어 내었습니다. 마술 같은 애플의 iPad 에서 신선한 관점에서 만들어진 어플들은 다음과 같습니다.




  • Pennant (a 2011 Apple Design Award)
  • Nursery Rhymes
  • Flipboard
  • The History of Jazz
  • Paper
  • Magic Piano


위의 어플들은 애플의 슬로건인 "think different" 와 HI(Human Interface) 가이드라인과 커뮤니티에서 형성된 스탠다드를 따르고 있습니다. 

학교의 교실과, 부엌, 자동차, 사무실 그리고 커피샵에 자리잡은 iPad 의 어플을 만든다는 것, 너무나 즐거운 작업이 아닐수 없습니다. UX 와 디자인 프로페셔널들이 지속적인 iPad UX 변화에 적응하려면, 

사용자들처럼 새로운 어플들을 집착하듯 사용해 봐야 합니다. 그래야 가능/불가능 한 UX 를 생각/판단할 수 있다고 봅니다.


아직까지는, 그리고 어느정도 까지는 iPad 의 시대이기 때문에, 이제 다르게 생각하기(Think Different) 를 실천해야 할 때 입니다.

반응형
반응형

[출처: http://stackoverflow.com/questions/6101286/making-a-button-call-a-phone-number-in-xcode ]

어플 내에서 버튼을 누르면 특정 전화번호로 전화를 걸어야 하는 기능이 들어가야 해서.. 찾아보니

아래와 같이 구현하면 바로 되네요.. 대신 전화번호 스트링의 형식이 있어요..

 [[UIApplication sharedApplication] openURL:[NSURL URLWithString:PhoneNo]]; 

PhoneNo 는  @"tel:2135554321"

이렇게 넘겨야 하는군요. 중간에 " - " 이 있어도 되구요. 제가 테스트 한 번호는..


@"tel:010-222-3333" 입니다. 

-(void)PhoneCall:(NSString*)PhoneNo{
     [[UIApplication sharedApplication] openURL:[NSURL URLWithString:PhoneNo]];
}    

반응형
반응형

상대방에게 iMessage 든 SMS 든,
주소를 URL Link 로 포함 전송하여 클릭 했을 때
구글맵에 보여주고 싶어서
NSString 을 URLEncoding 하는 방법을 찾아봤습니다.

NSString *addr = @"서울시 서초구 서초동 1363-1";

[[NSString stringWithFormat:@"http://maps.google.com/maps?q=%@", addr]  stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding] ];

 

 

URLEncode  된 링크가 잘 전송이 되어 메세지의 링크를 누르면 구글 멥에서 지정된 주소가 지도에 잘 열리네요.. :)

음.. 이제 저 길고 긴 링크를 줄이는 녀석을 찾아봐야겠네요.
bit.ly 로 짧게 하는 방법이 있긴 있다고 들었지만.. ㅋㅋ

반응형
반응형
아이폰 어플을 만들고, 아이튠스 커넥트를 통해 아이튠스에 올리면, 판매가 시작되는데요, 판매 리포트 중, 판매, 업데이트, 등이 있는데 아래와 같은 그림의 내용이 있습니다.


Royalty waived transactions.. 도대체.. 뭘까..
궁금해서 찾아봤습니다.
(https://apparentetch.com/2011/01/royalty-waived-transactions/)

리딤코드로 다운받은 경우라고 하네요.. :0

p= promo code (리딤코드) 사용하여 다운받아 진 내역입니다. (나만 몰랐나 봐요~~~~) 
반응형
반응형

[참고: http://www.iphonesdkarticles.com/2008/11/localizing-iphone-apps.html ]

간혹 필요한 아이폰에서 사용자 언어를 리턴하는 간단한 메소드 입니다.

NSString *resultCheckLanguage = [self checkLanguage];


로 받으시면 되겠네요.

-(NSString *)checkLangauge
{
    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
 
   return [[defaults objectForKey:@"AppleLanguages"] objectAtIndex:0];
}


resultCheckLanguage 결과문은

NSLog(@"current language: %@", resultCheckLanguage); 


로 확인해 보시면 아래와 같이 나옵니다. 

//한글일 때
     2012-02-27 10:58:36.167 wordList[1229:15803] current language: ko
//영어일 때
     2012-02-27 10:58:36.167 wordList[1229:15803] current language: en



반응형
반응형
[참고: http://bees4honey.com/blog/tutorial/how-to-add-iad-banner-in-iphoneipad-app/]

필요한 framework : iAd.Framework

1. ziAd.h

#import <Foundation/Foundation.h>
#import <iAd/iAd.h>
@interface ziAd : NSObject <ADBannerViewDelegate>
 
{
    ADBannerView *adBanner;
    BOOL bannerIsVisible;    
}
@property (nonatomic, assign) BOOL bannerIsVisible;
 
- (ADBannerView *)getADBanner;
@end


2. ziAd.m

#import "ziAd.h"
@implementation ziAd
@synthesize bannerIsVisible;

// iAd 배너
 
- (ADBannerView *)getADBanner
{
    adBanner = [[ADBannerView alloc] initWithFrame:CGRectZero];
 
    [adBanner setRequiredContentSizeIdentifiers:
 
    [NSSet setWithObjects:ADBannerContentSizeIdentifierPortrait, nil]];
 
    [adBanner setCurrentContentSizeIdentifier:ADBannerContentSizeIdentifierPortrait];
 
    [adBanner setFrame:CGRectMake(0, 410, 320, 50)];
 
    [adBanner setDelegate:self];
 
    self.bannerIsVisible = NO;
 
    return adBanner;       

}

- (void)bannerViewDidLoadAd:(ADBannerView *)banner

{
    if(!self.bannerIsVisible)
 
    {
        [UIView beginAnimations:@"animateBannerAppear" context:nil];
 
        [adBanner setFrame:CGRectMake(0, 410, 320, 50)];
        [UIView commitAnimations];
 
        self.bannerIsVisible = YES;
 
    }
}

- (void)bannerView:(ADBannerView *)banner didFailToReceiveAdWithError:(NSError *)error
{
 
     if(self.bannerIsVisible)
 
    {
        [UIView beginAnimations:@"animateBannerOff" context:nil];
 
        [adBanner setFrame:CGRectMake(041032050)];
        [UIView commitAnimations];
 
        self.bannerIsVisible = NO;
 
    }
}
@end
// iAd 배너


3. 호출..

#import "ziAd.h"

- (void)viewDidLoad
{
    //iAd
    [self.view addSubview: [[[ziAd alloc]init] getADBanner]];
    [super viewDidLoad];
 
}

//viewWillAppear 에 올리는 방법이 더 좋다고 해서 DidLoad 에서 지웠습니다.

-(void)viewWillAppear:(BOOL)animated
{  
     [self.view addSubview: [[[ziAd alloc]init] getADBanner]];

}


 


반응형
반응형
작년 11월 말..

iOS 기반 프로토 타입 어플을 만들어 보자..
프로토 타입 어플을 만드는 동안 스파이킹을 많이 해 보자..
이 기간 내 공부도 많이 하여 다음 어플을 만들 떄 좀 편안하게 진행하자..

참 여러가지 생각도 많고 욕심도 많고..
하지만 단 한가지 팀 내  공통적으로 있었던건..

iOS 어플에 대한 궁금증과 도전 정신 하나만은 충만 했었다는것..

막내는 UI 를.. 고참은 CoreData 를.. 디자이너는 디자이너대로의 목표가 있었을 테고..
난.. ㅡ,.ㅡa 내 목표는 만들자.. 인거 같은뎀.. ㅎㅎ

1주정도 브레인 스토밍으로 어플에 대한 전반적인 테마와 캐릭터 그리고 타겟마켓까지 정한뒤..
주 목표로 삼았던 유명 어플의 분석에 들어가, 프로토 타입이 나오는데 까지 걸린 시간은.. 3주...

디자인 입히고 UI 쪽 User Experience 관련, 기능 향상 및 디자인 쪽 필요 요소 챙기는데 1주..
목소리 녹음 하고 BGM 작업 1주..
1차 테스트 들어가니.. 어플이 막 죽더라.. 팍팍.. ㅎㅎ
2차 테스트 는 아마 모두 설에 고향 내려가서 했을 듯.. ㅋㅋ

뭐 iPad 1(wi-fi), iPad 2(wi-fi), iPod Touch 4세대, iPhone 3Gs, iPhone 4, iPhone 4S
등등.. 하여 모든 기기에서 동작하는것 확인..

3G 버전의 iPad 1 에서 어플이 실행이 안되는 부분에 대해선 조금 아쉽지만..
일단 어플은 아이폰이 목표이기에 막무가내로 통과 시켜 아쉽긴 하다.

뭐 이래저래 하야..

지난 목요일 2011/01/26 심사를 위해 어플을 업로드 시키고..

오늘 (2011/01/28) 은 Processing For AppStore 라고 뜬다.
이게 뭘까.. 하는 마음에 인터넷을 찾아보니.. 24시간 내 Ready for Sale (판매 준비 완료) 이라고 한다.

곧 Ready for Sale 이 뜨게 되면 Store 에 올라가는건.. 시간문제.. ㅎㅎ 
겁 없이 유료 어플에 일단 도전!!

ㅎㅎ.. 사용자들이 잘 봐 주었으면 한다.

자자자.. 다음 버전에 대한 준비는 완료..
월요일 부터는 난 이 어플 관련 무료 버전 어플 제작에 들어간다. 

--------------------------------
Update!!! 다행히 Ready For Sale 이 떠서 지금 2011/01/28 AppStore 에 올라왔습니다. ㅎㅎ
3일만에 올라왔네요 ㅋㅋ 
-------------------------------- 
반응형

+ Recent posts