2012-06-22 3 views
2

무료 및 유료 버전의 앱을 개발하는 가장 좋은 방법은 프로그램의 주요 대량을 포함하는 라이브러리 프로젝트를 갖는 것입니다. 무료 및 유료 프로젝트는이 라이브러리 프로젝트를 사용합니다. 이를 통해 무료 및 유료 프로젝트가 서로 다른 리소스를 가질 수 있습니다.다른 기능으로 Android 무료 및 유료

그러나 제 질문은 무료 앱에서 기능을 제한하거나 유료 앱에서 기능을 확장하는 방법입니다. 예를 들어, 무료 앱은 데이터베이스 테이블의 최신 행에만 액세스 할 수 있으며 유료 앱은 모든 행에 액세스 할 수 있습니다.

이렇게하는 한 가지 방법은 리소스에 부울 플래그를 지정하여 지불을 위해 true로 설정하고 무료로 false로 설정하는 것입니다. 런타임에 라이브러리 프로젝트는 부울 플래그를 확인하고 이에 따라 동작을 변경합니다. 그러나 이것은 잠재적 인 공격에 대해 매우 쉽게 해킹하는 것으로 보입니다. 더 좋은 방법이 있습니까?

하나의 무료 앱으로 더 쉽게 완료 한 다음 인앱 결제를 사용하여 Pro 기능을 잠금 해제 할 수 있습니까?

+0

-1 인해 중복 http://stackoverflow.com/questions/3711967/best -way-to-have-paid-and-free-and-android 앱 - – rds

답변

4

IMHO, Java/Android는이 시나리오에서 쉽게 만들지 않습니다. 이상적으로 당신은 하나의 코드베이스를 가져야하고 마음대로 유료 또는 무료 버전을 컴파일 할 수 있어야합니다. 무료 버전에는 중요한 메소드/클래스가 비활성화되어 있으므로 아무도 데이터베이스 또는 xml을 사용하여 응용 프로그램의 모든 기능을 사용할 수 없게됩니다.

이 작업을 수행하는 한 가지 방법은 다시 Java에서 지원하지 않는 조건부 컴파일을 사용하는 것입니다. 그러나이를 수행 할 수있는 Ant 태스크가 있습니다. http://prebop.sourceforge.net/doc.html. 이 같은 코드에서 뭔가를 추가 할 수 있습니다

/* $if paid_version$ */ 
public void paid_method() { 

} 
/* $endif$ */ 

위의 코드가 제거 얻을 것이다, 당신이 구축하고 개미 대상이 정의 된 변수 paid_version이없는 경우.

prebop을 설정하는 방법은 또 하나의 주제입니다.이 코드는 복잡하지만 단일 코드베이스가있는 것이 가치가 있습니다.

업데이트 : 2012 년 5 월 12 일 : Gradle을 기반으로 한 새로운 Android 빌드 시스템은 유료 및 무료 APK를 약간 쉽게 만듭니다. 'Build Variants'에 대한 주제는 Android Tools 웹 사이트를 참조하십시오. 즉,이 같은 소스를 구성 할 수 있습니다

/src/main/ 
/src/paid/ 
/src/free/ 

모든 공유 코드, /src/main에 거주 /src/free/src/paid 무료 코드에 코드를 지불했다. 빌드 시스템은 유료 및 무료 APK를 생성합니다. 그러나 여전히 누락 된 기능 중 하나는 소스 자체에서 조건부 컴파일을 수행 할 수있는 기능입니다. 이 글을 쓰는 시점에서 Gradle 빌드 도구는 아직 베타 버전이므로 잘하면 최종 릴리스에 추가 될 것입니다.

+0

이것은 아주 좋은 해결책입니다. Ant와 Prebop이 어떻게 작동하는지 이해하려고 노력하면서 하루를 보내고 난 후에 Unfortuanlty는 안드로이드 라이브러리 프로젝트를 사용하여 포기했습니다. –

+0

'아직 포기하지 마라. 제대로 설정하려면 일주일이 걸렸습니다. 핵심은 먼저 기본적인 개미 빌드를 수행하는 방법을 배우는 것입니다. 일단 개미에 익숙해지면 빌드하는 동안 프로젝트를 조작 할 수있는 모든 종류의 개미 작업을 추가 할 수 있습니다. 예 : 프로 기능을 사용하려면 부울 플래그가 있어야합니다. 빌드시에 개미를이 부울 플래그를 false로 설정할 수 있습니다. 즉, 프로 기능 섹션이 컴파일되지 않습니다. 그런 다음 젠킨스 (Jenkins)와 같은 CI를 사용하면 무언가를 체크인 할 때마다 프로와 무료 빌드를 뱉어 낼 수 있습니다. – azgolfer

+1

유료 기능의 불법적 인 잠금 해제로부터 보호하는 데 적합합니다. OTOH. 인앱 결제로 이러한 기능을 점진적으로 사용하려면 좋지 않습니다. 또한 누군가가 무료 앱을 유료 버전으로 변환한다는 것이 얼마나 위협적인지 궁금합니다. 평범한 사용자가 컴퓨터에 익숙하지 않은/해킹하는 경향이 없다면 몇 명의 숙련 된 인력이 몇 분의 돈을 절약하면 정말 중요할까요? 그들은 단지 2 달러를 지출하고 앱을 사기 만하면 얻을 수없는 것보다 공개적으로 게시 할 수있는 콘텐츠로 끝나지 않을 것입니다. 생각? – Carl

