Barnes and Noble, You Could Do Better

Let’s give Barnes and Noble some credit. The Nook color is a nice device as a reader with some tablet stuff. At the time they came out with it, the android honeycomb code base was not available, so one can see why they went with the older code base when they designed their device. The Honeycomb source has been available for a while now. Why not upgrade your device to the new Android codebase so you can run better more modern apps which can be those optimized for a tablet versus a phone. Now Barnes and Noble comes out with the Nook Tablet and they are still in the old android code base. What gives, the honeycomb code has been around for a while now. Why use an aging code base that isn’t even intended for tablet use?

Kindle Fire, Lame Decision

Amazon made a lame decision to build the kindle fire with an android 2.2 tablet and not working with the android Honeycomb class codebase, which are typically 3.2 version. The device has a limited amount of memory as well (8GB) and not 16GB or 32GB which is standard with the honeycomb tablets. the User Interface also looks like it was  borrowed from Barnes and Noble’s Nook Color device, also a android 2.2 device. One wonders what manufacturer is building these devices for them. When the honeycomb devices started to come out, Google clamped down on the rights to the code base so only well established manufacturers could get the honeycomb code base.

Built new Celebrity Astrology Tablet App

I just built a new version of my Celebrity Astrology App for Honeycomb tablets with a new design. It turned out very nice, much better than the standard phone modal designs. Using the new Fragment architecture allows multiple views to be placed on screen, each with separate code, so user isn’t switching as often to new Activities and the user flow is far more natural and easy to work with. This is a real aspect where the 2.2 android devices fall short. I am sure there are those who will try to emulate them for devices like Kindle Fire, but Honeycomb and later devices are far superior and are designed for tablets.

Experiences Developing PHP Extensions

In the past I had done a lot of development in C and C++. It used to be the language I worked the most with. C++ can help make developing a complicated application far easier than writing it in pure C. I have moved away into doing more Java work in the last four years. I started with PHP during the latter part of the C/C++ period. I wanted to try to work on developing a PHP extension based on some C and C++ code I had written a number of years ago.

Reading about extension writing appears very intimidating because of the Macros and Zend api aspects. Starting off from scratch this can be very challenging, particularly setting up the structures and the boilerplate as it were for the extension. PHP is written in standard K&R C so that it can be compiled on any platform, which is a great feature, but the code is very intricate, particularly when it comes to object oriented code and reference counting. There have been articles written about wrapping C++ classes into PHP extensions, which seems like a possibility in terms of working with C++ libraries. You physically can build extensions with C++, but for wider distribution on PECL writing your extensions in C is probably the smarter way to go.

I found a Pear project to do the code generation for PHP extensions. This project takes an xml descriptor including code blocks, which generates all the code especially the boilerplate code. It seems to be promissing, It seems it’s best to  continually doing edits in the .xml file and generating new sets of code whenever possible as it makes it easier adding new functions. This approach also adds the necessary support for unit tests. Certain aspects of it seems to not be as well flushed out as could be. In a more complex extension, going beyond what is provided with this project.

PHP uses the the GNU Autotools system, autoconfigure and automake to configure builds. It makes use of M4 macros to manage and extending the basic scripts. It provides a way to interrogate the system and determine the options needed to build a piece of code on a given system. Unfortunately this doesn’t work on Windows. Windows requires a separate build script system in JScript. Aspects of the M4 macros can be challenging to understand which may be a problem with more complex projects.

PHP uses a unit test system using files with snippets of code, expectations, etc, that once one completes make on the extension make test will execute the test and show test results. You write these tests through the .xml described above.

Redis, the more Powerful NoSql Alternative to Memcached

