2012-04-04 9 views
11

Brak wcześniejszych pytań na ten temat, więc tutaj pytam.Efekty uboczne zmiany filtra i wymagania istniejącej aplikacji w Androidzie Play/Market

Tło:

Mam starą aplikację, w darmowe jak i płatne wersje, w grze rynkowej. Stworzyłem nową wersję, radykalnie zmienioną iz innym systemem płatności (bezpłatna aplikacja + tylko w zakupach aplikacji, nie ma już wersji płatnej: obniżenie kosztów utrzymania). minSdkVersion również zmieniono z 1.5 na 2.1.

Z powodu tych wszystkich różnic postanowiłem przesłać nową aplikację, a nie tylko zaktualizować bieżącą (tj. Nie dostarczać selektywnie nowej aplikacji dla API 7+ - wiele plików APK). Jest to szczególnie ważne ze względu na nowy system płatności, ponieważ nie chcę zmuszać starych, płatnych klientów do ponownego kupowania wszystkiego. Chcę je zostawić w spokoju i jestem szczęśliwy (4,4/4,7 oceny). Krótko mówiąc, nie chcę "zmuszać" ludzi do niczego. W tym przypadku, na kupując ponownie to samo poprzez zakupy w aplikacji, oprócz innych rzeczy nowa aplikacja oferuje.

Pytania:

Po wyjaśnieniu wam moje tło, to rodzi oczywiste pytania:

1. Jak ukryć stare aplikacje z API 7+ oglądalności zachowując są widoczne dla wszystkich obecnych klientów API 7+, tj. tych, którzy już je kupili?

Moją największą obawą jest tutaj płatna aplikacja. Zastanawiam się nad wypychaniem nowej wersji z maxSdkVersion ustawionym na 6 (SDK 2.0.1), skutecznie blokując nowych klientów API 7+ do starych aplikacji. Obawiam się jednak, że obecni klienci korzystający z interfejsu API 7+ nagle utracą dostęp do aplikacji. To rodzi dwa pytania:

2. Czy będą one w stanie aktualizować aplikację? czy rozsądnie jest zgadywać "tak"?

3. Nawet jeśli odpowiedź na poprzednie pytanie brzmi „tak”, to wciąż dla mnie jasne, co się stanie, gdy użytkownik odinstalowuje aplikację, a następnie znajdź go ponownie na rynku (nie tylko aktualizację) . Czy zniknie, czy nadal będzie się wyświetlać pod swoją "kupioną" listą aplikacji, biorąc pod uwagę, że w międzyczasie zmieniły się wymagania dotyczące filtrowania aplikacji?

Uwaga: chciałbym przesłać aplikację testową, aby zobaczyć, ale AFAIK autora nie jest dozwolone, aby kupić własną aplikację (nawet licencja zachowuje się inaczej), więc nie mogłem przetestować uninstall- scenariusz filtra-instalacji.




# # # # # # # Odpowiedź w odpowiedzi: # # # # # # #

@Sparky:

myślę źle to zrozumiałeś. Znam wiele plików APK i, oczywiście, dokumentację. Problematyczny jest tu znacznie więcej.

Należy również zauważyć, że maxSdkVersion jest przestarzała, więc to rzuca trochę kluczem do swojej propozycji WPR starą APK po wydaniu nowego pliku APK.

Dziękuję. Tęsknie za tym.

Wiele pakietów APK oferuje prostszą historię użytkownika.

Jeśli tak mówisz (poza innymi rzeczami, których nie cytowałem), prawdopodobnie nie zawiodłeś sobie głowy tym problemem. Proszę za mną:

  1. mam n paid że kupiłem aktualną wersję aplikacji Pro.
  2. Używają zestawu funkcji X, który mają w wersji Pro.
  3. Postanawiam teraz wdrożyć in-app-zakupy oferuje zestaw funkcji X, Y i tak dalej ...
  4. Niestety, te zmiany dokonane przez app API 7+.
  5. Tak więc, jak sugerujesz, postanawiam zaoferować wiele pakietów APK.
  6. Teraz tłum API 7+ nagle zostaje zaktualizowany do nowej wersji mojej aplikacji.
  7. Ponieważ aktualizację do nowej APK, oni stracić ich zestaw funkcji X. Teraz muszą ponownie kupić X (z menu zakupu w aplikacji). Wziąłem od nich coś, co już mieli, choć w "mniej błyszczący" sposób. Tak jak ja mówię:

Albo zapłacisz mi ponownie, albo stracisz to, co już masz.

Czy widzisz problem teraz? Czy widzisz, dlaczego jestem zmuszony do dostarczenia nowej aplikacji? Czy nadal nie dostaję tego, co powiedziałeś (chyba nie)?

+2

+1 Za genialnie sformułowane i precyzyjne pytanie. I z pewnością chciałbym znać odpowiedź również na tę. –

+2

Cóż, normalnie widziałem: A) Weź swoją starą aplikację i wypuść ją ponownie z kompatybilnością <2.1. B) Wydanie zaktualizuj bieżącą aplikację do nowej architektury z wyższym wymaganiem interfejsu API. Wynik: Starzy klienci z wersją 2.1+ będą mogli zobaczyć aktualizację i zaktualizować aplikację. Stary klient z wersją <2.1 nie zobaczy aktualizacji i będzie miał starą aplikację. Działa to tylko wtedy, gdy nie planujesz już aktualizacji starej aplikacji. – Ali

