Privind înapoi, Ano 2014 când în tine Conferința mondială pentru dezvoltatori Apple ne-a oferit un nou limbaj de programare menit să înlocuiască Obiectivul C, un limbaj care ar face munca mult mai ușoară pentru dezvoltatori și aplicațiile mult mai fluide și optimizate pentru utilizatori, iar dacă Apple să-și creeze propriul hardware și propriul sistem de operare vi s-ar părea insuficientă, și crearea limbajului său de programare ar oferi atât de extins control asupra produselor sale că ne-ar putea aduce o îmbunătățire foarte substanțială în optimizarea generală și experiența utilizatorului.
Swift a fost introdus ca un limbaj simplu și revoluționar, un limbaj care ar marca viitorul dezvoltării din multe aspecte, iar încetul cu încetul (cum este normal, într-un limbaj nou creat) se adaugă noi posibilități și Apple implementează acest limbaj în aplicațiile sale native, atât pe iOS, cât și pe OS.
Și din acest motiv Swift a fost lansat „Open Source” sau Open Source, asta înseamnă că oricine poate experimenta cu el fără a fi nevoit să plătească pentru drepturi sau ceva de genul acesta, este liber de utilizat, pentru comunitate.
Un destin al expansiunii
Dacă Apple ar lansa Swift exclusiv pentru sistemele sale, dezvoltatorii ar refuza (marea majoritate) să învețe o limbă pentru o singură companie, și de aceea au decis să lase pasărea să elibereze, să-i dea aripi și să zboare, poate de aceea au a ales acel logo...
Important este că, deoarece este open source, orice altă companie îl poate folosi și implementa în sistemul său dacă dorește și tocmai asta Google are în vedere implementarea Swift pe Android.
Cântărind ancora
Google și Java au o istorie lungă în spate, Java a fost întotdeauna inima Androidului, aceste două nume au mers întotdeauna mână în mână, în bine și în rău, și tocmai răul este cel care poate face acum din Java o răspundere pentru Android, deoarece, dacă asta nu ar fi suficient, cu performanța slabă pe care o provoacă Androidului având pentru a virtualiza pentru a rula Java, Oracle (compania care a achiziționat Sun Microsystems, proprietarul inițial al Java) și-a dorit partea sa din plăcintă și a înjunghiat Google cerând o sumă mare de bani (9.300 miliarde USD) pentru utilizarea API-urilor din Java fără permisiunea dvs.
Nail after nail face ca Google să înceapă să caute alternative, alte căi de dezvoltare pentru Android care să permită îmbunătățirea performanței acestui sistem fără a-și încălca filosofia Open Source, și se pare că Google vorbește cu Facebook și UBER despre posibilitatea de a include Swift în sistemul său de operare mobil.
o pasăre liberă
Swift nu este singura limbă pe care Google o ia în considerare, Kotlin este numele unei alte alternative După cum se gândește Google, Kotlin ar fi mult mai ușor de integrat în Android decât Swift din cauza asemănărilor și compatibilităților existente, cu toate acestea, acesta din urmă ar cauza probleme dezvoltatorilor, deoarece este foarte lent la compilare.
Astfel, Google are o decizie „dificilă”., fie se gândește la sine și continuă să integreze Kotlin în Android, fie se gândește la dezvoltatori și sacrificând mult mai mult timp și muncă din partea lor (deoarece pentru a introduce Swift pe Android va fi necesar să se modifice și să refacă multe aspecte ale sistem și chiar bazele proprii) ușurează mult sarcina dezvoltării pentru Android.
Dar avantajele Swift pe Android pot fi mult mai suculente decât par la prima vedere, iar dacă Swift este inclus, Google ar aduce Android și iOS mai aproape Fără a fi nevoit să schimbe filozofia niciunuia dintre ele, Google ar putea dezvolta Swift după propriul său capriciu, fără să depindă de Apple și să includă funcții Android, dar utilizarea Swift ar putea permite dezvoltatorilor să creeze aplicații pentru ambele sisteme cu o bază comună, ceea ce ar reduce numărul de aplicații exclusive pentru un sistem sau altul și ar reduce foarte mult timpul și dificultatea creării a 2 versiuni ale aceleiași aplicații, destinate sistemelor diferite.
Integrarea Swift în Android ar putea pune, de asemenea, Google în pericol o oportunitate pe farfurieși există mulți dezvoltatori care și-ar putea porta aplicațiile de la iOS la Android, optimizându-le corect pentru sistemul menționat și oferind o experiență de utilizator foarte similară, făcând Android și iOS să înceapă să lupte unul împotriva celuilalt numai pentru beneficiile lor ca sistem de operare. , și uitând odată pentru totdeauna de numărul de aplicații disponibile într-una sau alta, ușurința de dezvoltare pentru un sistem sau altul, fluiditatea aplicațiilor din fiecare dintre ele și multe alte probleme pe care le dăunează folosirea Java.Android.
Tranziție lentă
Nimeni nu l-ar învinovăți pe Google că folosește un limbaj creat de Apple, eu personal îl văd mai lăudabil decât blamabil, iar dacă aveți ocazia să oferiți un produs mai bun sau o experiență mai bună utilizatorilor dvs., lucrul condamnabil ar fi să nu profitați de el și, făcând astfel, puteți profita și de rivalul dvs. pentru a vă îmbunătăți propriul produs fără plătindu-le un singur cent.
Acesta este ceva care Apple l-ar putea folosi și el, cu cât Swift este mai folosit și cu cât devine mai popular, cu atât mai mulți oameni vor lucra la el și o calitate mai mare va fi adusă în acest nou limbaj, lucru care poate duce la aplicații mai bune pentru iOS și OS X.
Dar trecerea de la java la swift (daca se va realiza) Nu va fi imediat sau rapid., Google nu intenționează să înlocuiască Java, cel puțin pe termen scurt, dar ar permite folosirea ambelor limbi în sistemul său, oferind mai multe opțiuni dezvoltatorilor, lucru care dacă are succes cu Swift s-ar putea încheia într-o tranziție completă. , dar acest lucru rămâne departe, mai ales că Swift este o limbă atât de recentă și Google are atât de mult de lucru în față...
Tot cu tot Aceasta este o veste foarte bună pentru toată lumea., orice înseamnă mai multe aplicații, o experiență de utilizator mai bună și mai puține probleme, este ceva care vine ca o fabulă pentru utilizatori, și chiar mai bine pentru dezvoltatori, care și-ar vedea munca simplificată, ceva care ar da acces mult mai multor oameni cu idei noi .la acest tip de lucru, mai ales că Swift este un limbaj destinat a fi ușor de utilizat.
Acestea fiind spuse, nu putem decât să așteptăm să vedem ce mișcare face Google, dacă primește sau nu presiune din partea altor părți și cum aceste mișcări îi afectează produsele finale sau Apple, în timp ce așteptăm, Ți-ar plăcea să vezi acest scenariu devenind realitate?
Cu fragmentarea care există în Android, Google nu poate juca asta, gândindu-mă la asta înainte, domnule Google
Asta mi se pare perfect. Android ar trebui să scape de mașina virtuală Java și să lucreze direct pe hardware real dacă dorim ca sistemul de operare și aplicațiile să profite cu adevărat de puterea telefoanelor și tabletelor de astăzi. Iar Google nu ar trebui să ofere doar o singură limbă, ci mai mult de un limbaj de programare, așa cum este cazul computerelor, care există pentru toate gusturile și nevoile.
Și, desigur, ar trebui să fie posibilă programarea pentru Android PE Android. Ce e să ai o tabletă decacore, cu 4GB de RAM și spațiu de stocare pentru un tub... și să mergi la un PC vulgar pentru a programa ceva? Trebuie să realizați aceste două lucruri și trebuie să le realizați acum sau pe lângă fragmentare, Android va fi un sistem stagnant.
Într-adevăr, autorul articolului ar fi trebuit să se documenteze mai bine cu privire la multe lucruri. Sunt lucruri care nu au nici măcar relația minimă. Problemele de performanță care existau în Android s-au datorat lipsei hardware-ului la acea vreme și, la rândul său, faptului că sistemul de operare permitea ceea ce IOS-ul nu permitea. În prezent IOS a introdus multitasking real, iar Voila!! Vedem dispozitive Apple cu. Mașinile virtuale sunt de fapt o tehnică pentru a obține o execuție chiar superioară celei a limbajelor compilate, performanța nu are legătură. Mașinile virtuale, cum ar fi .Net (de la Microsoft, unde rulează jocurile Xbox) au performanțe și mai mici decât mașina virtuală Java. Mașinile virtuale de astăzi au un compilator de rulare, numit JIT. Ei compilează bytecode în binar prima dată când este executat, dar înainte de respectiva compilare, bytecode este un cod de programator optimizat și, la rândul său, este optimizat din nou atunci când este compilat de JIT. Ar trebui să documentați mai bine data viitoare.
Altceva, Google dorește cu siguranță să evite problemele legale, care nu are nicio legătură cu adoptarea lui Kotlin, deoarece Kotlin este încă construit în Java. Îl folosesc de ceva vreme (de când era beta), este Java pe steroizi, ai putea spune că este versiunea de Swift care rulează în Java, sunt foarte asemănătoare ca sintaxă, timpul de compilare este excelent, nu la fel de rapid ca Java, dar nu este un motiv relevant așa cum am menționat. Un alt detaliu este că Kotlin este deja folosit destul de puțin în lumea Android, nu este nimic nou în ceea ce privește utilizarea lui. Ceea ce ar trebui să facă Google este să ofere cadre cu modele arhitecturale mai bune și să facă lucrurile mai confortabile, cum ar fi adnotările Android sau cuțitul de unt.