Windows Centralin mukaan Microsoft ei ole ollut syyskuun jälkeen aktiivinen Project Astorian keskustelupalstalla, minkä kautta Microsoft on kerännyt palautetta Project Astoriaa testanneilta sovelluskehittäjiltä. Microsoft ei ole vastannut edes kysymyksiin, joissa on ihmetelty ohjelmistojätin radiohiljaisuutta. Vahvempi merkki hankkeen keskeyttämisestä löytyy Windows 10 Mobilen uusimmista koontiversioista, joista on poistettu Android-sovellusten ajamiseen tarkoitettu emulointijärjestelmä.
Microsoftin edustaja kommentoi asiaa Windows Centralille. Yhtiön mukaan Project Astoria ei ole vielä valmis, mutta kommentista ei selviä kunnolla, että onko hanketta tarkoituskaan enää saada valmiiksi. Microsoftin mukaan muut tarjotut porttausvalinnat (iOS, Web ja Win32) ovat hyviä vaihtoehtoja Windows 10 -sovellusten nopeaan luomiseen. Microsoftin toivoo eri alustoille tarjottujen porttaustyökalujen ratkaisevan Windows 10:n "app gap" -ongelman eli sovellusten puutteen.
Kommentit (10)
Islandwood onkin ainut millä on todellista merkitystä koska 95% appeista tehdään iOS first.
Aivan. Ja monissa iOS versio on laadukkaampi kuin Android -versio. Tässä jutussa ei vaan mainita että mitä ilmeisimmin Project Astoria on kuopattu siksi, että kyseessä ei ollut Android -sovellusten porttaaminen Windowsille vaan niiden suora emulointi, joka ei välttämättä olisi ollut laillista.
Ja laillista tai ei, sovellusten toimintalogiikka olisi ollut android-logiikkaa ja ne olisivat näyttäneet android-sovelluksilta ja pyörineet natiivisovellusta huonommin.
iOS-sovellusten hyvään laatuun on ainakin kaksi syytä. Ensimmäinen on koodaamisen helppous. Etenkin nykyisin Applen kehittämä Swift tarjoaa naurettavan helpon mahdollisuuden koodata omia sovelluksia ja saada ne vieläpä näyttämään hyvältä - Apple kun on tehnyt puolet valmiiksi. En usko, että Objective C:kään olisi ollut kovin hankala, sillä Swift sisältää monia sen elementtejä.
Toinen syy on yksinkertaisesti se, että maksullisista sovelluksista saa varmemmin rahaa iOS-puolella, sillä niitä ei pysty lataamaan laittomasti tai muuten kiertotietä. Apple-käyttäjät ovat myös herkemmin valmiita maksamaan sovelluksista ja peleistä.
Et oo tainnut ikinä kuulla esim. Cydiasta? Noita paikkoja, mistä iOS-piraatteja saa löytyy vaikka kuinka paljon.
Olen kyllä kuullut, mutta jailbreikattujen iPhonejen määrä on prosentuaalisesti paljon pienempi paha verrattuna siihen, että Androidissa vastaavan tempun voi tehdä ilman sen kummempia kikkailuja.
Söpö rölli
Viittaa varmaan alkuperäisen uutisen kohtaan:
Eihän Islandwood porttaa mitään vaan on bridge. Eli sen saman iOS koodin pystyt buildata Windows10 laitteille sopivaksi sellaisenaan Islandwoodia avuksi käyttäen.
iOS -> Android taitaa nykyäänkin mennä niin natiiveissa appeissa, että androidprojekti aloitetaan puhtaalta pöydältä ja iOS koodia käytetään mallina. Ellei käytössä ole multiplatform frameworkkia jolloin lopputulos on joka alustalla huono.
Olen jokseenkin eri mieltä. Kielellä, oli se sitten Swift, C++, Objective-C tai vastaava ei ole kauheasti tekemistä kehityksen helppouden kanssa, kielen oppii yleensä päivissä tai viikoissa sellaiselle tasolle, että sitä voi käyttää työssään. Käytössä olevilla rajapinnoilla ja työkalujen laadulla on. Niiden tehokkaan käytön oppiminen vie usein paljon enemmän aikaa.
Swift on paperilla paljon mukavampi kieli kuin ObjC, mutta käytännössä työkalut (alkaen kääntäjästä ja debuggerista, joiden nopeus ja stabiliteetti ovat olleet jotain ihan muuta kuin voisi toivoa) ovat olleet huomattavasti heikommat kuin ObjC:lle, myös itse kieli on elänyt hämmentävän paljon eikä vanhan koodin yhteensopivuudesta uusien Swift-versioiden kanssa ole välitetty lainkaan. Tämä ei tietenkään tullut minkäänlaisena yllätyksenä, uusi kieli on uusi kieli ja Apple myös varsin selkeästi ilmoitti että kieli tulee muuttumaan 1.0:sta paljon ja niin on myös käynyt.
Vaikeusastetta on lisännyt myös se, että aluksi Cocoa rajapintojen Swift versiot sisälsivät paljon vähemmän tietoa kuin mitä Swiftin kanssa olisi tarpeen (tiedostot listaava rajapinta saattoi esimerkiksi palauttaa tyypin [AnyType]? , kun oikea tyyppi on [NSURL] (tai [String], riippuen API:sta). Koska Swift on vahvasti tyypitetty kieli, toisin kuin ObjC, tuli tyyppiepäselvyyksien hoitamisesta paljon ylimääräistä koodia (tässä tapauksessa ehdollinen cast ja optionaalisen tyypin unwrappaus)
Suunta on oikea, Swift 2.1 alkaa olla jo aika hyvä, kääntäjän nopeus ja vakaus on parantunut, mutta debuggerin ja etenkin Swiftillä tehtyjen dynaamisten frameworkkien kanssa on edelleen suuria ongelmia. Suosittelisin edelleen Objective-C:n käyttöä jos ei ole jotain erityistä syytä siirtyä Swiftiin ja silloinkin tiukkaa kuria mitä ominaisuuksia käytetään, miten ja pysymään erossa dynaamisista frameworkeista kunnes Apple saa hommat kuntoon.
Samaa mieltä olen siitä, että Applen Cocoa API on varsin laaja ja hyvä, tietyt asiat ovat erittäin helppoja, loputkin mahdollisia. 😊 Lisähyötynä on Applekäyttäjien nopea päivittäminen uusiin käyttöjärjestelmiin, joten vanhoja käyttiksiä ei tarvitse tukea hamaan ikuisuuteen vaan pääsee nauttimaan uudemmista Applen tarjoamista rajapinnoista varsin pian julkaisun jälkeen.
Joku tästä jo nipottikin, mutta olet oikeassa. iOS puolella on enemmän valmiutta maksaa softasta ja etenkin kun kehitykseen vaadittava työmäärä on useista syistä johtuen huomattavasti pienempi, on usein järkevää tehdä iOS versio ensiksi.