Komentarze Metztlee Usuń wszystkie komentarze

Nawet cocoapodsy nie są jeszcze w pełni dostosowane do Swifta (pojawiła się beta go obsługująca w tym miesiącu). Skoro programujesz, to na pewno zauwżyłeś, że dla Apple pomysł załączania zewnętrznych bibliotek jest obcy, sami to mega utrudniają i nigdy na dev videos o tym nie mówią. Coś a'la cocoapodsy powinno być de facto wbudowane w Xcode'a. Także to dla nich raczej nie będzie wytyczną. Podejrzewam, że faktyczną wytyczną będzie ilość appek napisanych w Swifcie w AppStore za jakiś rok- oni na bank mają takie statystyki.

Angry Birdsy na 95% nie są pisane natywnie tylko w jakimś Unity czy innym podobnym ;) Jasne, że tamto tłumaczy sobie kod na natywny, ale to już nie wiesz czy się nie aktualizuje do Swifta ;).

'Narzędzia developerskie dla języka programowania Swift pobrano 11 milionów razy' - czyli Xcode, to samo co jest używane do starego Objective-C... Co za tym idzie, te 11 milionów wlicza programistów piszących w Obj-C a nie tylko w Swift.

To nie tak. Jak piszesz oprogramowanie, to nieraz popełniasz błędy, to całkowicie normalna rzecz. Dlatego właśnie stosuje się testy manualne, automatyczne, jednostkowe, code review, code refactor, pair programming etc - żeby jego jakość była jak najwyższa. Niestety nie jesteś w stanie osiągnąć kodu idealnego. Starasz się obstawić wszystkie furtki gdzie użytkownik może coś dziwnego zrobić, ale nie przewidzisz wszystkiego. Jeżeli nie przewidzisz czegoś poważnego, co zmieni coś w aplikacji na stałe i nie możesz tego odwrócić, to użytkownik będzie musiał reinstalować niestety. Nie unikniemy tego do momentu, aż nie zmieni się sposób programowania, na co na razie się nie zanosi, bo nikt nawet nie ma koncepcji jak moglibyśmy to robić inaczej.

Podejrzewam, ze przepisali już wszystkie moduły, niektóre po parę razy. Wiadomo, że ten kod, który to spaja razem, musiał się w międzyczasie trochę skomplikować i pewnie jest tam lekki szał, jednak podejrzewam, że koło 90% kodu Windowsa jest przepisane. Języka nie trzeba upgradować, bo oni używają głównie C/C++/C#, czyli spoko. Mogłeś nawet nie wiedzieć, że w którymś momencie przepisali bazę ;). Co do tego reinstalla - tak jest z każdym oprogramowaniem. Fakt, że z Windowsem w miarę często, między innymi bo mają swój nieczyszczący się rejestr, jednak ostatnio na infolinii Apple kazali mi reinstallować iOS, bo większy bug wyszedł. Nawet zwykłe appki na iOS, których poziom skomplikowania jest na poziomie niemowlaka w stosunku do Windowsa, nieraz się skopią i trzeba je przeinstalować. Zdarzyło mi się to z Googlowym YouTube'em.

Bardzo to popieram. Jakkolwiek dobry by nie był code refactor, tak czy siak przy zmianie podstaw i środowiska dobrze nieraz napisać kod od początku. Właściwie nie ma opcji by przy wprowadzaniu jakichkolwiek zmian przy takiej abstrakcji warstw poniżej nie skopać czegoś. Zwłaszcza, jeżeli zajmuje się tym nowa osoba (code review nie wyłapie wszystkich usterek). Z drugiej strony naprawdę nieźle im to wychodzi, jeżeli faktycznie nie przepisywali modułów Windowsa (nie interesowałam się- nie wiem, polegam na tym co napisałeś).

Posiadam Air zakupionego w 2011, korzystam również z Pro. W obu są takie same trudności z doczyszczeniem narożników, czyli robi się to całkiem spoko. Może mam po prostu dobrą ściereczkę i płyn do okularów ;).