The NoSql Paradigm has proven to be an interesting alternative to rdms systems, particularly where having a system that is more flexible than one requiring a very complicated Schema to account for complex aspects of an application, particularly those that change quickly. Document oriented systems such as Mongodb are useful to fit this type of problem. It supports highly scalable sharding system. Mongodb can become complicated, when sharding is involved, but other systems can as well. If you want to store complicated model data, Mongodb is a good choice. It offers good performance and features. Memcached is a key value store which has had a following for caching website content and mysql queries. It is a purely memory based store. Mongodb, on the other side is a disk based store using memory mapping of the file, disk storage and disk I/O is always involved.

An interesting alternative to Memcached with more than just a get/set model as well as solving the problem that Memcached has to solve. This is Redis, a key value store featuring in addition to simple key value features, lists, sets, and hashes. Even in the plain key space, redis ads features such as in place string manipulation. With these new data types, it features atomic operations on these protecting the integrity of the data contained within. Memcached is a good product for what it is, a cache system and key value store but it’s limited in terms of the sematics it supports for more complicated uses, and the developer winds up writing more complicated code to deal with the limitations.

Redis is also fast. It is comparable in speed to Memcached. A writer did a benchmark comparison, though Salvatore Sanfililipo the lead developer of Redis found the benchmark problematical including it  being a tight loop which didn’t show how it behaved with many clients. This benchmark showed Redis slightly slower than memcached. A rewritten apples to apples benchmark showed Redis performing slightly better, particularly under more clients. Even with this comparison, it seems like comparing apples to oranges in a way, the comparison doesn’t show a comparison to a product with comparable features.

Redis is a newer product, though the developers focus on a high quality product with fast performance. The newest version is in release candidate status, with new features to manage multiple keys in one command, and future clustering and sharding features coming. Personally I am not sure of the value of these, but I am user there are those who can use them. One challenge are the clients. There are clients for many languages, even the estoeric. There are a number of php clients. The most mature however only works with php-5.3 and requires namespaces, a feature that has value, but if you are supporting 5.2 servers it won’t work. There is a C based php module, but it is very new and not in the Pecl collection yet. One I like, Rediska, written by a russian group which is well designed, performs well, and integrates very well with Zend Framework.

Problems with Early Android Tablets

A full range of tablets have been developed using the Android operating system. The new 3.x Honeycomb versions such as the Motorola Xoom (below) represented a major change for tablets. This is an operating system with many features to help provide a base for a powerful and highly interactive solutions. Initially Android was not built for tablets, only smaller devices such as phones. Eventually support for large screens was added but it was really minor changes and the Ui was not built for tablets. I have several android applications, which later I will have honeycomb specific versions which will make use of the new user interface features. In the mean time I was working on support for the older larger screen devices like the Samsung Galaxy tab (left), which is a non-standard aspect ratio 600 x 1024 dpi, people have reported problems with applications on this device. A developer can rework a layout for specific Android software versions or device features such as aspect ratio. One still is relying on the operating system scaling the layout to fill the space. Android has predefined screen sizes, which one can use and the emulator knows how to use these predefined sizes, but when device manufacturers built tablets from the older, the sizes didn’t exist. A developer dealing with this situation may say, skip the older tablets and spend the energy on the newer tablets, which may be the best solution.

Comparisons of Three PHP MVC frameworks.

PHP is fast becoming one of the dominant languages in the web. It is easy enough for beginners, but has significant power for serious sites. Model View Controller (MVC) frameworks which have been used in many different contexts for desktop applications, mobile phone achitectures and web sites have become a significant force. Java’s Spring Framework  is great in Java and ported to C#. In PHP there are a number that are work considering, some key ones are Zend Framework, by the developers and maintainers of the PHP interpreter, Cake PHP, Code Igniter, and Symphony. I have been working with Zend professionally at work, and have been using Cake and Code Igniter in some personal projects, though have not worked with Symphony. I am going to discuss comparisons of the first three.

