On Modularity and Separation of Concern

On Modularity and Separation of Concern

This is a hastily written diatribe that was prompted out of frustration.  It’s mainly focused on Java web application development but applies to all software development.

Modularity

Ability to swap, exclude chunks of functionality or features without any effect on remaining architecture or application.  Each module is independent of each other. Shared resources can exist between modules in separate jars

PROS:

  1. Allows full flexibility for custom builds.  Depending on customer some features can be included while others excluded
  2. New features can be added regardless of rest of the application
  3. Easier maintenance.  Problematic section can turned off, replaced without effecting rest of application.
  4. Vendors and technology changes can be done on limited basis

Separation of Concern

Every area is responsible solely for the area to which it is assigned.  This concept starts at the macro level and works it way down to the micro influencing the full gamut.  At the macro level, there are very distinct layers, each with it’s own concern.  The start of this is the tried and true MVC design pattern.  These layers still fit into the traditional three-tiered system with some more fine graining distinction.

Layers:

  • Model- objects that the view act upon
  • View or Presentation- the visual interface that the users see
  • Controller- Responds from views and provides data to view
  • Business layer- Provides all business functionality
  • Data Access- Intermediary between DB and the rest of application
  • Data Storage- Stores the data for efficient recall

On the micro level this concept affects every web page, and every java class, and every DB table.  This greatly increases coded reuse, saves developer time, and reduces bugs.

  • JSP (or an alternative) should not have any business logic inside.  Its only area of concern is to provide a view to be displayed
  • HTML should not be concerned with layout, style, or interactions.  It area of concern should be solely for structuring data.
  • CSS should handle page layout and style
  • JavaScript is responsible for event handling on the client side.  JavaScript should be separated out of the code and included either in separate files or at the beginning or end of files.  No inline onclicks, etc.
  • Java classes should represent a single object, or series of related procedures.  Name should reflect its purpose
  • Java methods should be kept very short, each responsible for a single thing.  Meaning that there will many small methods each responsible in place of long unwieldy methods that are difficult to maintain and difficult to extract or overwrite.  Concept of least surprise.  Methods should not effect areas outside of its stated purpose in the method name.
  • Database tables should be normalized with each table representing a single thing.  This keeps table size down, makes queries faster and more understandable and prevents data repetition providing more reliable data.

PROS:

  • Easier to understand, Less complexity
  • Better code reuse
  • Less bugs
  • More efficient
  • Different team members can work in different areas.

Why people write open-source code? The license is a great clue

Why ask why?

There seems to be some common misperception and lack of understanding about open-source code.  People in different positions of company tend to say things they don’t really understand.

–CEO’s think it might equal altruism

“We contribute to open-source projects…”

– Business staff people tend to think of it as a neat internet era shortcut to save costs.

“Just use open source…”

– Marketing people think customers will like to hear it since it sounds kindof trendy and probably means we are cutting-edge

“We use open source code in our code…”

– Programmers that have never used it before but would like to think it will solve all their problems for them

Boss: “We need this flux-capacitor algorithm ready right away!”  Programmer: “No problem, boss, I’ll just use open source :)”

Now all of these can be correct in certain scenarios, but not necessarily.

Not all open-source is the same

Duh, right? But this might be the too basic key that some people seem to miss.  Not all open-source code is the same!  There are many reasons why people would write code and provide the source, not always is it pure altruism, and not always is really open-source.  The first and best clue is usually the license that the code is released under.  Just because you can see it, does not make it free!

Why code might be open-source?

What is open-source code?  Any number of things.

Reason Typical License
Marketing On contract
Teaser LGPL, MIT, Apache, GPL
Hook-in MIT, Apache
Altruism or Rebellion GPL, BSD, MIT, None
Résumé BSD, MIT, GPL, Apache
And many other possible reasons.

Marketing

What is it?

Open-source could be used as marketing technique by some companies.  If a company would like to sell expensive customized software, some customers demand that be given access to the source code.  Perhaps they are planning to hire some in-house staff to do maintenance to lower costs, or perhaps they want to hire consultants to determine if it’s looks like quality code.

