Observed by Burcu Dogan

Türkiye pazarında Android telefon popülasyonu biraz düşük seyretmekte. Biz bundan yakınırken, LG bize yeni bir telefon getirdi. 599 TLden satacağı bu telefonun adı LG Optimus GT540. Yaklaşık 15 gündür test için bana ödünç verilen bu telefonla ilgili görüşlerimi yazacağım. İzlenimlerim, bu telefonu tasarım ve kullanılabilirlik anlamında diğer Android telefonlardan ayıran özellikler üzerine.

Fiziksel: Cihazın dış ögeleri

Bir cihazın dış güzelliği içi kadar, hatta içinden daha önemli olabilir. Cihazlarla fiziksel temasa girdiğimiz nokta, o cihazın başarılı olup olmayacağı konusunda büyük bir kriterdir.

Dış yüzey tuşları

Telefonu elinize aldığınızda ilginizi çeken ilk şey Android telefonlarda gelen tuşların (ana ekran, geri, menü tuşlarının) bir kısmının soft, diğer bir kısmının ise hard tuşlardan oluşuyor olması. Zira tuşlar iki sıra halinde yerleştirilmiş. İlk sırada dokunmatik (soft) olan menü ve geri tuşları var. Alt sırada ise arama kabul etme, ana ekran ve arama sonlandırma tuşları sıralandırılmış. Android bir telefonda en çok etkileşime geçtiğiniz tuşların geri ve menü tuşları olduğunu söyleyecek olursam bu yerleştirim başarılı sayılabilinir. Fakat dokunmatik olan geri ve menü tuşları ekranın kendisi kadar hassas değil. Bu durum, yanlışlıkla basmaları engellemek için alınmış bir tasarım kararı olarak görünse de doğru bir karar olduğunu düşünmüyorum. Çünkü cihazı test ederken geri tuşu yerinde bir çok kez ekranın sağ alt köşesine, menü tuşuna basacağım diye de birçok kez ekranın sol alt köşesindeki tuşlara dokundum. Telefonun en çok kullanılan iki tuşuna bu kadar sert davranmak zorunda kalmanız parmaklarınız açısından acı verici.

Geri tuşunun ergonomisi hakkında yapılabilinecek bir yorum daha var. Bunlardan en önemlisi bu tuşun yerleşimi. Telefon benim kişisel görüşüme göre solaklar için tasarlanmış. Sağ elinizle kullandığınızda geri tuşu avucunuzun tam içinde kalıyor. Baş parmağınızla ona dokunmanız gerçekten büyük bir uğraş. Ayrıca bu iki soft tuş yüzünden ekranın alt kısmında olan biteni görmek gerçekten imkansız. Soft tuşlar, fiziksel tuşların altında olsaydı belki daha kullanılabilir olurlardı. Özelleştirilmiş ekranlarda ana fonksiyon tuşlarının en alta yerleştirilmesi uygun olmamış, bu ögeler parmaklarınız yüzünden tamamen görünmez kalıyor – Özelleştirme ile ilgili yorumların devamını yazının alt kısmında bulabilirsiniz.

Arama için ayrılmış Android tuşunun ön yüzeyde değil de sağ yan duvara konumlandırılmış olması ise iyi düşünülmüş. Keza, ara sıra yanlışlıkla arama tuşuna basıp arama uygulamasının çalıştırmasının önüne geçilebiliyor.

Ekran özellikleri

320×480 çözünürlüğünde 160dpi’lık resistif bir ekran var önümüzde. Resistif bir ekran kullandıysanız bu ekranların çalışma prensibini biliyor olabilirsiniz. Resistif ekranlar iki katman arasında yer alan hava boşluğunun daralıp genişlemesi sayesinde sizin dokunuşunuzu fark eden ekranlardır. Bu nedenle iPhone veya Nexus One’daki kapasitif ekranlarla karşılaştırıldığında dokunmaya değil basınca duyarlı ekranlar oldukları söylenebilir. Resistif ekranlar bu nedenle kullanırken daha fazla azim gerektiren yüzeylerdir. Özellikle sanal klavyede hassasiyetle ilgili sorunları olan bir ekran oldukça problem yaratabilir. Optimus’un resistif ekranının belirgin en büyük özelliği de bu. Varsayılan olarak numkey ile gelmesi QWERTY klavyesinin yeterince kullanabilir olmadığını kanıtlar gibi. Yatay pozisyonda ise çok daha rahat bir kullanım sağlıyor QWERTY. Açıkcası klavyeyi sürekli olarak yatay pozisyonda kullandım ve herhangi bir kullanılabilirlik sorunu yaşamadım. Göreceli olarak minik sayılabilecek parmaklarım dikey konumadaki klavye ile fazla barışık değildi.

