Tangere.Net Version 0.3 - Orchard Integration

by Admin 16. February 2012 12:41

While developing the first version of the Gatekeeper for Version 0.2 it became obvious that just plain MVC for backend development won’t be a solid foundation for the future.

After some brain storming we defined the following minimum requirements for a flexible backend architecture:

  1. Modularity
  2. Pluggable User & Permission Management
  3. Multilingual

I think Options 2. and 3. are quite obvious, but Modularity is just the headline for a bunch of requirements:

  1. Each App should be a self contained, downloadable and installable “Module”.
  2. An App might depend on one or more others Apps/Modules.
  3. It should be possible to release/update a single App.
  4. Each backend component should be pluggable/replaceable.
  5. The framework should support multiple database systems and generate all required tables.

Our first idea was that we need to develop the basic backend infrastructure on our own. But somebody remembered Orchard – which seems to be just an ugly CMS or Blog at first sight. But after some analysis we discovered that Orchard is a surprisingly well-thought-out web framework.

Orchard is also a CMS – but we currently don’t use or need the CMS part. But we’re using the following Orchard features:

  • Dependency Injection
  • Module/Feature Management
  • Database Migrations
  • Transactions
  • Site Settings
  • Users and Roles
  • Permissions
  • Localization
  • Logging

Tags: ,

Blog

Tangere.Net Version 0.2

by Admin 30. January 2012 01:05

3 months since the last release - so development had been slower than planned as we've added two additional backend components:  

 

v0.2 provides now also a tile layout similar to Windows Phone as well as new RSS reader sample.

Tags:

Blog

One month later - Tangere.Net v0.1

by Admin 20. October 2011 06:36
Just one month after the definition of the project goals a first version of Tangere.Net was just finished.
A sample email App can be accessed at http://tangere.mobi/app/email and this blog can be viewed with a blog viewer app at http://tangere.mobi
The apps are currently only working on WebKit/Safari browsers. So an iPhone or iPad or a Safari browser on Windows is required to access the samples.
Tangere.Net is based on knockout.js - so the app logic is defined in a JavaScript ViewModel and comepletely seperated from the presentation.
 
So from our initial to do list we can already remove most items:
  1. Pure HTML5/Javascript5. No need to deal with browser cruft (IE6, etc.) and dated devices.
  2. Apps should be usable on different sized screens (e.g. iPhone/iPad) with minimal device specific code/logic.
  3. Clear separation between backend logic, frontend logic and user interface. The backend provides just JSON data, the frontend controls the application flow and the user interface.
  4. The Apps are real applications and not public, mobile web sites. So SEO tactics can be completely ignored. This allows to build high performance, single page applications .
  5. The user interface should be easily customizable/brandable. A designer with just HTML/CSS knowledge should be able to change e.g. the color schema or the order of buttons.
  6. The Apps should be modular e.g. allowing to add customer specific modules or features.
  7. The Apps should be easily upgradable without breaking customizations.
  8. Unlike traditional web applications WebApps don’t need to be stateless any longer. Local storage allows to maintain local state information.
  9. The WebApps should have a default look & feel quite similar to native Apps.
  10. The Apps should be addable to the iOS home screen.
  11. The Apps need to support the limited iOS multitasking WebApp capabilities (avoid unwanted complete restarts).
But we added already a lot of items to our to do list for the next version:
  1. Add more predefined styles for lists, buttons etc.
  2. Add support for Android and Blackberry devices
  3. Add support for IE10/Win8
  4. Add permission and membership provider support
 

Tags:

Blog

Architecture Overview

by Admin 19. October 2011 08:13

The server component of Tangere.Net is essentially a ASP.NET MVC3 application. The Controller uses Models to retrieve data from data bases and backend systems. Views don’t really exist – the controller sends the “view” data in the JSON format to the Tangere.Net App.

The main logic of the client side resides in a View Model (VM). For each page of the App a View is defined in HTML5. The views are using declarative bindings using a concise, readable syntax to connect with the view model. The VM uses knockout.js to provide also templating and dependency tracking services. The VM retrieves the Model data from backend services. Dependency tracking is used to automatically update the views after any change of the model data or view model state information. So the core architecture of the client site is MVVM.

