Solving development problems  |  About this blog

Intro
We like the taste of MVC in ASP .NET and have some practical experiences in coding Java applets, J2ME and Silverlight applications.

Lately our team decided to build a simple application for Android phone to try the platform. Story begins with an idea and motivation, installing and setting Eclipse + Android SDK, and like always, a sketch, todo list, etc.

Issues

• For each property in layout xml the “android:” namespace is needed. Of course it can be replace with “a” but it still annoying to write it every time. Example <LinearLayout android:id=”@+id/pnlSomething” />   There is more advanced graphical xml standard – SVG
• oops, I tried (miss-clicked) to run android as classic Java application but it returns an error (like build error),
  next time I try running as android application this error wont go away even if the code is fine
  solution: delete error from the error list and it should work fine
• sometimes I run a debug and don’t notice the tiny icon in the far right bottom corner of eclipse
  that shows the application is launching and it’s stuck… and I try to launch it again, and again
  and applications are trying to launch parallel… solution: close eclipse and start again
• connection refused on localhost? is this a joke? is only google.com allowed?
  firefox opens it normally, firewall is off, same on IIS and apache, permissions are set in manifest.xml
  reason: ‘localhost’ means the internal loopback of device (emulator) not the PC,
  solution: use your LAN IP
  //solution: edit hosts and set something like 127.0.0.1   pc-localhost //does not work
  http://groups.google.com/group/android-developers/browse_thread/thread/801645febf0523ea/9e779925e9570828
• when a crash occurs it is just a crash, without detailed message or tip, developer should guess the error
  * and, BTW, emulator shows wrong time on windows (7:04 PM while the real time is 21:04 on GMT+1 timezone
  or 5:07 PM when the time is 19:07)
• Record breaker among IDEs: 1.131 GB of RAM taken by Eclipse
• A lot of features: social media, web, google maps, sqlite, bluetooth,
• gestures, camera, speech recognition, 3D, processing…
• s it easy to learn? theory yes, it is logical and quite simple, well documented;
  but dealing with basic practical issues is a pain

What really annoys us is that when we write layout in xml and we are confidant with it schema is right, works in theory, draws a preview but just don’t work in emulator Eclipse won’t tell what is the problem it just says “Source Not Found.”

Comparison: C# vs Java