"No tak iDioci, ja jednak jestem dumny z tego, że buduję brzydką skrzynkę stojącą obok biurka", "Apple chyba nie uczy się na błędach" lub inne komentarze - czy wyście na głowy upadli? Toż to KONCEPT, wyciek, żadne prawdziwe dane i raczej nie mają za wiele wspólnego z Apple. Nie zrobią lapka z jednym portem USB-C, bo jak podłączyć np. iPhone'a? Toż chcą być kompatybilni bez przejściówek ze swoim własnym sprzętem. Jakby ktoś Wam przedstawił zdjęcie nowego telefonu jako lodówkę z ekranikiem też byście uwierzyli i pojechali "Apple zawsze robi szmelc"? Bez sensu, myślcie, nie wierzcie bezwarunkowo w to, co piszą media.

"Gratulacje drodzy developerzy"? To brzmi, jakby byli temu winni. Zgaduj, ile developer ma do powiedzenia w tej kwestii. Może najwyżej nie wspierać danego systemu.

Konieczność kompromisowego pakowania w programie dwóch rodzajów bibliotek, 32 i 64 bit. -- bzdura.... Po pierwsze, biblioteki systemowe nie są "pakowane" w aplikacji, są dobierane z systemu w zależności od deklaracji appki. Jak jest system 64bit i appka jest 64bit, mamy tylko 64bitowe. Jeżeli system jest 64bit a appka 32bit to system wtedy wczytuje te 32bitowe. Te biblioteki są współdzielone między appkami. Jak widać, od lutego obowiązek wrzucać zgodne z 64bit, więc opcja 2 nie będzie zbyt popularna niedługo. Na 32bit nie wczytamy 64bit, więc nie ma co tłumaczyć.

To bardzo "racjonalne", że oceniasz iOS na podstawie Windows. Miałam też paru znajomych programistów, którzy nawet UI robili jak w desktopowym Windows. Cóż... Było wybitnie "wygodne" w obsłudze. Do tematu: oczywiście, że im więcej RAMu tym lepiej pod kątem wymagań aplikacji, nikt temu nie zaprzecza (osobiście uważam, że z pół giga iPhone 6 mógłby mieć więcej, ale teraz nie ma tragedii). Jest też problem zużycia baterii, czego nie bierzesz pod uwagę. Dlatego trzeba w miarę wypośrodkowywać między baterią a wydajnością w urządzeniach mobilnych. Nie porównuj do desktopowego Windowsa, który zupełnie inaczej zarządza multizadaniowością. Nawet do Androida trudno, ze względu na kompletnie inne zarządzanie pamięcią. Właśnie przez to zarządzanie na Androidzie musisz mieć więcej RAMu niż na iOS. Jak mi nie wierzysz, to zapraszam do obejrzenia wykresu wraz z wyjaśnieniem: http://qr.ae/qDcUv.

Nie wiem czemu tu wciskasz temat iPhone'a 4s, co to ma wspólnego z dyskusją o 64bitach? A może nie wiesz, że to zależy od CPU i iPhone 4s ma jeszcze 32bit? To częste (niestety dla nas) działanie, że ostatni system jest tak napisany by zmulił urządzenie - dzięki temu użytkownicy potem kupią nowszy sprzęt, bo "stary nie domaga". Na Androidzie i Windows Phone też tak robią. Ofc dla nas, userów, jest to niekorzystne. Anyway, używam iOS8 na iPhone 4s (16GB) i nie zauważam specjalnych zmuł. Ale to nie jest temat tej dyskusji.

Dobrze, że masz swoje zdanie, jednak przyporządkuj je trochę do systemu, bo na razie mam bekę z tej wypowiedzi ;P. Absolutnie nie przeczę, że powinny mieć więcej ramu. Ale stwierdzenie, że 64bit appka ogólnie potrzebuje więcej pamięci niż 32bit na 64bit systemie jest nieprawidłowe i o to mi chodzi, z tym polemizuję.