Genel klasmanda en sorunsuz klavye telefon tuş takımı dizilimine sahip olan klavye (son resimdeki). QWERTY’den daha hızlı yazabiliyorsunuz, üstelik strese girmeden. Read the rest of this entry »

Coming from a regular background, you’re probably introduced into inheritance in a classical way with C++ or Java. JavaScript does not have any native mechanism to provide inheritance in the terms of what you’ve known already. JavaScript is a prototype based language. Behaviors of classes can be ported to other classes in a prototype based methodology. In this article, I’ll underline this concept and will illustrate you how it works.

So, what is Object.prototype?

You should be familiar with Object.prototype at least you have a little dirty object oriented JS experience. If you dont, let me explain you in a few words. In order to bind methods to a type, you extend your type’s prototype. For instance, let us assume we need a Student type, who can enroll to and withdraw classes.

var Student = function(){};
Student.prototype.enroll = function(classes){
     // code here
}
Student.prototype.withdraw = function(classes){
     // code here
}


So, Student’s prototype is referencing to an object which has two functions, enroll and withdraw. Similarly you could have written the same as:

var Student = function(){};
var methods = {
     enroll: function(classes){ /* code here */ },
     withdraw: function(classes){ /* code here */ }
}
Student.prototype = methods;

Great, now it’s time to explain you what prototype object is doing. Whenever you are constructing an instance of Student type, it appends enroll and withdraw functions to the created object. In short,
var student = new Student();
student object can call student.enroll([4, 5]); and student.withdraw([5]); in order to enroll to classes which are identified with 4 and 5. And withdraw the class identified with 5. Student class will be extended before Student.constructor is called so, you can use enroll and withdraw right inside of the constructor if needed. Visually the memory looks like:

So if you make a change to Student.prototype after student is created, changes will affect the student instance.

You started to be fascinated, arent you? But we’re just beginning. We’ll take a look how we’re using prototypes to share common behavior among classes. Assume we need another class called PartTimeStudent that inherits Student. To transfer all of the capabilities of the Student, we can set PartTimeStudent’s prototype to a Student object.
var PartTimeStudent = function(){}
PartTimeStudent.prototype = new Student();
PartTimeStudent.prototype.constructor = PartTimeStudent;
By setting the prototype to a Student object that’s being initialized by new Student() line, you also transferred the PartTimeStudent’s constructor to the Student’s. Last line resets the constructor to the right one.

And finally you can continue to extend PartTimeStudent by adding more methods to its prototype.
PartTimeStudent.prototype.other = function(){/* code here */}

Anytime you ask for enroll() from a PartTimeStudent, firstly PartTimeStudent will be searched if it has its own property called as enroll. After no result is found, object’s prototype is being searched. This chain goes until a match is found. If there are no matches, there will be an error to output. Prototype chaining is usually a very costly operation and as you change the deeper definitions such as Object.prototype, it’s becoming a performance bottleneck. That’s the main reason behind the common advices that tell you not to extend Object.prototype directly. And as far as I can understand, if you don’t extend Object.prototype (or any of the existing classes), JS engine uses the natively implemented Object internally which is expected to run . If you make changes, standard implementation cannot be used and extra memory will be consumed to keep the definitions.

This was a quick intro for prototype based inheritance. Part II will cover more existing issues.

Yesterday, I put some code and graphics together and launched Twifighting: a simple tool which compares how trendy your phrases are in Twitter’s ecosystem. It’s an easy tool I always needed, to make some market research, to gather the latest interest metrics and etc.

I simply thought that I’m not the only one on the comparison need side, that’s how I decided to launch it. It’s funny to watch the metrics from Gordon Brown vs David Cameron, Obama vs BP and etc. I became a huge addict! I’m planning a minor update with some useful features and fix some of the usability problems. If you have any feedback, please drop it here.

Lately, as I browse web for maps related questions on Android, what’s frequently requested is an example of setting bounds of a map (zooming to a proper level and panning) to be able show all of the pins given on the screen.

Most of the maps APIs provide this functionality such as Google Maps API, so developers seem to have problems with implementing theirs. Google Maps API for Android does not provide functionality for setting bounds to a box. Instead, what’s provided is to zoom to a span.

com.google.android.maps.MapController.zoomToSpan(int latSpanE6, int lonSpanE6)

latSpanE6 is the difference in latitudes * 10^6 and similarly lonSpanE6 is the difference longitude * 10^6. You may question how map controllers know where to zoom in just by the differences. For examples, kms between longitudes differ from equator to poles. Fortunately, Google maps projection has them in the same length. This may remind you the infamous South America versus Greenland syndrome. Although Greenland is much much smaller than South America, it doesnt look so with this map projection.

