Archive for the ‘Mobile Development’ Category

Transition operating systems

Monday, May 16th, 2011

Modern mobile operating systems are all the hype, and we’re feeling it here at GORGES – clients are becoming increasingly aware of the importance of mobile technology.

The major contenders when it comes to mobile operating systems are Android, iOS (more commonly known as iPhone, iPad and iPod), and Windows Phone 7 – all fantastic mobile operating systems, it is hard to even begin to compare them to their predecessors.

But why were we suddenly (these past few years) imbued with these brilliant new OS’es?

The answer of course is advances in hardware – lower cost, more computation power, high resolution displays and multi-touch, more storage, faster wireless networks, longer battery life… and on top of all that, advances in nanotechnology has made everything smaller and lighter, too.

My point with this little article, is to share with you an observation that has surfaced in a few of my conversations lately: that these new mobile operating systems are part of a transition towards “real” operating systems running on mobile devices. In fact, I’ve taken to referring to them as “transition operating systems” myself.

The evolution of mobile hardware does not cease. What made these new OS’es possible, is the fact that mobile devices are now almost as fast as “real” computers – and that same progress will put an end to them, too.

Soon, mobile devices will be fast enough to run “real” operating systems – and when that time comes, why would you want a dedicated mobile OS, or even a mobile device dedicated to wireless communications, such as your phone? If you could run a real Windows, OSX or Linux OS on your device, why wouldn’t you? At least two of the major players in mobile hardware, NVidia and QualComm, are currently racing to bring quad-core processors to market this year, so it may be more imminent than you think.

I suspect certain companies, such as Apple, are already having the same realization – it was recently rumored that certain features are being migrated from iOS to OSX. My guess is, they’re getting ready to add support for iOS apps to OSX, with the intent of running OSX on a mobile device in the no-too-distant future.

This is all speculation, of course – and either way, it doesn’t diminish the value of the mobile “transition” operating systems, which paved the way for new advances in user interface / user experience development, and have set new standards for human-machine interfaces overall.

And it certainly doesn’t mean that you should hold out on your business ideas – waiting for real operating systems to hit your cell phones – the new mobile platforms are already embedded in our lives, and they are inevitably here to stay, in some form or another.

Rasmus Schultz has worked for web development companies, advertising agencies and a music software company during his extensive development career. His main strengths are software development and database design. Rasmus has more than a decade of experience with many development platforms, languages and standards.

Getting the CRUD out

Friday, March 18th, 2011

The topic of one of GORGES recent internal Friday Tech Talks was “Yii CRUD: Tips and Tricks.”  I proposed this because I was curious to hear war stories from other developers about the problems and solutions they ran into when building “CRUD” – principally in the Yii framework, which has become one of our favorite tools at GORGES for creating complex web applications.

CRUD stands for Create, Read, Update and Delete (or, for some folks, Create, Retrieve, Update and Destroy). It refers to the basic operations that any data-centered application needs to make it run – creating new objects or records, viewing them, editing them, and getting rid of them. The code that performs these operations tends to get pretty repetitive after a while, so for a seasoned developer it can become the part of the application that you most want to “get out of the way” so you can focus on the more interesting bits, like complex business logic and nifty Javascript widgets. It is also often predominant in the administrative side of an application, where there is typically less budget for fancy design and interactivity than on the public side – but it still needs to work effectively. Thus, when developers refer to it as “crud”, they don’t always have the acronym in mind.

Here are some of the comments I heard from our team on how to create CRUD efficiently, in order to deliver quality, maintainable, cost-effective applications to our clients:

1. Don’t build it at all, if you can help it - For simpler web applications, or ones that are more content-oriented, a “full stack” framework like Yii or Ruby on Rails can be overkill – a platform such as Drupal can take care of most of the housekeeping operations, with coding (or configuration) only required for the more “custom” features of the application.

2. Use code generators – Yii and most other advanced web frameworks include tools for generating “skeleton” code for CRUD operations. Most developers felt that these are a good starting point, especially when first learning a framework, but after a while it becomes more efficient to write from scratch, with judicious use of copy and paste from existing similar code (but beware the Rule of Three).