Totalna nieprawda. Aktualnie wszystkie systemowe frameworki i tak siedzą w pamięci w 64bit. W przypadku napisania aplikacji 64bit używamy tych już siedzących w pamięci, dla 32bit aplikacji należy wczytać 32bit odpowiedniki systemowych frameworków. Narzut powiększenia aplikacji do 64bit to betka w stosunku do narzutu wczytania dodatkowych 32bit frameworków. Polecam się douczyć przed pisaniem steku bzdur. Co do RAMu, jeżeli porównujesz do Androida, doucz się o garbage collector i różnicach.

@supair Eh i dałam się strollować ale muszę skomentować. Współczuję wyrazu twarzy jak dowiesz się o komputerach DNA, kryptografii molekularnej, algorytmach genetycznych itp. @lupusrex Co do braku "digital" faktycznie, nie ma. Jednak nie mówimy również "aparat telefoniczny" tylko telefon - również z czasem wyewoluowało. Zamiast "telefon komórkowy" używamy "komórka" i wcale nie mamy na myśli komórki pod schodami. Nieraz łatwiej jest użyć formy skrótowej, tutaj właściwie zawsze się jej używa (bo informatycy są leniwi ;)), w związku z czym nigdy nie słyszałam pojęcia "cyfrowy ekosystem", mimo iż jestem z branży.

Jak na razie to ja daję rzeczowe argumenty. Jeżeli posługujemy się językiem polskim, to występują w nim formy osobowe i proszę zwracać się do mnie w poprawnej formie - to jedyne o co poprosiłam i nie widzę związku z resztą rzeczowej rozmowy. Oczywiście, cały świata nie ma pojęcia co znaczy 'eko', zwłaszcza w dzisiejszych czasach gdy to tak modne "słówko". Tego typu dyskusja nie ma sensu. Definicja w encyklopedii jest, znaczy że istnieje.

Śmieszny argument. Po pierwsze użyłam formy żeńskiej, także idzie wywnioskować, że nie "Panu", a "Pani". Po drugie, jeżeli zarzucasz komuś, iż używa słowa niepoprawnie, a takowe występuje, to nie masz racji i naucz się czegoś nowego, rozwiń swoje horyzonty skoro my swoje potrafimy. Język jest zmienny, nowe słowa, znaczenia powstają. Świat się zmienia czy to się dziadkom podoba czy nie. Takie znaczenie jest używane w świecie IT, z kolei sjp ma prawo nie nadążać za wszystkimi modyfikacjami. Analogicznie znasz słowo hashtag? http://sjp.pl/hasztag, http://sjp.pl/hashtag - brak wpisu znaczy, że jednak takie słowo nie istnieje? Wikipedia o nim wie: http://pl.wikipedia.org/wiki/Hasztag.

@supair Najpierw doczytaj o różnych znaczeniach słów, później krytykuj (nie będę bezczelna i nie nazwę Ciebie niedouczonym hejterem): http://en.wikipedia.org/wiki/Digital_ecosystem.

Chyba pierwszy raz tak bardzo nie zgadzam się z artykułem Krystiana. W całym Apple'owym podejściu chodzi o bardzo intensywny sandbox'ing, który przyczynia się do bezpieczeństwa systemu. Jeżeli damy dostęp aplikacjom do danych w chmurze (i ewentualnej edycji na przykład), to bezpieczeństwo przechowywanych danych spada. Analogicznie gdy widget ma za dużo możliwości. To tak, jak jazda bez pasów samochodem - jest wygodniejsza, nie trzeba tracić czasu na zapinanie ale nie przesiądziemy się mając je założone. Analogicznie tutaj - iOS ma wiele zabezpieczeń, które zamykają niektóre możliwości ale ogólnie system jest bezpieczniejszy. Co do developerów, nie kierują się wspomnianą 'racjonalnością posunięć Apple' ale opłacalnością i jeżeli widgety są mile widziane przez użytkowników to będą je pisać.

