r   e   k   l   a   m   a
r   e   k   l   a   m   a

OS X Yosemite od środka: na zmianach w interfejsie użytkownika się nie skończyło

Strona główna AktualnościOPROGRAMOWANIE

Nowy OS X 10.10 Yosemite przykuł uwagę przede wszystkim odświeżonym interfejsem graficznym, korzystającym w pewnym stopniu z estetyki i wzornictwa wypracowanego przy iOS-ie. Tuż przed oficjalną premierą Yosemite przygotowaliśmy dla Was krótki przegląd zmian w pulpicie Maków. Czy jednak faktycznie z Yosemite jest jak z Windows 10 – dużo hałasu o interfejs użytkownika? Po kilku dniach pracy z nowym systemem Apple przekonujemy się, że tak nie jest. Choć typowy użytkownik Maka może tego nie zauważyć, Yosemite wprowadza fundamentalne zmiany do systemu, otwierające drogę do bardzo ciekawej przyszłości. Zapraszamy do zapoznania się z tym, co na pierwszy rzut oka w nowym OS X niewidoczne.

System plików

Nie raz sygnalizowaliśmy, że system plików w OS X to tragedia. Wykorzystywany od lat 90 HFS+ znacząco odbiega od nowoczesnych systemów plików, takich jak linuksowy btrfs czy nawet rozwijany przez Microsoft ReFS. Niektórzy liczyli na to, że w Makach w końcu pojawi się potężny ZFS, znany z Solarisa i FreeBSD – ale tak się, zapewne z powodów licencyjnych, nie stało. Apple musiało w końcu zrobić coś swojego. I faktycznie zrobiło, tylko że boczną drogą. W 2011 roku w OS X 10.7 zadebiutował menedżer wolumenów logicznych (LVM) dla tego systemu, Core Storage. Jego podstawowym zastosowaniem było wówczas wsparcie dla znacznie ulepszonego mechanizmu szyfrowania dysków FileVault. Rok później Apple pokazało korzystający z CoreStorage mechanizm FusionDrive, pozwalający tworzyć pule pamięci masowej z dysków różnej szybkości (np. SSD+HDD).

Oczywiście wciąż poszczególne wolumeny korzystały z HFS+ – i tak jest także w Yosemite. Coś się jednak zmieniło. Nowy system Apple'a wymusza stosowanie CoreStorage. Testowy komputer z OS X 10.9 korzystał z najprostszej możliwej konfiguracji dyskowej – jeden napęd SSD, z jednym wolumenem HFS+. Po zaktualizowaniu systemu do OS X 10.10 okazało się, że ten pojedynczy wolumen HFS+ został przekształcony w pojedynczy wolumen logiczny, znajdujący się w grupie Core Storage.

r   e   k   l   a   m   a

Jest to o tyle istotna zmiana, że z tego co wiadomo o menedżerze wolumenów logicznych Apple'a, zapewnia on kilka typowych dla nowoczesnych systemów plików rozwiązań, takich jak struktury drzewiaste, kopiowanie przy zapisie czy niezależne przechowywanie metadanych. Wprowadzając LVM jako standard, Apple będzie mogło w kolejnych wydaniach OS X bezboleśnie dla użytkowników zastąpić HFS+ czymś nowocześniejszym.

Integracja z chmurą

OS X raczej nigdy nie upodobni się do Chrome OS-a, dla którego to chmurowy system plików jest tym podstawowym, ale to nie znaczy, że jego użytkownicy nie są zainteresowani przechowywaniem swoich dokumentów poza komputerem. Co prawda w Makach od kilku lat można już przechowywać dokumenty w chmurze iCloud, ale rozwiązanie to nie było dopracowane – tam każda aplikacja przechowywała pliki tylko dla siebie, w sposób niewidoczny dla innych. Nic więc dziwnego, że praktycznie nikt z tego rozwiązania nie korzystał, nawet wierni fani Apple wybierali bardziej zrozumiałego Dropboksa czy Dysk Google, wiedząc, że z nimi będą mogli znaleźć swoje pliki.

O tym, że szykuje się zmiana tego stanu rzeczy, było już wiadomo po wydaniu iOS-a 8. iCloud zamienił się w iCloud Drive. Co prawda aktualizacja nie jest obowiązkowa, wciąż można korzystać z chmury Apple po staremu, ale widać, że zmiana jest mocno zalecana. W jednorazowym procesie wszystkie dokumenty z iCloud zostaną przeniesione do iCloud Drive. Stare wersje systemów (iOS 7 i OS X 10.9) nie będą już miały do nich dostępu.