3. Modularize your MVC components – Even though the Model-View-Controller idiom forces the developer to think in modular terms to some extent, it is still possible to write overly repetitive code within that idiom, and violate the DRY principle. Frameworks such as Yii provide a great foundation for building a web app, but the larger and more complex an application is, the more it makes sense to build on that foundation by using inheritance, polymorphism, and other object-oriented techniques in the CRUD (as well as in the non-CRUD components).

4. Build widgets where appropriate – This is just a specific example of modularization; Yii provides a widget API for building components that can be reused in different areas of an application. There are many standard widgets available, for components such as date pickers, but again, in some cases custom-building just the widget you need for a given application makes sense to keep everything “DRY”.

5. Use advanced languages - Just like application frameworks, many of the standard web development languages provide a great basis, but leave plenty of room for additional optimization. Two tools that our team is very excited about are HAML and SASS, which provide more efficient and elegant syntax for generating XHTML and CSS, respectively, than coding directly to each language. I won’t go into technical details here, but both tools allow the developer to create more robust solutions with fewer keystrokes.

These techniques and the fact that GORGES has structured ways of building staff efficiency, illustrate how GORGES developers are constantly looking for better ways to deliver quality web applications – avoiding CRUD!

Ted Caldwell is an Application Developer and Senior Software Architect for GORGES. Ted's work encompasses all aspects of web application development, including requirements analysis, database and software design, programming, project management, and system administration. Ted focuses on delivering practical, cost-effective technology solutions for GORGES clients, using a variety of custom and off-the-shelf software tools and frameworks.

Intern Creates Smart Phone App

Thursday, December 9th, 2010
Patrick Putnam presents his project.

Patrick presents his iPhone and Android apps for the New Roots Charter School to the GORGES staff.

We recently hosted a student intern at the GORGES offices.  Patrick Putnam is a student at the New Roots Charter School, and joined us for his Intensives Week program, supervised by his teacher Sarah Rubenstein-Gillis.

We recommended that he try to create a mobile phone app that could be used by students and staff at New Roots.  Patrick came up with several features that would be useful to have on a mobile app, for example the school academic calendar, map directions, website links, and accessing an online system so students can check assignments.

After an intensive week (now we know why they call it that!), Patrick created working prototypes that run on both iPhone and Android devices.  He based his solution on the GORGES mobile framework we have developed that is in turn built on top of a leading mobile development platform.  The prototype has the calendar, map, and links features, and features Patrick’s photography in the splash image.

Every few weeks we host “GORGES University” where one of us shares some new knowledge or tidbits during a brown bag lunch meeting in our office lounge area.  This week Patrick presented his project, followed by an equally-lively discussion about mobile technology.

We have enjoyed having Pat with us for his program, and GORGES will support his iPhone app store submission when the app is finalized.

Our hats are off to Patrick for his successful internship!

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

Web Development – Adapt or Die

Monday, November 22nd, 2010

The blog title sounds extreme, but there is truth to these words in our industry.

I have been developing software since high school, and building software and web applications for about thirty years.  If there is one thing I can count on, it is that the software business will continue to change.

Ten years ago we had primitive web browsers, and web pages were usually exclusively HTML.  Microsoft and their proprietary ActiveX technology dominated the browser wars.  As a developer, there were few debugging tools and no decent server-side or Javascript frameworks.  Developing web sites took time, and the results were clunky and crude by today’s standards.

I am pleased at how efficient we are nowadays and how much value we offer, since we develop great solutions at a fraction of the time and cost compared to the days of web infancy.  We have learned to leverage existing open source or proprietary packages as much as possible, and have a wealth of development, debugging, and deployment tools in our arsenal.  If we are allowed to target “modern” browsers such as IE7/IE8, Firefox and Safari, then we can count on browser support for features required by web 2.0 graphics and behaviors.

The web server hardware industry has also had amazing strides, and every year we see better value and better prices.  For example we recommended a single modern server for hosting a client’s complex web application instead of their previous vendor’s recommended 3-server cluster approach; the resultant performance has been similar to our estimated model, and every month for the last three years our customer has saved thousands of dollars since hosted cluster solutions are expensive.

