Oleg Andreev
Month
In last two months I had an opportunity to build two versions of the same application: on iPhone and Android. Both applications are basically navigation/tableview-based browsers for existing French website. Absolutely nothing extraordinary about the whole thing, but it is interesting how similar features could be accomplished on competing platforms.
The Good
First of all, you don’t have to register or pay a fee in order to start developing and testing on a device. Also, you may work on Windows and Linux, but I have not tried that out.
There’s a very flexible layout framework which allows you to position elements relative to each other, to the parent and to the content. You may wrap layout around its content, but also tell it to fill N% of free space. Or fill the whole parent width (or height). Android layout are much more flexible and still simple comparing to Cocoa and even HTML+CSS. Even though the Eclipse IB-like plugin sucks, XML layout language is easy to learn and is not hard to type.
Layouts seem to be simpler and more light-weight than iPhone views: in iPhone I have to render tableview cell by hand (all these tedious pixel calculations: paddings, margins and conditional layout depending on missing text) to maintain smooth scrolling; on Android an straight-forward XML layout for a cell was enough. This is a real time-saver.
Resolution-independent metrics are very powerful: you have regular points and pixels (device-dependent), device-independent points (dips) and device- and textscale-independent points (sips). Elements with dip-dimensions will be sized equally on different screens and elements with sip-dimensions will scale according to user preferences.
The Bad
The first bad thing about Android is Java. Though it is not a language or VM. It is the way people write Java code. They do it fundamentally complicated in every single place. My application does not have any sophisticated features. It is damn simple. And iPhone has simple tools for that. Android and Java have tools to build a space shuttle.
Every single thing in Java (and I’m speaking about both legacy java.lang.* and modern android.* APIs) makes you use a couple of classes and a couple of interfaces. The classes themselves usually inherit 4 levels of superclasses and countless interfaces. In sake of code reuse, the core functionality which you use on a single object is usually split across several classes which makes you switch between various doc pages enormous amount of times. This creates a great pressure on developer’s brains: in process of building a 5-minute feature you have to load your head with almost useless hierarchical structures.
Java developers would say that on the other hand you have a rich reusable toolkit. In fact, the simple thing like network connectivity (parse url, asynchronous download over http, setting and reading http headers) could not be done using a single doc. In iPhone I’ve build a little handy OAHTTPQueue around just a couple of Cocoa classes: NSURL, NSURLRequest and NSURLConnection. I was learning Objective-C and Cocoa from scratch and it took just a couple of hours to implement a descent queue. When I switched to Android I already knew what I’m going to build and how should it work. But it took almost three days to get through 3 (!) huge independent packages android.net.*, org.apache.http.* and java.net.*. Each package had some useful bits on its own, but none was easy to take and build something right away. None contained a simple asynchronous API. Finally, I got to take single thread executor from java.util.concurrent and use a blocking HTTP API from org.apache.http. Other options were as high-level as writing to a socket by hand. The devil of Java is very well illustrated by apache HTTP library: not only it has tons of classes and interfaces, these classes are scattered across 10 sub-packages. In Cocoa you can do all the same things with about 20 NSURL* classes, using 3-4 (!) of them 90% of the time.
In average, for each Cocoa class there are 10 classes and interfaces in Android providing about the same functionality. In other words, Cocoa is 10 times more productive than Java.
Android lacks good programming guidelines. With that amount of options Java spits on you, the guidelines are absolutely a must.
It seems, Google does not care much about the phone. I got lots of stupid errors in MapView. It also lacks built-in pins, annotation pop-ups and callbacks for region-changing events! I had to implement pins and pop-ups by myself. And without useful callbacks, there’s a repeating timer which polls MapView properties and triggers a callback after user stopped dragging/zooming the view.
The Ugly
UI is slow and does not feel right. Scrolling momentum is not natural, every screen opens with a noticeable delay, maps are slow and some screens are 16bit. (Hello, it is 2010 already!)
Android device has physical buttons. Only 2 of them wake device from sleep: “menu” and “hang up”. Others are no-op. Very confusing.
Every application has a hidden menu. It pop-up when you click a “menu”, which is a physical button. And then you have to click a screen button. And to go back from wherever you are you have to tap a physical button again.
Android is over-engineered and under-designed platform. It has interesting model of multitasking stack of activities, but it fails completely when it comes to actual UI. There are “back” and “home” physical buttons. Pressing “back” removes current activity from the stack. Pressing “home” pushes Home Screen on top of the stack. All running activities remain in memory. And when you tap application icon from the home it opens the top-most application activity.
There are 3 lists of the applications: on the home screen, on the “placard” which slides over home screen and somewhere in the Settings (where you should go in order to remove an app). When you remove an app from the home screen it is not clear that you are not going to erase it completely (same issue with Dock on the Mac).
I gave HTC Tattoo phone to several people around me: everyone got confused by the navigation.
The End
Android UI is ugly, slow and complicated. Google is happy to put its apps and a search box in the system, but they are not interested in phone sales. Mobile carriers are interested in having an iPhone competitor, but they do not produce anything. Finally, manufacturers from China do not care about UI and global market strategy, they just produce devices.
Apple, on the other hand, is interested in both device sales and app sales. And they care about the whole chain: from hardware to end-user services.
Android seems to be dying already.
The average web-based shop works like this: there’s a front and a back. The front is sexy, the back is not. One group of people goes to the front to buy stuff, other group goes to the back to manage that stuff. These groups of people intersect only when those who go to the back pretend they are buyers. But still, there’s a huge distinction.
On the other hand, the real shop also has a front and a back. But those who sell stuff do not stay in warehouse all day long turning knobs to rearrange stuff on shelves. They actually go to the shop room to put things in place, see how they look and how customers explore them. In other words, a physical shop is more WYSIWYG than a web-based one.
My suggestion is to outsource to warehouse pages as little functions as possible. The shop owner should have a control on what is presented to the people. He should be able to immediately update prices, titles, rearrange things and see some basic stats which help to decide how good something sells.
I’m using Safari because it is fast, simple and not ugly. But it has several annoying issues:
1. It does not return allocated memory back to system (however, it recycles it internally and does not leak). I end up with Safari eating 1+ gigs and multiple windows with multiple tabs opened. And it is not easy to restart Safari due to a second issue:
2. It does not remember opened windows and tabs automatically. If I opened 10 tabs to read later (or to work with), I have to save them in a bookmark group. And it is not easy to remove/add new pages to that bookmark group.
3. Even if I have enough memory and Safari does not crash too often, I still have multiple windows and tabs, and hidden tabs. It is hard to switch between them, especially using a keyboard.
Let’s see what we can do about it.
First, I turn to other applications I use every day: Mail, TextMate and Xcode.
In Xcode and TextMate I have a quick access to any file using a Cmd+T shortcut: I press Cmd+T, a small window pops up with a search field. I type a portion of file name and it appears in the list. Press Enter — and here it is.
Cmd+T is useful for rare switching. For more frequent switches there’s Alt+Cmd+Up to switch between .h/.m files and Alt+Cmd+Left/Right to navigate through tabs in TextMate.
In Mail I have an Inbox and the folders. Inbox contains unread/undone messages. Everything else is in the folders.
In Mail I also have a single window with a single list of items. If I want to open a particular message in another window, I double-click on an item.
With some background I may draw some requirements for a browser useful at work:
1. It should always remember all windows positions and opened websites. If it crashes, it should restore all pages as they were opened before crash. (Just like Opera did for many years, by the way.)
2. It should have a Cmd+T menu to have a quick keyboard access to all open and bookmarked pages.
3. It should remember history for a page even if it is opened in a new window or tab.
4. The unread pages should be marked so.
5. There should be a context menu item “Read Later” which puts the link into Inbox and marks it as unread.
6. It should cache all the bookmarked pages on disk (in a form of webarchive) for indefinite amount of time. Each new version should be stored as well, but not overwrite the previous one. I want to access exactly the same content I’ve once seen.
7. Closed pages should be easy to reopen. (Safari lets you reopen a window, but not a tab).
Next step is to make some UI mockups to see how silly (or not) these desires are.
In the first part I suggested to use messages like to_my_interface or asMyInterface to ensure interface-compliance. This method just returns whatever object seems to be suitable for the interface, but does no actual checks. IDE like Xcode or Eclipse can do a static check for implemented methods and issue warning/error at compile time. Today I will show how to build the same feature in the dynamic system (and make it more useful).
First, two important points from the first part:
One object (sender) send a message to another (receiver) with an argument which should implement String interface (receiver will call asString method on its argument).
1. The sender does not need to perform any “casting” before sending an interface-compliant object. If appendString(obj) wants a string and you know that your object can (or should) behave like a string, you just pass it in without any conversion. Only low-level method which relies on actual string methods like substring should send asString to obtain the String interface.
2. The receiver should not perform any checks like respondsToSelector or isKindOfClass. It should only tell the argument to return something with an interface it needs.
If both sender and receiver do not check actual interface compliance, where should it happen? Obviously, inside the asString method:
# this method does not check the interface
def asString
self
end
# this method checks the interface
def asString
String.check(self)
end
How’s that different from just testing application as before? First of all, check is performed before any protocol message is send to the subject. So it is more like a “compile-time” check: some message could not be sent in runtime, but the error could be thrown before.
In addition to basic checks like missing methods String.check can also perform some unit tests (and be smart enough to test each particular class (hidden class) only once).
Needless to say that interface checks could be omitted in production mode to increase performance.
Tages Anzeiger redesign suggestion.
“Bits do not naturally have Colour. Colour, in this sense, is not part of the natural universe. Most importantly, you cannot look at bits and observe what Colour they are. I encountered an amusing example of bit Colour recently: one of my friends was talking about how he’d performed John Cage’s famous silent musical composition 4'33” for MP3. Okay, we said, (paraphrasing the conversation here) so you took an appropriate-sized file of zeroes out of /dev/zero and compressed that with an MP3 compressor? No, no, he said. If I did that, it wouldn’t really be 4'33" because to perform the composition, you have to make the silence in a certain way, according to the rules laid down by the composer. It’s not just four minutes and thirty-three seconds of any old silence.“
“So in summary, OOM-safety is wrong:
- Because it increases your code size by 30%-40%
- You’re trying to be more catholic than the pope, since various
systems services you build on and interface with aren’t OOM-safe
anyway
- You are trying to solve the wrong problem. Real OOM wil be signalled
via SIGKILL, not malloc() returning NULL.
- You are trying to solve the wrong problem. Make sure your app never loses
data, not only when malloc() returns NULL
- You can barely test the OOM codepaths”
— I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
— Can I summarize your thinking as “find the [generic] data structure inside an algorithm” instead of “find the [virtual] algorithms inside an object”?
— Yes. Always start with algorithms.
Usually you start deciding what components your application consists of, then you write some code to glue them together. Later, you face a change in the requirements and start “fixing” the object model with a scotch tape. When you run out of tape you finally redesign your object model to fit the algorithm. Otherwise, if you focus on the algorithm instead of data structures, you’ll spend less time on (re)writing the code.
OOP, however, is orthogonal to this idea. Objects still encapsulate code (algorithms) and data (requirements). Requirements are set through the object’s interface. The only difference is that you should design objects from the algorithms perspective, not the abstract data relations. This is why relational database should be normalized, tuples should have as little number of fields as possible, object should do only one job etc.
Very good post (google translation) on airport security improvement and security strategies in general.
class ::Object
def blank?; false end
def or(default = nil)
blank? ? (block_given? ? yield : default) : self
end
def and
blank? ? nil : yield(self)
end
end
class ::FalseClass
def blank?; true end
end
class ::NilClass
def blank?; true end
end
class ::Array
def blank?; compact.empty? end
end
class ::String
def blank?; strip.empty? end
end
class ::Hash
def blank?; values.empty? end
end
Examples:
" ".or "Untitled" # => "Untitled"
" ".or { calculate_value } # => "42"
[nil].or { ["apple", "orange"] } # => ["apple", "orange"]
"data".and {|data| Wrapper.new(data) } # => wrapper
" ".and { ... } # => nil
I would also suggest treating 2+ spaces as one or more tabs to avoid tab vs. spaces debates. See also my article on DSSV.
In college computer science classes, we learn all about b*trees and linked lists and sorting algorithms and a ton of crap that I honestly have never, ever used, in 25 years of professional programming. (Except hash tables. Learn those. You’ll use them!)
What I do write – every day, every hour – are heuristics that try to understand and intuit what the user is telling me, without her having to learn my language.
The field of computer interaction is still in its infancy. Computers are too hard to use, they require us to waste our brains learning too many things that aren’t REAL knowledge, they’re just stupid computer conventions.
”—On Heuristics and Human Factors by Wil Shipley.Thanks to @groue for the link
Thanks to Pierlo for the link.
“If you’re familiar with how Objective-C objects are declared […] blocks are Objective-C objects. This may not seem strange in Objective-C but the reality is that even in pure C or C++, blocks are still Objective-C objects and the runtime support for blocks handles the retain/release/copy behaviors for the block in an Objective-C messaging manner.”
by Matt Gallagher
When you up to implement a feature similar to what you already have, there’s a huge temptation to refactor and abstract existing code right away. Sometimes you even have a perfect idea how it should be done.
Nevertheless, Don’t Do That.
Take an existing class, copy it, rename and update to meet your needs. Test, tweak, test again. You will see clearly how it is different from the original code. Don’t rush to extract common code, let yourself test/tweak more. Of course, don’t let it stay unDRY for a long time: it may become hard to refactor them later when you forget what you were actually doing.
In other words you should let your code evolve in a natural way like Darwin prescribed. Replicate and mutate the code: you will see better solution among the options. Then according to the Rule Of Survival Of The Fittest delete everything not worth living.
In many-many cases this technique helps to avoid wasting time on fitting code into wrong abstractions built on pure imagination.
[Blames himself for the mistakes of the past.]
“You, as a programmer, should be programming EVERY LINE as defensively as possible. You should assume that every other method in the program is out to kill you, and they are intentionally passing you corrupted buffers and pointers, and it’s your job to handle all that crap and make the best of it. (And, if you can repair it, do so, and if not, raise an exception so you can catch it in beta testing, instead of silently failing and/or corrupting data.)”
@wilshipley
“Here are five things that will kill your startup before software security does:
— Slowness
— Poor graphic design
— XML
— The RIAA
— Product Marketing Managers
The graveyards in this town are littered with the corpses of startups that pinned their hopes on advanced security. Better engineers than you have tried and failed. Theo de Raadt coordinated the first large-scale security codebase audit. His reward: Only two remote holes in the default install!”
This is an evolving document describing sRuby, a subset of Ruby that can be easily compiled to fast low-level code. The purpose of developing sRuby is to use it to implement a Ruby virtual machine. However, we anticipate that it can be used to write Ruby extensions that needs to bridge the gap between Ruby and a low-level language © in an easy and portable way.
Robert Feldt
April 4, 2001
Suppose you have that kind of user interface:
The efficient rendering algorithm would be the following:
1. Cell should render its content manually: that is not using multiple views, but using a single contentView which is updated programmatically in drawInRect: method.
2. Each time cell is rendered, it checks the cache of downloaded images. If image is not present, cell schedules request to download it. Cell should remember the request URL to be notified when data is ready.
3. Download request goes to FILO queue with async NSURLConnection delegate. Async API uses the main thread which is notified when data is ready.
4. The queue size should be limited by a maximum number of visible cells. The most recently requested images go to the end of the queue, while the head of the queue is truncated each time new request is added. This way scheduled requests are removed when corresponding cells become invisible.
5. Download callback should lookup [tableView visibleCells] to find the exact cell which requests the downloaded image. The cell could be different than the one started the request (remember cell recycling!). You cannot just call [tableView reloadData]: it works poorly when a lot of images are loaded while you scroll.
6. In addition to downloaded images cache, there should be pre-rendered images cache: each time cell draws itself and finds the downloaded image, it should rescale and crop the image. The rescaled image should be put in the cache, otherwise scrolling won’t be smooth. Of course, if the downloaded image is already sized as needed, this step could be omitted. See UIGraphicsBeginImageContext.
Toolkit summary:
— download requests queue with async i/o (no NSOperations, no background threads)
— manual cell rendering (no subviews)
— individual cell update (do not reloadData)
— pre-rendered images cache
— discard pending downloads for invisible cells
“Tracing and reference counting are uniformly viewed as being fundamentally different approaches to garbage collection that possess very distinct performance properties. We have implemented high-performance collectors of both types, and in the process observed that the more we optimized them, the more similarly they behaved — that they seem to share some deep structure.” David F. Bacon at al.
Great article explaining multithreading issues on multiprocessor systems.
Reference-counting is traditionally considered unsuitable for multi-processor systems. According to conventional wisdom, the update of reference slots and reference-counts requires atomic or synchronized operations. In this work we demonstrate this is not the case by presenting a novel reference-counting algorithm suitable for a multi-processor system that does not require any syn- chronized operation in its write barrier (not even a compare-and-swap type of synchronization). A second novelty of this algorithm is that it allows eliminating a large fraction of the reference- count updates, thus, drastically reducing the reference-counting traditional overhead. This paper includes a full proof of the algorithm showing that it is safe (does not reclaim live objects) and live (eventually reclaims all unreachable objects).
1. Some GCs do pointer recognition in the arbitrary data array (e.g. Boehm-Demers-Weiser GC); this is not necessary if GC should track objects of the known structure (e.g. Steve Dekorte’s GC)
2. If we track object references only, there’s no need to fight fragmentation of the GC-managed heap: all entries are of the same size.
3. After coding Obj-C for a while, I’ve noticed that the only issue which should be resolved by some kind of garbage collector is circular references. Retained properties and autorelease pools already help to avoid manual retain/release calls. That is: allocation should be always succeeded by autorelease and all the properties should be nullified on deallocation (this could be done automatically).
I wonder if it is possible to use a simple reference-counting mechanism with a simple referential cycles resolution, thinking that way we can imagine a very simple and efficient garbage collector.
References:
1. Minimizing Reference Count Updating with Deferred and
Anchored Pointers for Functional Data Structures by Henry Baker
2. Concurrent Cycle Collection in Reference Counted Systems by David F. Bacon and V.T. Rajan
1. When using sandbox user account, do not sign in using Preferences, just sign out and sign in when your app asks so.
2. Transaction receipt should be Base64 encoded before sending to Apple verification service. This is not mentioned in the docs.
3. Subscriptions should not be restored using restore API. Do not even try: Apple suggests sending relevant data from your application server.
4. Title/description you set in iTunes connect do not really matter if you supply products from the server. Only product id and the price tier matter. Everything else you supply by yourself.
5. Do not forget to sort the products elsewhere since it is impossible to sort them on iTunes Connect site.
6. Transaction receipt should be verified at apple server for two reasons: 1) secure validation; 2) this is the only way to get transaction details
“That is what happens when a conventional generational garbage collector is used for a program whose object lifetimes resemble the radioactive decay model. The collector simply assumes that young objects have a shorter life expectancy than old objects, and concentrates its effort on collecting the generations that contain the most recently allocated objects. In the radioactive decay model, these are the objects that have had the least amount of time in which to decay, so the generations in which they reside contain an unusually low percentage of garbage. For the radioactive decay model, therefore, a conventional generational collector will perform worse than a similar non-generational collector.”
Paper by William D. Clinger and Lars T. Hansen (PostScript)
The major feature of a dynamic language is interactivity. With Smalltalk you may run the program and inspect/change it at runtime. This implies some GUI for VM with built-in crappy text editor: you don’t edit files, you edit objects now.
This does not sound very comfortable for many reasons. First, you would always want to have a “canonical” state of your application which is not affected by runtime mutations: that is, plain text files stored under some version control. Next, you would like to use a different text editor or GUI and it is much simpler to achieve when you operate with plain files instead of fancy VM/language-specific API.
How do we combine interactivity of Smalltalk with text file editing? Let’s take the puriest OO language ever designed: Io.
1. Each file contains an expression.
2. The only way to load the file is to evaluate it in context of some object: object doFile("file.io"). The return value would be a result of the expression in the file.
3. We may have a convention that some files return a prototype object: the object which is used as a prototype for other objects created in runtime.
4. To load “prototype object” we use a special loader object which would track the file-to-object mapping: Article := Loader load("article.io")
5. Loader monitors the filesystem and when some file is changed, it loads it into another object and replaces the prototype with that object: Article become(load("article.io"))
6. At that point, all articles in the system suddenly have another version of Article proto.
You have to follow some safety rules. For instance, proto’s descendants should not modify the proto and rely on such modifications.
Of course, this method still does not allow you to change/inspect any object in the system. For this to work you may put a breakpoint message somewhere and use a debugger after the proto is reloaded and VM stepped on that message. Or wire some Smalltalk-like GUI to your app.
Simple proto-based reloading helps development a lot and in contrast to class loading methods with full app reload, works faster and for full range of source code including all libraries. Rails dependency system does not reload gems, but does a pretty good job with constant reloading. All ruby/rails issues with global data applied.
Now, working with Objective-C where nil eats messages, I realized that the code is more elegant, but it takes significant amount of time to debug it. You create if/else branches and breakpoints to trace the nil, then you fix the bug which causes it and erase the conditional code. You get your elegant code back and wait for another issue to arise later.
“Essentially, Haas Unica came about as a result of analysing the original version of Helvetica, its variants (as they were in 1980) and similar faces and seeking to improve them - to produce the ultimate archetypal sans serif face. A single face to unite them all, if you like. ”
See also: From Helvetica to Haas Unica (flickr set)
The paper discusses how thread-oriented programming is more efficient (in terms of performance and development cost) than event-oriented.
My personal observation is that cooperative multitasking (based on coroutines, fibers) requires less and easier to read code comparing to evented callback-based code.
The Objective C syntax is poisoned with nested square brackets:
[[[Class alloc] initWithApple:a andOrange:o] autorelease];
First, lets move opening bracket behind the name of the receiver:
Class[alloc][initWithApple:a andOrange:o][autorelease];
You may agree that this is much easier to write now. However, at this point we lose compatibility with ANSI C (think buffer[index]).
Lets omit brackets for messages without arguments and use a space as a delimiter:
Class alloc [initWithApple:a andOrange:o] autorelease;
At this point we may get back compatibility with ANSI C by making a non-context free grammar (parser should recognize that a[b:c] could not be used for index operations).
You can implement exactly that syntax in Io using the standard language features.