+0

Siddharth, dzięki. Ali, A nie działa, ponieważ nie chcę porzucać moich starych klientów. Nie chcę rezygnować z aktualnej bazy użytkowników, bieżących osiągnięć, komentarzy itp. Chcę po prostu zablokować nowych klientów, nie przeszkadzając w niczym obecnym. B to dokładnie to, czego nie chcę: zmusić obecnych klientów, by kupili wszystko ponownie, ponieważ nie będą mieli nowych zakupów w aplikacji, ale już mają (niektóre) funkcje. To katastrofa prawna, dlatego zdecydowałem się całkowicie użyć nowej aplikacji. – davidcesarino

Odpowiedz

1

Oto niedoświadczony pomysł za uwagę:

  • uaktualnić obecnego, pre-in-app-płatności app aby zawierać ContentProvider który zapewnia kryptograficzną hash, że tylko on wie jak generować w odpowiedzi do losowego materiału siewnego (aby zapobiec atakom powtórki).

  • Uwolnij swoją nową aplikację, która wykorzystuje płatności w aplikacji jako odrębnej APK, i to sprawdzić na istnienie wcześniejszej aplikacji w systemie użytkownika, próbując uzyskać dostęp do ContentProvider właśnie opisany, przekazując jej wartość losową i potwierdzenie, że odpowiedź jest prawidłowa. Jeśli taka odpowiedź zostanie odebrana, użytkownik jest właścicielem starej aplikacji i możesz włączyć odpowiednie funkcje starej aplikacji w nowej aplikacji, nie wymagając przy tym żadnych płatności w aplikacji.

Teraz, jeśli niektórzy użytkownicy pominąć uaktualnienie do starej aplikacji, która daje im nową ContentProvider i iść prosto do Twojej nowej aplikacji, zostaną one dinged dla płatności. Ale mogą następnie uaktualnić, jeśli chcą i uruchomić ponownie aplikację, aby uzyskać walidację.

To rozwiązuje twój problem. Ma jednak własne problemy. Tak więc, umieść go w zestawie narzędzi i sprawdź, czy przydaje się, jak jest lub w połączeniu z czymś innym, co możesz później wymyślić!

1

Zrobisz sobie przysługę, wydając nową aplikację zamiast aktualizacji, nie biorąc pod uwagę wielu plików APK, ponieważ komplikuje ona aktualizację istniejących płatnych użytkowników.

Załóżmy, że po prostu zaktualizujesz płatną aplikację do poziomu interfejsu API 7, obniżysz jej cenę do 0 i dodasz płatności w aplikacji. Urządzenia z poziomem interfejsu API> = 7 będą oferowane do aktualizacji, natomiast urządzenia z poziomem interfejsu API < = 6 nie będą powiadamiane, nie będą widoczne w Play (Market) i nie będą mogły zostać ponownie zainstalowane po odinstalowaniu. To byłoby 'nie' na pytania 2 i 3.

Ale teraz jest to możliwe do wykonania wielu plików APK: http://developer.android.com/guide/market/publishing/multiple-apks.html http://developer.android.com/training/multiple-apks/

W zależności od problemu możesz oferować wiele pakietów APK na poziomie interfejsu API: http://developer.android.com/training/multiple-apks/api.html

Pozwala to zachować dwie wersje tej samej aplikacji, oddzielone poziomem interfejsu API. Tak więc odpowiedź na twoje pytanie 1 polega na implementacji wielu pakietów APK na cytowane artykuły.

Publikując zupełnie nową aplikację, Twoja odpowiedź na pytanie 2 brzmi "tak". Wdrażając wiele pakietów APK, odpowiedź na pytanie 2 również brzmi "tak", a historia linii/aktualizacji aplikacji jest o wiele prostsza z punktu widzenia użytkownika (nieco trudniej dla ciebie technicznie, łatwiej w dziale obsługi klienta). Zwróć też uwagę, że maxSdkVersion jest przestarzałe, więc rzuca trochę klucza do twojej propozycji, aby zamknąć stary plik APK podczas wydawania nowego pakietu APK.

Podobnie z pytaniem 3. Poprzez opublikowanie nowej aplikacji lub zaimplementowanie wielu plików APK można nadal oferować pakiet APK dla starszych poziomów interfejsu API, które użytkownicy mogą znaleźć i zainstalować.

Wiele pakietów APK oferuje prostszą historię użytkownika. Publikowanie nowej aplikacji ułatwia rozróżnianie aplikacji, na przykład, gdy chcesz powiedzieć: "Zobacz, teraz DOSKONAŁE błyszczące!"

+0

Zaktualizowane pytanie z twoimi komentarzami. O ile widzę, nie rozwiązałeś głównej kwestii mojego problemu: obecni klienci API 7+ muszą kupić ten sam zestaw funkcji wersji Pro, co zakupy w aplikacji. Zobacz odpowiedź na swój komentarz w pytaniu. Zobacz wyliczenie. Dziękuję Ci. – davidcesarino

Powiązane problemy