Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 165 reacties
Submitter: t-x-m

Microsoft heeft een overeenkomst met Xamarin getekend voor een overname. Xamarin is de maker van een ontwikkelomgeving waarin apps gemaakt kunnen worden voor verschillende platforms in de C#-programmeertaal. Financiële details over de deal zijn niet bekendgemaakt.

Het Xamarin Platform maakt het mogelijk om in C# apps te ontwikkelen die native draaien op iOS, Android, Mac en Windows. De overname past bij de wens van Microsoft om meer apps naar zijn Windows 10-platform te krijgen. De overname is bekendgemaakt door Scott Guthrie, executive vice president van de Cloud and Enterprise Group bij Microsoft. In maart 2014 gingen er al geruchten dat Microsoft het bedrijf wilde overnemen.

Microsoft werkte eerder samen met Xamarin. Zo werd het platform geïntegreerd in Visual Studio, Microsoft Azure, Office 365 en de Enterprise Mobility Suite. In 2014 zette Microsoft samen met Xamarin de .Net Foundation op, een stichting om opensourceprojecten met betrekking tot .Net te coördineren.

Xamarin, dat in 2011 werd opgericht, heeft kantoren in de VS, Londen, Denemarken, Singapore en Argentinië met in totaal zo'n 350 werknemers. Het bedrijf heeft 15.000 klanten en meer dan 1,3 miljoen ontwikkelaars maken gebruik van het platform. Guthrie zegt dat er meer bekend wordt gemaakt over de toekomstplannen tijdens de Microsoft Build-conferentie die in maart plaatsvindt en tijdens het Xamarin Evolve-evenement in april. Tegen die tijd moet de deal ook volledig afgerond zijn.

Xamarin

Moderatie-faq Wijzig weergave

Reacties (165)

Jammer zeg. Alle bedrijfjes die inventief zijn in het opvullen van gaten worden zo opgekocht. Zo gaat deze markt eraan, en is het maar de vraag of de consument er beter van wordt.
Sorry hoor, maar hier ben ik het helemaal niet mee eens.

Allereerst vwb. innovatie. Xamarin is begonnen door MonoDroid te assimileren en er een Xamarin stikker op te plakken.

Ten tweede 'de markt stukmaken'. Wat ik wil is een goed ontwikkelplatform op deze aarde, waar we gewoon heel hard code mee kunnen klussen. Liefst open source, zodat er niet een monolytisch bedrijf is dat het platform waar we alles mee klussen kan verklooien. En liefst 'standaard', dwz: portable naar alle andere systemen. Waarom wil ik dat dan? Wel simpel: Een goed software development platform is de fundering waarop alle software wordt gebouwd. Een beter platform betekent meer innovatie, meer markt en betere oplossingen in de markt. Een beter platform is het allerbelangrijkste waar de consument beter van wordt.

Er is veel voor te zeggen om "het ultieme platform" niet in handen te laten zijn van een bedrijf -- het is gewoon te belangrijk voor onze ambacht. Echter, we moeten ook pragmatisch zijn: we eisen als ontwikkelaars best veel van zo'n platform - en er is geen overheidsbedrijf dat als kerntaak (en mogelijkheden) heeft om een software platform op dit niveau te maken.

.NET begint zo'n "ultiem" ontwikkelplatform te worden. Open source zijn ze hard aan aan het sleutelen, wat een goed begin is. Vwb. geld: VS Community edition is gratis en bevat eigenlijk alles wat je nodig hebt.

Vwb. platform: ik vind dat er geen echt goed alternatief is voor het platform dat ze Microsoft aanbieden. Ik heb het daarbij niet alleen over .NET, maar ook over de integratie met Azure, Windows, etc, etc. -- het speelt allemaal mee. Laten we wel zijn: het is gewoon fantastisch. Ik heb echt van alles jarenlang geprogrammeerd (ik heb liever ook geen vendor lock-in!), incl. Java, Swift, Javascript, C, C++, Pascal -- maar kom telkens weer op dezelfde conclusie uit: in .NET kan ik heel veel meer in elkaar rammelen in minder tijd met betere kwaliteit. (Disclaimer: Ja, dit is mijn persoonlijke mening obv. jarenlang programmeren, daar hoef je het niet mee eens te zijn).

Het opkopen van bedrijfjes die deze gaten vullen is weer een stap richting het ultieme platform. Ik voorzie vooral dat het bereik daarmee groter wordt. En een deel hiervan wordt vast ultimo weer open source, conform de trend van Microsoft. En dat - dat is precies wat we willen.
Je mist totaal het punt. Een ultiem platform, zoals jij je woorden zo mooi "in elkaar rammelt", kan maar een beperkte tijd ultiem zijn. Wanneer alles opgekocht wordt, koopt men ook potentieel toekomstige concurrentie op, en zonder concurrentie is er ook geen need voor innovatie. Stilstand komt dan vanzelf.

Maar als je kijkt met de pet van programmeur op....tsja....dan snap ik dat je het leuk vind.
In je profiel zie ik ook dat je "CEO" bent. Als "CEO" moet je wel wat verder kijken dan je neus lang is, wil je overleven in deze markt.

[Reactie gewijzigd door 70599 op 25 februari 2016 09:58]

Je mist totaal het punt. Een ultiem platform, zoals jij je woorden zo mooi "in elkaar rammelt", kan maar een beperkte tijd ultiem zijn.
Daar zou ik maar niet te zeker van zijn. Er zullen zeker wel nieuwe platformen komen, nieuwe hypes, nieuwe devices, etc -- maar bottom line gaat het daar niet om.

Als je het hebt over lange termijn -- het is compleet inefficient om een nieuwe programmeertaal en een nieuw platform te moeten leren omdat toevallig je telefoon, je horloge of wmb. je koelkast ook begrijpt wat een programma is. Het ultieme platform vangt dat op. Omgekeerd willen we wel graag dat we ook alle andere hardware kunnen blijven ondersteunen - en dat alles een beetje efficient.

Je merkt zelf op dat ik CEO ben. Werkelijk, het zal mijn klanten jeuken welk platform en welke programmeertaal ik gebruik. Maar praktisch gezien zijn personeelskosten 80% van de bedrijfskosten, die je vanuit je klanten moet verdienen - en daarmee zijn dit soort "details" operationeel heel erg belangrijk. Business wise heb ik geen innovatie nodig van het platform - wat ik nodig heb is stabiliteit, (veel) library support, cross-OS en cross-hardware support.

.NET laat hierin een aantal dingen zien. ( A ) ze ondersteunen met afstand het meest uitgebreide platform van de wereld. ( B ) de libraries en opzet zijn stabiel - zelfs icm cross-platform development via Xamarin. Je ziet bijv dat het aantal deprecations vrijwel nihil is. ( C ) De taal C# heeft meer innovatieve toevoegingen doorgemaakt in de afgelopen jaren dan andere 'grote' talen. ( D ) Het is portable naar verschillende fysieke hardware en OS platformen.

Het is nu al zo dat het maken van een nieuw platform from scratch gewoon onbegonnen werk is - het concurreert gewoon niet tegen wat er al is. Dat zie je ook: de hoeveelheid serieuze (software) platformen die opkomt stagneert over de tijd.
Wanneer alles opgekocht wordt, koopt men ook potentieel toekomstige concurrentie op, en zonder concurrentie is er ook geen need voor innovatie. Stilstand komt dan vanzelf.
Je doet net alsof Xamarin een serieuze concurrent is van Microsoft. Even om het helemaal scherp te krijgen: Xamarin was Microsoft partner en verdiende het meeste door de reclame voor cross-platform die Microsoft zelf maakt! De stap om Xamarin op te nemen in Visual Studio is daarvan een voorbeeld - maar jaren geleden lieten ze al dingen zien op MS Partner meetings en schoven ze Xamarin al naar voren als 'oplossing'.

