Google geeft preview-versie van Android Studio 2.0 vrij

Google heeft een vroege versie vrijgegeven van Android Studio 2.0, een ide voor het maken van Android-applicaties. In de nieuwe versie kunnen ontwikkelaars sneller veranderingen bekijken die zij hebben aangebracht in hun apps.

Details over de nieuwigheden van Android Studio 2.0 staan op het blog van Google. De belangrijkste nieuwe functionaliteit is Instant Run, waarmee veranderingen in de code sneller visueel bekeken kunnen worden: de bedoeling is dat wijzigingen na een snelle verversing van de pagina al zijn te zien, al kan dit bij gebruik op mobiele apparaten iets langer duren. De functionaliteit moet het ontwikkelen van Android-applicaties sneller maken. Nieuwe projecten hebben automatisch ondersteuning voor Instant Run als Android Studio 2.0 voor de ontwikkeling wordt gebruikt, terwijl het bij bestaande projecten nog moet worden aangezet.

In een interview met TechCrunch geeft Stephanie Cuthbertson, bij Google als productmanager verantwoordelijk voor de ontwikkeltool, aan dat in Android Studio 2.0 het compileren van applicaties ongeveer 2 tot 2,5 keer sneller moet gaan. Verder zijn de ingebouwde emulators sneller gemaakt en is daar meer mee mogelijk, zoals het emuleren van netwerkverbindingen en gps-gestuurde routes. Ook is er een gpu-profiler ingebouwd. Laatstgenoemde functionaliteit is overigens nog in ontwikkeling.

Geïnteresseerden kunnen via het Canary-kanaal een vroege versie van Android Studio 2.0 binnenhalen. In de komende tijd worden er nog nieuwe features toegevoegd aan de software, maar wanneer de final versie uit moet komen is nog niet duidelijk. Google bracht de eerste versie van Android Studio eind vorig jaar uit, met als doel om de ontwikkeling van apps voor het mobiele besturingssysteem gemakkelijker te maken.

Reacties (60)

[SomerenV]

Is er niet een ontwikkeltool die voor iOS, Android én Windows (Phone) (10 Mobile) apps eruit kan persen? Een beetje zoals Unity dat doet zeg maar, één programma om games mee te maken maar die kun je dan compilen voor zo'n beetje elk denkbaar OS.

[MATANDO]

In het kort: nee.

Iets langer: Er zijn enkele platformen die dit beweren te kunnen, maar geen van deze komen in de buurt van Native apps. Ik heb zelf ervaring met Xamarin, Appcelerator en native apps.