Who benefits?

Companies can reel in new customers and lower their initial fears by giving them full behind the scenes access to the software

What license restrictions would their typically be?

Typically the company selling the software would have a non-disclosure agreement.  They will let you view the source code, but never let you share it or discuss it with anyone else.

Examples?

Many large business-to-business software firms

Teaser

What is it?

This is essentially the same as shareware.  A company will grant access to the source code allow you to use it in your demo project, but if you want to use in production then you’ll need to pay the licensing fees.

Who Benefits?

User benefits are simple- by not needing to write all the code from scratch you can save a lot of time.  Company benefits by selling you licenses, upgrades.

Examples?

Sencha- Solid JavaScript library.  Personal and demo use is free.  Production use will cost you money.

Hook-in

This is probably the most common form of open-source that you will see out there.

What is it?

Free software, that you can use as part of your project.

Who Benefits?

Here again, user benefits are simple- by not needing to write all the code from scratch you can save a lot of time.  The authors can benefits in a variety of ways.  Either by selling you documentation providing training, consulting, selling you maintenance, or selling you customized requests.  Also, these tend to be the most used and organic code.  The more users the more bug fixes, the more users the more opportunity for business.

What license restrictions would their typically be?

The licensing here tends to be pretty permissive.  Meaning you can usually use it and sell it as part of your product with paying a dime.  But you generally need to include somewhere a copy of the license that basically admits who the real author is.  No taking all the credit for yourselves.

Examples?

SpringSource- Awesome, de facto standard for Java frameworks.  Completely free, documentation rocks.  They make money by training you to use it, providing consulting, and selling books.

JasperReports- Its really solid, and they let you use it for free! But documentation is pretty non-existent without paying money.  So good luck without it.

PrimeFaces- Best looking JSP component library with huge feature set.  They tried to make money by selling documentation.  Now they will sell you consulting, customization, or outsourcing.

jQuery- Legendary JavaScript library. So good, companies offered sponsorship so they can continue their work.

Altruism or Rebellion

What is it?

Software written by motivated people that want to make a difference.  Either to create good in the world, or to rebel against corporate greed by providing a free alternative.  This is probably what most people think of when they think open-source.  Software written by free spirited people that don’t wear shoes.

Who Benefits?

Anyone who has a need for that software.  Authors typically don’t benefit at all financially, but their legacy, reputation, etc lives on.  Frequently friendships and communities can prosper around the software.

What license restrictions would their typically be?

All changes you make to the software, whether new features or bug fixes have to returned to the communit,y no hogging it to all for yourself.  It’s usually the take freely, give freely approach.  Although sometimes there wont be a license at all.

Examples?

Linux- Enough said.

Résumé

What is it?

This one is also pretty common out there.  Usually written by an individual with some free time on his hands.  Software provided free to use and to change.  No ulterior motives.

Who Benefits?

Anyone who has a need for that software.  Author benefits by getting their name out there.  Job seekers can show proof of capabilities.

What license restrictions would their typically be?

Usually just limitation that the author reserves the right to be identified as the author.

Examples?

Backbone- JavaScript MVC framework. Ok not sure about this one.

Conclusion

Open-source software is a broad term with many motivations behind it- frequently even if the initial reason for releasing it publicly were one thing, it often changes when the software becomes popular.

Convert Java SimpleDateFormat to jQueryUI datepicker formatDate and parseDate

Using Java’s SimpleDateFormat for jQueryUI datepicker

In my current assignment I am working on a legacy Java JSP application.  I wanted to use the nice jQueryUI datepicker for form elements that are dates.  Unfortunately the formatDate and parseDate options for jQueryUI datepicker seems to be pretty homegrown as far as I can tell (correct me if I am wrong).  We support configurable date formats, so I don’t know at compile/design time what the format is.  What to do?

Conversion method