Cake PHP is a powerful strongly MVC standards based framework. It has a popular following, and a lot of nice features. If your application can fit into the strict cake pattern, it works well, when you can’t work within the framework’s expectations, it can be challenging and frustrating. This is similar to Spring in Java. Understanding the framework well enough to know how to implement your design is important. One challenge is how tightly coupled the database structure and the model is, including field and table naming. It also has substantial ORM features featureSimple joins where difficult, requiring unnecessary association tables for a simple project. Scripts are used to manage the application dealing with the mappings and creating objects. Cake is in active development and has a strong following, including fanatics.

Code Igniter is a lighter more flexible framework, with base classes that are highly optimzed and kept light by comparison, though you can add complexity as you need it. It has a strong user base and is in active development. For a smaller project, this is a good match. The coupling between model and database are looser. It also has the ORM mapping.  The model can be simple or complicated as necessary. A big project with a lot of complexity, may not be a good fit, but it has good features. Development is pretty fast. Php templating is standard, though a template system is integrated as a feature.

Zend Framework is a framework that is one of the best, but with limitations. I have been using it to build a large REST middle tier that to extend xmlrpc services provided by the Openx Adserver. It has features for many types of technologies, including integrating STOMP JMS features, web services, ajax,  json and front end view functionality. It has some decent database technology which  can work with more databases than just mysql. It uses a modern php style reminiscent of java, including interfaces, abstract base classes, access levels i.e. public, private, protected. It uses a substantial number of design patterns. Class naming is somewhat strict, though by doing so, gives wonderful autoloading features, so no include_once code just construct an object. Zend does not have the strong ORM features, though users have intergrated the Doctrine modeling framework. Others have also included the Ezcomponents framework which can help to do nice features. Php views are standard, though it’s easy to integrate smarty templates. An additional challenge is the structure of the app has changed frequently and technology has been added and improved so some documentation you may find from other sources may be out of date.

More about the limitations of Mobile devices.

I had been working on an Android app that would work with a popular professional photography site Smug Mug which I have been using to promote my photography. Smug Mug has a nice REST layer with a number of different formats including json, XML, php, and other formats. It works well and is reliable. One of the biggest challenge is the limited bandwidth and power of these devices. The app is nice, allowing to browse from an account. Later I had been planing a photo uploader feature, which is definitely a good idea and could work. My account, which I was using for testing has a lot of photos, and surfaced real challenges in terms of performance. Building a persistence layer with sqlite has promise, along with background threads loading resources, but with a heavily loaded account, the devices don’t keep up. Given some of the newer devices available for instance the Droid Bionic, which will have dual cores, and making available 4G capabilities such as Verizon’s LTE and Sprint’s Wimax, and HSPA+ on T-Mobile and later on AT&T will definitely help.

Published Celebrity Astrology Android App

I have been working on an android application to work with my site. It is now in alpha and can be downloaded from the android marketplace. Built a json service into the celebrity astrology site, after doing mobile/webkit optimized version. Application works with this service to display lists and show content. I needed to downgrade the chartwheel activity to a webview until the image viewer can be perfected.

Mobile Apps from a Shareware Lens

Being involved with mobile development, including web, applications, etc and having developed and successfully sold applications  in the shareware market for many years, has given me an interesting perspective into the Android, iPod, iPhone and iPad applications market. One of the challenges with these markets has been that many applications are sold for little or no cost, nor with an expectation of payment. People used to complain about shareware that you’d never get paid, but those with successful, compelling products did develop substantial businesses, for instance WinZip. Many of those who didn’t do well, didn’t consider market issues and demand for propsed products and consider what it would take to develop a full featured product competitive with commercial products. I had always producted numbers including a shareware version, and several different commercial versions, and the strategy basically worked until the market got saturated. A saturated market is also a problem for mobile applications, consider the number of iphone applications for sale, and the typical prices. There is more space in the Android marketplace, but more challenges including different hardware and software versions. If the android user base continues to grow at a quick pace, which i suspect it will, a significant market could arise, if developers find a way to get paid for their work.