Moze nigdy nie otwierales tej opcji i dlatego Ci sie nie wyświetla? Jezeli tak to spróbuj za pierwszym razem w Settings-General-Cellural-Personal Hotspot. Potem skrót bedzie dostępny pod Settings-Personal Hotspot.

W sobotę w iSpot CityCenter (Poznań ofc) było kilka rodzajów etui z tego co widziałam. Podejrzewam, że Cortland też ma ;).

Pitu pitu. Pamiętam jak wszyscy narzekali na iOS7. Prawdziwym problemem jest fakt, że aktualizacja wymaga 8GB przy nie używaniu iTunes, co jest niemożliwe dla sporej ilości użytkowników z iDevice o małej pamięci (8/16GB). Nie ma co szukać dziury w całym...

MBA 11' mid 2011, i5, 4GB RAM - wszystko śmiga, nic nie muli, nie widzę różnicy wydajnościowej między tą a poprzednią wersją ;).

Miałam okazję przyjrzeć się osobiście kodowi aplikacji na iOS jednego z naszych banków i strach - wyciągnięcie informacji nie było żadnym problemem. Cały proces wytwarzania oprogramowania opiera się na błędach i testach. Twierdzenie przeciwnie świadczy o kompletnej ignorancji komentującego- zapraszam do przeczytania jakiegokolwiek artykułu o tworzeniu oprogramowania i to właściwie tyle co mam do powiedzenia, ze ścianą nie da się dyskutować skoro rozsądne argumenty się odbijają i 0 chęci poszerzenia wiedzy.

@jasiecki

Postęp opiera się na błędach, inaczej wciąż jeździlibyśmy VW Garbusem, w którym spot reklamowy mówił 'w tym aucie zepsuło się już wszystko, co mogło'. To jak, kupujesz Garbusika? Niezawodny jest, a z nowymi VW nie wiadomo, ale ostatni Polo miał częste usterki, więc w tym Golfie też się może coś zdarzyć.

Nie wystawiajmy więc żadnych nowych technologii, bo może się okazać, że gdzieś będzie błąd (a będzie na 100%, tak działa informatyka, po to zatrudnia się testerów i hackerów by zdążyć samemu wyłapać i naprawić zanim ktoś inny zauważy - nie tylko w Apple, wszędzie). A jak nie będzie już tych nowych technologii to narzekajmy, że firma się kończy ;). Nie bronię Apple, wtopa z atakiem ddos na icloud była duża, ale nie można od razu twierdzić, że trzeba wszystkie komputery wyrzucić za okno, bo wyolbrzymiając właśnie to napisałeś.

@Szemot

Kompletnie nie widzę powiązania między iWallet a Apple Pay, nie wymyślaj bo potem ktoś głupszy powtórzy i tak powstają plotki ;). Jeżeli to a'la iWallet ma oznaczać dedykowaną appkę do płatności, to podejrzewam że tak będzie. Będzie się na niej wyświetlać co i za ile kupujesz zapewne. Inaczej byłoby to niebezpieczne, bo ktoś mógłby Ci podstawić coś innego obok i to coś innego byś kupił a nie obiekt pożądania- nie widzę w tym rozwiązaniu żadnych minusów.
Co do stwierdzenia, że Polska wiecznie na końcu - zgadzam się, zobacz na moją wypowiedź wyżej gdzie napisałam, że pewnie za rok/dwa dopiero coś się pojawi, nie ma co się podniecać.
Jednak NFC pojawiło się tu dość wcześnie i daje mi to nadzieję, że mój mBank znów pochwali się podejściem do młodych ;).
Weź pod uwagę, że u nas użytkowników iOS jest mało - nawet pisząc programy nie warto ich wypuszczać do Polskiego AppStore, bo się to nie kalkuluje. Co więcej nikt nie wyda złamanego grosza na aplikację, ew jeden kupi, reszta ściągnie nielegalnie ;P. Sorry, takie fakty, sami sobie tworzymy tą rzeczywistość, że u nas wszystko gorsze. Oczywiście to też wynika z niższych pensji (błędne koło się zapętla) ale też ogólnego przyzwolenia na taką kradzież. Przez to mija nas dużo różnych nowinek - głównie w oprogramowaniu. Więc pytanie brzmi: czy bankowi zwróci się inwestycja w ten drobny procent użytkowników iOS.