After doing some Googling for answers it seemed not many people had this need.  But I did find a stand-alone date formatter that understood Java’s SimpleDateFormat.  This was more than I needed since jQueryUI datepicker already provided that code, and I just wanted to shove in the format string as an option.  So with much thanks to this post by Laurent Picquet I extended it to meet my needs.  The code I wrote is far from from beautiful but it doesn’t appear that JavaScript’s regexp supports if-else clauses.

	/* This method is neccessary to close the gap between Java's SimpleDateFormat and jQuery UI datepicker formatDate methods.
	   Takes the SimpleDateFormat string from the server and turns it into the expected jQueryUI formatDate.
	   Note: the jQueryUI formatDate only supports some of SimpleDateFormat settings.  Basically only Years, months, days, day of week */
	function convertToJquiDateFormat(localFormatString){

		//Year
		if(localFormatString.search(/y{3,}/g) >=0){                 /* YYYY */
			localFormatString = localFormatString.replace(/y{3,}/g,     "yy");
		}else if(localFormatString.search(/y{2}/g) >=0){            /* YY   */
			localFormatString = localFormatString.replace(/y{2}/g,      "y");
		}

		//Month
		if(localFormatString.search(/M{4,}/g) >=0){                 /* MMMM */
			localFormatString = localFormatString.replace(/M{4,}/g,     "MM");
		}else if(localFormatString.search(/M{3}/g) >=0){            /* MMM  */
			localFormatString = localFormatString.replace(/M{3}/g,      "M");
		}else if(localFormatString.search(/M{2}/g) >=0){            /* MM   */
			localFormatString = localFormatString.replace(/M{2}/g,      "mm");
		}else if(localFormatString.search(/M{1}/g) >=0){            /* M    */
			localFormatString = localFormatString.replace(/M{1}/g,      "m");
		}

		//Day
		if(localFormatString.search(/D{2,}/g) >=0){                 /* DD   */
			localFormatString = localFormatString.replace(/D{2,}/g,     "oo");
		}else if(localFormatString.search(/D{1}/g) >=0){            /* D    */
			localFormatString = localFormatString.replace(/D{1}/g,      "o");
		}

		//Day of month
		if(localFormatString.search(/E{4,}/g) >=0){                 /* EEEE */
			localFormatString = localFormatString.replace(/E{4,}/g,     "DD");
		}else if(localFormatString.search(/E{2,3}/g) >=0){          /* EEE  */
			localFormatString = localFormatString.replace(/E{2,3}/g,    "D");
		}
		console.log(localFormatString);
		return localFormatString;
	}

Where I use it

To use this method I needed to turn my JavaScript file into a jsp so I could dynamically set the SimpleDateFormat string constant at server load time.  To this simply change the name of the file extension to JSP and add this line at the top

<%@page contentType="text/javascript; charset=UTF-8" %>

Hope this helps some people.

Thank you Laurent Picquet for 95% of needed code.

Why jQuery Mobile over/vs Sencha Touch, DHTMLX Touch, Dojo Mobile

Why Jquery Mobile (JQM) over other frameworks?

Declarative vs Programmatic

The answer to this question becomes pretty obvious considering my last post- Declarative vs Programmatic JavaScript frameworks.  To summarize in one line, declaritive frameworks give a very low learning curve and allow to mix-in all the tools, tricks, custom JavaScript libraries and everything else that you are already using rather painlessly.  Although the end results are still a little less impressive than the end-results you might get from Sencha the differences are rather slight.

Again, if you are stuck working with legacy server side coding, like JSP or ASP the declarative approach is your only solution that wouldn’t involve bending over backwards to fit a square peg in a round opening.

Major Mobile Frameworks Categorized

Framework Type Link
Sencha Touch Programmatic http://www.sencha.com/products/touch/
jQuery Mobile Declarative http://jquerymobile.com
Dhtmlx Touch Programmatic http://www.dhtmlx.com/touch/
Dojo Mobile Declarative http://dojotoolkit.org/features/mobile
Wink Toolkit Programmatic http://http://www.winktoolkit.org