Do chmurowej pamięci masowej mamy oczywiście dostęp zarówno z Findera, jak i z okna dialogowego plików. Pozornie wygląda to jak kolejna lokacja systemowa, zachowuje się jednak nieco inaczej. Po pierwsze, tworzy hierarchię folderów dla poszczególnych zgodnych z iCloud Drive aplikacji, z którymi niewiele można zrobić – nawet nie mamy dostępu do informacji o nich. Tak samo nie można (zbyt łatwo) znaleźć informacji o lokalizacji lokalnego folderu, który miałby synchronizować się z chmurą. Z poziomu terminala w końcu znajdziemy jego lokalizację, w ~/Library/Mobile Documents/, gdzie zobaczyć można będzie całą listę podkatalogów z nazwami w odwrotnej notacji DNS (np. com~apple~TextEdit). Wyraźnie nie jest to coś, co miałby oglądać użytkownik – Apple nie chce byśmy myśleli o iCloud Drive jako o folderze, który się synchronizuje z chmurą. To pełna abstrakcja wolumenu w chmurze, nic mniej.

Warto tu też wspomnieć o frameworku CloudKit, który ma przekonać deweloperów do korzystania z usług synchronizacji i uwierzytelniania od Apple, i wydaje się być zamiennikiem niemożliwie skomplikowanego Core Data. Ujawnia on podstawowe struktury danych (np. konta użytkowników) i pozwala na łatwe manipulowanie nimi na serwerach Apple. Sądząc po opiniach wyrażanych w serwisach takich jak StackOverflow, programistom CloudKit bardzo się podoba. Zachowuje się w pełni przewidywalnie, jest dostępny za darmo, chroni też w wysokim stopniu prywatność użytkowników – nie ma sposobu, by twórca aplikacji korzystającej z CloudKit uzyskał dostęp do prywatnych danych użytkownika.

Rozszerzenia

Koncepcja rozszerzeń jest chyba oczywista dla każdego użytkownika przeglądarki internetowej. Kilkoma kliknięciami możemy znacznie zwiększyć możliwości programu – albo go popsuć, jeśli rozszerzenie zrobi coś niewłaściwego. A gdyby tak można było rozszerzać cały system za pomocą takich dodatków? Pomysł nie jest niczym nowym. Takie możliwości rozszerzeń były w Amiga OS-ie i klasycznym Mac OS-ie... pozwalając czasem na spektakularne zawieszenia systemu. Brak ochrony pamięci w tych antycznych systemach sprawiał, że awaria jednego programu mogła zawiesić cały komputer.

Nowoczesne systemy operacyjne nie pozwalają programom na takie bezeceństwa, ale zarazem utrudniają modyfikowanie systemu. W OS X od niemal samego początku można było takie niezależne modyfikacje wprowadzać, korzystając z mniej lub bardziej udokumentowanych API, ale nie ma co ukrywać – system Apple'a był znacznie trudniejszy i mniej podatny na modyfikacje niż Windows. OS X Extensions zmienia to. Otrzymaliśmy globalny mechanizm rozszerzeń, odpowiedni dla nowoczesnych systemów operacyjnych.

Rozszerzenia są tu dostarczane w paczkach aplikacji (nie mogą być zainstalowane samodzielnie), ale działają jako niezależne binarki, z własnymi uprawnieniami, w niezależnych procesach i w oddzielnej przestrzeni adresowej. Uruchamiane są w odpowiedzi na działania użytkownika przez system operacyjny, nawet jeśli przypisana im aplikacja nie działa, wykonując operacje na dostępnych im punktach styku z aplikacją. Na razie są cztery takie punkty – Share (do współdzielenia plików poprzez serwisy internetowe), Action (zmiany treści w jednej aplikacji przez inną aplikację), Today (do wyświetlania zdarzeń w pasku powiadomień) oraz Finder Sync (do kontrolowania stanu synchronizacji plików przez niezależne usługi).

Warto wspomnieć, że rozszerzenia nie są ograniczone do tylko jednej aplikacji. Dzięki mechanizmowi App Group możemy współdzielić rozszerzenie między wieloma aplikacjami, dając np. wszystkim aplikacjom graficznym możliwość publikowania w niewspieranym przez Apple serwisie internetowym czy edytowania za ich pomocą obrazków wklejonych do procesora tekstu. Trzeba pamiętać, że rozszerzenia dziedziczą ustawienia prywatności po swojej macierzystej aplikacji. Zarządzać dostępnymi rozszerzeniami typu Share, Action i Today można w Preferencjach systemowych (Rozszerzenia) – sprowadza się to do zaznaczania i odznaczania tego, co nas interesuje.

Ze względu na podobieństwo zastosowanych interfejsów między OS X 10.10 i iOS 8 można się spodziewać, że wiele tych rozszerzeń będzie wymienianych między oboma systemami. Zapewne też pojawią się aplikacje-atrapy, których jedynym zastosowaniem będzie wprowadzanie do systemu nowych rozszerzeń.

Automatyzacja

Ręka do góry – wszyscy ci, którzy znają AppleScript. No cóż... a teraz ręka do góry wszyscy ci, którzy znają JavaScript. Dziękujemy za las rąk. Mechanizm automatyzacji systemu operacyjnego, udostępniany poprzez Open Scripting Architecture, otrzymał interfejs, z którym poradzi sobie każdy webdeweloper – wreszcie można będzie sterować Makiem za pomocą popularnego JavaScriptu. Co ciekawe wprowadzono tu mostek do Objective-C, dzięki któremu z poziomu skryptów można uzyskać dostęp do systemu plików i budować wizualne aplikacje Cocoa.