Daarnaast heb je volgens mij gemist dat Microsoft in de laatste jaren enorme delen open source maakt onder een hele fijne licentie. Het staat je vrij om daarvan een branch te maken en zelf te gaan klussen -- sterker nog, dat vinden ze alleen maar gaaf en ondersteunen ze je zelfs in als je ze een mailtje stuurt met een vraag. (been there...)

Maar nogmaals, ik zou ook liever zien dat "het ultieme platform" volledig in het publieke domein wordt ontwikkeld als 'globaal, open' project. Niet vanwege de innovatie, maar simpelweg omdat ik vind dat fundamentele dingen zo horen te zijn.
In je profiel zie ik ook dat je "CEO" bent. Als "CEO" moet je wel wat verder kijken dan je neus lang is, wil je overleven in deze markt.
Tot nu toe gaat dat dikke prima, dus dank je voor het compliment. :)

[Reactie gewijzigd door atlaste op 25 februari 2016 12:55]

wat ik nodig heb is stabiliteit, (veel) library support, cross-OS en cross-hardware support.
Xamarin is geen crossplatform oplossing in de zin van write once run anywhere.
Je schrijft nog steeds platform specifieke apps alleen gebruik je C# en C# interfaces van de platform native API's.
Je hebt dus nog steeds een ervaren native iOS/Android ontwikkelaar nodig welke vervolgens verplicht een andere taal en IDE moet gebruiken.

Mijn advies voor wie Xamarin wil gebruiken als crossplatform oplossing: met een grote boog omheen lopen!
Kun je de slechte ervaringen met Azure en Xamarin toelichten? en aangeven wat er niet zo cross platform aan Xamarin is t.o.v. web voor mobiele applicaties?
Daar kan ik ook wel e.e.a. aan toelichten:

Azure:

Over het algemeen werkt het wel. Er zijn alleen wat narigheidjes:

- SQL Azure - simpel uitgelegd: het is veel te traag. Je kan beter gewoon SQL Server op een Azure VM draaien.
- Azure storage is prima, als je het correct gebruikt. Als je het incorrect gebruikt wordt je applicatie heel erg traag.
- Je moet verstand hebben van distributed systems (en distributed algoritmes) om het meeste eruit te halen. Dat geldt eigenlijk voor alle distributed systems icm. stateful processen.

Persoonlijk ben ik wel tevreden met Azure; je moet alleen even oppassen met de manier waarop je bijv. storage inregelt en dat goed benchmarken... then again, dat moet je eigenlijk sowieso wel in een professioneel software development proces.

Xamarin:

Again, ook hier: over het algemeen werkt het wel - er zijn alleen narigheidjes die met name optreden als je werkt met third-party componenten die het niet ondersteunen (nu nog de meeste!) en/of code die je 1 op 1 wilt migreren. Wat voorbeelden:

- Een aantal belangrijke dingen werken in de Xamarin/Mono CLR net anders dan in de .NET CLR. Bijv. Initializatie van statische objecten icm. meerdere threads.
- Een aantal features zoals Reflection.Emit werkt niet icm AOT compilatie. Emit wordt gebruikt voor allerlei features, zoals bijv. WCF. Hier kan Xamarin weinig aan doen, dit komt doordat Apple het niet toestaat.
- De Android/iOS app API's exposen vrijwel direct de native API's. Dat betekent dat je features dus op de UI laag meerdere keren moet implementeren (tenzij je gebruik maakt van Universal apps).
- Universal apps gebruiken XAML om dit op te lossen. Xamarin XAML werkt alleen niet lekker; ze zijn sort-of vergeten om de UI goed te bouwen (Note: Microsoft heeft een goede XAML implementatie) en de native API's lopen op sommige vlakken iets te veel uit elkaar.
- UI's op OS/X, Windows, iOS, Android en WinPhone werken gewoon anders, bijv. qua buttons, kleurstelling, etc. Daar moet je dus rekening mee houden.
- Sommige details zijn gewoon stom, bijv. de manier waarop embedded resources worden opgeslagen... dat hadden ze beter kunnen doen.

Voor een deel kan je hier als ontwikkelaar omheen werken, voor een deel is dat lastig.

Dat allemaal gezegd hebbende zijn er ook een hoop dingen die wel gewoon goed werken. Het grote voordeel van dit alles is dat je code compileert naar een native app.
Met het LLVM project dunkt mij dat je toch een breed ondersteund alternatief hebt, met zijn eigen intermediate language, die verreweg het breedst wordt gedragen.
Ja en nee.