[author=iLambert]

Na pewno będzie to obciążeniem środków, dyskutujemy o tym w jaki sposób. Zauważ, że podczas konferencji dużo mówili o beznadziejnym bezpieczeństwie plastikowych kart - co jest w 100% prawdą. Padło stwierdzenie, że ich system ma być bezpieczniejszy, co jest wysoce prawdopodobne patrząc na zwykłe karty. Płatność z użyciem NFC też jest bezpieczniejsza niż zwykłe karty. Na tak wstępnym poziomie jak teraz trudno dyskutować czy i które jest bezpieczniejsze.

Z kolei jak chodzi o wdrażanie przez banki czy nowe terminale - coś na pewno trzeba będzie zrobić, podczas konferencji podali 8 banków w wysokiej fazie rozwoju projektu i paręnaście innych dopiero wdrażających kompatybilność z tym.

Nie mam pojęcia czy będzie potrzebne dopisanie algorytmu gdzieś, zmiana terminala czy czegokolwiek po drodze - większość to moje domysły na bazie tego co mówili. Coś na bank trzeba dorobić, gdyż inaczej od razu działałoby to ze wszystkimi bankami a nie 8. Jeżeli oni do terminala przesyłają 2 numery generowane przez telefon - jeden stały, drugi jednorazowy, to terminal musi być w stanie zinterpretować otrzymaną informację. Aktualne tego na pewno nie potrafią, bo niby skąd, programiści w myślach Apple'owi nie czytają i nie zaimplementowali tego przed premierą ;).

Jestem kobietą, mam taki różowy znaczek przy mojej nazwie użytkownika ;)

Po pierwsze Twój bank musi przystać na warunki tej usługi i zaimplementować odpowiednie rzeczy po swojej stronie. Następnie podejrzewam (choć pewności nie mam, w końcu to dość początkowa faza i nie ma skąd czerpać wiedzy), że sklep również będzie musiał mieć kompatybilny czytnik.

Jak dwa pierwsze warunki są spełnione i wykonasz jednorazową 'inicjalizację' (o której za chwilę) po prostu podchodzisz, kasjer wklepuje co potrzebuje na kasę, podaje Ci terminal płatniczy (czy jakkolwiek się to zwie), sprawdzasz czy cena jest prawidłowa (czyli wszystko co do tej pory robiłeś przy NFC, płaceniu kartą czy gotówką). Następnie przykładasz swój telefon do device'a oraz swój palec do przycisku home, który ma czytnik linii papilarnych w celu uwierzytelnienia i voila, koniec. To ze strony użytkownika. Ze strony iphone'a, po uwierzytlenieniu generuje security code (unikalny na transakcję), przesyła do czytnika wraz z Device Account Number. Terminal cośtam dalej z nim robi co nie jest wyjaśnione.

Inicjalizacja z tego co zrozumiałam, wygląda w ten sposób, że podajesz wszystkie dane karty (numer, security code i data wygaśnięcia, czyli to co zawsze podaje się przy zakupach). Następnie generowany jest z tego Device Account Number, który jest przechowywany na urządzeniu a nie w cloudzie, znów ze względów bezpieczeństwa.

Czyli w skrócie: 1. Za pierwszym uruchomieniem podajesz numer karty, security code i expiration date. 2. W sklepie przykładasz telefon do terminala a swój palec do przycisku home. 3. Przy kolejnych zakupach powtórz punkt 2, bo pierwszy jest jednorazowy (per device).