The Eric Wroolie Blog

Overpass Experiences

Android for the Visual Studio C# developer

by Leave a Comment

Last year, I started looking into learning Android development.  I’m a C# developer who spends most of his time in Visual Studio, so I had some trouble getting accustomed to it.  I’ve looked at a lot of ways to ease the transition into Android.  Here are some of my thoughts:

Mono For Android or Proper Android Java

After struggling with Eclipse, I started looking into Mono for Android.  I’m a C# developer, and I have to say that I felt a lot more at home in Visual Studio. I’ve also done very little Java development over the years.  I took a week-long course in 1999—but mostly don’t use it.

I found Mono For Android to be decent, but it’s not easy.  You still have to have learn how to use intents and activities and use the xml layouts that are expected.  I found myself trying to learn the Android architecture and how the Mono libraries work with it.

Here are my problems with Mono for Android:

1.  There is far less documentation than you would need.  If you get in a bind, not many people would be able to help you.

2.  It’s like learning VB.Net instead of C#.  At some point, you have to take the hit and relearn a few things.  Almost all of the example code you look at will be in Java.

3.  I can’t be 100% that it will perform well enough on the device.  There could be a performance hit.  And you need to include the mono runtime, so it would bloat the size of your apk.

4.  It costs $400.  This is fine if I’m asked to create an app by the end of the week by an employer.  But when learning for fun, it’s too high a price to pay.  Besides, compared to “free”, it’s too expensive.

So, I prefer to native.

PhoneGap

I did a lot of stuff with PhoneGap too.  I love coding in javascript and there is so much that can be done with HTML5.  I was able to quickly code a little app that fed off data from Toodledo.  For cross platform, I think this is ideal.  But if I want to take full advantage of the Android platform, I would need to do native.

Eclipse or IntelliJ IDEA

So, I struggled with Eclipse.  Even things like autocomplete were throwing me because I was hitting TAB instead of ENTER to accept the autocomplete suggestions.  It was messing me up.  When I went back to Visual Studio, it was messing that up too.  I hate having my flow upset like that.

The majority of tutorials for Android development are using Eclipse.  All of the Android tools are well integrated into it.

However, JetBrains has a Java IDE called IntelliJ Idea which is soooo much better for a Visual Studio user than Eclipse is.  Jetbrains also develop Resharper, so their shortcuts are very similar.  There is a community edition (free) available here.  I highly recommend it for Visual Studio developers moving to Android.

The only downside I see with IntelliJ Idea is that some tools like DDMS viewer are not integrated into the IDE.  To use them, you have to go to the tools folder of your Android sdk folder and start them manually.  But everything is there.

Windows Phone 7

I did some WP7 work last year.  It’s a nice platform and I loved writing code for it.  But the market share is too small.  I know one person who has a Windows phone.  I upgraded my phone this weekend, I looked at the Lumia—but went with the Galaxy S3.  Maybe one day Microsoft will advance in the phone arena, but I have sincere doubts. 

I love coding for WP7

by Leave a Comment

So, I’ve spent ages trying to learn to code on an Android.  I’ve read a few books.  I’ve got my dev environment all set up.  I’ve coded a few test apps and put them on my phone.  But the going is slow.  If I were a Java developer, I’d probably be all over it.

A friend asked me to do a quick Windows Phone 7 app and I could not believe how easy it was.  Since I’ve been working heavily with Silverlight for the past few years, I know most of the code already.  I had to do minimal reading to get a full app up and running.  It was was nice to work in Visual Studio again.  Using Resharper, I was flying through the code.

I only wish more people had Windows Phone 7. 

I would get a phone myself, but 3 things are holding me back currently:

  1. I don’t want to be one of 5 people in the UK with a Windows Phone 7.
  2. It’s not open, like Android is.  I would be at the mercy of the phone manufacturers for upgrades (like with an iPhone).
  3. It doesn’t have expandable memory (to my knowledge).
  4. My current contract isn’t up until April.

But it’s nice to be able to write apps so quickly (since I spent so much time learning the trivial details of Silverlight).  Maybe.

The “View Source” belongs to me too.

by Leave a Comment

For me, the sign of a good web developer (or web application developer) is someone who can right-click a web page to view the source and tell you why he did things the way he did.  “I used this div to position this element over here, and used the unordered list for a sub-menu, . . . “

A bad web developer is someone who says “It looks fine in my browser” and “Well, I’m not a designer . . . “

One of the biggest crimes of ASP.net Web Forms was to strip HTML skills from new web developers.  They view the source of their code (in the browser—not Visual Studio) as gobbledy-gook.  And ASP.net ensures that it is.  It’s full of ViewState and control names like ctl_100_className_ctrlName which the developer didn’t put there.  It tried to remove the whole stateless-http challenges and make web development accessible to desktop developers.

I’m so very pleased every time I see a new site created with the Microsoft MVC Framework.  MVC is making up for the ASP.Net webform crimes.  Just like Ruby  on Rails or PHP (or classic ASP), it allows the developer to think about what gets sent from the web server to the browser.  When I do a site in MVC framework, I can view the source and recognize my own handy-work.  I can make full use of CSS3 and jQuery.  I know that everything in my user’s browser is something I put there intentionally.

CSS, Javascript, and HTML (along with images, flash movies, Silverlight, or other plugins) are the ingredients of any web application.  Server languages like ASP, PHP, and Ruby are only tools to deliver these ingredients to the browser in unique and creative ways.  A good web application developer (like a good chef) can look at his source and tell you exactly what everything does.  ASP.Net webforms are like ready-meals.  Everything is done for you, but you don’t really know everything that’s in it.

Now, don’t get me wrong, I’ve known some fantastic ASP.Net devs who build apps free of ViewState and server controls.  But I’ve worked with too many who could drag a control onto a web canvas, set a few properties, and call themselves web developers.

I recently worked on a DotNetNuke project where we customised a third-party component.  The page was not rendering as it should.  ViewSource gave me a bunch of ViewState and nested tables.   I knew of a 100 ways to get css to make the site look the way I wanted, but this wasn’t my source.  It wasn’t even the developer’s source—it was the clientIds of the server control.  Since I was struggling, a web guy (proper Mac-using, firebug-toting, standards-compliant, web guy) asked to see the source so he could suggest something.  When he saw the source, he was mortified.  I was embarrassed –“It’s not mine!  I didn’t write it.”  In the end, I hacked it with jQuery.  I didn’t have the sourcecode to modify it properly. 

The legacy of Web Forms lives on.  Sharepoint 2010 is full of it.  Young Microsoft developers (in the last 5 years or so) know nothing but how to use WebForms.  (An ASP.net dev told me a few years ago “But I don’t know html.”).  But, hopefully, one day we will get around this idea of creating tools that “do everything for you” for developers who should know to do it themselves.  Just like I wouldn’t create ready meals for people who call themselves chefs.