LLVM is awesome als compiler/code generatie tool. Ook .NET doet dit, zowel via Mono als via het MS team / CoreCLR (LLILC is de Microsoft LLVM target voor CoreCLR: https://github.com/dotnet/llilc ). Het biedt je een aanzienlijk deel voor cross-device compatibiliteit.

Wat LLVM je NIET biedt is ... nouja eigenlijk al het andere. Low-level begint dat bij exception handling, multi-threading, etc. Het vertelt je niet eens de regels over calling conventions -- allemaal dingen die o.a. .NET IL wel gestandaardiseerd heeft. Op een hoger (library) level zit er eigenlijk helemaal niets in.

Dus... hoe awesome LLVM ook is, het is niet een platform (en ook niet zo bedoeld). Het is een (belangrijk) bouwblok, dat wel.
Waarom is Microsoft gestart met LLILC? Om via de IL van LLVM de gewenste cross platform te krijgen. De IL van LLVM is rijk genoeg om alles wat in die van .NET te bevatten. Wat dat betreft kom je echt niets tekort bij de IL van LLVM.

Bijkomend voordeel is dat LLVM open source is i.t.t. sommige delen van .NET waarvoor wel degelijk licentiekosten zijn verschuldigd.

Voor innovatie moet je in de regel niet bij commerciële bedrijven zijn maar bij start-ups, veelal voortkomend uit onderzoek bij de diverse universiteiten. Al is het natuurlijk wel zo dat aardig wat wetenschappelijk onderzoek aan technische universiteiten voor een niet onaanzienlijk gedeelte wordt betaald door marktpartijen.

Staat een beperkte lijst met innovatieve projecten op de site van LLVM: http://llvm.org/ProjectsWithLLVM/ met bijvoorbeeld links naar Emscripten http://kripken.github.io/emscripten-site/ en RTSC (Real Time System Compiler) https://www4.cs.fau.de/Research/RTSC/
De IL van LLVM is rijk genoeg om alles wat in die van .NET te bevatten.
En daar gaat je argumentatie de fout in. .NET rust nog altijd zwaar op native Windows DLL's.

Een klein jaartje geleden heb ik zelf geprobeerd om .NET te compileren naar native code (in mijn geval via C++). Ja, de core library werkt prima (het aantal native calls is uit mijn hoofd een stuk of 30). Dat is alleen het makkelijke gedeelte - het wordt moeilijker als je bijv. WPF aan de praat wilt krijgen (of Windows Forms, of ...). WPF en WinForms hangen zwaar op C++/CLI resp. GDI+. En daar gaat het fout. Zelfs als je alle generics, rtti, GC, etc allemaal goed krijgt, blijf je issues hebben met native calls.

Als alternatief kan je proberen te praten tegen de Mono libraries. Dan heb je alleen weer het probleem van P/Invokes en marshalling, die aannames doen over dingen als calling conventions en exception handling. Als je veel tijd investeert, gaat dit uiteindelijk overigens wel lukken.

Ik heb in die tijd ook contact gehad met met Microsoft JIT team. Die wezen met op o.a. LLILC. Waarom wil Microsoft dit? Nou, omdat het best onhandig is om compilers te bouwen voor meerdere platformen en al die instructiesets te beheren. Ze waren al teruggegaan van de (oude) C++ compiler (die deels gebruikt werd voor de .NET JIT) naar een eigen runtime - maar eigenlijk is ook dat onhandig omdat je voor een optimizing compiler gewoon een hele bulk werk moet doen. De stap naar LLILC is logisch.

Daarbij moet worden opgemerkt dat LLILC op dit moment dezelfde issues heeft mbt. native libraries als mijn projectje. Er zijn overigens best veel van dit soort initiatieven... er zijn zelfs compilers die .NET IL compileren naar Javascript.

Vwb. je argument mbt. innovatie. Ik twijfel of dat zo is, dus ga daar geen uitspraken over doen. Ik wil je er wel graag op wijzen dat LLVM alles behalve een klein / universitair projectje is. Zo is het ooit begonnen, maar inmiddels werken partijen zoals Apple, Microsoft, AMD en Google er ook serieus aan.
Het ligt er maar helemaal aan wat Microsoft met Xamarin gaat doen. Hoeft niet persé negatief te zijn.

Xamarin heeft door zijn prijsstelling maar een beperkte markt, en het is maar de vraag of ze genoeg vernieuwingen in hun applicatie kunnen bouwen om klanten vast te houden. Het eerste idee was goed, maar zo'n bedrijf moet zich blijven ontwikkelen en dat kost bergen met geld.

Microsoft heeft die diepe zakken, en kan die gebruiken om ofwel de applicatie door te ontwikkelen, ofwel de licentiekosten acceptabeler te krijgen - of en combinatie van die twee.

Vergelijk het met Mojang, de ontwikkelaar van Minecraft. Microsoft heeft dat bedrijf voor een hoop geld gekocht en ogenschijnlijk gebeurt er niet zo heel veel. Maar je ziet nu ineens wel dat Minecraft wordt geport naar nieuwe platforms (bijv. Xbox). Nu is het natuurlijk nog te vroeg om te zeggen wat Micorosoft met Xamarin van plan is, maar het hoeft niet persé slecht nieuws te zijn.

En 'bedrijfjes die inventief zijn' zijn van alle tijden. Zo is de VOC begonnen, en IBM, en Philips, Microsoft, Google, Facebook, Twitter - ga zo maar door. Ja de meesten zullen opgekocht worden, maar als ze mazzel hebben glippen ze er tussendoor en met nog veel meer mazzel worden ze zelf zo'n grote moloch die bedrijfjes opkopen die inventief zijn.
De hoop is dat Microsoft Xamarin producten gratis gaat aanbieden om zijn marktaandeel op Android en iPhone te verhogen. Hopelijk pikken ze dan ook nog wat Azure klanten mee.
Dat is ook een beetje mijn hoop. Xamarin licenties zijn niet bepaald goedkoop en dat verhinderd veel ontwikkelaars en bedrijven om ermee aan de slag te gaan. Het zou mooi zijn als Xamarin onder de MSDN licentie gaat vallen bijvoorbeeld.
Inderdaad Xamarin is duur, het zou mooi zijn als het nu rechtstreeks in Visual Studio zou worden geintegreerd. Het zou vooral leuk zijn als Community wat crossplatform features mee pakt.

Vooral dat laatste zou denk ik goed zijn voor meer Windowsmultiplatform apps.
Als ik op hun site kijk zie ik 999$ (enterprise) per platform per jaar. Valt op zich nog mee lijkt me (voor een bedrijf)? Als je de prijzen bekijkt van de Oracle variant (Oracle mobile application framework) ...
Voor een professioneel software bedrijf zullen de licenties ook niet het struikelblok zijn. Voor de individuele ontwikkelaars die iets leuks willen bouwen is het gewoon een hoop geld.

Xamarin is een mooie oplossing voor het probleem dat Cross-Platform heet. Zelf koester ik de stille hoop dat e.e.a. nu voor de hobbyist gratis gaat worden (met alle functionaliteit) en dat we een boost gaan zien aan applicaties die zowel voor iOS, Android, Windows 10 Mobile, Windows 10 en OSX beschikbaar komen.
Het is eerder cross compiler dan cross platform. De apps zelf zijn namelijk niet cross platform en verschillende binaries beheren voor verschillende platformen is voor de meeste bedrijven ook geen feest. Voor cross platform kunt je kiezen uit tig Cordova gebaseerde tools en platformen.
Voor zover ik weet is een .NET executable geen x86 code, maar IL-code die door een JIT compiler door elk platform uitgevoerd wordt.

Ikzelf heb op windows een proggie geschreven en met Visual Studio gecompileerd. Die kon ik met mono op mijn Beaglebone Black (ARM) gewoon uitvoeren (En op mijn windows machine).

Verder is het beheren van verschillende "gecompileerde" versies uit één code base absoluut geen probleem als je dat vergelijkt met het opnieuw moeten ontwikkelen voor elk platform omdat ze andere ontwikkeltools gebruiken.

[Reactie gewijzigd door misterbennie op 26 februari 2016 08:50]

Het zal er wel op neer komen dat je VS Ultimate moet hebben om het te kunnen gebruiken. Zelf zou ik het geweldig vinden als het in alle versies, inclusief Community zou verschijnen. :)
Volgens mij ben je niet helemaal op de hoogte van de koers die Microsoft de laatste tijd vaart. "Cloud First, Mobile First"
Steeds meer (delen) worden Open Source, steeds meer applicaties en diensten zijn beschikbaar op niet-microsoft platformen. (android en ios)
Kijk bijvoorbeeld eens op
https://www.microsoft.com/en-us/garage/
De hele .Net 5 ontwikkeling is open. Issues op Github, voortgang wordt besproken op live.asp.net je kan meepraten via google hangouts.
Ze maken bridges zodat je ios, android etc. kan porten naar windows 10 en Xamarin zorgt ervoor dat je met je .net code en wel platform specifieke UI een app kan maken voor ios en android. Ik denk dat ze met deze overname een goede beslissing hebben genomen om zo meer developers te binden aan Visual Studio.
Voor mij bijvoorbeeld is het nu fijner een ios app te maken, omdat ik mij niet/minder hoef te verdiepen in object-c of swift 1 of 2.
Microsoft is momenteel goed bezig, als het over azure gaat en openheid van zaken, ook support voor andere platformen zijn ze inderdaad goed aan aan het werken. Ik hou er van, en zie op deze voet een goede toekomst in Microsoft.
TypeScript is geen tool ;-)
De mobile developers zijn ze niet zo zeer kwijtgeraakt. Die focussen gewoon op het mobiele OS met grootste marktaandeel (android 1, ios 2, windows 3)
Verder geef je aan dat je minder kan kiezen bij Microsoft terwijl ik juist het idee heb dat het meer wordt. Cross platform. Diensten op meerdere besturingssystemen. Docker op Azure, Linux op Azure etc.
Maar goed, zoals je al aangeeft de consument is gebaat bij vrije keus en die hebben we gelukkig. (google apps/office 365, aws/azure, office/openoffice, windows/linux/bsd/osX etc.)
Xamarin is ook gewoon een bedrijf met concurenten, als ze een concurrent "saboteren" hebben ze hier ook baat bij
Microsoft heeft er baat bij om de concurrentie te saboteren, Xamarin niet.
Microsoft is echter behoorlijk actief op zowel iOS als Android gebied. Waarschijnlijk hopen ze dat mensen apps gaan maken met Xamarin zodat die apps ook beschikbaar komen voor Windows 10/WP10, en niet alleen voor Android en iOS.
Sterker nog, in oorden als Silicon Valley is het voor 90% (ik schat maar wat) het enige doel om juist overgenomen te worden.
Dat maak ik er ook telkens van: 5 jaar goed werken aan een uniek/goed concept. Een paar miljoen op je rekening en je moet je nergens meer van aantrekken. Wie zou het anders willen?