But the VM doesn’t directly show the views on the device. A “SmartPresenter” uses again dependency tracking to detect changes in the state of the VM. Anytime the state changes the screen of the device is updated to reflect the new state of the VM. The smart part of the Presenter knows if the device is a phone or a tablet and shows the views either on a single page or uses a SplitView to show two views side-by-side on a tablet. The SmartPresenter manages also animated transitions between the views and provides all device specific features  (like “Add to Home Screen”).

So what’s the name of the architecture? We have MVC + MVVM + P. But the traditional V of MVC became a MVVMP. So Tangere.Net is probably the first framework with a MCMVVMP architecture – so we desperately need some ideas for a better acronym…

Tangere.Net Rationale

by Admin 20. September 2011 05:34

Before this summer I wasn’t really aware of the revolutionary impact of HTML5. I ‘v seen just some new tags in html and some esoteric capabilities in CSS3. I missed the up rise of tables – at least I didn’t see any reason why I should get a tablet.

But every time I had been travelling this year the number of people I saw using iPads had been doubled. On my last trip before summer holidays I even got the feeling that now everybody had an iPad.

So on the day before our summer holiday trip I decided to get an iPad myself and to check if a tablet might be beneficial. Big surprise – I was immediately in love. During the whole trip I didn’t need my laptop and was really surprised that I like the basic interface of email, calendar, notes and tasks on the small screen more than the bloated Outlook 2010.

After my return I started to analyze the tools for mobile/touch/tablet application development. We’re developing web applications based on .NET since ASP.NET 1.1. So developing native apps in Objective-C is no real option. The mobile/touch market is also not just iOS. Android is gaining more and more traction and there is whole bunch of niche players from Windows Phone to Blackberry. I got the feeling that the only option to build future proof, device independent mobile/touch applications is using HTML5/Javascript5.

When Microsoft announced last week that HTML5/Javascript5 applications will be the new first class citizens in the Windows 8 universe my decision was finally confirmed. HTML5/Javascript5 is the future.

In the last 10 years our internal toolbox became a collection of different tools including COM, WebForms, MVC, jquery, extjs etc. Quite powerful but not nice and clean any longer. So HTML5 is also the time to restart with an empty toolbox. The only design principle we absolutely wanted to keep is our “holly” design principle: DRY KISS.

DRY KISS? Don’t repeat yourself and keep it simple and stupid.

After some days of brainstorming and research I came up with the following list of core requirements for our new Apps framework:

  1. Pure HTML5/Javascript5. No need to deal with browser cruft (IE6, etc.) and dated devices.
  2. Apps should be usable on different sized screens (e.g. iPhone/iPad) with minimal device specific code/logic.
  3. Clear separation between backend logic, frontend logic and user interface. The backend provides just JSON data, the frontend controls the application flow and the user interface.
  4. The Apps are real applications and not public, mobile web sites. So SEO tactics can be completely ignored. This allows to build high performance, single page applications .
  5. The user interface should be easily customizable/brandable. A designer with just HTML/CSS knowledge should be able to change e.g. the color schema or the order of buttons.
  6. The Apps should be modular e.g. allowing to add customer specific modules or features.
  7. The Apps should be easily upgradable without breaking customizations.
  8. Unlike traditional web applications WebApps don’t need to be stateless any longer. Local storage allows to maintain local state information.
  9. The WebApps should have a default look & feel quite similar to native Apps.
  10. The Apps should be addable to the iOS home screen.
  11. The Apps need to support the limited iOS multitasking WebApp capabilities (avoid unwanted complete restarts).


Being not among the first ones jumping on the HTML5 bandwagon comes with the benefit that a lot of tools and libraries are already available. But it became quickly obvious that none of the available frameworks comes even close to our core requirements. So we decided that we’ll build our own WebApp framework:

Tangere.Net

Tags:

Blog