As you can see there is a quite a few of both.  But having disqualified all programmatic frameworks rather quickly our decision is simplified. (In reality I actually downloaded almost everyone of those, and made demo apps before disqualifying them.  Additionally I tried out all their demo’s on an Android 2.2 device, where JQM was actually NOT the most impressive, but not far behind.)

jQuery Mobile vs Dojo Mobile

Now we are left with only two frameworks two chose from jQuery Mobile and Dojo Mobile.

jQuery Wins

Wait! What? That was a little too fast, where’s the discussion where the reasoning?

What does jQuery Mobile has Going For It?

  • Backed by jQuery
  • Good looking UI
  • Really easy to use
  • Decent set of widgets (admittedly not as much as others out there)
  • Broadest set of targeted devices
  • Works equally well on desktops
  • Best chance for long term maintenance
  • Huge community already formed in it’s first alpha release (like me)
  • Easy to customize
  • Can’t beat the price

Backed by jQuery

It’s associated and backed by jQuery! Need anyone say more?  I mean honestly jQuery’s success is rather astounding.  You can find it being used by Google, Microsoft, Adobe,etc. Which means when using jQuery Mobile you can continue to use all the jQuery API’s and plugins that you’ve come to learn and love.  The learning materials on jQuery is probably the richest of any JavaScript framework out there.  I mean even w3schools has a dedicated jQuery tutorial, you don’t find that about any of the others.

Besides name recognition and familiar API’s the jQuery name gives highest chance for long term maintenance and community support (See last two bullet points)

Good Looking UI

Let’s be honest, if it wasn’t for the good looking touch capable UI’s most of the mobile framework API’s would be ignored completely.  Sure, AJAX page loading is nice, and swipe events are great, but the UI is really what’s people see.  jQuery Mobile looks good.  It’s implements nice CSS3 effects like gradients, shadows, and rounded corners, with fall backs for browsers that don’t support them.  In reality the CSS is where all the action is, most of the time the JavaScript just selectively adds and removes classes.  Efforts were made to be touch friendly, so buttons are big, check-boxes are easy to strike, and icons are given padding.

Really easy to use

If you are like me working at a company that does not want to cutting edge, but would rather deliver results quickly and at a low cost, the administration does not really care about all the techno. stuff.  Throw in a whole team of workers that need to maintain, customize and expand on your code, learning curve is really important. jQuery Mobile delivers here with an intuitive structure.  The one thing that takes time getting used to, is the heavy reliance on html5 data-x tags.

Decent set of widgets

The widget set of jQuery Mobile is pretty comparable to other frameworks and is even sometimes lacking compared to others.  But it provides the most needed ones. Some crucial features like a carousel/scroll windows are missing but a presumably this is limited by mobile limitations on scroll windows.  Although experimental solutions are out there.  The JQM teams seems to be focusing on getting what they have stable before adding any new widgets.

Broadest set of targeted devices

This has been the main goal since the beginning, aim high but account for low.  Their infamous device browser grid shows this.  Can’t say it looks great on older devices (try opening it in ie8) but not too bad either.  Besides if you need to target specific devices most likely workarounds are out there.  Like to add rounded corners and shadows in IE8.

Works equally well on desktops

In my current project I started targeting for mobile phones, only to have my requirements change to laptops (with optimistic support for adaptive layouts for phones)!  No bother, app still looks great on desktops, tablets and phones.  Just need to add a lot of data-inline=”true” and add a more restrictive container div with a max-width.  Otherwise the all your forms and buttons will take up the whole width!

Best chance for long term maintenance

With some corporate sponsors in place, and the jQuery name behind it, there is a great chance that this will continue to evolve with full time involvement of web developers.

Huge community

In open source projects community is crucial.  If there is no interest, the creators also lose interest.  Communities find and fix bugs, spread the word, create plugins, help materialize sponsors and add features. Active communities are also crucial so creating tutorials, books, and forum questions and answers to ensure more attraction to framework.

Easy to customize