Ja, niet iedereen heeft het geluk, er gaan er voldoende overkop. Maar die "Lucky Few" mogen gerust zijn!
Dit is dé kans voor Microsoft om C# één van de belangrijkste hogere programmeertalen te maken! Desktop applicaties en mobiele apps, allemaal multi-platform met één taal en soms zelfs dezelfde codebase. Dat moet je als ontwikkelaar toch ook willen..?

Ik heb voor school onderzoek gedaan naar verschillende cross platform platformen en Xamarin is veruit de meest levensvatbare.
Ik denk dat C# Native een veel grotere potentie heeft. De wereld is al decennia lang op zoek naar een waardige opvolger van C++ en C, die nog veel gebruikt worden en erg fout-gevoelig zijn wat het internet zeer onveilig maakt.
Valt wel mee, C/C++ is zo onveilig niet. Het wordt pas onveilig als je prutprogrammeurs er mee laat stoeien. Zeker sinds c++11 zijn er een hoop problemen met c++ opgelost. Daarnaast heeft c# bij lange na niet de featureset van c++, iets waar ik zelf ook wel eens tegen aan loop in C#.
Dat gelul van programmeurs die denken dat zij het wel goed kunnen begint me de keel uit te hangen. Het is bewezen dat mensen gewoon fouten maken en dat een computertaal daarom zo ontworpen moet zijn dat fouten maken moeilijk is. Ja, je kan een C programma foutloos schrijven maar gezien deadlines, slaaptekort en onwerkbare schedules is dat in de praktijk gewoon een illusie.

De gevolgen zijn voor de gehele mensheid ernstig, zoals de miljoenen kwetsbare internet routers die verkocht zijn. Het Internet-of-Things wordt een nachtmerrie als we niet C# Native gebruiken om alles wat op kleine apparaten draait te ontwikkelen!

[Reactie gewijzigd door ArtGod op 25 februari 2016 19:55]

C# is niet een oplossing voor alles hoor, denk je echt dat triple AAA games die performance impact willen? Groot probleem met C# is ook timing kritische zaken. Door de Garbage Collector is het praktisch onmogelijk om dit te doen in c#. En daarnaast, een professioneel c++ programmeur maakt welliswaar ook fouten, maar je denkt toch niet echt dat kritische code niet gereviewed wordt door meerdere lagen en getest wordt voor het in productie gaat?
Neemt niet weg dat de gemiddelde 'programmeur' niet geweldig kan programmeren in talen als c/c++.
maar je denkt toch niet echt dat kritische code niet gereviewed wordt door meerdere lagen en getest wordt voor het in productie gaat?
Het zal je verbazen hoeveel zooi er in kritische omgevingen wordt gedraaid. De situatie die jij schetst is een utopie.
Welke idioot gaat C++ vergelijken met C#. Die twee talen liggen in een ander domein. Wat je wel kan vergelijken met C++ is, D of Rust. C# kun je vergelijken met Java, of andere bytecode talen. En voor de internet of things moet het niet uit maken welke taal je gebruikt. Maar moeten er gewoon fatsoenlijke standaarden komen met betrekking tot communicatie. Dat ga je niet vast timmeren op een bytecode taaltje zoals C#. C# is een hogere taal. Dit betekend dat het altijd een onderliggende laagje nodig heeft. En dat is niet altijd handig voor Internet Of Things met betrekking tot kleine microcontrollers welke dus alleen fatsoenlijk draaien met lagere talen. Tenzij je elk apparaat wil uitvoeren met een OS + .NET laag. Wat dus zeer ongunstig is voor het stroomverbruik. Je wilt juist een super zuinige chip met ethernet verbinding die kan slapen. Met publish subsribe dat werkt op een lagere taal. En de node moet bijvoorbeeld kunnen slapen of in een soort hibernate stand vallen. Hogere talen zijn energie verslindend. Dat is alleen handig als hub taal waar je je zogenoemde router implementatie van signalen maakt. Dit moet volledig asynchroon zijn. Dan kom je weer bij Erlang of NodeJS.
Je bent bekrompen in je intellect en je weet kennelijk niet waar ik het over heb. C# Native draait rechtstreeks op de hardware en niet in een virtual machine.

C++ is een voortborduring op C en de stap tussen C++ en C# is niet super groot. In C# kan je ook geheugen zelf managen als je dat leuk vind en je kan er dus in theorie hetzelfde mee doen als C of C++. Als C# Native uitkomt dan zal er binnen de kortste keren een besturingssysteem in geschreven worden.
Maar dan zit je toch nog aan minimale hardware eisen die nogal wat kosten. En veel resourches beschikbaar moeten hebben zoals de wat snellere ARM boardjes. In plaats van 8bit uC's met een heel laag verbruik met betrekking tot internet of things. Want een ethernet stack draait daar wel op. Maar C# taal krijg je daar niet op hoor. Dus om C# nou de internet of things taal te benoemen. nee.

En ik wist niet van dat C# native af. Dat is mij nieuw terwijl ik wel wat met C# zelf doe op Linux met mono. Blijkt dus dat het native verhaal ook niet op gaat voor Linux. Enkel Windows?
Behalve dat, afgezien van de naam, C# op een heel ander niveau werkt dan C/C++.

Voor gewone apps en alledaags gebruik heb je overigens gelijk, maar C# is geen vervanger. C# is origineel geschreven in C++. Python is origineel geschreven in C. De JAVA VM (waarin je java code wordt uitgevoerd) is geschreven in C/C++.

Het enige wat je kan doen is je gebruikers (programmeurs) zo goed mogelijk afschermen van de boze wereld door een veilige abstractielaag toe te voegen, maar uiteindelijk vervang je C/C++ niet, je bouwt alleen een extra laag om de grootste nadelen van deze low-level talen te ondervangen.
C# Native werkt niet op een ander niveau dan C/C++. Het huidige C# draait in een VM, maar C# Native niet.

Je kan met C++ ook al veel geheugen fouten voorkomen (zoals met STL). Zelfs Garbage Collection is beschikbaar voor C++ en C (heb het zelf gebruikt) maar toch kiest men er nog steeds voor om op een middeleeuwse manier in C te programmeren vanwege performance redenen. Die 5% snelheid die het kost is het meer dan waard.
Onveilige software komt door slechte ontwikkelaars en net zoals de komst van de computer er niet voor heeft gezorgd dat we minder hard hoeverre werken lost C#, noch allerlei test tools ervoor dat software beter en veiliger worst want zodra ze een dure kundige C++ ontwikkelaar kunnen vervangen door een aap met C# (trouwens c# niet verwarren met managed. NET) dan doen ze dat. Niks wijst er op dat software veiliger is geworden, wel trager en niveau van ontwikkelaars ook, en CO2 uitstoot is toegenomen. Zolang mobiele devices draaien op batterijen heb je ontwikkelaars nodig die niet alleen functioneel maar ook resource efficient kunnen denken en snappen waar ze mee bezig zijn.
Als MS met C# & .net qua marketing niet zo enorm verprutst had, waren ze een goede concurent van JAVA geweest.

Met de taal en platform is niks mis, maar de keuze om de programmeertools alleen op Windows en het platform alleen op Windows en OS X uit te brengen was behoorlijk stom.
Op de desktop is Linux toch echt een niche markt, en laat daar nu juist toendertijd door Microsoft de focus op gericht zijn. Nu Microsoft binnen bedrijven grote concurrentie van Linux heeft (vooral op servergebied), is de focus verschoven naar cross-platform development, om ook daar weer marktaandeel te krijgen.
Op de desktop ja, maar op server-gebied is Linux nooit een nice-markt geweest.
Microsoft heeft hier serieus steken laten vallen. Ik heb niks met dat bedrijf, maar C# zit goed in elkaar. Het is puur dat platform-gebondenheid waardoor ik het heb laten vallen na mijn opleiding.

