Michal Ždanský Baie skyfies het geval toe die bos van kompleksiteit vir die oorspronklike iPhone afgekap is. In die naam van vereenvoudiging en gebruiksgemak van die revolusionêre foon, het Apple sommige aspekte van die bedryfstelsel tot 'n absolute minimum gesny. Een idee was om ontslae te raak van klassieke lêerbestuur.
Dit is geen geheim dat Steve Jobs die lêerstelsel gehaat het soos ons dit van tafelrekenaars af ken nie, hy het dit kompleks en moeilik gevind vir die gemiddelde gebruiker om te begryp. Lêers wat in 'n hoop subvouers begrawe is, die behoefte aan instandhouding om chaos te vermy, dit alles moes nie die gesonde iPhone-bedryfstelselstelsel vergiftig het nie, en die enigste bestuur wat op die oorspronklike iPhone nodig was, was deur iTunes om multimedialêers te sinchroniseer, of die stelsel het 'n verenigde fotobiblioteek gehad waaruit beelde opgelaai of daarheen gestoor kon word.
'n Reis deur gebruikerspyn
Met die koms van derdeparty-toepassings het dit duidelik geword dat die sandbox-model, wat die sekuriteit van die stelsel en die lêers daarin verseker, waar lêers slegs deur die toepassings waarin dit gestoor word, toegang verkry, onvoldoende is. Ons het dus verskeie opsies ontvang om met lêers te werk. Ons kon hulle van die toepassings na die rekenaar kry via iTunes, die "Maak oop in..."-kieslys het dit moontlik gemaak om die lêer te kopieer na 'n ander toepassing wat sy formaat ondersteun, en Dokumente in iCloud het dit moontlik gemaak om lêers van dieselfde af te sinchroniseer toepassings oor Apple-platforms heen, al is dit op 'n taamlik ondeursigtige manier.
Die oorspronklike idee om 'n komplekse lêerstelsel te vereenvoudig, het uiteindelik teen Apple en bowenal teen gebruikers teruggesak. Werk met lêers tussen veelvuldige toepassings het chaos verteenwoordig, in die middel daarvan was 'n groot aantal kopieë van dieselfde lêer oor toepassings heen sonder die moontlikheid van enige oorsig van die aktualiteit van 'n gegewe dokument of ander lêer. In plaas daarvan het ontwikkelaars na wolkberging en hul SDK's begin wend.
Met die implementering van Dropbox en ander dienste kon gebruikers vanaf enige toepassing toegang tot dieselfde lêers kry, dit redigeer en veranderinge stoor sonder om kopieë te maak. Hierdie oplossing het lêerbestuur baie makliker gemaak, maar dit was ver van ideaal. Die implementering van lêerwinkels het baie werk beteken vir ontwikkelaars wat moes uitvind hoe die toepassing sinkronisering sou hanteer en lêerkorrupsie sou voorkom, en daar was nooit 'n waarborg dat jou toepassing die winkel wat jy gebruik sou ondersteun nie. Om met lêers in die wolk te werk, het nog 'n beperking gehad - die toestel moes te alle tye aanlyn wees en lêers kon nie net plaaslik gestoor word nie.
Sewe jaar sedert die eerste weergawe van iPhone OS, vandag iOS, het Apple uiteindelik met die finale oplossing vorendag gekom, waar dit wegbeweeg van die oorspronklike idee van lêerbestuur gebaseer op die toepassing, en eerder 'n klassieke lêerstruktuur bied, maar slim verwerk. Sê hallo vir iCloud Drive en Document Picker.
iCloud Drive
iCloud Drive is nie Apple se eerste wolkberging nie, sy voorganger is iDisk, wat deel was van MobileMe. Nadat die diens na iCloud verander is, het die filosofie daarvan gedeeltelik verander. In plaas van 'n mededinger vir Dropbox of SkyDrive (nou OneDrive), was iCloud veronderstel om 'n dienspakket te wees veral vir sinchronisasie, nie 'n aparte berging nie. Apple het hierdie filosofie teengestaan tot hierdie jaar, toe dit uiteindelik iCloud Drive bekendgestel het.
iCloud Drive self is nie anders as Dropbox en ander soortgelyke dienste nie. Op die lessenaar (Mac en Windows) verteenwoordig dit 'n spesiale vouer wat voortdurend op datum is en gesinchroniseer is met die wolkweergawe. Soos onthul deur die derde beta van iOS 8, sal iCloud Drive ook sy eie webkoppelvlak hê, waarskynlik op iCloud.com. Dit het egter nie 'n toegewyde kliënt op mobiele toestelle nie, maar word eerder in toepassings binne 'n komponent geïntegreer Dokumentkieser.
Die magie van iCloud Drive is nie net in die sinkronisering van handmatig bygevoegde lêers nie, maar in die insluiting van al die lêers wat die toepassing met iCloud sinkroniseer. Elke toepassing het sy eie vouer in iCloud Drive, gemerk met 'n ikoon vir beter oriëntasie, en individuele lêers daarin. U kan Pages-dokumente in die wolk in die toepaslike vouer vind, dieselfde geld vir derdeparty-toepassings. Net so het Mac-toepassings wat met iCloud sinkroniseer, maar nie 'n eweknie op iOS het nie (Preview, TextEdit) hul eie vouer in iCloud Drive en enige toepassing het toegang daartoe.
Dit is nog nie duidelik of iCloud Drive bykomende kenmerke soos Dropbox sal hê nie, soos die deel van lêerskakels of gedeelde vouers vir veelgebruikers, maar ons sal waarskynlik in die herfs uitvind.
Dokumentkieser
Die Document Picker-komponent is 'n integrale deel van die werk met lêers in iOS 8. Daardeur integreer Apple iCloud Drive in enige toepassing en laat jou toe om lêers buite sy eie sandbox oop te maak.
Die Document Picker werk soortgelyk aan die Image Picker, dit is 'n venster waar die gebruiker individuele lêers kan kies om oop te maak of in te voer. Dit is feitlik 'n baie vereenvoudigde lêerbestuurder met 'n klassieke boomstruktuur. Die wortelgids sal dieselfde wees as die hoof iCloud Drive-lêergids, met die verskil dat daar ook plaaslike vouers met toepassingsdata sal wees.
Die lêers van derdeparty-toepassings hoef nie noodwendig met iCloud Drive gesinchroniseer te word nie, Document Picker kan plaaslik toegang daartoe kry. Databeskikbaarheid is egter nie van toepassing op alle toepassings nie, die ontwikkelaar moet uitdruklik toegang toelaat en die Dokumente-lêergids in die toepassing as publiek merk. As hulle dit doen, sal die toepassing se gebruikerslêers beskikbaar wees vir alle ander toepassings wat Dokumentkieser gebruik sonder dat 'n internetverbinding vir iCloud Drive vereis word.
Gebruikers sal vier basiese aksies hê om met dokumente te werk - oop, skuif, invoer en uitvoer. Die tweede paar aksies neem min of meer die funksie oor van die huidige manier van werk met lêers, wanneer dit kopieë van individuele lêers in die toepassing se eie houer skep. Byvoorbeeld, 'n gebruiker wil dalk 'n prent wysig om sy oorspronklike vorm te behou, dus in plaas daarvan om oop te maak, kies hulle invoer, wat die lêer in die toepassing se gids dupliseer. Uitvoer is dan die min of meer bekende "Open in..." funksie.
Die eerste paar is egter interessanter. Om die lêer oop te maak, doen presies wat jy van so 'n aksie sou verwag. 'n Derdeparty-toepassing sal die lêer vanaf 'n ander plek oopmaak sonder om dit te dupliseer of te skuif en kan voortgaan om daarmee te werk. Alle veranderinge word dan in die oorspronklike lêer gestoor, net soos dit op rekenaarstelsels is. Hier het Apple die werk van ontwikkelaars gered, wat nie bekommerd hoef te wees oor hoe 'n lêer wat in verskeie toepassings of toestelle gelyktydig oopgemaak word, hanteer sal word nie, wat andersins tot die korrupsie daarvan kan lei. Alle koördinasie word deur die stelsel saam met CloudKit versorg, ontwikkelaars hoef slegs die relevante API in die toepassing te implementeer.
'n Skuif lêer-aksie kan dan eenvoudig 'n item van een toepassingslêergids na 'n ander skuif. Dus, as jy een toepassing wil gebruik vir al die bestuur van lêers wat plaaslik op jou toestel gestoor is, sal file mover jou dit laat doen.
Vir elke toepassing spesifiseer die ontwikkelaar met watter tipe lêers dit kan werk. Die Document Picker pas ook hierby aan, en in plaas daarvan om alle lêers in die hele iCloud Drive en plaaslike toepassingsvouers te vertoon, sal dit net daardie tipes wys wat die toepassing kan oopmaak, wat die soektog baie makliker maak. Daarbenewens bied Document Picker lêervoorskoue, lys- en matriksvertoning en 'n soekveld.
Derdeparty-wolkberging
In iOS 8 is iCloud Drive en Document Picker nie eksklusief nie, inteendeel, derdeparty-wolkbergingsverskaffers sal op 'n soortgelyke manier aan die stelsel kan koppel. Dokumentkieser sal 'n skakelknoppie bo-aan die venster hê waar gebruikers kan kies om iCloud Drive of ander beskikbare berging te bekyk.
Derdeparty-integrasie vereis slegs werk van daardie verskaffers, en sal op soortgelyke wyse as ander toepassingsuitbreidings in die stelsel werk. Op 'n manier beteken die integrasie ondersteuning vir 'n spesiale uitbreiding in iOS 8 wat wolkberging by die lys in die dokumentkieser se stoorkieslys voeg. Die enigste voorwaarde is die teenwoordigheid van 'n geïnstalleerde toepassing vir die gegewe diens, wat geïntegreer is in die stelsel of Document Picker deur sy uitbreiding.
Tot nou toe, as die ontwikkelaars sommige van die wolkbergings wou integreer, moes hulle self die berging byvoeg deur die beskikbare API's van die diens, maar die verantwoordelikheid om die lêers korrek te hanteer om nie die lêers te beskadig of data te verloor nie hul koppe. Vir ontwikkelaars kan 'n behoorlike implementering lang weke of maande van ontwikkeling beteken. Met Document Picker gaan hierdie werk nou direk na die wolkbergingverskaffer, en ontwikkelaars hoef net Document Picker te integreer.
Dit geld nie heeltemal as hulle die bewaarplek dieper in die toepassing wil integreer met hul eie gebruikerskoppelvlak, soos byvoorbeeld Markdown-redigeerders doen nie. Vir die meeste ander ontwikkelaars beteken dit egter 'n aansienlike vereenvoudiging van ontwikkeling, en hulle kan feitlik enige wolkberging op een slag integreer sonder enige ekstra werk.
Natuurlik sal die bergingsverskaffers self tot 'n groot mate baat vind, veral die minder gewilde. Dit was vroeër dat bergingondersteuning vir toepassings dikwels beperk was tot Dropbox, of Google Drive, en 'n paar ander. Minder gewilde spelers op die gebied van wolkberging het feitlik nie 'n kans gehad om by die toepassings te integreer nie, aangesien dit 'n buitensporige hoeveelheid ekstra werk vir die ontwikkelaars van hierdie toepassings sou beteken, waarvan die voordele vir die verskaffers moeilik sou wees om te oortuig hulle van.
Danksy iOS 8 kan al die wolkberging wat die gebruiker op sy toestel installeer in die stelsel geïntegreer word, of dit nou groot spelers of minder bekende dienste is. As jou keuse Dropbox, Google Drive, OneDrive, Box of SugarSync is, is daar niks wat jou keer om dit vir lêerbestuur te gebruik nie, solank daardie verskaffers hul toepassings dienooreenkomstig opdateer.
Afsluiting
Met iCloud Drive, Document Picker en die vermoë om derdeparty-berging te integreer, het Apple 'n groot stap vorentoe geneem in die rigting van behoorlike en doeltreffende lêerbestuur, wat een van die grootste swakpunte van die stelsel op iOS was en wat ontwikkelaars moes omseil. . Met iOS 8 sal die platform meer produktiwiteit en werkdoeltreffendheid bied as ooit tevore, en dit het 'n magdom entoesiastiese derdeparty-ontwikkelaars wat bereid is om hierdie poging te ondersteun.
Alhoewel iOS 8 baie vryheid aan die stelsel bring danksy al die bogenoemde, is daar steeds 'n paar merkbare beperkings waarmee ontwikkelaars en gebruikers te doen sal hê. iCloud Drive het byvoorbeeld nie sy eie toepassing as sodanig nie, dit bestaan net binne Document Picker op iOS, wat dit 'n bietjie moeilik maak om lêers apart op iPhone en iPad te bestuur. Op dieselfde manier kan die Dokumentkieser nie byvoorbeeld opgeroep word vanaf die Mail-toepassing en enige lêer wat aan die boodskap geheg is nie.
Vir ontwikkelaars beteken iCloud Drive dat hulle op een slag van Dokumente in iCloud moet oorskakel vir hul toepassings, aangesien die dienste nie met mekaar versoenbaar is nie en gebruikers dus die moontlikheid van sinchronisasie sal verloor. Maar dit alles is slegs 'n klein prys vir die moontlikhede wat Apple aan gebruikers en ontwikkelaars verskaf het. Die voordele van iCloud Drive en Document Picker sal waarskynlik nie onmiddellik na die amptelike vrystelling van iOS 8 verskyn nie, maar dit is 'n groot belofte vir die nabye toekoms. Een waarna ons al jare bel.
As dit moontlik sal wees om 'n vouer te skep en gemengde lêers daarin te hê (Nommers, Bladsye...) Dan sal dit 'n uitkoms wees...
dit moet ook wees...
Dit is een van Apple se grootste foute in die geskiedenis van iOS-ontwikkeling. Dit is 'n volledige verraad van die aanvanklike idee waarvoor die stelsel geskep is. Die lêerstelsel is nie onvervangbaar nie, dit is net dat die implementering daarvan geleidelik moet ontwikkel. As hulle net lêerredigering in 'n ander toepassing by iOS gevoeg het (sodat 'n mens toegang tot die lêers van 'n ander kan kry), kan die sandbox-stelsel maklik aanhou werk. Ongelukkig is dit 'n oormaat wat chaos, rommel en bestuurskwessies sal meebring. Ek is regtig baie jammer. Hiermee het Apple een van sy grootste kenmerke prysgegee – om te innoveer. Veral om sinvol te vernuwe en nie te kyk na die sinnelose klagtes van gebruikers wat nie kreatief kan dink nie.
Ek is glad nie verbaas dat toe hulle iCloud Drive by WWDC bekend gestel het, daar onaangename geboe uit die gehoor was nie. Ek verstaan hulle heeltemal. Die afwesigheid van 'n lêerstelsel was een van die beste kenmerke van iOS en het bygedra tot die eenvoud en gewildheid daarvan. Ten spyte van al die kritici. Dit is hoofsaaklik die afwesigheid van 'n lêerstelsel wat bydra tot die stabiliteit en voorspelbaarheid van die stelsel. En danksy dit het sy sy gewildheid verseker.
sekuriteit was belangriker as lêerstelsel... Ek onthou nog baie goed hoe ek per ongeluk 'n slegte lêer uitgevee het toe ek my eie luitoon by iPhone 1ste gen wou voeg
volgens wat by WWDC aangebied is, moet iOS 8 dit wat jy beskryf aktiveer - sodat een lêer deur verskeie toepassings verkry kan word
Ek sien uit na die integrasie van wolkberging, veral OneDrive, waar daar nou 365x5TB spasie binne Office1 is
1. Ek is nogal bang vir hoe dit gaan lyk bv met so 'n PDF deskundige wat absoluut alles kan oopmaak... Ek wil ook graag hê dat 'n persoon kan beïnvloed wat hulle kan en nie kan oopmaak vir individuele toepassings nie. ..
2. Wat van vanlyn inhoud in die wolk? Byvoorbeeld, met die CUBBY-program wat ek gebruik, het ek lêers om af te laai sodat ek dit dan enige plek kan oopmaak... Sal dit dan via die kieser oopgemaak word? Kan die ontwikkelaars van hierdie program dit op enige manier beïnvloed?