Xamarin komt op papier aardig in de buurt, maar helaas is de ervaring in de praktijk anders. Alleen met Xamarin Forms is cross-platform development mogelijk en daarmee kan je enkel simpele grafische interfaces bouwen (zeggen ze zelf ook, zie de vergelijking van project types: https://xamarin.com/forms). Dat klopt, voor hele simpele interfaces moet je al naar de platform specifieke projecten terugvallen. Maar zelfs als je de plaftorm speciefieke Xamarin Android of Xamarin iOS gebruikt dan is het nog steeds zeer moeizaam ontwikkelen omdat het Mono project hopeloos achterloopt op Android en iOS. Simpele zaken ontbreken, zoals bijvoorbeeld een fatsoenlijke http client die zowel met TLS1.2 en cookies overweg kan..... Ook de componenten die je kan gebruiken zijn in de regel oud en worden niet of amper onderhouden.

Over Titanium Appcelerator kan ik korter zijn, dat wil ik niemand aanraden....

Het zou geweldig zijn als je in één platform zou kunnen ontwikkelen voor Android en iOS, maar totdat Apple en Google gaan samenwerken op dit vlak blijft het een droom.

Dus trap er niet in en ontwikkel native!

[killingdjef]

Werp eens een blik op RoboVM ( https://robovm.com/ )

RoboVM is multi-platform vanaf de "andere kant", namelijk vanaf de Java zijde. Het voordeel is dat alle libraries van Android (maar belangrijker, Java) gewoon te gebruiken zijn.

Voor UI hebben ze ook support voor native iOS schermen maar je kan ook door middel van JavaFX een UI ontwikkelen die op beide platforms draait.

RoboVM wordt ook gebruikt om cross-platform games te ontwikkelen met LibGDX, de enige echte tegenhanger van Unity, mijn inziens.

[MATANDO]

Klinkt zeker interessant. Maar hoe werkt het in de praktijk?
Xamarin ziet er op papier een stuk interessanter uit dan hoe het platform werkt in de praktijk, hetzelfde zou kunnen gelden voor RoboVM....

Heb je zelf ervaring met RoboVM in combinatie met een shared codebase voor iOS en Android? Kan je echt de meest recente Android libraries gerbuiken zonder port? En hoe zit het met iOS? Daar zal in ieder geval iets tussen moeten zitten neem ik aan?

Gezien de ontwikkeling gemeld door @wimpers2, zou ik overigens even wachten met gebruik totdat duidelijk is wat Xamarin ermee gaat doen..... Zonde als ze er de stekker uit trekken of het project op een andere manier de nek omdraaien.

[killingdjef]

Ik ontwikkel alleen in Java dus Xamarin valt voor mij sowieso af.

Ik werk met LibGDX dus heb nog geen ervaring met ontwikkeling van een shared Android/iOS UI. Ik weet wel dat ik mijn LibGDX game volledig werkend heb op iOS en dat ik voor diezelfde game een embedded java database (H2) werkend heb gekregen.

Sowieso kun je de meeste java libraries gewoon binnen Android gebruiken zolang ze stand-alone zijn en niet afhankelijk zijn van bijv. Swing o.i.d. Ik moet zeggen dat ik die hele "conversion" echt erg prachtig gemaakt vind en qua performance is het evensnel als native een game ontwikkelen. Zie anders deze vergelijking: https://www.youtube.com/watch?v=C3-p-Txnr4Q

Wat betreft de ontwikkelingen van RoboVM. De prijs van de licenties zijn naar mijn inzien best betaalbaar (beter dan Unity) en voor LibGDX gebruikers wordt er vrijstelling geleverd als je aan kunt tonen dat je een libgdx game maakt.

[wvc_]

Xamarin heeft RoboVM onlangs overgenomen trouwens.
Info: https://xamarin.com/pr/xamarin-acquires-robovm

[Mittchel]

Blijkbaar heb jij niet genoeg ervaring met Xamarin...

Er zijn genoeg componenten voor Xamarin die het codesharen echt wel versimpelen. ModernHttpClient kan bijvoorbeeld TLS supporten.

Xamarin.Forms is inderdaad voor wat basale UI's erg effectief, maar ook met complexere UI's kun je ver komen.

'omdat het Mono project hopeloos achterloopt op Android en iOS'.. Dit stukje gaat helemaal nergens over, want Xamarin support praktisch alle API's beschikbaar voor iOS en Android. Daarnaast beloven zij bij de release van een nieuwe iOS om binnen 1 dag ook de API's beschikbaar te hebben in Xamarin.

Als je het goed doet, dan kun je met Xamarin.iOS en Xamarin.Android echt veel code sharen. Helemaal in vergelijking met native

[rdridder]

Mono loopt wel degelijk achter want de out of the box http client support geen tls 1.2. Je kunt inderdaad modernhttpclient gebruiken maar dat is een lib die niet door Xamarin zelf is gemaakt. Geen tls 1.2 out of the box is gewoon slecht.

Jij doet het voorkomen alsof modernhttpclient zo geweldig is maar ik heb bij zowel iOS als bij Android de cookiehandling moeten repareren. Als de server meerdere set-cookie headers stuurt werd alleen de laatste cookie header opgeslagen in de headers in de response. Voor deze bug heb ik voor beide platformen de code moeten repareren.

Die first day api support is hartstikke leuk maar dat heb je native ook.

Misschien doe jij wel totaal andere projecten dan ik maar ik kon eigenlijk alleen de data- en servicelaag delen. Door die brakke http clients heeft dat echter veel meer tijd gekost dan het heeft bespaard.

[rdridder]

Ik heb ook redelijk wat ervaring met native development. Ik heb laatst een Xamarin project gedaan en aan het begin was ik er redelijk over te spreken. Naarmate het project meer vorm kreeg werd Xamarin steeds meer een probleem. De problemen die Matando noemt omtrent TLS 1.2 bijvoorbeeld. Mono ondersteunt geen TLS 1.2. Je kunt hier omheen door een library te gebruiken, modern http client. Dit is een wrapper rond de native clients in Android en iOS. Het probleem met deze library is dat de cookie handling niet goed is. Als een server meerdere Set-cookie headers stuurt wordt alleen de laatste doorgegeven,.

Debuggen kan ook heel gecompliceerd zijn. Simpele dingen als een nullpointer kunnen heel moeilijk te fixen zijn omdat de stacktraces verwijzen naar gegenereerde code. De enige manier om dan de fout te vinden is door een groot try catch statement om codeblokken heen te zetten. Als je dan een breakpoint in de catch zet kun je uiteindelijk zien waar de fout zit. Ik snap best dat een nullpointer een programmeerfout is maar in een project waar meerdere programmeurs samen werken worden dit soort fouten gemaakt.

Tenslotte viel het delen van code erg tegen. Het begon met forms en uiteindelijk werden het twee bijna native apps met een gedeelde data-laag. Met alle problemen in die data-laag zoals de bovenstaande issues met TLS 1.2 en cookies heeft dit eigenlijk geen tijd bespaard.

Tenslotte lopen de libraries die er zijn achter. Ook zijn het vaak halve ports waar niet alle functionaliteit in zit. Voor native platforms zijn veel meer goede libraries aanwezig die hun sporen al hebben verdiend.

[fslembro]

xamarin ?
https://xamarin.com/

[SomerenV]

Geen idee, ik heb er de ballen verstand van Maar ik zie regelmatig dingetjes voorbij komen over Xcode (of hoe het ook heet) Visual Studio en nu dan dit. Maar waarom zou je als een ontwikkelaar een tool gebruiken dat zich richt op één OS in plaats van een tool die zich kan richten op álle OS'en?

[cornedor]

Ik heb zelf niet echt ervaring met Xamarin, wel veel van gehoord, maar vaak is het zo dat als apps in een keer voor meerdere OS'en wordt gemaakt dat het resultaat minder goed aanvoelt. En omdat er nogal veel verschil zit tussen het ontwikkelen van iOS, Android en Windows Phone apps zijn hier ook verschillende editor's voor gemaakt.

edit: typo

[Reactie gewijzigd door cornedor op 24 juli 2024 05:31]

[Richh]

De ervaring die ik er mee heb komt uit een soort hackaton-achtige situatie met vier app-teams, waar eentje met Xamarin werkte. Dat was redelijk buggy en crashede regelmatig. Kan aan de devs liggen, maar volgens mij lag het aan Xamarin.

Daarblij blijft het ruk: het is nooit 100% up-to-date met de nieuwste designstandaarden en uiteindelijk zit je alsnog drie verschillende lay-outs te schrijven.

Wil je multiplatform, dan ben je al snel toegewezen op een webapp, zoals Cordova/Ionic. Daarmee is tegenwoordig zelfs bijzonder veel mogelijk en het werkt behoorlijk goed, al blijf je natuurlijk nadelen houden bij webapplicaties.

Voor echt grote applicaties die dicht blij de designstandaarden van je smartphone moeten blijven, ben je gewoon toegewezen op drie native apps.

[xFeverr]

Webapps? Doe maar niet... Zie ook het recente fiasco van de Rabobank. Ik ben van mening: wil je een webapp, maak dan een webapp, en niet een een "hybride" app met een webview er in. Er zijn nog een aantal voorbeelden (facebook...) die aangeven dat het gewoon niet werkt. Wil je toch native functionaliteit, maak dan gewoon een fatsoenlijke native app en geen halve zeer slecht uitgevoerde 'dirty' oplossingen.

[NLkaiser]

Omdat iOS apps in objectieve-c of swift worden gemaakt, Android apps in Java en Windows phone apps in .net
Andere talen betekent vaak een andere editor. Windows phone is trouwens wel bezig met de mogelijkheid om objectieve-c en Java code te importeren naar iets waar Windows ook mee overweg kan

[GekkePrutser]

De taal is niet eens zo'n probleem. Je kan gewoon cross compilen.

Het grotere probleem is de API's die radicaal anders zijn. Bijvoorbeeld bij iOS moet je zelf een tabel handler maken die de data cellen 'tekent' net voordat ze verschijnen, de API interesseert zich er niet voor hoe je de data opslaat. Terwijl je op Android een soort ingebouwde sqlite hebt.

Je kan hier wel een overkoepelende API overheen maken maar dan krijg je nooit de maximale flexibiliteit op elk platform, en ook zal het niet zo 'native' aanvoelen.

[Gimmeabrake]

Xamarin is volgens mij de enige partij die zoiets aanbiedt: je schrijft je backend in .net en je frontends met mono for android/monotouch/"normaal" .net. Probleem is dat ze bij Android en iOS altijd achter de feiten aanlopen omdat ze alles wat Google/Apple uitbrengen met veel moeite moeten vertalen en daardoor pas later releasen in hun eigen libraries.

Het grootste probleem van het maken van een all-in-one tool is dat, als je een native user experience wilt aanbieden voor alle ondersteunde platforms, je er niet omheen kunt om voor elk platform een eigen versie te maken van de frontend. Het enige wat die frontend-applicaties kunnen delen is dus de backend code, de code die bijv. opslag van gegevens regelt en berekeningen doet. De verschillende OSen/platforms hebben dusdanig andere componenten(lijsten, knoppen, etc.) en gebruiken(regeltjes die voorschrijven hoe en wanneer je de componenten wel of niet in moet/mag inzetten) dat het niet echt mogelijk is om een algemeen ontwikkelplatform te maken.

[Reactie gewijzigd door Gimmeabrake op 24 juli 2024 05:31]

[Carbon]

Xamarin is geen crossplatform (write once, run anywhere) oplossing.

[Verwijderd]

Als je C# prefereert kun je Xamarin gebruiken. Je hebt dan support voor iOS Windows Phone en Android.

Als je c++ wilt, kun je Visual C++ gebruiken.

Als je html, css en javascript kun je Ionic gebruiken. Under the hood gebruikt het Apache Cordova met daarbovenop Angular JS. Je hebt support voor iOS en Android. Windows en Firefox OS zijn ze mee bezig.
Je kunt ook Apache Cordova los gebruiken en daarbovenop alles zelf bakken.

Ionic is gratis en open source net als Apache Cordova en Angular JS. Xamarin is commercieel en vereist een licentie.

Voor desktop kun je Electron Shell gebruiken. Dit is ook open source en word door Github ontwikkeld. Je kunt dus jezelfde code van Cordova gebruiken, mits je geen Cordova modules gebruikt. Anders zal je deze moeten fixen. Voor de UI kun je Photon gebruiken.

Ik heb met allen geen ervaring, maar wel goede en slechte dingen gelezen. Geen van allen heb ik echt slechte dingen over gelezen. Wel weet ik dat Angular JS al wat langer mee gaat, net als Apache Cordava. Ionic zou dus een degelijke basis moeten hebben.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 05:31]

[418O2]

Ionic werkt prima met Windows kan ik je vertellen. Mijn eerste app met Windows (8.1), ios en Android support gaat binnenkort in productie (bedrijfsapplicatie)

[Highlandd]

Ja die is er, http://www.appcelerator.com/product/ al moet ik eerlijk zeggen dat het voor grote zware apps niet heel erg goed werkt, je moet namelijk wel inleveren op performance.

Je programmeert in Javascript en de tool compiled naar alle andere talen.

Zo ook https://xamarin.com die hetzelfde (al geen ervaring mee) kan via C#

Naast dat heb je ook nog http://phonegap.com/ wat een webview maakt afaik, maar wel een wrapper voor andere platformen.

[Reactie gewijzigd door Highlandd op 24 juli 2024 05:31]

[SuperDre]

De laatste versie van visual studio zou het ondersteunen..

[Johan9711]

Cordova?
https://cordova.apache.org/

[pibara]

Een IDE? Nee. Maar in de buurt komen van een code-base is wel te doen, en in mijn beleving via een best wel vreemde weg. Mijn advies:

1) Schrijf je core-logic en basis GUI eerst voor de Chrome browser met JavaScript en (NaCl) C++.
2) Port je GUI naar Cordova & jqtouch
3) Clean-up je C++ zodat het portable genoeg is om in Android, IoS, WP en BB te kunnen draaien.
4) Schrijf lijm-code om op elk van de platforms je code als Cordova-plugin te kunnen gebruiken.
5) Voeg de mobile-caps toe aan je app.