2

앱이 지급되었는지 여부를 지정하는 Res 또는 SharedPrefs에 플래그를 저장하지 마십시오. 루팅 된 전화기는 해당 전화기에 액세스 할 수 있으며이를 수정할 수 있습니다. 나는 또한이 문제가 있고 2 개의 분리되는 apps를 썼다 (지불 된 것을 베끼고 몇몇 방법을 삭제하고, 광고를 etc로 추가했다). 이것은 가장 간단한 해결책입니다.

+2

이것은 매우 유지 보수가 쉬운 방법은 아닙니다. 버그를 발견하면 두 번 수정해야합니다. –

+2

글쎄, @Styx, 괜찮은 소스 제어 관리를 사용하면 한 분기에서 다른 분기로 변경 사항을 병합 할 수 있습니다. 그래서, 블루 루힐의 해결책은 완벽하게 합리적입니다. – rds

2

IMO 단일 소스 에서 여러 앱 릴리스를 만드는 가장 좋은 방법은 라이브러리 프로젝트를 사용하는입니다.

나는 이것을 최근에 시도했지만 매우 잘 작동하는 것으로 보인다. Google Play에이 코드를 기반으로 코드를 공개하지는 않았지만 테스트 장비에서 동시에 실행할 수있는 별도의 앱을 자체 아이콘과 함께 만들었습니다.

Android의 개별 앱마다 각각 다른 패키지 이름이 있어야하므로 개별 동작을 구성하는 가장 쉬운 방법은 무료 또는 유료 버전 내에서 라이브러리가 실행 중인지 확인하기 위해 라이브러리의 패키지 이름을 테스트하는 것입니다. 이 테스트는 라이브러리 프로젝트에 정의 된 사용자 정의 Application 파생 객체 내에서 수행 할 수 있습니다. getPackageName()를 호출하면 패키지 이름을 얻을 수 있습니다.

무료 및 유료 앱에는 AndroidManifest.xml 파일과 몇 가지 리소스 (예 : 무료와 구별되는 애플리케이션 아이콘) 만 필요할 수 있습니다.

두 응용 프로그램 각각에 대한 매니페스트에서 응용 프로그램 요소의 android.name 특성을 응용 프로그램 파생 클래스의 전체 경로 (라이브러리에 정의 된대로)로 설정해야합니다. 물론 매니페스트 요소 자체의 package = 속성을 각각의 앱에 대해 .free 또는 .paid와 같은 형태로 끝나는 별개 패키지로 설정하고 싶을 것입니다. 그런 다음 매니페스트의 액티비티 객체에는 라이브러리의 적절한 Activity 파생 클래스 (전체 경로 사용)로 설정된 android : name 특성이있을 수 있습니다.

유료 기능을 사용할 수있는 코드는 사용자 지정 Application 개체의 패키지를 테스트하는 메서드를 호출하고 패키지 이름을 구문 분석 한 다음 유료 또는 무료 버전이 실행 중인지 여부를 결정한 다음 이에 따라 유료 기능을 비활성화하십시오. 매우 도움이 예있다

(비록 다소 여전히 이전 관련) 여기에 전체 코드와 함께 :

https://github.com/donnfelker/FullAndLiteVersionSharedLibrary/blob/master/FooLibrary/src/com/example/foolibrary/FooLibraryApplication.java

+0

응답 해 주셔서 감사합니다. 결국 저는 도서관 프로젝트에 참여했습니다. 제가 질문 한 다른 질문과 제가받은 대답을 확인하십시오. 그것은 당신을 도울 수 있습니다 : http : // stackoverflow.com/questions/11176113/android-free-paid-architecture-using-library –

+0

다른 스레드에서 라이브러리의 변형 동작이 포함 된 응용 프로그램의 패키지 이름을 테스트 할 때 조건이 될 수 있다고 제안하여 올바르게 수정되었습니다. 모듈이 라이브러리를 사용하는 모듈을 기반으로 라이브러리 동작을 구성하기 위해 모듈성을 위반할 수 있습니다. 그래서 모든 app- * specific * 정보는 위에 설명 된 접근법을 적용 할 때 앱에 있어야합니다. 기능을 비활성화하는 경우 앱의 패키지를 기반으로하는 것이 좋을지 모르지만 무료 대 유료 대화 상자가있는 경우 대화 상자는 라이브러리가 아니라 앱에 있어야합니다. – Carl

+0

이 필요성 (라이브러리 프로젝트의 경우)이 어떻게 발전하는지에 관해서는, 개발자가 일반적으로 모든 기능을 갖춘 앱을 만들고 * 다음 *으로 장애가있는 무료 버전을 만들기로 결정했기 때문에 대부분의 전체 앱이 무능력을 통제하기 위하여 도서관에있는 신청 포장의 시험과 더불어 도서관 프로젝트. 사용하지 않는 항목을 무료 앱에로드하는 경우 이는 논리적으로 이상적이지 않습니다. OTOH, 나중에 인앱 결제와 같은 기능을 사용 설정해야하는 경우 필요합니다. 또한 라이브러리와 앱간에 적절한 전체 앱을 나누기위한 일관성을 손상시킬 수 있습니다. – Carl

관련 문제