W poprzednim wpisie dotyczącym porównania właściwości formatted_address z address_components zwracanych przez GeocoderResult starałem się przedstawić potencjalne problemy związane z wyświetlaniem pobranego na podstawie lokalizacji adresu.

Pod koniec wpisu postawiłem trzy pytania, na które warto sobie odpowiedzieć na etapie opracowywania założeń funkcjonalnych naszej aplikacji – czyli na początku prac.

  1. Czy nasza aplikacja będzie od początku/z czasem wielojęzyczna?
  2. Czy obsługujemy cały świat?
  3. Czy baza dostępnych punktów będzie dostępna dla użytkowników w trybie offline?

Odpowiedzi mogą znacząco uprościć lub skomplikować budowaną aplikację. Spróbuję na podstawie tych punktów rozważyć pewne możliwe rozwiązania.

Odpowiedź na pytanie pierwsze zdaje się wynikać z charakteru/zasięgu naszej działalności. Jeśli nasi klienci są rozsiani po całym świecie wówczas odpowiedź na to pytanie może być wcale nie taka oczywista.

Jeden język aplikacji, czy wiele…

Wiele firm działających w skali globalnej decyduje się na udostępnianie swoich aplikacji jedynie w wersji angielskiej – zakładając, że ich grupa docelowa posługuje się tym językiem. W takiej sytuacji dalsze rozważania problemów poruszonych w poprzednim wpisie dotyczące tłumaczeń adresów właściwie znikają – poruszamy się w obrębie jednego języka.

Inna sytuacja ma miejsce, gdy firma wporwadza aplikację z głównym językiem angielskim, honorując jednocześniej dodaniem języka kraju (regionu językowego) z którego ma największą liczbę odbiorców. Często w takich wypadkach pojawiają się takie języki jak: hiszpański, francuski, portugalski, chiński czy japoński. Kolejność może być różna. Mamy więc już do czynienia z aplikacją multilanguage. Nawet jeśli obsługujemy aktualnie tylko dwa języki, warto myśleć przyszłościowo i całość opracować tak, aby dodatnie kolejnego jezyka nie stanowiło problemu.

Cały świat czeka na nas!

Odpowiedź na drugie pytanie też może okazać się różna. Możemy sobie bowiem wyobrazić sytuację, gdy zapewniamy wielojęzycznośc w ramach aplikacji, ale jednocześnie poruszamy się w ramach jednego kraju. Taką aplikacją może być np. jakiś wirtualny przewodnik dla osób podróżujących po Polsce, czy jakimkolwiek innym kraju. Musimy zapewnić odpowiednie tłumaczenie adresów (np. typów miejsc: muzeum, park, zabytki…), ale formatowanie adresów nie stanowi problemu. W przypadku, gdy poruszamy się w ramach wielu krajów – całego świata, musimy również zapewnić odpowiednie formatowanie adresów dla każdego z tych krajów.

Aplikacja online, czy/i offline

Odpowiedź na pytanie trzecie jest zero/jedynkowa, nawet jeśli stanowi kompilacje tych dwóch rozwiązań. Oczywiście znajdujemy wiele aplikacji wymuszających na użytkowniku tryb online, zarówno pod kątem dostępu do sieci Internet jak i GPS, celem pobrania koordynatów. W takiej sytuacji pozostaje jedynie odpytywanie API w języku zdefiniowanym przez użytkownika w ramach aplikacji. Jeśli nasza aplikacja może się opierać na takim modelu korzystania z niej, takie rozwiązanie jest do przyjęcia i pozwalaj uniknąć sporej ilości wspomnianych problemów. Pomijam tutaj kwestie finansowe – Google pobiera opłaty za korzystanie z API (powyżej ustalonych limitów). Należy więc rozważyć opłacalnośc biznesową takiego rozwiązania.

Inna sytuacją jest, gdy nasze oprogramowanie ma raczej charakter biznesowy – np. udostępnia bazę odbiorców z całego świata, do której musimy mieć dostęp nawet, gdy jesteśmy offline lub gdy chcemy wprowadzić zaawansowane wyszukiwanie po wszelkim dostępnych elementach składowych adresu (np. generowanie raportów związanych z geolokalizacją). Musimy zatem zapisywać adresy w bazie danych. W ramach jednego języka – zapisujemy jedynie jedną wersję językową – problem jest zapewnienie odpowiedniego formatowania adresów z całego świata. W takiej sytuacji warto by było zastosować takie rozwiązanie, w którym posługujemy się właściwością formatted_address do pokazania odpowienio sformatowanego adresu, a klucze właściwości address_components służą nam do przeszukiwania bazy, czy tworzenia raportów. Zapewnienie funkcjonalności mulilanguage pociągnęłoby za sobą konieczność multiplikacji każdego adresu w każdym z dostępnych w aplikacji języków (można byłoby pominąć pewne klucze jak te związane z ulicą, numerem lokalu itp.). Czy jest to najbardziej optymalne rozwiązanie? Szczerze mówiąc na ten moment nie znajduję innego, które pozwoliłoby na zachowanie zakładanej funkcjonalności. Podobnie jak w przypadku jednej wersji językowej, formatted_address byłby wyświetlany jako adres miejsca – address_components do przeszukiwania. Problemem oczywiście byłoby zachowanie integralności danych pomiędzy wersjami językowymi – jednak nie jest to coś z czym nie można sobie poradzić. Wydajność? Tutaj wydaje się, że kluczowe byłoby opracowanie struktury bazy danych. Zapisywanie nadmiarowych/zduplikowanych danych – również opracowanie struktury. Warto byłoby to tak rozwiązać, aby przechowywać jedynie niezbędne „tłumaczenia” adresów, bez powielania tego, co nie bywa zwykle tłumaczone.

Dobrze zdefiniowane założenia początkowe

Odpowiadając na postawione na początku pytania możemy zbliżyć się do znalezienia odpowiedniego dla nas rozwiązania.  Rozważanie zapewnienia obsługi wielu języków w późniejszym czasie, gdy prace nad aplikacją są już zaawansowane, to proszenie się o dodatkowe koszty. Nie proponuje tutaj tak naprawdę gotowych rozwiązań, a jedynie rozważam pewne kierunki prac nad aplikacją. Do każdej należałoby podejść indywidualnie, doprecyzowując jak tylko to możliwe zakładane funkcjonalności. Pozwoli to na wybór najbardziej optymalnego oprogramowania, dla którego być może podstawą może być, jedno z omawianych przeze mnie powyżej rozwiązań.