The built-in CSS is nice, but almost definitely you will want some other colors besides, yellow, blue, grey and black.  Until the theme-roller is released hopefully with version 1, http://www.mobjectify.com/ has done a good job to fill in the gap of easy custom CSS coding, and galleries which you can copy.  Even without any tools it’s a just a matter of copy paste into your own css file. In your code it’s just a matter of setting data-theme=”x”. My current app bears only structural resemblance to the built-in styles.

Can’t beat the price

Isn’t the MIT licence great?  Years of man hours free for the taking?  Hard to believe but true.

Conclusion

While some of the points in jQuery Mobile favor also equally apply to the other frameworks, I think most of these hold stronger for JQM.  For me though the community support and lofty clearly stated goals set it apart in the end.

Declarative vs Programmatic in JavaScript mobile app frameworks

Introduction

After deciding to go with a web framework/toolkit for developing our App instead of creating a native app, I needed to wade through the different framework/toolkit options out there to determine which best suited our needs.  As mentioned in the previous post, PhoneGap does a good job providing links to some of the good options out there. http://www.phonegap.com/tools

Two Different Paradigms of Web App Development

I evaluated several different frameworks/toolkit and made a demo app with each.  Before I explain (in another post) why I ultimately chose JqueryMobile let me explain a very important distinction between the different frameworks out there which made my decision very easy in the end. In my opinion this distinction cannot be overemphasized, because it will seriously change the way you work during the entire life of the app. In terms as Dojo-Toolkit puts it, Declarative vs Programmatic way of doing things.

Declarative

What you write: (mostly) 100% Pure HTML markup

<div class="tab">Tab Header</div><div>More stuff here...</div>

What the framework/toolkit does to it: picks up on the class name wraps the div in another div, adds a span to to the header, adds an event listener on the div, etc. etc.

The important point here is that you are required to follow the guidelines and conventions that the framework sets for you, and the markup decorations, listeners, etc. are automatically added afterwards.  This leaves you, the developer to create almost full markup and provide data.  So if you have dynamic data, it’s more or less up to you to loop through your data yourself to create the markup that can subsequently be decorated by the system.

Programmatic

What you write: JavaScript code, and a lot of it.

(Taken directly from Sencha touch Hello World tutorial)

<script type="text/javascript"> 

    new Ext.Application({
        launch: function() {
            new Ext.Panel({
                fullscreen: true,
                html: 'Hello World!'
            });
        }
    });

</script>

What the framework/toolkit does to it: Creates the full set of markup, all divs, spans, everything is done for you.

Pros and Cons of Declarative vs Programmatic JavaScript frameworks

Declarative

PROS:

  • Working with HTML means all tricks, lessons, frameworks will continue to work
  • Easy to read and understand
  • Consistent with all other web development
  • Lower learning curve

CONS:

  • Harder to create dynamic apps with data driven layouts and markup
  • More for you to write (arguable)

Programmatic

PROS:

  • Easy to create very powerful apps
  • Less markup needed to get better end results
  • Easier to template and use code reuse
  • Easier to make data-centric pages that markup can dynamically change with the data

CONS:

  • Does not play well with others
  • Bigger learning curve
  • Harder to customize, extend
  • Much higher chance of vendor “lock-in” since your code will ultimately be almost very coupled to the framework

Declarative Wins, By a Lot

The first Pro I put for declarative is the real kicker and TKO against any programmatic way of developing a mobile web app. The complete flexibility of using regular divs, and spans and links, means the thousands of JavaScript widgets, components, plugins, frameworks will continue to work.  Case in point validation, in our app we wanted a validation.  If the chosen framework includes data validation on form submit, then whoopee we are in luck, but if not… Then what?  Second case in point, we wanted to have a Google Calendar like screens in our app.  We eventually went with http://arshaw.com/fullcalendar/ available under MIT and GPL licenses but what if we were using a programmatic approach- we would need to write the whole thing from scratch.

The other huge reason why declarative wins was the learning curve.  I could just imagine the look on my boss’s face if I told him we need to have the entire team go under training to learn a new API and way of writing web apps.  In our case, the team is highly experienced in JSP and most are not youngsters and not eager to learn brand new way of doing things.