A good programming language uses less code and effort to complete a task. What makes Silverlight (C#) coding easier and Android (Java) coding harder? Advantages of C# over Java or what is missing in Java:

• lambda expression and Linq make handling data, arrays, xml easy
• properties
• partial types when dealing with large files
• preprocessor directives (#if, #region) to bring visual focus on the particular part of code that is being developed and hide the other code
• verbatim string, like @”C:\Program Files\android\sdk.exe” without escape characters
• nullable types, like int? that can be -n…0, 1, 2…n or null
• ‘yield’ keyword
• ‘??’ operator
• enumerations that are avoided in Android (Android uses constants, requires documentation to locate a constant)

* comparing to Silverlight you need to write more code in a more complex way for same features (ie. async, binding,
db, events)

Use HttpContext.Current.Request instead of Request

i.e.

HttpContext.Current.Request.UserHostAddress

not

Request.UserHostAddress

Comparison: ASP .NET WebForms vs MVC

We had some problems with subdirectories under our root website.

We wanted to add different examples under our website root (organized into folders) like this:

• www.our-website.com/example1
• www.our-website.com/example2
• …

And we always got these errors.

At root of our website www.our-website.com we didn’t have any web.config and we didn’t want any. Every subfolder has its own web.config and it didn’t worked under IIS7

Solution:

Click on each folder under IIS and then right mouse click Convert To Application and it worked.

We found these guides here at WebDesignerDepot.com:

1. Stay Organized

Just like anything else, it pays to keep yourself organized. Rather than haphazardly dropping in id’s and classes in the order in which they come to mind, use a coherent structure.

It will help you keep the cascading part of CSS in mind and sets your style sheet up to take advantage of style inheritance.

Declare your most generic items first, then the not-so-generic and so on. This lets your CSS properly inherit attributes and makes it much easier for you to override a specific style when you need to. You’ll be faster at editing your CSS later because it will follow an easy to read, logical structure.

Use a structure that works best for you while keeping future edits and other developers in mind.

• Resets and overrides
• Links and type
• Main layout
• Secondary layout structures
• Form elements
• Miscellaneous

2. Title, Date and Sign

Let others know who wrote your CSS, when it was written and who to contact if they have questions about it. This is especially useful when designing templates or themes.

Wait a minute… what’s that bit about swatch colors? Over the years, I’ve found that adding a simple list of common colors used in my style sheets is extremely helpful during initial development and when making edits later on.

This saves you from having to open up Photoshop to sample a color from the design, or look up colors in the site’s style guide (if it has one). When you need the HTML code for that specific blue, just scroll up and copy it.

3. Keep a Template Library

Once you’ve settled on a structure to use, strip out everything that isn’t generic and save the file as a CSS template for later use.

You can save multiple versions for multiple uses: a two-column layout, a blog layout, print, mobile and so on. Coda (the editor for OSX) has an awesome Clips feature that lets you do this easily. Many other editors have a similar feature, but even a simple batch of text files will work nicely.

It’s insane to re-write each and every one of your style sheets from scratch, especially when you’re using the same conventions and methodologies in each.

4. Use Useful Naming Conventions

You’ll notice above where I declared a couple of column id’s and I called them col-alpha and col-beta. Why not just call them col-left and col-right? Think of future edits, always.

Next year you may need to redesign your site and move that left column to the right. You shouldn’t have to rename the element in your HTML and rename the id in your style sheet just to change its position.

Sure, you could just reposition that left column to the right and keep the id as #col-left, but how confusing is that? If the id says left, one should expect that it will always be on the left. This doesn’t leave you much room to move things around later on.

One of the major advantages of CSS is the ability to separate styles from content. You can totally redesign your site by just modifying the CSS without ever touching the HTML. So don’t muck up your CSS by using limiting names. Use more versatile naming conventions and stay consistent.

Leave position or style specific words out of your styles and id’s. A class of .link-blue will either make more work for you, or make your style sheet really messy when your client later asks you to change those blue links to orange.

Name your elements based on what they are, not what they look like. For example, .comment-blue is much less versatile than .comment-beta, and .post-largefont is more limiting than .post-title.

5. Hyphens Instead of Underscores

Older browsers like to get glitchy with underscores in CSS, or don’t support them at all. For better backward compatibility, get into the habit of using hyphens instead. Use #col-alpha rather than #col_alpha.

6. Don’t Repeat Yourself

Re-use attributes whenever possible by grouping elements instead of declaring the styles again. If your h1 and h2 elements both use the same font size, color and margins, group them using a comma.

This:

You should also make use of shortcuts whenever possible. Always be on the lookout for opportunities to group elements and use declaration shortcuts.

You can accomplish all of this:

with only this:

It’s very important that you understand the order in which CSS interprets these shortcuts: top, right, bottom, left. A big clockwise circle, starting at noon.

Also, if your top and bottom, or left and right attributes are the same, you only need to use two:

This sets the top and bottom margins to 1em, and the left and right margins to 0.

7. Optimize for Lightweight Style Sheets

Using the above tips, you can really cut down the size of your style sheets. Smaller loads faster, and smaller is easier to maintain and update.

Cut out what you don’t need and consolidate wherever possible by grouping. Use caution when using canned CSS frameworks as well. You’re likely to inherit lots of bulk that won’t be used.

Another quick tip for slim CSS: you don’t need to specify a unit of measure when using zero. If a margin is set to 0, you don’t need to say 0px or 0em. Zero is zero regardless of the unit of measure, and CSS understands this.

8. Write Your Base for Gecko, Then Tweak for Webkit and IE

Save yourself troubleshooting headaches and write CSS first for Gecko browsers (Firefox, Mozilla, Netscape, Flock, Camino). If your CSS works properly with Gecko, it’s much more likely to be problem free in Webkit (Safari, Chrome) and Internet Explorer.

9. Validate

Make use of W3C’s free CSS validator. If you’re stuck and your layout isn’t doing what you want it to do, the CSS validator will be a big help in pointing out errors.

10. Keep a tidy house

Separate browser-specific CSS to its own individual style sheet, and include as needed with Javascript, server-side code or conditional comments. Use this method to avoid dirty CSS hacks in your main style sheets. This will keep your base CSS clean and manageable.