Z JavaScriptu możemy teraz korzystać w edytorze skryptów, globalnym menu skryptów, appletach i dropletach, poprzez linię komend i we wszystkich innych miejscach, gdzie można było dotąd używać AppleScriptu (np. w zarządzaniu folderami poczty). Kod działa na tym samym silniku JavaScriptCore, z którego korzysta przeglądarka Safari.

Swift

Wygląda to niepozornie – ot w katalogu /usr/bin można znaleźć coś, co nosi nazwę swift. Jest to jednak największa zmiana w historii Maka od czasu przejścia na procesory Intela. Swift to nowy język programowania, na pierwszy rzut oka przypominający mieszankę Pythona i Ruby, ale podobno dający możliwości statycznych języków o silnej typizacji. Stworzony przez Chrisa Lattnera, jednego z głównych programistów pionu Apple Developers Tools, autora narzędzi dla kompilatora LLVM, ma docelowo zastąpić Objective-C jako wiodący język programowania – i to dla obu systemów Apple'a. Firma z Cupertino określa go jako pierwszy na świecie język przemysłowej jakości, który jest równie ekspresyjny i przyjemny jak języki skryptowe, skalujący się od 'witaj świecie' do całego systemu operacyjnego.

Osoby zainteresowane Swiftem powinny odwiedzić iTunes, by pobrać z nich darmowego e-booka The Swift Programming Language. Tutaj jedynie przedstawimy kilka najważniejszych cech Swifta. Można o nim myśleć jako o języku wyższego poziomu niż Objective C, z przejrzystą składnią, automatycznym zarządzaniem pamięcią, typami danych przechowywanymi w bibliotece standardowej języka (notabene też napisanej w Swifcie) i pełną inferencją typów. Znajdziemy tu w zasadzie wszystkie rozwiązania znane z innych nowoczesnych języków, w tym domknięcia, krotki, szybkie iteracje po kolekcjach czy wywoływanie funkcji wyższego rzędu, takich jak mapy czy filtry.

Ze Swifta możemy korzystać zarówno jako z języka skryptowego, uruchamianego shebangiem (#!), poprzez interaktywną konsolę, jak i do budowania wysoce zoptymalizowanego kodu pośredniczącego i maszynowego, z wykorzystaniem (a jakże!) kompilatora clang i całej infrastruktury LLVM. Oczywiście Swift zapewnia pełną obsługę systemowych frameworków Apple'a, na czele z Cocoa, pozwala też na wykorzystanie praktycznie wszystkich API dla Objective-C bez konieczności wprowadzania zmian w kodzie.

Opinie o Swifcie są podzielone. Na pewno wiele osób jest niezadowolonych z tego, że Swift nie jest opensource'owy – ale pewnie wcześniej czy później Apple będzie zmuszone do wydania języka na jakiejś otwartej licencji. Dyskusje o składni czy semantyce języka nie mają końca, zapewne wiele rzeczy można byłoby tu zrobić lepiej, ale trzeba podkreślić jedno – Swift to nie jest produkt akademicki. Język został zrobiony przez człowieka, który zawodowo pracuje nad kompilatorami, dla którego najważniejsza jest wydajność i wygoda programowania.

Refleksje

Zmiany wprowadzone w systemie, który swoją numeracją żadnego wielkiego przełomu przecież nie obiecywał, są daleko bardziej idące, niż można by było sądzić. To postawienie fundamentów pod nowy, znacznie bardziej modularny i elastyczny system Apple'a, od podstaw pisany z myślą o zastosowaniach desktopowych – ale zarazem dobrze się integrujący z systemem tworzonym dla urządzeń mobilnych, współdzielący z nim liczne interfejsy i mechanizmy.

Wbrew spekulacjom o tym, jakoby Apple dążyło do połączenia OS X i iOS-a w jeden system, coś na podobieństwo jednego Windows 10 dla wszystkich urządzeń, na to się tu nie zanosi. Producent sprzętu z Jabłkiem widzi, że między komputerami osobistymi a tabletami czy smartfonami rozciąga się przepaść – i nie ma co na siłę jej zasypywać. Maki mają być przede wszystkim narzędziami do tworzenia treści, podczas gdy iUrządzenia – narzędziami do jej konsumpcji. To wymaga integracji interfejsów systemowych, a nie ujednolicania interfejsów użytkownika, jak to sobie wyobraził swego czasu Microsoft. Dlatego też autor tego tekstu wątpi w pojawienie się kiedykolwiek hybrydowych Maków-iPadów czy wciśnięcie dotykowego interfejsu do OS X-a. Apple stawia na wspólne fundamenty – ale odmienną ergonomię, dostosowaną do specyfiki poszczególnych urządzeń.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.