Lock-in can also not be ignored.  If you are going with Sencha, than you are ultimately going with Sencha for the long haul.  True, almost every framework requires it’s own conventions and changing would require a rewrite, but for Programmatic way it’s all or nothing.

More on specific frameworks in a different post.

The Big Debate: Native Apps vs Web Apps

The trouble with this debate is that it is a moving target.  Every few months the landscape changes and the decision need to be reevaluated.   Each presents advantages and disadvantages, but those lines are quickly blurring.

Native Apps

Pros

  1. Natural device interface. Consistent with the overall user experience for the device. Means using an app should be familiar.
  2. Access to device hardware and software. Phones, GPS, persistence, phone book, calendar, etc, etc. are all accessible when using native API
  3. Speed.
    1. Having all the code on the machine means only the data needs to change.
    2. Business logic sits inside the app. Accessing the server is only secondary.
  4. Power. Running directly on the machines CPU gives the app strong processing power and encryption abilities
  5. Lighter. Access to the native API’s means rich User Interfaces without any added bulk. A lot of choices and flexibility in the UI widgets to use
  6. Offline- 
    1. Since app sits on machine, no need for sometimes expensive data access
    2. App works even when no access to internet

Cons

  1. Development- Each device needs to be developed separately!
  2. Learning Curve- Each device has it’s own quirks and catches and programming model. This takes time to learn.
  3. Objective-C – iPhone apps are written in objective c!
  4. Maintenance- Native for each device means maintaining different apps written in different programming languages
  5. Updates- Since the app sits on user machines pushing an update requires the user to reload the app. Can lead to app fragmentation, since not all users will update at the same time

Web Apps

Pros

  1. Cross-Platform. One app- all devices.
  2. Learning Curve- Familiar working tools, html, CSS, & JavaScript
  3. Full control over the content. Since user needs to access server for content, constantly decide what to deliver.
  4. Dynamic- Interfaces, content, features, can very easily be added/removed based on the user
  5. Updates- Updating the version is invisible to the user. Just need to restart the server and the user instantly has access to latest version

Cons

  1. Less consistent with the user experience with the device since there will be a single site for all devices
  2. Unpredictability- Since different users with different size screens, hardware- hard to know how the app will look and perform (partially true for native apps as well)
  3. Look and Feel- Hard to get a web site to look and feel like a native app
  4. Touch- web wasn’t made for touch
  5. Power- Slower since JavaScript running through the browser is not as fast as native code
  6. Speed- Slower since all content needs to be retrieved from server. Two hits- one data retrieval is slower on mobile, server needs to send process the request
  7. Limited access to hardware accessories and other apps features of the phone (phonebook, etc)

Many of these positions are quickly becoming no longer relevant.  Web apps are very quickly gaining speed. The powerful cons against native apps, namely cross-platform and learning curve means most companies cannot afford to develop and maintain two (or more) apps.  However, the historically awful user experience for mobile web-pages left little alternative.

Html5- How does this help?

Html5 capabilities are changing the landscape a bit.

How?

  • Offline mode- The app can be downloaded to the device and only refresh itself when a manifest file changes. Solves partial speed problem while still leaving open ability to easily upgrade the app
  • Powerful new UI capabilities. Widgets got smarter and the phones already support this. For example form type email on iPhone automatically displays a email optimized keyboard. CSS3 is a game changer.
  • Persistence- HTML5 allows local storage beyond just cookies
  • Geocoding- Easy access to GPS information

The magic bullet?

Obviously not, even with HTML5 web apps, most of the cons against Web Apps persist.  The youtube.com Android app is still easier to use than the mobile optimized site.  However, the advantages of native are not significant enough to most users whereas the company developing these apps can save a significant amount of money by writing and maintaining only one app.

It should be noted that there are a many solutions out there that look to bridge the gap.

Phonegap

