[blakker]

Firebase czy zwykle polaczenie bazy przez SQL?

#androiddev #android #androidapp

[another_throwaway23]

@blakker skoro zadajesz to pytanie to Firebase

[blakker]

@another_throwaway23 Chcialem troche bardziej rozwinieta odpowiedz, np dlaczego akurat to a nie to . :D Mimo to, dziekuje mirku!

[Mithrindil]

@blakker w sensie chcesz z apki mobilnej bezpośrednio się łączyć z bazą SQL? Az mnie ciarki przeszły ( ͡° ͜ʖ ͡°)

[blakker]

@Mithrindil: Po prostu aplikacja musi zapisywac dane uzytkownikow np. po zarejestrowaniu konta musisz miec gdzies to zapisane. *.*

[PieceOfShit]

@blakker: Firebase jest prostrze w implementacji. Nie musisz mieć serwera, nie musisz wystawiać API.

[blakker]

@PieceOfShit: Bardziej mi zalezy na byciu bezpiecznym niz na prostrzej implementacji.

[PieceOfShit]

No to tym bardziej idź w Firebase bo tam masz Auth i rejestracja jest praktycznie automatryczna. Masz kilka możliwości: mailem, gmailem, twitterem, facebookiem, githubem i co ino.

[Mithrindil]

@blakker zdecydowanie bezpośrednie połączenie do bazy SQL nie jest bezpieczne... Chyba że masz na myśli lokalna bazę SQLite

[PieceOfShit]

Tu masz libkę która ma LoginActivity które odpalasz forResult i albo się zarejestrujesz/zalogujesz albo nie. Wspiera też SmartLocka.
https://github.com/firebase/FirebaseUI-Android/tree/master/auth

[blakker]

@Mithrindil: tak, wlasnie mialem na mysli sqlite

@PieceOfShit zaraz obczaje

[Mithrindil]

@blakker to zmienia postać rzeczy. Jeżeli to tylko dane do logowania to szkoda czasu na SQLite. Do sharedpreferences wpisujesz username i hash hasła z solą i powinno być git

[stefansiarrasiarzewski]

Weź pod uwagę, że w Firebase Database wyszukiwanie jest dość ubogie.

[blakker]

@PieceOfShit
@Mithrindil

Oogolnie potrzebuje, rejestracje + logowanie a pozniej podlaczyc dosc duzo rzeczy do profilu gracza itp. Wiec szukam tutaj jak najlepszego rozwiazania aby bylo bezpieczne samo przechowywanie jak i "logowanie" , nie tylko logowanie i rejestracja bedzie w samej apce.

@PieceOfShit Na pewno rozwaze to

[Mithrindil]

@blakker pamiętaj że na zrootowanym telefonie wszystkie dane o ile nie są zaszyfrowane. Z tego co pamiętam to Realm ma jakieś szyfrowanie bazki wbudowane. SQLite nie ma, trzeba dopisać jakaś warstwę pośrednicząca odpowiedzialna za szyfrowanie.

Wybór między firebase i SQLite ma sens jeżeli dylemat masz pomiędzy aplikacja rozproszona a aplikacja lokalna. Firebase daje Ci API do źródła danych więc odpada pisanie serwera. W przypadku SQLite musisz sam napisać synchronizację danych, przesyłanie

[blakker]

@Mithrindil: Userzy prawdopodobnie kilka tys max. ( Wygorowane juz z gory, aby sie zabezpieczyc)

Powiedzmy przykladem:
- 2tys premium ( nazywam to tak aby zroznicowac konta dla was) mysle ze dobrze to max wygorowalem a nawet moze i za bardzo? nie wazne, powiedzmy ze tyle.
- pewnie bedzie siegalo 2 tys zwyklych uzytkownikow

jako ze z "racji nieaktywnosci" moze wprowadze funkcje aby kasowalo owe konta ktore nie wprowadzilo nic do

[Malthan]

@blakker: Żebym dobrze zrozumiał - chcesz w kliencie zaszywać dane dostępowe do bazy, z uprawnieniami do edycji tej bazy?

[blakker]

@Malthan: Nie. Dane maja byc calkowicie niedostepne. Nawet ja nie musze miec dostepu do nich za bardzo, jedynie przywileje zmieniac itp. typu "wydluzanie konta" czy cos w tym stylu, haslo, email, musze zabezpieczyc .

Nie wiem po czym stwierdziles ze chcialbym tak zrobic ale ok. :P

[Malthan]

@blakker: No dobra, to tym bardziej nie rozumiem. Myślałem, że chodzi Ci o to, żeby użytkownik wprowadził w aplikacji dane do logowania, a one zostały zapisane w bazie danych na serwerze.

[another_throwaway23]

@blakker chodziło mi o to, że jeżeli się zastanawiasz nad różnicami itp to firebase jest dla ciebie, bo masz dużo rzeczy gotowych, a twój projekt pewnie nie jest jakiś rozbudowany (gdyby był to sam byś wiedział co wybrać ;) ).
problemem mogą być płatności w przyszłości, jeżeli twój projekt "chwyci" i będziesz mial dużo użytkowników. wtedy może się okazać, że migracja z firebase jest trudna/nieopłacalna itp.

osobna baza wymaga dopisania API,

[blakker]

@Malthan czytaj ponizej mniej wiecej info
@another_throwaway23:

Z jednej strony to moze byc maly projekt pod wzgledem uzytkownikow, to zalezy jak bardzo sie "celowym osobom spodoba". Jezeli projekt chwyci to niestety bedzie bardzo duza liczba osob, a wszczegolnosci bardzo duzo uzytkownikow zwyklych przegladajacych owe rzeczy.

Co do samego projektu, jest dosc rozbudowany ale moge lekko sie mylic . zalezy kto co