Resultaat: alleen de lijm-code is platform specifiek, de rest is portable C++ en JavaScript, en met een beetje massel heb je nog een semi-bruikbare Chrome App kado ook ;-)

Jammer wel dat Google zelf de techniek voor ons aan elkaar plakt en met een NaCl enabled Cordova achtig framework komt. Ze hebben feitelijk alles in huis om van bovenstaande setup een naadloze cross-platform omgeving te maken die dus niet als duct-tape oplossing voelt.

[hanszorn]

Niet verder vertellen: Delphi (http://www.embarcadero.com/products/delphi) kan dit. Wel voor €€.

[Toettoetdaan]

Ik ben zelf fan van: https://www.madewithmarmalade.com/

[WoutervOorschot]

iOS development kan in visual studio, android development ook(de ms android emulator is beter dan die van google, ook de nieuwe) maar wel alleen in c++ en niet in java.

[svenolio]

Zoals de meeste al zeiden, kort gezegd nee. Maar er zijn een hoop alternatieve mogelijkheden die in de buurt komen.

Als toevoeging aan de genoemde mogelijkheden is het ook mogelijk apps te maken met HTML, CSS & JS en deze vervolgens met Cordova (of een Cordova based platform zoals Phonegap) te exporteren/builden als app voor iOS, Android of Windows(phone). Dit levert natuurlijk geen optimale native app op, maar met verschillende libraries is er een hoop mogelijk met HTML, CSS & JS waaronder gewoon toegang tot camera en sensoren van het mobieltje.

Oeps, bij het iets verder lezen van de posts zie ik dat deze mogelijkheid en zelfs Ionic ookal genoemd is, dus sorry voor het dubbel posten!

[Reactie gewijzigd door svenolio op 24 juli 2024 05:31]

[Vexxon]

Xamarin voor visual studio

[fritek373]

Phonegab, gebasseerd op Cordova. Werkt goed bij wat simpelere apps.

[Reactie gewijzigd door fritek373 op 24 juli 2024 05:31]

[morrowyn]

Je kan ook gewoon swift en java leren. Zo moeilijk is het allemaal niet. Coden is coden. Gewoon even wat tijd investeren om het hamertje te leren gebruiken.

I.p.v. 1 hamer te willen gebruiken voor al je problemen/spijkers.

[Reactie gewijzigd door morrowyn op 24 juli 2024 05:31]

[GunterO]

http://www.embarcadero.com/products/rad-studio/firemonkey

[HitDyl]

Ionic draait zo goed als native op iOS. Helaas nog niet "native like" op android ivm de single core performance op android. Maar ze zijn in versie 2 bezig meer te focussen op optimalisaties voor Android. Maar het is in ieder geval een geweldige ontwikkeling.

[Fladder80]

Als ze nou ook hun virtuele machines een performance boost gegeven hebben zou dat geweldig zijn.

[SBTweaker]

Quote

Verder zijn de ingebouwde emulators sneller gemaakt en is daar meer mee mogelijk, zoals het emuleren van netwerkverbindingen en gps-gestuurde routes. Ook is er een gpu-profiler ingebouwd. Laatstgenoemde functionaliteit is overigens nog in ontwikkeling.

[Carbon]

Gelukkig hebben we Genymotion nog

[Zezura]

ik houd niet zo van dat Eclipse (java) based programma's & IDE's die voelen naar mijn weten niet lekker native aan.
en hebben vergeleken met Xcode en Visual studio een dikke achterstand van vormgeving en functies.
ook dat van netbeans (of hoe dat ook heet).

[Niekfct]

Android Studio is niet gebaseerd op Eclipse, maar op IntelliJ van Jetbrains. Dat is een redelijk verschil.
Ik ben benieuwd welke achterstand je precies bedoelt?

[Zezura]

Lijkt allemaal op elkaar en dat jetbrains lijkt veel op eclipse het heeft te maken dat het allemaal Java based is volgensmij. Als je er mee werkt dan voel je het verschil.. Geloof me ik heb ze allemaal een goede kans gegeven.. Alleen ik heb nu naar mijn mening betere tools en IDE's gevonden, Visual studio en Xcode voor de power en voor de operaties waar het minder zwaar kan Text editors zoals sublime, atom & brackets.. Met addons. Dat is voor mij de perfectie combinaties..

En het mooie van alles is dat al die tools SNEL en fijn werken.
Met fijne interfaces. En goede ondersteuning zonder veel rotzooi er om heen.

[Reactie gewijzigd door Zezura op 24 juli 2024 05:31]

[renalpha]

Klopt phpstorm en Android studio zijn Java based en zuigen het geheugen van je PC helemaal op. Visual studio en xcode draaien inderdaad veel fijner. Echter ben ik geen C schrijver.

[Zezura]

Je kan in visual studio meerdere talen schrijven, tegenwoordig ook JavaScript Windows programma's

Maar C based is idd wel het belangrijkst in VS.
Ik schrijf het liefst C based. Ik schrijf momenteel ook veel JavaScript, HTML5 games.

[Verwijderd]

Ikzelf ben ook actief Eclipse hater. Voor de komst van Eclipse had ieder taal/platform zijn eigen smaakje IDE, geoptimaliseerd voor het doel, en meestal "native" (geschreven in C). In de jaren 2000 hebben vele vendors het Eclipse "walhalla" omarmd en nu plukken we daar de zure vruchten van. Traag, zwaar, lelijk, een wirwar aan versies en plugins, veels te algemeen opgezet.

Ik denk ook dat dit de oorzaak is dat code editors inmiddels zo populair zijn (Sublime, Atom), als soort van tegengas, dat we lichte en simpele tools willen.

Terug on topic: wanneer we even een stap terug zetten, is het eigenlijk bizar dat we nu weer in een multi platform wereld zitten. Het web had dit probleem grotendeels opgelost: software losgekoppeld van hardware, slechts een browser nodig. We gaan in feite terug in de tijd met al die app store tuintjes.

Ik weet het: web technologie is niet zo goed als native technologie. Maar dat is een keuze en geen voldongen feit. Al de zaken die native apps kunnen hadden ook op het web gekunnen indien de vendors actief het web beter hadden gemaakt. Maar dat is uiteraard niet in hun belang. Men wil juist wel de keiharde lock-in tussen hardware en software.

[Verwijderd]

Ik kan er als xcode 7 gebruiker totaal niet mee overweg. Ik ben in Android studio zo vaak de weg kwijt dat ik het opgegeven heb. Het is bij lange na niet zo gebruiksvriendelijk of overzichtelijk als xcode

[Brummetje]

Ik heb het juist exact andersom... Ik denk dat het puur gewenning is.. Ik ben van Eclipse met Android naar Xcode gegaan (omdat ik ook voor iOS moest ontwikkelen) maar ik vond Xcode echt een ramp (en nog steeds). Nu dat Android Studio er is vind ik dat echt zo prettig werken.

Zelfs nu na 2 a 3 jaar met Xcode vind ik het nog steeds een complete ramp. Dus nogmaals ik denk het gewenning is welke IDE je gewent bent.

[Carbon]

Nu dat Android Studio er is vind ik dat echt zo prettig werken.

Kan ik me bijna niet voorstellen!
Het enige pluspunt aan Android Studio is de editor, voor de rest is het uiterst primitief (tekstuele configuratie) en vergeleken met Eclipse een enorme stap terug.

[Reactie gewijzigd door Carbon op 24 juli 2024 05:31]

[Verwijderd]

Nee ik kan gewoon niet met Android studio werken. Xcode heb ik daarentegen geen moeite mee.

[Brummetje]

Een appel is niet lekker een peer daar in tegen is prima te eten.. Lekkere onderbouwing ook zeg

[Dual Infinity]

Het is bij lange na niet zo gebruiksvriendelijk of overzichtelijk als xcode

Hier moest ik wel even om lachen.

Zelfs de grootste Apple-fanboys die daadwerkelijk kunnen programmeren vinden XCode slecht. De rating van XCode in de app store is niet voor niets 2/5.

[Carbon]

Zelfs de grootste Apple-fanboys die daadwerkelijk kunnen programmeren vinden XCode slecht.

Die lage rating komt voornamlijk door de installatie problemen, welke veroorzaakt werden door een AppStore issue.
De huidige versie van XCode is een prima IDE.

[Dual Infinity]

De huidige versie van XCode is een prima IDE

Nope.
- Version control support in XCode is abominabel
- Variable inspection tijdens het debuggen is bijna non-existent
- Maximaal twee editor panes open; geen tabbed editors
- In het algemeen uiterst rigide en non-customizable interface
- Geen overwrite autocomplete (en generally shitty and stupid autocompletion)

I could go on, maar bottom-line: XCode zit echt nog lang niet op het niveau van VS of Eclipse.

[Carbon]

- Version control support in XCode is abominabel
Overdrijven is ook een kunst, de meest voorkomende handlingen als pushen,pullen, committen, branchen, mergen en conflict resolution (Git) werken prima vanuit XCode. Voor de wat ingewikkelder dingen gebruik ik liever de commandline of SourceTree.

- Variable inspection tijdens het debuggen is bijna non-existent
Dat herken ik niet geef eens een praktijk voorbeeld!

- Maximaal twee editor panes open;
View->Assistant Editor -> Show Assistant Editor
Met de "plus" in het venster kun je de editorpanes verder splitten.

- geen tabbed editors
File->New->Tab

- In het algemeen uiterst rigide en non-customizable interface
Het belangrijkste, font en editor kleuren zijn gewoon aan te passen.

- Geen overwrite autocompleteautocompletion)
Overwrite autocomplete zit er gewoon in! Of bedoel je misschien wat anders?