Tevens heb ik het niet alleen over Linux. De ontwikkeltools bestonden (de pro-versies nog steeds niet!) ook niet voor OS X.
Persoonlijk geloof ik zelf in JavaScript en misschien zelfs TypeScript als 'one language to rule them all'. Ondertussen kan je JavaScript draaien in je browser, als mobiele app met Cordova / Ionic, desktop apps met Electron en als server / CLI met NodeJS.
Maar het blijft een scripttaal tegenover rijke en breed ondersteunde talen als Java, C en C#.

Het kan, ja. Maar wat is precies de vooruitgang, met name als cross platform er niet toe doet.

Microsoft is overigens zelf ook hard aan Java/TypeScript aan het werken. Het feit dat je Windows Apps volledig in Html5/JavaScript kan schrijven is daar en mooi voorbeeld van.

Maar overstappen naar JavaScript voelt bij mij echt als wisselen van een Mercedes S naar een Opel Corsa met gas, omdat je dan tenminste kunt kiezen waar je op wilt rijden. (Slechte analogie...)
Gevoel is een slechte raadgever.

Vroeger werden alle bedrijfsapplicaties native ontwikkeld en draaide het op je desktop. Tegenwoordig is dit vrijwel ondenkbaar wat die bedrijfsapplicaties worden allen geschreven als web applicatie. Alle voordelen die daarbij horen zijn evengoed van toepassing op mobiel, al vind ik het gevoelsmatig ook fijner om een desktop app te bouwen met visual Studio.

Maar wij doen wat goed is voor de eindgebruiker en niet wat wij als ontwikkelaars leuker vinden. Browsers en web containers zijn een stuk veiliger dan een native app.
Ook hier worden de bedrijfsapplicaties steeds meer naar NodeJS / PHP gemigreerd icm MySQL, Postgres of MongoDB backend en een Angular / Bootstrap frontend.

Het grote voordeel is dat application delivery veel goedkoper is, en omdat we de eindgebruiker de keuze willen geven tussen OSX / ChromeOS / Windows / Linux / Android / iOS zonder dat we 6 applicaties onderhouden.

Voor legacy gebruiken we RemoteApp, hoewel dat licentietechnisch weer een prijzige oplossing is.

[Reactie gewijzigd door merauder op 25 februari 2016 17:57]

Het geinige vind ik dat TypeScript van Microsoft afkomt (Anders) en dat Google het gebruikt voor Angular. En Angular weer beschikbaar is met project templates in Visual Studio.

Maar om terug te komen op je Javascript. Ik denk dat jouw optie ook zeker levensvatbaar is, naast Xamarin. Ieder heeft zijn voorkeur. Mijn persoonlijke is Xamarin omdat dit compileert naar een native app.
Hmm, om nu maar iets te noemen: ooit al van Node.js gehoord? Dat is verrevan 'laggy' of omslachtig. Er zit gewoon een degelijke Javascript-engine (V8 van Chromium) achter en dingen zoals opslag en bestandoperaties (verplaatsen, verwijderen, aanmaken) zit er zelfs native in. Verder kan het enorm ui!tgebreid worden met packages, soort van plugins. Op het moment van schrijven zitten we aan 244,563. Eerlijk toegegeven, waarschijnlijk niet allemaal even nuttig of uitgewerkt, maar nagenoeg alles wat je zou kunnen nodig hebben, heeft één iemand wel al eens gemaakt. Deze packages maken dan weer gebruik van andere packages die elk 'gespecialiseerd' zijn in hun core functie en zo krijg je gewoon een degelijke chain aan door de community geteste functionaliteit. Helemaal geen bij elkaar geraapt zooitje ;)

Nog meer zelfs: een website is tegenwoordig een app of desktopapplicatie met frameworks zoals AngularJS of React. Deze frameworks kunnen net zoals programmeertalen in een MVC-omgeving gebruikt worden waardoor je een mooie scheiding kan brengen tussen de verschillende lagen in je applicatie. Controllers, services, models, you name it. Je kan zelfs nog verder gaan en je 'website' omzetten naar een volwaardige native applicatie. Daarvoor heb je bijvoorbeeld Electron. Je core bestaat uit HTML, CSS en Javascript (je typische website elementen dus), maar je kan er cross-platform applicaties mee maken die native menu-elementen hebben (om nu maar een voorbeeld te noemen), maar ook installers en tools om automatische updates mee te installeren, zijn gewoon beschikbaar.

Al bij al lijkt me dit toch best wel een gestructureerd zooitje :)

[Reactie gewijzigd door PixelShooter op 25 februari 2016 09:06]

Toch blijven de meeste Electron applicaties (bijvoorbeeld die nieuwe tekst editor van github) vrij traag. Vooral de opstart tijd. Als je dan iets neemt als Sublime Text (een concurrent in C/C++) dan is dat toch echt een stuk rapper. (Ja beide van een ssd gerund)

Ik vind de html5/js/css apps/programma's altijd maar een beetje gebeund aanvoelen. Native (of zelfs Java/.NET) zit toch echt nog in een andere league.
Atom bedoel je waarschijnlijk? Maar inderdaad, toen ik hem eens geprobeerd had, had ik ook dat gevoel. Duurde wel even eer ie goed en wel voor m'n neus stond.

Andere Electron-applicaties heb ik nog niet geprobeerd - toch niet dat ik me nu herinner - maar misschien zijn die wel gewoon snel. Wat Atom bij de opstart allemaal doet is uiteindelijk ook maar giswerk.

Node.js als platform, maar ook andere frameworks, vind ik verder wel snel werken. Ongetwijfeld niet zo snel als Java of .NET, maar dit zie ik nog wel verbeteren in de toekomst. Zeker nu er meer en meer aandacht aan besteed wordt.

Tot slot, ik dacht dat Sublime Text ook deels Python was? Ik gebruik deze editor voornamelijk voor web development of zelfs andere dingen, en dat bevalt me niet slecht :)
De python bindings zijn volgens mij alleen maar voor de packages en dingen.
Ik zelf walg van Javascript, wat misschien wel de slechtste computertaal OOIT is die een aanzienlijk marktaandeel heeft behaald.
Ik vind JavaScript eigenlijk pas sinds de laatste 3 / 4 jaar een serieuze optie. Vooral de eerste implementaties waren echt enorm buggy, traag en brak, maar sinds jQuery, Jquery Mobile en NodeJS is er echt prima mee te leven.
De meeste crossplatform applicaties die ik persoonlijk ken. Crossplatform als in Windows Desktop / OSX / Linux desktop. Dat zijn vaak HTML applicaties verpakt in NW.JS of Electron van Github.

Maar als je het over de mobiele wereld hebt is Xamarin zeker een grote speler. En het verbaasd mij totaal niet dat Microsoft hun heeft overgenomen. Dat was gewoon een kwestie van tijd volgens mij.
Nooit van wxWidgets en QT gehoord?
Daar moet je anders nog aardig wat platform specifieke code voor schrijven hoor als je niet een library gebruikt om graphics/filesystems/system calls te abstraheren.
Voor graphics kan je OpenGL gebruiken. Je kan er geen spelletjes mee maken maar wel de meeste desktop applicaties, zoals word processors, email clients, web browsers, chat clients etc. etc.

