Znajomi autor tutaj.
Rzeczywiście, jak podejrzewasz, obsługa kont Ubuntu Online jest wymagana przed dodaniem wsparcia do znajomych. Architektura znajomych w dużym stopniu zależy od UOA w celu wykonania całej autoryzacji i zarządzania dla nas wszystkimi kluczami API. Moim ulubionym przykładem jest LinkedIn, ponieważ jest to do tej pory jedyny protokół, który został wniesiony przez społeczność. Wtyczka UOA to w większości tylko dwa pliki XML, a także trochę sztuczek z autoconf, które wyglądają tak. (przewiń trochę w dół, aby zobaczyć różnicę, która wyraźnie pokazuje każdą rzecz, którą trzeba było dodać, aby LinkedIn działał).
Kiedy już zrobisz to samo dla swojego protokołu, musisz zaproponować scalenie z wtyczkami lp: account i zmusić Mardy do ich przeglądu, zatwierdzenia i scalenia. Gdy to będzie na miejscu, możesz zacząć pisać wtyczkę znajomych, która zostanie napisana w Pythonie 3.
Teraz jednym z głównych, głównych ulepszeń wprowadzonych przez Friends w stosunku do Gwibbera jest wykorzystanie podklas. W oryginalnym kodzie Gwibber absolutnie nic nie zostało zrobione z podklasami, więc każda nowa wtyczka protokołu była ogromną metodą kopiowania i wklejania różnych fragmentów funkcji niskiego poziomu. Wdrażając Friends, dołożyłem wszelkich starań, aby wyodrębnić wspólną funkcjonalność do nadklasy, którą można łatwo podklasować i modyfikować. Nadklasa ma również całkiem sporo dokumentów, do których powinieneś się odwoływać na początku. Niestety nie skonfigurowaliśmy jeszcze sfinksa do publikowania ich nigdzie, więc na razie będziesz musiał przeczytać kod.
Należy pamiętać, że nazwa twojej klasy musi pasować do użytej nazwy „nazwa-dostawcy”, bez rozróżniania wielkości liter. Jeśli więc zdefiniowałeś nazwę dostawcy instagram, powinieneś utworzyć plik protocols/instagram.pyi nazwać swoją klasę Python Instagram.
Dwie najważniejsze metody, które musisz bezwzględnie zaimplementować, aby wtyczka mogła cokolwiek zrobić, są nazywane _whoamii receive. Są one dobrze udokumentowane w pliku base.py (link powyżej), ale w zasadzie _whoamimetoda zostanie wywołana automatycznie i przekazana w nagraniu, który reprezentuje już przeanalizowany obiekt blob JSON, który został nam przekazany przez usługę w momencie uwierzytelnienia. Jeśli masz szczęście, ten słownik będzie zawierał twoją nazwę użytkownika na Instagramie, identyfikator użytkownika i nazwę wyświetlaną, ale jeśli nie, będziesz musiał wykonać drugie wywołanie API w celu zebrania tych informacji. Zobacz Facebook._whoamiprzykład protokołu, który nie dostarczył informacji z góry i wymagał dodatkowego wywołania API z poziomu metody, i zobaczTwitter._whoami na przykład protokołu, który dał nam wszystkie szczegóły, których potrzebowaliśmy od razu.
Następnie receivemetoda odpowiada za wywołanie interfejsu API, który odpytuje usługę w poszukiwaniu nowych wiadomości. Ten jest nieco bardziej dowolny, ponieważ każdy interfejs API REST jest nieco inny, dlatego powinieneś zapoznać się z dokumentami API witryny, aby dowiedzieć się, co dokładnie należy tutaj zrobić. W http.py zapewniamy Uploaderi Downloaderklasy, które ułatwiają wykonywanie wywołań interfejsu API REST, a nawet mogą analizować odpowiedzi serwera JSON za Ciebie. Ważne jest, aby używać tych klas wygody, ponieważ są one libsoupskonfigurowane tak, aby honorować ustawienia proxy GNOME (możesz sobie przypomnieć, jak okropne było zawsze wsparcie proxy Gwibbera, cóż, naprawiliśmy to teraz).
Gdy otrzymasz odpowiedź API z serwera, musisz ją zapisać w naszym DeeModel (gdzie Gwibber użył obiektu blob JSON zrzuconego do dbq sqlite do przechowywania twoich wiadomości, używamy DeeModel, który jest po prostu bazą danych które współużytkują stan w DBus, ułatwiając wielu klientom łatwe wyświetlanie danych wiadomości). Akt przechowywania nowej wiadomości nazywamy „publikowaniem” i udostępniamy jej dogodną metodę na stronie Base._publish. Zasadniczo wszystko, co musisz zrobić, to wypełnić puste pola tutaj, upewnij się, że jak najwięcej informacji jest wypełnionych w jak największej liczbie kolumn. Możliwe argumenty do opublikowania są zdefiniowane w schemacie i ponownie możesz odwołać się do istniejących wtyczek, aby zobaczyć, jak to robią.
Gdy dotrzesz już tak daleko, powinieneś mieć wystarczająco dużo, aby móc go przetestować. Udostępniamy kilka narzędzi w toolskatalogu, aby ułatwić uruchamianie kodu z drzewa źródłowego, dzięki czemu nie musisz instalować go w systemie za każdym razem, gdy chcesz wprowadzić zmiany. Co powinieneś zrobić, to otworzyć jeden terminal, cd do katalogu głównego drzewa źródłowego i uruchomić ./tools/debug_slave.py. To, co robi, łączy się z DeeModel i po prostu wyświetla wszystko, co się z nim dzieje, abyś mógł zobaczyć wiadomości pojawiające się na żywo w momencie ich wejścia. Następnie, w drugim terminalu, ponownie cd do katalogu głównego drzewa źródłowego, i uruchom ./tools/debug_live.py instagram receivei który ręcznie uruchomi metodę Instagram.receive i wyświetli kilka wyników debugowania, aby poinformować Cię o tym, co się dzieje w trakcie jego działania (możesz posypać kod wywołaniami funkcjilog.debug("hi") jeśli chcesz zobaczyć jeszcze więcej szczegółów na temat tego, co się dzieje).
Aha, a jeśli nadal czytasz, wtyczka linkedin nie wylądowała jeszcze w bagażniku, ale nadal możesz na nią spojrzeć tutaj.
Jeśli masz jakieś inne pytania, zawsze jestem na #gwibber na freenode, a także mocno czuję, że nowa baza kodów jest znacznie bardziej czytelna i lepiej udokumentowana niż cokolwiek, co kiedykolwiek miał Gwibber, więc proszę przeczytaj kod, który tam jest i nie powinien zbyt trudne do nauczenia się na przykładzie. Facebook i Twitter są najbardziej kompletne.
Dziękujemy za zainteresowanie przyjaciółmi!