- (en generally shitty and stupid
In de allereerste XCode versies (jaren geleden) was autocomplete een lachertje maar nu werkt het zoals je dat mag verwachten van een modern autocomplete systeem.

Is het perfect? Natuurlijk niet maar met FuzzyAutocompletePlugin komt je aardig in de buurt.

[Reactie gewijzigd door Carbon op 24 juli 2024 05:31]

[Dual Infinity]

de meest voorkomende handlingen als pushen,pullen, committen, branchen, mergen en conflict resolution (Git) werken prima vanuit XCode

Je noemt grofweg de enige dingen die kunnen. Fatsoenlijk de history van je hele project inspecten kun je mooi vergeten (per file is het dan weer wel aardig). De Git-capabilities van XCode zijn speelgoed vergeleken met die van EGit.

[variable inspection] herken ik niet geef eens een praktijk voorbeeld!

CoreData objecten inspecten. Of eigenlijk alles wat een beetje OOP-based is inspecten.

View->Assistant Editor -> Show Assistant Editor
Met de "plus" in het venster kun je de editorpanes verder splitten.

Dit zal ik straks eens proberen. Ondanks dat ik al een jaar met XCode werk is dat me niet opgevallen. Vooralsnog ben ik nog regelmatig files die ik had geopend kwijt, door de behaviour dat een keer klikken op een file in de navigtion == open in editor.

- geen tabbed editors
File->New->Tab

Ook dit moet ik zo even proberen. Ik weet niet hoe het in de nieuwste versie van XCode werkt, maar eerder was dit in ieder geval superkarig geïmplementeerd:
http://stackoverflow.com/...-work-normally-on-xcode-4

- In het algemeen uiterst rigide en non-customizable interface
Het belangrijkste, font en editor kleuren zijn gewoon aan te passen.

Jij vindt dat 'het belangrijkste'. Ik vind het verschrikkelijk te kort schieten. Wat je noemt kan in pretty much elke text-editor. Dat is niet hetzelfde als een IDE.

Overwrite autocomplete zit er gewoon in! Of bedoel je misschien wat anders?

Overwrite autocomplete vervangt de overige letters als je bijvoorbeeld midden in een variabelenaam gaat editen en iets wil autocompleten, zodat je die niet telkens zelf weg hoeft te halen. Dat ben ik nog niet tegen gekomen (en ik heb gezocht, omdat het strontirritant is zonder!)

In de allereerste XCode versies (jaren geleden) was autocomplete een lachertje maar nu werkt het zoals je dat mag verwachten van een modern autocomplete systeem.

Onzin, de autocomplete is bij het completen van methodes niet slim genoeg om priority te geven aan de methoden van de directe subclass waar je iets aan vraagt. NSObject-methodes zouden onderaan de lijst moeten staan bij autocompletion.

Is het perfect? Natuurlijk niet maar met FuzzyAutocompletePlugin komt je aardig in de buurt.

Dat is een kruk. Ik ben helemaal voor het concept van plugins, maar iets als autocompletion moet in een IDE out of the box toch echt gewoon goed werken.

Laat ik mijn originele kritiek relatief maken: van de 6 proper IDEs waar ik ooit mee gewerkt heb is XCode verreweg de slechtste.

[Carbon]

Je noemt grofweg de enige dingen die kunnen. Fatsoenlijk de history van je hele project inspecten kun je mooi vergeten (per file is het dan weer wel aardig). De Git-capabilities van XCode zijn speelgoed vergeleken met die van EGit.

XCode heeft in tegenstelling tot Eclipse build-in Git support.
En dat voldoet prima voor de meest gebruikte git handelingen.

Vervolgens ga je dat vergelijken met EGit, functionaliteit welke je separaat moet toevoegen.

Als je toch wilt vergelijken dan moet je EGit/Eclipse vergelijken met SourceTree/Xcode

CoreData objecten inspecten.

Mee eens, het faulting mechanisme compliceert het inspecten van een CoreData objecten.
Beetje de aard van het beestje.

Of eigenlijk alles wat een beetje OOP-based is inspecten.

Zoals?

Jij vindt dat 'het belangrijkste'. Ik vind het verschrikkelijk te kort schieten. Wat je noemt kan in pretty much elke text-editor. Dat is niet hetzelfde als een IDE.

En ik heb een gruwelijke hekel aan MDI applicaties waarbij je de hele UI kunt verbouwen.
We verschillen dus van mening, so be it.

Overwrite autocomplete vervangt de overige letters als je bijvoorbeeld midden in een variabelenaam gaat editen en iets wil autocompleten, zodat je die niet telkens zelf weg hoeft te halen. Dat ben ik nog niet tegen gekomen (en ik heb gezocht, omdat het strontirritant is zonder!)

ipv één click in de naam dubbel clicken op de naam en dan typen?

Onzin, de autocomplete is bij het completen van methodes niet slim genoeg om priority te geven aan de methoden van de directe subclass waar je iets aan vraagt. NSObject-methodes zouden onderaan de lijst moeten staan bij autocompletion.

Ik weet niet meer waarom maar wel dat het een bewuste keuze is voor Objective-C code.

Bij C++ code werkt het zoals jij beschrijft.

Laat ik mijn originele kritiek relatief maken: van de 6 proper IDEs waar ik ooit mee gewerkt heb is XCode verreweg de slechtste.

Ook daar verschillen we van mening

Mijn ranglijst uitgaande van de meest recente (niet beta) versies:

1. Xcode / VisualStudio
2. Eclipse
3. QtCreator
4. Xamarin Studio
5. Android Studio

[Dual Infinity]

Vervolgens ga je dat vergelijken met EGit, functionaliteit welke je separaat moet toevoegen.

EGit is een officiëel Eclipse Foundation-project en standaard gebundeld bij Eclipse: http://www.eclipse.org/egit/

Mee eens, het faulting mechanisme compliceert het inspecten van een CoreData objecten.

Ook als het geen fault betreft kun je er nauwelijks achter komen wat de contents zijn. 'Print description' helpt soms een beetje, maar is een kruk.

[...]
Zoals?

Tja, soms klik je een object 'open' en dan verandert alleen het pijltje (NSIndexPath, bijvoorbeeld), soms staat er wel een type maar geen waarde en zo zijn er nog meer van dat soort dingetjes die inspecten van de object graphs pijnlijk maken. Print description helpt dus soms, maar blijft een (onhandige) kruk.

En ik heb een gruwelijke hekel aan MDI applicaties waarbij je de hele UI kunt verbouwen.

Wel kunnen maar niet willen is objectief gezien beter dan wel willen maar niet kunnen, tenzij je een end-user bent die niet met keuzes om kan gaan.

ipv één click in de naam dubbel clicken op de naam en dan typen?

:`)
Een beetje programmeur blijft van z'n muis af, tenzij het strikt genomen noodzakelijk is. (De mogelijkheid tot) Overwrite autocomplete is 100x handiger dat hetgeen jij voorstelt, zeker als je het over een methode met meerdere parameters hebt.

Ik weet niet meer waarom maar wel dat het een bewuste keuze is voor Objective-C code.

Dit is objectief gezien een waardeloos tegenargument.

Maar er zijn nog zo veel dingen meer die XCode ruk maken.
Wat te denken van het ontbreken van een dedicated code outline view voor de huidige file? CMD+6 is niet hetzelfde, noch is de Symbol view er via via voor gebruiken een serieuze optie.

Of het absoluut omslachtige hernoemen van een variabele met meer animaties dan functionaliteit?

Nee, ik ben blij voor je dat je XCode fijn vindt, maar objectief gezien is het een matige IDE.

[Brummetje]

meer dan 100 5 sterren van de hoeveel mensen die Xcode gebruiken? Dat is gewoon triest te noemen.

[Carbon]

Misschien ook even lezen waarover ze klagen!

[renalpha]

3.5 is het gemiddelde.
Je komt zeer onprofessioneel over. Fanboy much?

[bvdbos]

Ook met webview: NSBasic : https://www.nsbasic.com/
android, winphone, ios en desktop