Mobile devices, like Android and iOS- allow apps to have a “webview”. Webview is essentially a browser running inside of an app.  Phonegap provides the code to bridge the divide between native access and html code via JavaScript.  This gives the major advantage of having the ability of JavasSript to hook into native code and give access to native hardware software.  A different build still needs to be done for each targeted device, but the source code stays the same.

Solves-

  • Learning curve- App is written in html, css, javascript
  • Cross-platform maintenance. Since same core code is inserted into each app
  • Access to hardware
  • Some speed- Code is stored on the machine (this is both good and bad), though not compiled into lower level languages

Doesn’t Solve-

  • User Interface (UI) & UX (User experience) Essentially a website inserted into an app. Doesn’t use the native UI widgets.
  • Speed. No native processing power. Still running on JavaScript and not a statically compiled, fast, native code like Java or Objective-C. This might not be noticeable however.

This is only a partial solution, to be used with other solutions. See:  http://www.phonegap.com/

Mobile Build Frameworks

Similar to Phonegap in principal, but these can take many different directions.  These tools allow developers to write their app in the language of the tool (which varies) and use the tool’s IDE and API’s.   The app will then be compiled into native language using the native UI widget sets.

I have never seriously looked into any of these solutions.  I have always been quickly turned off by their walled garden approach of using their tools and IDE’s and their expensive proprietorial nature.  Smelled too much like “vender lock-in”.  But there a lot out there, so somebody must like these ideas.  For example- http://www.appcelerator.com/http://pyxismobile.com/ and others.

UI Frameworks

Different solutions mostly based on html5, CSS and JavaScript.  Styling and widgets that mimic native devices. Some are iPhone only. Some are for all devices.  Different approaches- Sencha and others uses pure JavaScript to create the UI and interactions.  JQuery Mobile very smartly uses regular html with tags. The JavaScript then turns that into mobile looking app. Special JavaScript lets you access touch events.  For all of these you can use different CSS files for different devices mimicking native look and feel.

Solves

  • User interface look and feel, and user interactions.

See http://www.phonegap.com/tools for a list of these types of frameworks.  Hopefully another blog entry about my experiences with these frameworks another time.

Summary

As of today (mid 2011), I would timidly say apps that need good processing speed (e.g. encryption) and don’t change frequently should be made using native code.

Apps that require a lot of data coming from servers, changes frequently, need to target a lot of different devices, and do not require a lot of processing power should be a web app.

But in the end it will probably come down to a question of finance and developer know-how.

Impetus for new blog

This is the start of my new blog.  Where did the impetus come for another blog come you might ask?  Well.. I have been enjoying tech. blogs for some time now.  Ever since I started working with opensource frameworks some years ago blog posts have been an essential tool.  Both for learning what new technogies are out there, but more importantly how to use them and how to overcome the many many potholes, ditches, and strange bugs that popup along the way.

And another thing… My friend recently handed me a book written by Seth Godin titled “Linchpin” which he highly recommended.  Some of the content in the book is debatable but the premise I think is correct.  His basic thesis is that the past 200 years have been ingraining in us to follow rules, do your job well, get paid, go home and sleep the night.  Or as he describes it- “Be cogs in a wheel”.  Well we all know that a cog in a wheel is easily replaceable if it breaks, but more importantly he argues- cogs are being replaced even when not broken.  The lowest paid bidder who is capable of doing the same job will eventually take your position.  Now- every job done without creativity or “art” as he calls it, will one day be done by a machine or by an outsourced competitor perhaps living in a foreign country where the cost of living is a lot cheaper.  That being said the secret to maintaining your position and not being replaced is to be an “artist” to bring your genius to your job.  Not just to do what you are told to do, but to take risks to bring emotional connections to your job.  Do what you think is right even if your boss doesn’t if you think in the end (s)he will love what you brought to the table.

Now as Seth Godin is a blog writer he obviously encourages to write blogs as well.  As a self marketing tool.  As an expression in which to share your genius.  Which got me thinking, I think I might have some intelligent thoughts to bring to the table even among the thousands of others out there.  Especially as research so many cutting edge topics and pave ways that are still being hewed.

Follow

Get every new post delivered to your Inbox.