Back to the blog title:  in our business, if we do not continue to learn from and embrace technology improvements, then we will lose our competitive edge.  The obvious result would be that we will no longer be quality or price competitive in the web development market.  Few other industries have this sort of pressure – consumer electronics and mobile phones are probably other examples.

It is interesting to note that only the software industry allows small firms to compete with larger ones, since creating new hardware products require so much more capital than software development.  That is one reason why there is so much more innovation and creativity in the software industry, which really has exploded now that laptops and app phones are ubiquitous.

What will the web world look like in the future?  Prognostication is not one of my strengths, but I imagine we will see more web applications tailored towards mobile solutions (app phones & differently-sized tablets), continual improvements in frameworks, and probably the browser battles will continue to be fought between Microsoft, Firefox, and Google.

And as for myself, I plan on continuing to learn and adapt.

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

New iPhone App: Rye YMCA

Tuesday, October 5th, 2010

We recently launched an iPhone app for the Rye YMCA.  It displays events, schedules, articles, videos, and other information useful to the members and community of the YMCA in Rye, New York.

To make updating the app automatic, we use content on the Y’s website. The website for the Y is modern and it sends out several RSS feeds. We pull these feeds into the app to continually update it with the latest information. There are convenient links on the app for the Rye YMCA website, map location, Facebook, YouTube, e-mail address, and a single button to dial the Y telephone number.

The client is thrilled, and is considering adding Android and Blackberry apps as well.

To open the Rye YMCA link in your iTunes, click this link.  If you have an iPhone or iPod Touch, download it and check it out!

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

Developing Apps within Android’s 16MB Memory Limit

Friday, July 16th, 2010

One challenge to developing for the Android platform is how to squeeze everything into 16 megabytes of heap space.  App-phones with 16GB and 32GB are common, but that is solid state storage and not RAM.  For Android applications, the limit for each application is 16MB (24MB on newer Droid and Nexus One phones).

Images, audio, and video are memory-intensive items, and many apps have these features. There are tools to help monitor memory use (e.g. Eclipse MAT, Android DDMS), and these tools are good for diagnosing problems, but you still need to understand enough to be able to fix memory leaks.

Here are some ideas for reducing the memory footprint of your application:

Reduce image sizes:  Lower the width, height, pixel bit-depth, and compress your images as much as you can.  Of course when an image is uncompressed and loaded into a Bitmap object then it takes up more memory, but you can reduce the memory footprint by lowering the image quality (for example see: View.setDrawingCacheQuality and View.DRAWING_CACHE_QUALITY_LOW) or even disabling the cache on views containing images.

Lower audio and video bitrates: I don’t know this for a fact, but I would guess that a lower-bitrate audio stream may have a smaller memory requirement during playback.  For example a mono-48 kbit/second audio file would require decoded fewer samples per second than a stereo-192 kbit/second file. (Please comment to this post if you test this theory or know the answer.)

Destroy or reuse objects: When you can, re-use objects and make sure that old objects are fully-destroyed. when they are no used anymore.  Even better, never create objects in the first place if possible.  This is especially true for bitmap objects – be sure to call the Bitmap.recycle() method. Remember to clear callback methods of objects before destroying them, because otherwise an object may not be properly returned to the memory heap during a java garbage collection operation.

Use final and static:  Virtual methods take up more space, and are slower, than static methods.  Final variables and arrays are stored in code space and not the memory heap.  Granted the difference is very small compared with 16MB of space, but every little bit counts!

Separate applications for localization:  If you are developing apps for multiple languages, consider creating separate applications instead of including all the language-specific strings, images, audio files, and videos in a single application.

Rely on external storage:  If you know that there is smart-card memory available, use that to store data instead of in memory.

Revert to an earlier Android SDK: When we reverted our most-memory-challenged Android application from Android 2.2 to Android 1.5, we gained two important things: first, we are now compatible with almost all existing Android phones; and second we reduced our memory footprint by almost a megabyte.  This latter statement is extremely interesting, since it indicates that the Android framework is getting bloated by all the new features added between versions 1.5 and 2.2.

worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.
©2012 GORGES - All rights reserved
where programming meets design and lives happily ever after