[priseffects]

#androiddev #programowanie
Drogie mireczki. Jakbyście rozwiązali problem logowania się w appce mobilnej? Appka typu cash reward (płacimy userom za klikanie ofert).

Opcja 1:
-logowanie za pomocą loginu i hasła, pełen profil użytkownika
Opcja 2:
-google login, facebook login, twitter
-zwykłe logowanie
Opcja 3:
-brak logowania, user od razu dostaje appkę gotową do działania, to jest w tle odbywa się autorejestracja, loginem jest device IMEI, user sobie może tylko hasło dostępu do appki ustalić, wada - zgubione urządzenie = brak konta, chyba, że ustali sobie security code, który przypisze nowe IMEI do starego

Opcje 1 i 2 dają więcej kontroli userowi. Opcja 3 jest bardziej user friendly, appka i tak ma działać tylko na jednym urządzeniu by userzy nie klikali sobie ofert z wielu urządzeń jednocześnie, np. na emulatorach.

[epi]

@priseffects: połączenie wszystkich opcji ;)

czyli opcja 3 z możliwością utworzenia normalnego konta później (logowanie, przez google, fb, twitter, email) i przypisania do niego tego anonimowego

[rzuf22]

zależy co chcesz osiągnąć, jak wyciągniesz od niego fb to masz dużo więcej info o użytkowniku, a wiedza to władza ( ͡° ͜ʖ ͡°)

[priseffects]

@epi: oj, widzę tutaj spore pole dla force close ;) Każdy kto tworzył na androida wie, że urządzenie urządzeniu jest nierówne. Póki co testuję na 5 innych, ale i tak zawsze coś wyskoczy.
Baza musi być jednak prosta, by udźwignąć te kilkadziesiąt tysięcy userów (pesymistyczna wersja).

[priseffects]

@rzuf22: taką wiedzę mogę użyć tylko w opcji marketingowej i powiadomić usera, niestety chcę to zrobić bez shady activity, więc wszystko musi być czarno na białym ;)
User ma klikać w oferty, zarobek appki typu cash reward jest 10 krotnie wyższy o reklam w gierkach.

[epi]

@priseffects: ale w czym problem? ;)

[RufuSx]

@priseffects: Opcja 2

[priseffects]

@epi: w złożoności, musiałbym sprawdzać wiele warunków, w których być może sam bym się pogubił
dodaj też pierdylion try/catchów, a i tak coś wyjdzie po release ;)

[saund]

Może coś takiego https://passwordless.net/ - to jest implementacja na noda ale na pewno da się zrobić na andku ;-)

[epi]

@priseffects: czy ja wiem, skoro i tak rozważasz opcję 3, to i tak musisz jakis profile usera tworzyc, tylko ze przypisany jest do jakiegos id (imei)

w mojej opcji user po prostu ma opcję odanonimizowania się, czyli podpięcia swojego emaila pod istniejące juz konto z imei ;)

[priseffects]

@epi: tzn. cash reward? :)

[epi]

@priseffects: nie, taką autorejestrację jak opisałem

[priseffects]

@epi: wiem, że podawanie swoich danych na starcie to średni pomysł ;) sam bym appkę usunął, gdyby kazała mi się zarejestrować przed zobaczeniem co oferuje. Widziałem, 99% tych cash reward to stosuje, ale... kilka właśnie ma autorejestrację

[asdasdce2w]

@priseffects: jakich rozmiarów zysk można osiągnąć? mówie o stronie programisty, chociaż end-usera przypadek też może być ciekawy

[priseffects]

@asdasdce2w: przy 15k userach $200-$300 na dzień, to nie jest zwykła appka, jej celem samym w sobie jest robienie pieniędzy

[Mithrindil]

@priseffects: żeby uzyskać IMEI musisz mieć pozwolenie READPHONESTATE o które musisz explicite poprosić przy Androidzie M gdzie komunikat brzmi mniej więcej: "Aplikacja prosi o pozwolenie na odczytywanie i wykonywanie połączeń" - co jak user odmówi w trosce o swoją prywatność?

Ja bym poszedł w opcję 2: logowawnie z google lub facebook lub stworzenie nowego konta.

[priseffects]

opcję 2: logowawnie z google lub facebook lub s

@Mithrindil: właśnie te appki proszą i nie przepuszczą dalej, wyskakuje komunikat dlaczego potrzebują tych uprawnień
być może masz rację, zwłaszcza, że robię już pod API 24

[i.....y]

@priseffects: bez zbytniego kombinowania. Firebase Authentication. Logowanie kontem Google lub tradycyjnie emailem. Każdy Android ma podpięte konto Google, więc mega wygodne. A jako, że o wszystko troszczy się Firebase to jest bezpiecznie i wygodnie to zaimplementować.