Veel bekende applicaties gebruiken wxWidgets (Truecrypt, Password Safe) en QT (Skype).
Dat weet ik wel, been there done that. Ik bedoel alleen maar dat ze niet volledig "abstract" zijn. En sommige andere platformen proberen dat wel te zijn. (Dus echt 1 code base, zonder al die pre-processor #if statements)

Je kan trouwens met OpenGL echt wel games bouwen hoor, net zo goed als met DirectX, je moet alleen ECHT weten wat je doet.
Je kan voor de UI en de implementaties in cross platform libraries voor bijvoorbeeld sockets, threads wel 1 codebase maken. Voor de rest moet je gewoon componenten gebruiken die cross platform zijn zoals MySQL, SQLite e.d. Echt helemaal zonder conditional compilation kan niet voor echt technische zaken zoals device drivers of low-level OS access.
ben wel benieuwd naar de resultaten van je onderzoek; wat heb je allemaal bekeken? kun je je bevindingen puntsgewijs opsommen of heb je die anderszins ergens staan?

[Reactie gewijzigd door CynicRelief op 25 februari 2016 11:44]

Cross platform? Daar heeft html5 toch gewonnen?
html5 is alleen een opmaaktaal. Je hebt nog iets anders nodig voor de logica, zoals bv controleren of een wachtwoord correct is ingevoerd. Dan is javascript een logischere cross-platform oplossing zoals @merauder hieronder al aangeeft.
Javascript draait in je browser, clientside. Dat is nou net waar je in een webapplicatie niet je wachtwoord wil valideren. 1) de client kan het debuggen, aanpassen of compleet overslaan, 2) als je clientside valideert staat je hashingmechanisme, salt, etc inclusief de passwordhash dus ook clientside.
Ooit van NodeJs gehoord, het kan prima op server-side draaien toch al weer 7 jaartjes bijna.

Prefereer een wat andere back-end uiteraard, maar ik denk dat Cracking doelt op javascript icm. HTML5, zonder javascript ga je timeouts krijgen, en page refreshes hebben veel nadelen qua UX, zoals de scroll positie, laadtijd etc.

Maar ik ging er van uit dat je dat wel doorhad.
Ook met NodeJs draait de geschreven HTML uiteindelijk op de client. En als je die HTML-opmaaktaal wil vervangen met javascript, staat dat op de client.

Kalix hieronder zegt hetzelfde als dat ik poste, dus zo duidelijk was het niet.
Die timeouts, pagerefreshes en dergelijke wat jij allemaal op noemt. Dat is puur afhankelijk hoe je het programmeert. Niet dat het een eigenschap er van is.
Je programmeert niet veel op het moment dat je enkel HTML gebruikt dat was mijn punt, daarom gebruik je een JS laag.

Die timeouts zijn dan wel een eigenschap, omdat er puur op http requests gerust wordt en geen tussenlaag gebruikt wordt.

AKA, geen AJAX in een "web app"
Ik zou alleen nooit mijn wachtwoord controle in javascript schrijven. Client-side wachtwoordvalidatie is not done. Je hebt dus server-side nog iets nodig hiervoor en server-side javascript klinkt mij nog een beetje vreemd in de oren.
En toch bestaat het al jaren. Nodejs draait op server en werkt met javascript. Amazon heeft heel veel apache webservers vervangen door nodejs scripts want het is kinderlijk eenvoudig in nodejs om server apps zoals web servers, proxies of webservice te bakken.

Maar vooral is het retesnel! Sneller dan gangbare native servers zoals IIS of apache.
Ja, html/css/javascript met de nodige plug-ins en extensies en de ellende om simpele functies te implementeren... Ellende!
Mwoah, doe het al een paar jaar (HTML5 frontend (jquery, gwt, plain-old-html, diverse backends). Nooit de behoefte gevoeld voor dingen als flash en andere troep in de browser erbij te zetten. Native apps, dat is pas doffe ellende: iOS, Android en (als je pech hebt ook nog windows) en bij iedere OS update maar hopen dat alles blijft werken. Dan nog het aantal versies (inmiddels meer dan er browsers zijn). Nee, HTML5 is dan vele malen beter.
Hoe is de performance van html5 apps in iOS en Android?
Goed genoeg. Scheelt wel als je de content eventueel lokaal neerzet (phonegap). Opstarten van een webview duurt langer dan een native app opstarten, maar is geen bottleneck gebleken.
Zoals anderen in dit topic al opmerking is Xamarin (zelfs de Indie editie) best wel een investering voor app ontwikkelaars. Je moet denken aan zo'n 500 EUR per jaar voor iOS en Android. Nog meer als je ook WinPhone wilt ondersteunen. En de meeste apps leveren niet eens (noemenswaardig) veel geld op.

Met Microsoft hier achter is de kans groot dat de prijzen voor indies zullen dalen of misschien wordt de tooling zelfs gratis. Dat zou voor veel ontwikkelaars een overstap naar C# ontwikkeling een stuk kleiner maken.

[Reactie gewijzigd door MacWolf op 24 februari 2016 23:28]

Maar Microsoft moet er zelf ook wat aan hebben. Alleen dat ontwikkelaars een veel gebruikte app in .NET hebben geschreven levert het bedrijf niets op. Ik vermoed dat men ook hoopt dat Azure als back-end wordt gebruikt. Lijkt mij iig logisch.
Wat het oplevert is dat een veelgebruikte app ook op windows phone beschikbaar is. Als er veel populaire apps op windows phone beschikbaar zijn is er een grotere kans dat mensen een windows phone aanschaffen. Als er meer mensen zijn die een windows phone aanschaffen is er weer een grotere kans dat MS daar geld aan kan verdienen ivm app verkopen, ads etc.

Het hoeft direct niks op te leveren zolang het indirect maar de positie van MS versterkt.
Waarom lopen jullie steeds te emmeren over Windows Phone? Dat is een DOOD paard waar zelfs Microsoft niet meer aan trekt!

En volgens mij heb jij nooit met Xamarin ontwikkelt (ik wel). Een Android app ontwikkelt met Xamarin is qua structuur gewoon hetzelfde als bij Java, alleen de taal is anders. Idem voor iOS. Je kan wellicht bepaalde business logica delen tussen de platformen maar de opbouw van de apps verschilt heel veel per platform.
Wat t_o_c ook zegt; Microsoft zit in de positie dat het ze (in theorie) niet eens rechtstreeks financieel gewin hoeft op te leveren. Zolang er maar meer C# ontwikkelaars bij komen zit Microsoft goed. Zolang er maar meer Windows Phone apps bij komen zit Microsoft goed.

En dat is precies wat deze overname mogelijk zou kunnen maken, want nog betere integratie. En als de licentiekosten ook nog eens dalen wordt het veel aantrekkelijker om Xamarin voor cross platform ontwikkeling te gebruiken.
Inderdaad, als t gebacked word door een groot bedrijf, en de kosten dalen, zullen veel ontwikkelaars die voor hun klanten crossplatform apps moeten maken mogelijk overstappen.
windows phone is "gratis", aangezien iedereen eigenlijk alleen maar ios en android wil kopen. Overigens is je 500 euro per jaar een schijntje vergeleken met wat je als bedrijf moet betalen (indie is alleen individual, mag je officieel heel veel dingen niet mee).

Als bedrijf betaal je standaard 999 per jaar per developer per platform. dus ios+ android met 2 man = 4000 euro per jaar. (en dan moet je nog geld gaan verdienen aan je app ;) ).

Voor dat geld krijg je ook nog een een platform wat op heel veel fronten zwaar kut is, en als een beta product voelt.
Ik vind 500 euro per jaar veel geld als ik er niets mee verdien. Wellicht dat je ergens een mobiele app voor iemand kan maken (a 60-80 euro per uur) maar dat is allerminst zeker.

Ze kunnen het beter gratis weggeven en dat je alleen het volle pond betaald als je er commerciële apps mee maakt.

[Reactie gewijzigd door ArtGod op 25 februari 2016 20:03]

Denk je niet dat het met de maker van C#, Microsoft, het bedrijf een veel groter potential heeft?
YES Hier wachtte ik al een paar jaar op!

Je moet je voorstellen dat Microsoft graag zijn .NET platform beschikbaar wil maken voor alle OS'en. That includes Linux, Android, iOS en OS/X. In een eerdere fase zijn daar al verschillende delen van vrijgekomen:

- CoreCLR draait op verschillende platformen. https://github.com/dotnet/coreclr
- Project Native probeert code te compileren als AOT compiler. Het was oorspronkelijk de bedoeling dit ook naar andere platformen te porten.
- LLVM integratie in de CLR. https://github.com/dotnet/llilc
... en zo nog het een en ander.

Het issue met al deze projecten is echter library support. Daarmee heb ik het niet over de .NET library, maar met name over de native libraries, zoals GDI+. Mono, wat voor mobile devices geassimileerd is door Xamarin heeft deze library support. Sinds een tijdje raad Microsoft daarom Mono/Xamarin aan hiervoor.

De Mono runtime zelf is helaas echter buggy... ik heb een paar maanden geleden wat productie code van me te runnen op de laatste versie en ik kwam best veel issues tegen. Die zijn allemaal te herleiden tot details in de .NET specificatie - die net anders zijn in Mono dan in de .NET CLR. Een voorbeeld hiervan is bijv. initializatie van static variables over meerdere threads (in .NET CLR gebeurt dit gegarandeerd in 1 thread en eindig je met 1 instance, in Mono kan je ineens meerdere instanties hebben). Inmiddels begreep ik dat Microsoft zelf ook bezig is met Mono hierin helpen.

Dat Microsoft nu Xamarin overneemt is een grote stap voorwaarts! Het is fantastisch als Microsoft Visual Studio uitbreidt met cross-platform native support en de Mono runtime tijdens het proces vervangt of aanpast complient met de .NET CLR. Daarnaast kunnen de beperkingen van Xamarin XAML ook meteen worden opgelost -- Microsoft heeft dat immers gewoon op de plank liggen.

Kortom: ik kan niet wachten op Visual Studio 2017. Geweldig!
Same here. Dit maakt mij blij!
Ben al redelijk content met de Apache Cordova Tools in Visual Studio, maar als dit standaard geintegreerd zou worden, wordt het helemaal geweldig. En hopelijk voor een iets schappelijker prijs dan wat Xamarin er voor vraagt.

Aan de andere kant heeft dit hopelijk geen nadelige gevolgen voor de Apache Cordova Tools binnen VS.
Microsoft is rijkelijk laat met zich te realiseren dat het draaien van .NET op verschillende platformen gunstig voor hen kan zijn. Op z'n minst houdt het Microsoft relevant, ook als de hele wereld overstapt op Linux (of een ander besturingssysteem). Oracle is ook nog steeds relevant vanwege Java, en zal dat daarom voorlopig ook nog wel even blijven.

Men heeft te lang vastgehouden aan het feit dat .NET alleen op Windows moest draaien. Dat heeft verkeerd uitgepakt want andere talen zoals Java (e.g. Android) hebben daarom een grote voorsprong weten op te bouwen, terwijl C# feitelijk beter is.

Microsoft moet nu .NET op Linux nu als first-class citizen gaan behandelen en niet alleen roepen dat het mogelijk is om het er op te draaien met veel kunst en vliegwerk.
Als ze dat echt wilden hadden ze .Net (nog voor het open source ging) op Android kunnen zetten (op iOS mag niet). Xamarin niet nodig en 100% compatible. Dit is weer typisch een too little and much too late uit redmond.
Xamarin vind ik steeds interessanter worden voor app-ontwikkeling, maar ik denk dat als je als opdrachtgever (of programmeur met belang in de de resulterende app) een aantal overwegingen moet maken. Ik moet zeggen dat ik Xamarin al een tijdje niet meer bekeken had, maar het blijkt dat zij vanaf mei vorig jaar de mogelijkheid hebben een apart Android en iOS design te maken binnen hun platform. Dan wordt inderdaad een deel van het probleem van cross-platform ontwikkeling opgelost. Wellicht zit je dan wel nog met een relatief trage app en beperkte mogelijkheden om nieuwe functionaliteiten toe te voegen.

Als je wil weten of een app voor een gebruiker (van bijvoorbeeld een ouder of goedkoper Android toestel) een probleem gaat worden doen dan het volgende. Test met een oude of goedkope Android mobiel of de apps die een Xamarin developer al heeft gemaakt snel genoeg werken. Oude of goedkope toestellen zijn natuurlijk altijd trager, dus vergelijk met een aantal apps die er al op staan.

Als het gaat om de vraag of je genoeg nieuwe features kunt toevoegen met Xamarin boven Native app development: maak een zogenaamde MoSCoW analyse van je app. Hierin verdeel je de functies die je wil hebben of ooit wil laten maken in Must haves, Should haves, Could haves en Won't haves (vandaar de afkorting MoSCoW). Oftewel: zaken die essentieel voor het werken van je app (Must haves), dingen die er eigenlijk wel in moeten zitten maar niet essentieel zijn (Should haves), dingen die je wel leuk vind maar ook makkelijk uit je app gelaten kunnen worden (Could haves) en dingen die je in ieder geval niet gaat doen (Won't haves). Neem deze functionaliteiten mee naar het gesprek met de ontwikkelaar en vraag of deze ontwwikkelt kunnen worden in Xamarin. Mocht het zo zijn dat er enkele Could haves niet mogelijk zijn, dan is dat geen ramp. Maar als er Must haves of Should haves niet mogelijk zijn, dan moet je je achter een oor krabben. Zitten er beperkingen in Xamarin waar je niet omheen kan maar die in je Won't haves staan? Dan is cross-platform ontwikkeling met Xamarin waarschijnlijk niet voor jou.
Apart Android en iOS design is ALTIJD al onderdeel van Xamarin. het is de basis van Xamarin zelfs.

Het idee is dat je al je business logica etc in C# kunt bouwen en kunt delen over de platformen. daarop bouw je dan een NATIVE user interface. uiteindelijk tijdens compilatie komt er ook een native app uit met native performance.

Daarnaast hebben ze een extra optie die Xamarin.Forms heet. dit is een oplossing waarmee je user native interface kan "genereren". dit kost je echter wel iets performance.
Xamarin Forms is er nu bijgekomen, met als doel ook de UI-code in 1 keer te programmeren.
echter is het nog niet zo goed, compatibility issues tussen versies van libraries (android appcompat v4), sommige UI-elements geven errors in editor (maar werken dan wel perfect in de compiled app)
persoonlijk hoop ik dan ook dat de ontwikkeling hiervan in een stroomversnelling komt nu microsoft het overgenomen heeft.
De basis van Xamarin was altijd al een centrale business logic deel en een los (native) deel om de UI mee te bouwen. Echter hebben ze sinds kort Xamarin.Forms waarmee je ook met een centrale codebase een interface kan bouwen. Dit is echter nog redelijk experimenteel en compatibiliteit laat nog te wensen over.

De Belastingdienst waar ik stage heb gelopen gebruikt deze technieken al volop in hun eigen apps.
Wow, gaaf. Ik volg Miguel de Icaza (de oprichter) al lange tijd, en dit is wel heel bijzonder! Deze man is de founder van Gnome, en heeft Mono gestart, de open source variant van .Net. Langzaam maar zeker is .Net nu ook zelf opensource aan 't worden, en is dit een mooie stap op weg naar cross platform .Net, ook op mobile.

Met Microsoft achter C# op Android en iOS is dit een stuk reëlere optie om aan te bieden aan klanten die crossplatform willen gaan met hun app. De vraag rest nog hoe betaalbaar het gaat worden.

[Reactie gewijzigd door - peter - op 24 februari 2016 23:10]

