Info om tjänsten finns här: http://www.itmaskinen.se/nyheter/en-erfaren-android-utvecklare-sokes/

Xamarin har jobbat på ett projekt att ersätta Dalvik som är den java-baserat virtuella motorn i Android med Monos .NET
Det här öppnar prestanda ökningar för oss dotnet utvecklare som vill ge oss på Android plattformen.

http://blog.xamarin.com/2012/05/01/android-in-c-sharp/

http://www.idg.se/2.1085/1.446606/microsofts-sprak-kan-radda-google-vid-forlust-i-patentrattegang 

I onsdags deltog jag vid ett seminarium om välfärdsteknologi i riksdagen.

Seminariet gav olika perspektiv på hur den offentliga sektorn kan dra nytta av modern teknik.

En av talarna var Marie Andersson, lärare på Gotland, som berättade om hur hon använder Internet som en del av undervisningen.

Seminariet arrangerades av IT&Telekomföretagen, Sveriges Kommuner och Landsting, Christer Winbäck (fp) och Monica Green (s).

Här kan du kolla in webbplatsen Välfärdsteknologi, som ger flera praktiska exempel på hur IT kan användas i välfärden.

Vill slå ett slag för programmet Pencil som är ett gratis mockup-program (GPL-licens med möjlighet att donera till utvecklarna om man vill) . Programmet kan köras som vanlig stand-alone på linux och windows, eller som en addin till firefox.

När du varit ute hos kund och fått en massa input och snabbt måste ta fram ett underlag på program, gränssnitt, programflöde osv så är detta perfekt!

Visst, man kan skapa ett formulär i visual studio och börja koda en prototyp, men problemet med det är att man ofta lägger in för mycket tid och funktionalitet i prototypen och helt plötsligt så har den fått ett eget liv och i slutändan så sitter man och kodar produktionskod i prototypen. Och då är det inte lätt att kasta bort den och börja koda från början. Nackdelen med det är att man fortsätter koda på något som från början inte var meningen att vara något annat än en prototyp.

Ett annat problem med prototyper skrivna direkt i programmeringsverktyget är att kunden måste installera programmet för att se det. Du kan inte lätt skicka prototypen till 100 personer och få dessa förstå vad som ska göras (installeras, kanske avinstallera föregående prototyp osv), dessutom kanske inte alla 100 personerna har rätt att installera programvara på sin dator, många företag har nedlåsta miljöer i verkstäder, kassor osv.

Man kan gå andra vägen och göra bilder i photoshop och skicka ut, men dessa bilder förklarar bäst gränssnittet, inte programflöde m.m.

Därför är detta mockup-program riktigt bra. Du kan göra dina mockup-bilder, länka knappar m.m. till andra bilder. Snabbt göra om, modifiera osv utan att ens riskera att fastna i att överprogrammera en prototyp.

I programmet så finns det en massa färdiga GUI-kontroller (fler finns att ladda ner) som bara är att dra ut och börja använda för att skapa ditt mockup:

Väljer man t.ex. en datalista så populeras den automatiskt med demodata. Men man kan lätt ändra det mesta:

Det går att ladda ner nya kollektioner av kontroller och shapes och det finns olika export-templates att ladda ner också. En av dessa är riktigt bra, templaten heter GUI Prototyping 800x580. Om man laddar ner den och installerar den via Tools / Manage Export Template… så får man en möjlighet att välja den templaten när man exporterar till “Single web page”:

När man väljer det så skapas en mokup-html-sida där man kan testa programflödet enligt mockupen. Den kan man sedan ladda upp på webben och skicka en länk till alla som ska få komma med kommentarer på förslaget. Jag har modifierat min template så den passar mig, vilket är en trevlig möjlighet.

Här är ett exempel på mockup jag gjort: http://develop.itmaskinen.se/stefandev/gui/index.html

Så sluta göra prototyper! Gör mockuper istället! Din säljare, eller till och med din chef kan göra det efter ett kundbesök och sen lämna över den till dig för förfining!

Over and out!

/Stefan.

Onsdagen den 19 oktober håller ITM Mobile ett kostnadsfritt frukostseminarium om mobila lösningar - och du är välkommen!

Klicka här för att läsa mer.

Ibland så måste man felsöka i program. felsöker man i Visual Studio på sin utvecklingsdator så kör man oftast med breakpoints i kombination med att man skriver ut debuggdata till output-fönstret. Jag har sett att loggning ute hos kund är en sån sak som de flesta programmerare bygger egna lösningar för, loggning mot fil, Eventlog osv som står och fyller upp loggar 99% till ingen nytta, även om man ser flertalet som i alla fall lägger in flaggor för om det ska vara på eller avslaget.

