Another great advantage to webapps is that it’s easy to “try before you buy”, you can login and try the demo or a low function version of the software, if you want more functionality you can subscribe to the the service, if you don’t want it any more then just stop the subscription.
This does have a few draw backs, traditionally when you buy, download and install you have a copy of the software, forever. So it the company goes bust, the licensing model changes or support is stopped you still have the software on your computer and you are free to use and reuse it. Webapps though don’t have this luxury, if the company goes bust, the licensing model prices you out of the market, changes to Terms and Conditions or the server goes down then you simply don’t have access any more.
Webapps also have other trade-offs. The biggest problem for webapps is speed. Web-applications are written using interpreted code, this means that the web-browser reads the code using a language close to what a human can understand. Typically desktop PC software is written in a programming language and compiled to something understandable by the computer, in the computers native language (hence native code). For interpreted code the web-browser has to read the code, work out what each instruction means and convert it to a form that it understands each time the software is run. This does provide a bit of a performance and memory cost. Many modern browsers are though very good at doing this task, desktop computers are becoming increasingly powerful, so most users day to day don’t notice the performance bottlenecks. It’s mainly when you have complex data-processing tasks, or where you have embedded devices which don’t have the performance processing capabilities that these problems are observed.
Webapps though can be stored and used on devices. For example HTML 5 now introduces offline mode so if you loose internet connection the webapp is cached in your browser, and your files and settings re-synchronised with the web when you reconnect.
The future is certainly bright for the web and all those who can see opportunities to harness its advantages and capabilities.
After several years with my beloved Sony Ericsson K800i I recently decided that technology had moved far enough and it was time to enter the 21st century and buy myself an HTC Desire S. The HTC Desire is great, the Android user experience is great and it’s after a little bit of playing around and learning the features and quirks pretty nice to use. Unsurprisingly within a few hours I already had some ideas for projects that I could do on the HTC Desire and hopefully at one time or another get onto the Android Market place.
I used the Java programming language during my Masters degree and I also have some experience using it in industry, so I’m pretty comfortable with it. I was also pleased to see that the IDE of choice for Android development is Eclipse. After designing and creating a paint plug-in (with layer, blend modes, tools, effects support and even able to load Photoshop files) for Eclipse during my dissertation I’m quite comfortable with the Eclipse IDE and its way of doing things.
First thing first was to run through the tutorials. I started off with the tutorials at android.com, but found that although a pretty good way to start programming that they didn’t really have much on using the 2D functionality, also I like to sit in the park at lunchtime so a book, a notepad and a pen are ideal. Also when you are designing an application being well away from a computer is the best approach, but more about that at another time. I took a look at the forums and Amazon and finally found the book Hello, Android: Introducing Google’s Mobile Development Platform by Ed Burnett. Hello, Android is a pretty good and well written book in my opinion. After the first few chapters you are pretty much ready to get up and running on Android and producing some pretty good applications. It is also good if you are like me a little rusty on Java or using the Eclipse IDE and just need a few polite reminders to kick start those brain cells.
Well I’m pretty much nearly finished on the Sudoku example from the book and several tutorials on android.com. Generally I find Android development pretty nice. It’s great how you can design the User Experience in a clear and well defined XML schema. The architecture appears pretty good too and it’s fairly straight forward to create well designed, clear and scalable user interface designs. The SDK is well defined and it’s fairly straight forward to find what you need, or a tutorial on the internet to help you out. The Eclipse tools are also quite handy and after a little searching around you can find lots of time saving features. I would also add that if you are serious about developing for Android use a real Android phone, although helpful at some times the emulator is painfully slow even on an Intel Core i7, I would love to see the Android team put more effort into optimising and accelerating the emulator to be more like a real device.
So all in all pretty impressed. I’ll let you know how I get on further down the line.