Miguel heeft echter het mono project eerder ook aan novell verkocht en dat is hem uiteindelijk niet goed bevallen waardoor hij uiteindelijk Xamarin heeft gestart. Ben benieuwd naar zijn nieuwe rol bij MS
Niet het mono project dat is open source. Ximian was gekocht. En nadat een reorganisatie bij Novell een hoop Ximian devs de kop kostte lagen de rechten van onder meer MonoTouch nog bij Novell/Attachmate. Miguel was daar toen echt ziek van. En ze hebben uiteindelijk de boel kunnen kopen en hebben dat ondergebracht in Xamarin. The rest is history ;)

Miguel is nogal een unieke dev met social skills, creatief (design), en technisch heeel sterk.
De .Net visie was ook "out of this world" in 2002 https://youtu.be/8dPlQJ5Vx1M. Ver vooruit dan de iPad in 2009 ;) V&D valt nu in 2016, straks bestellen we allemaal direct bij de fabrikant, custom made aka 3D printed
Ik ben wel fan van het .net ecosysteem en de helderheid + productiviteit van c# maar in het begin was c# gewoon een java alternatief die enkel op windows draaide.
Pas later werd het een serieuze cross-platform taal.
Ik vind het interessant. Maar Swift is inmiddels ook open source, en IBM lijkt dat nu te willen gebruiken voor Enterprise oplossingen. Ik denk dat de combinatie Apple/IBM niet zomaar even weggecijferd moet worden. Dus ik heb werkelijk geen idee hoe het software development landschap er over een jaar of 5 uit gaat zien.

Miguel is een baas! Die is lang geleden (1997) al eens gevraagd om Internet Explorer te porten.

[Reactie gewijzigd door OMX2000 op 24 februari 2016 23:15]

hopenlijk wordt xamarin gratis voor developers het kost op dit moment nog teveel om mee te experimenteren
Inderdaad. Xamarin is echt helemaal geweldig, maar het is simpelweg te duur voor de zzp'er.
Nouja, helemaal geweldig...
Ik hoor graag je mindere ervaringen met Xamarin, zou je die in een dm kunnen sturen?
Waarom DM? Ik heb zelf beperkte ervaring met Xamarin maar het is vooral dat alles mooier klinkt dan het in de praktijk is. De tools zijn beperkter dan de native tools van Android en iOS. Het programmeren in C# is een voordeel, maar je moet toch echt app-developer (Android en/of iOS) zijn om Xamarin te kunnen gebruiken omdat de native APIs worden gebruikt, en je dus de 'flow' van het framework op het target platform goed moet doorgronden. Xamarin Forms is nog niet geschikt om alles in te maken dus dan moet je alsnog de hele UI twee keer programmeren, en sommige features van de C# taal zijn niet bruikbaar in PCL (shared code).
Ik heb het wel gebruikt maar de kosten voor de licentie direct bij de klant neergelegd.
Dat is natuurlijk een optie, maar als je een eigen app in ontwikelling hebt die niet aan de eisen van de gratis versie voldoet moet je flink diep in de buidel tasten. En als je een opdrachtgever probeert te overtuigen van Xamarin vanwege het gemak dan helpen de hoge kosten niet heel erg.
Lijkt mij vooral interessant voor cross-platform. En als het goed is bespaar je dan op ontwikkelkosten. Als dat namelijk niet zo, kan je dus net zo goed gewoon native ontwikkelen. Dus het is alleen commercieel interessant als je het aan uren terugverdient.
En het is ook niet zo handig voor de continuïteit mocht men een andere ontwikkelaar willen later, of meer mensen toevoegen aan een team. Omdat het duur en obscuur was, raadde ik dat mensen niet aan. Terwijl C# natuurlijk heel prettig werken is.
Mijn productiviteit in .net is veel hoger dan in java op android. Terwijl ik in java meer ervaring heb. Android is een heel lelijk ontwikkelplatform en gedraagd zich regelmatig onverwachts.
Had al wat ervaring met Xamarin maar heb 8 maanden geleden de (financiële)gok genomen en heb alle business licenties en Xamarin university aangeschaft. Na 3 maanden en veel experimenteren/bouwen op zoek gegaan naar een klus met Xamarin. Die heb ik vrij vlot gekregen en wordt momenteel gemiddeld 2 keer per week benaderd wanneer ik weer beschikbaar kom. Tarieven heel wat beter dan wat ik verder voorbij zie komen aan C#/ASP.NET/PHP/Java etc.
Kost gaat voor de baat in dit geval.
Qua techniek: de integratie Xamarin/VS2015 kan beter zeker als je ook vanuit VS met de Mac build hosts wil werken. Eerlijk gezegd zijn we allemaal overgestapt op MacBook Pro/Mac Pro (met Windows in VMWare) en Xamarin Studio op beide platforms. Kijken nu naar vervangen TFS door GIT. UWP is de reden dat VS nog relevant is in dit verband.
Of deze fusie iets toe gaat voegen qua waarde: geen idee. Grote/relevante klanten gebruiken al Xamarin. Persoonlijk hoop ik eerder dat het clubs als DevExpress over de lijn trekt om meer componenten te maken voor dit platform.
Goed dat je dit deelt, leuk om te horen.

Ik zit er al tijden likkebaardend naar te kijken idd, ook om een aantal oude windows 6 mobile apps te porten naar o.a. ios die ik op dat platform opnieuw kan verkopen.
TFS kan ook git repo's hosten.
Weten we cq zitten we naar te kijken en/of het de voordelen biedt die we zoeken.
Deze overname zat er aan te komen.

Ik ben wel benieuwd wat er nu met Mono gaat gebeuren (full .Net CLR op Linux). Blijft de focus zwaar op .Net Core liggen of zal Mono ook doorontwikkeld worden?

Xamarin is verder een leuk idee. Al vind ik het jammer dat je per se een Mac ernaast nodig hebt om iets voor ios te ontwikkelen.

Ik hoop ook dat de prijzen nu lager zullen worden.

Miguel de Icaza zal wel blij zijn. Die heeft vaker in zijn leven bij Microsoft gesolliciteerd, is nooit aangenomen en nu wordt zijn bedrijf voor een hoop geld overgenomen door ze :)

That's one happy Mexican :D

[Reactie gewijzigd door Lethalis op 25 februari 2016 07:38]

Xamarin is verder een leuk idee. Al vind ik het jammer dat je per se een Mac ernaast nodig hebt om iets voor ios te ontwikkelen.
Dat ligt niet aan Xamarin, dat is een eis van Apple.
Ik heb die vraag namelijk gesteld bij een Xamarin seminar.
Wat betreft die Mac die nodig is: je kunt ook een Mac in de cloud huren (kan volgens mij zelfs op pay-what-you-use basis), bv. op http://www.macincloud.com/. Kost niet zoveel. Maar je hebt gelijk, het is een lamme restrictie van Apple die niet nodig had hoeven zijn.
Super! Met de power van Microsoft achter deze kleine onderneming wordt het een betrouwbare partner voor de lange termijn. Ik ben benieuwd of het instapmodel ook wat scherper geprijsd gaat worden, maar dat lijkt me wel...met Visual Studio integratie wordt dit een hele mooi dev tool!
Ik ben een Microsoft- en Apple ontwikkelaar en ik hoopte al heel lang dat dit ging gebeuren. Op dit moment krijg ik alle Microsoft software voor mijn startup gratis via BizSpark / MSDN. Ongetwijfeld gaat dit ook gebeuren met Xamarin. Op dat moment is de investeringsdrempel om het te gaan gebruiken veel lager en kiezen heel veel teams zelfs als ze initieel alleen een iOS of Android app gaan maken voor een Xamarin based business laag, omdat dat het porten later veel makkelijker maakt en mensen nou eenmaal liever in C# werken dan in de oubollige Java versie voor Android of Objective-C (Swift is wel cool maar voor risico-ontwijkende bedrijven nog geen alternatief).
Nice! Hopelijk betere integratie in VS en een aantrekkelijker(startup) verdienmodel.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True