On the below, I implemented a boundary arranger method for MapView. Method takes three arguments: items, hpadding and vpadding. items as you may guess is a list of POIs. Other arguments are a little bit more interesting. hpadding and vpadding is the percentage of padding you would like to leave horizontally and vertically so that pins don’t appear just on the corners. For instance, if you assign 0.1 for hpadding, 10% padding will be given from top and bottom.

BTW, You’ll have to extend the existing MapView and add this method to your own MapView to use this method properly.

public void setMapBoundsToPois(List<GeoPoint> items, double hpadding, double vpadding) {

    MapController mapController = this.getController();

    // If there is only on one result
    // directly animate to that location

    if (items.size() == 1) { // animate to the location
        mapController.animateTo(items.get(0));
    } else {

        // find the lat, lon span
        int minLatitude = Integer.MAX_VALUE;
        int maxLatitude = Integer.MIN_VALUE;
        int minLongitude = Integer.MAX_VALUE;
        int maxLongitude = Integer.MIN_VALUE;

        // Find the boundaries of the item set
        for (GeoPoint item : items) {
            int lat = item.getLatitudeE6(); int lon = item.getLongitudeE6();

            maxLatitude = Math.max(lat, maxLatitude);
            minLatitude = Math.min(lat, minLatitude);
            maxLongitude = Math.max(lon, maxLongitude);
            minLongitude = Math.min(lon, minLongitude);
        }

        // leave some padding from corners
        // such as 0.1 for hpadding and 0.2 for vpadding
        maxLatitude = maxLatitude + (int)((maxLatitude-minLatitude)*hpadding);
        minLatitude = minLatitude - (int)((maxLatitude-minLatitude)*hpadding);

        maxLongitude = maxLongitude + (int)((maxLongitude-minLongitude)*vpadding);
        minLongitude = minLongitude - (int)((maxLongitude-minLongitude)*vpadding);

        // Calculate the lat, lon spans from the given pois and zoom

        mapController.zoomToSpan(Math.abs(maxLatitude - minLatitude), Math
.abs(maxLongitude - minLongitude));

        // Animate to the center of the cluster of points
        mapController.animateTo(new GeoPoint(
              (maxLatitude + minLatitude) / 2, (maxLongitude + minLongitude) / 2));
    }

} // end of the method

It hasn’t been a while since ppk wrote about totally a new W3C movement called “Widgets“. A Widget is a downloadable archive of HTML, JavaScript, CSS and a configuration file. It’s a downloadable web front-end. Basically it’s designed to build mobile apps to avoid extra network usage consumed to download heavy weight pages, CSS and JS. With Widgets, you only consume network traffic for data transmission. Before getting into details I have to share a fact that according to my knowledge, Opera Mobile is the only browser around with Widgets support.

You can read Vodafone’s tutorial to make a Widget first to have an initial look.

The Good

For many years, I’ve been in a huge debate with people who uses work force inefficiently by their 35k different platforms and SDKs. Half of the developer have written HTML once in their life and JavaScript has a very large developers base. Every new mobile platform is usually re-inventing the wheel once again and this default action is usually driven by business fears.

Widgets make software accessible anywhere you can run a browser. It’s definitely “Write once, run everywhere”. And the complaints about slow page transmission is being fixed by running them from local resources.

Widgets will push mobile web browsers to act more similarly as applications base grow. Many of the extensions such as geo-location APIs dont really fit each other and some mobile browsers provide totally non-standard features. If web applications dominates the mobile, community will push browsers to act better.

It’s easy to get in. You dont have to download SDKs, learn another language and read documentation/tutorials to learn something new.

The Bad

Performance. Native apps run fast. Even Dalvik empowered Android is horrible and not really responsive compared to other platforms’ applications because of Java. Heavy JS on web browsers are not scalable and just like most of the other browsers, Safari on iPhone has rendering issues even on local websites.

Forget the advantages of Web when it comes to releasing software. No on the fly updates at all. Software should be downloaded again and again as new versions release.  Accessibility to internal platform is questionable. Open platforms like Android provide access to internals such as contact lists, file system and invoking other applications. If mobile  operating system manufacturers cant meet at providing the similar APIs, this wont work.

The Ugly

I find the old-generation of mobile development community is very ill-minded. They use the know-how to make money and this community is interested in their complex and closed environments.

On the other hand, the only contributor is Opera for now. I’m not really sure if they go for larger market share or not. If an open standard acts like a diverse platform for Opera browser phones, it’s the same story.