Något vi använder oss av i stort sett dagligen (i alla fall jag) är Debug.Print() vilket skriver ut debugdata till Outputfönstret (eller motsvarande konfigurerbar eventlyssnare) i Visual Studio.

Låt oss säga att vi har ett program där man har en knapp och en listbox:

På olika ställen i programkoden så lägger vi in debug.print () som talar om vad som sker:

När vi kör programmet och klickar på knappen så får vi i Output-fönstret se att allt går rätt till:

DebugView

Om du har problem på en kunddator så vill du inte installera hela visual studio för att få fram den här informationen och det behöver du inte heller, ladda bara ner programmet DebugView från Sysinternals så hookar den in och lyssnar på debug-event från alla applikationer.

På det sättet kan du köra programmet live hos kund och ändå se debug-datat, självklart så krävs det att du har en version av programmet som är kompilerat i Debug-mode. Kunden kör ju antagligen applikationen i Release-mode så du får se till att kompilera programmet i debugmode och ta med och köra på targetmaskinen.

Ovanstående debuggdata ser ut så här när jag kör programmet på samma sätt med Debugview:

Man kan välja att logga till fil, vilket är väldigt smidigt om man vill logga programmet under en hel dag medan kunden använder det. Man kan även logga via nätverket, så du kan köra DebugView på en klient och sen starta DebugView på en server och connecta till klienten och få upp debuggdatat där. Du kan skapa include och exclude-filter som highlightar vissa meddelanden eller filtrerar bort vissa meddelanden osv.

Detta är ett mycket värdefullt program när man vill samla debuggdata ute hos kund.

Men Releasemode då???

Av prestandaskäl så tas alla debug.print-anrop bort när man kompilerar programmet i releasemode. Vill man ändå kunna få sådan information via DebugView när man har programmet i releasemode så är det bara att ändra debug.Print() till Trace.WriteLine(), då kommer du att få dessa meddelanden oavsett om det är i debug eller releaseläge på programmet.

Av prestandaskäl kan det vara bra att inte peppra programmet med tusentals Trace.WriteLine, men har man problem med ett program så kan det verkligen vara värt att lägga in dessa rader på ställen man misstänker att det finns problem.

Det är ju smidigt att bara starta DebugView, köra programmet och i DebugView få ut interna data som programmet använder sig av för att se varför man får t.ex. diffar eller error.

Over and out / Stefan

I dag har tre nyhetstexter lagts upp på itmaskinen.se: 

• Välkommen till oss på frukostseminarium om mobil appar! 

• MINT - ett mobilt CMS-verktyg

• Vår kund Mekonomen – ett multinationellt företag
  

I går deltog ITM Mobile vid Stockholm Summit on Service Innovation in Cities på Kistamässan. Det var ett bra event!

Här finns information:

http://www.amiando.com/livinglabsglobalstockholm.html

Satt precis med ett litet projekt där jag laborerade med data från en GPS-puck. Datat skickade jag till en listbox för att se vad som kom från GPS-pucken:

Jag ville kunna spara datat till en fil och började då, precis som jag gjort 1000-tals gånger tidigare, att göra en loop som loopade igenom alla items i listboxen för att skriva ner datat till en fil. Det går självklart att göra på massor av olika sätt, nedan är de två vanligaste.

Men så kom jag och tänka på LINQ.
Det borde gå att göra ett LINQ-fråga som skapar en array av listitems som gör att jag kan skriva ner allt till en fil med endast en rad kod. Genom att använda IO.File.WriteAllLines som tar en array av strängar och skapa en LINQ-fråga som returnerar en array av strängar från listboxens items så borde det alltså fungera, jag provade med nedanstående kod:

Vilket fungerade hur bra som helst! Men LINQ-frågan går att korta ner, “Select p” är vedertaget i LINQ-frågan så man behöver inte ange det, vilket gör att vi kan korta ner raden till detta:

Slutsats

LINQ är häftigt, det är rent ut sagt sexigt! Men tänk på att det ibland kan vara svårt att förstå LINQ-kod, så även om den gör koden kompaktare så kan den även göra koden svårare att läsa i vissa fall, samt att man får tänka på LINQs “late evaluation”-teknik som kan ställa till det i andra sammanhang. Men i det här sammanhanget så tycker jag att LINQ gör koden mer lättläst och tar bort onödiga rader kod.

Det finns ett talesätt: Varje rad kod du INTE skriver är en rad du inte kan få en bugg i.

Over and out / Stefan