GPhone? Just a Rumor - The Real Story Is The Android Developer Revolt | Hacker News Reader

GPhone? Just a Rumor - The Real Story Is The Android Developer Revolt

readwriteweb.com

32 pointssant0sk113 comments

Really good post. http://jbq.livejournal.com/151129.html

Basically, Google is trying to ship a phone first, and then worry about the SDK and developers. Their API and software stack is changing a lot while developing for real devices, therefore anything they relesead now, would be obsolete.

So, Developers are going to get a SDK only when google is about to ship real devices. The real issue is that they are taking forever to release a a real device,

and:

1. Their API sucks ass (so many hooplas to do even simple things, very kludgy).

2.Their UI is really not that great, especially compared to iPhone. Sure, it might be better than Symbian or Winmo, or Blackberry, but when it comes out, it will be nothing that exiting.

IIRC the UI isn't a fundamental part of Symbian, it can look like whatever the vendor wants.

I am not talking about the UI "skin", but the fundementals. Animations are not that easy as they should be, and the widgets are messy, and you find out they don't do exactly what you want.

Even the "Button" widget, extends the ImageSwap, which is a view, which has a gazillion of methods yet:

It doesn't do the thing you want! You can give it a background, but only one image associated with it, and there is the highlight, which is a color.

All I want is a ficking button that takes a normal, hover, pressed images. How hard is that? Well with Android you have to dig down, and extend it and change the code in order to get what you want.

Not elegant at all google.

http://code.google.com/android/reference/android/widget/Imag... Summary Methods inherited from class android.view.View awakenScrollBars, awakenScrollBars, bringToFront, buildDrawingCache, clearAnimation, clearFocus, computeHorizontalScrollExtent, computeHorizontalScrollOffset, computeHorizontalScrollRange, computeScroll, computeVerticalScrollExtent, computeVerticalScrollOffset, computeVerticalScrollRange, copyWindowBitmap, dispatchDraw, dispatchFreeze, dispatchKeyEvent, dispatchThaw, dispatchTouchEvent, dispatchTrackballEvent, dispatchUnhandledMove, dispatchWindowFocusChanged, dispatchWindowVisibilityChanged, draw, drawableStateChanged, finalize, findFocus, findViewById, findViewWithTag, focusSearch, freeze, getAbsoluteLocationOnScreen, getAnimation, getBackground, getBaseline, getBlockDescendantFocus, getBlockUnmatchedKeyUps, getBottom, getBottomFadingEdgeStrength, getContext, getContextMenuInfo, getDefaultSize, getDrawableState, getDrawingCache, getDrawingCacheQuality, getDrawingRect, getDrawingTime, getFocusType, getFocusables, getFocusedRect, getGlobalVisibleRect, getGlobalVisibleRect, getHandler, getHeight, getHitRect, getHorizontalFadingEdgeLength, getHorizontalScrollbarHeight, getId, getInstanceCount, getLayoutParams, getLeft, getLeftFadingEdgeStrength, getLocalVisibleRect, getLocationInWindow, getLocationOnScreen, getMeasuredHeight, getMeasuredWidth, getOnFocusChangeListener, getPaddingBottom, getPaddingLeft, getPaddingRight, getPaddingTop, getParent, getResources, getRight, getRightFadingEdgeStrength, getRootView, getScrollX, getScrollY, getTag, getTop, getTopFadingEdgeStrength, getVerticalFadingEdgeLength, getVerticalScrollbarWidth, getViewRootInstanceCount, getVisibility, getWidth, getWindowFrame, getWindowSession, getWindowToken, getWindowVisibility, hasBackground, hasFocus, hasWindowFocus, inTouchMode, initializeFadingEdge, initializeScrollbars, invalidate, invalidate, invalidate, invalidateDrawable, isClickable, isDrawingCacheEnabled, isEnabled, isFocusable, isFocusableInTouchMode, isFocused, isFreezeDisabled, isHorizontalFadingEdgeEnabled, isHorizontalScrollBarEnabled, isLayoutRequested, isPressed, isSelected, isVerticalFadingEdgeEnabled, isVerticalScrollBarEnabled, layout, measure, mergeDrawableStates, onAttachedToWindow, onCreateDrawableState, onDetachedFromWindow, onDraw, onDrawBackground, onFinishInflate, onFocusChanged, onFreeze, onKeyDown, onKeyMultiple, onKeyUp, onLayout, onMeasure, onPopulateContextMenu, onScrollChanged, onSizeChanged, onThaw, onTouchEvent, onTrackballEvent, onWindowFocusChanged, onWindowVisibilityChanged, performClick, performLongClick, populateContextMenu, post, postDelayed, postInvalidate, postInvalidateDelayed, press, refreshDrawableState, requestFocus, requestFocus, requestFocus, requestLayout, requestRectangleOnScreen, requestRectangleOnScreen, resolveSize, scheduleDrawable, scrollBy, scrollTo, setAnimation, setBackground, setBackground, setBackgroundColor, setBlockDescendantFocus, setBlockUnmatchedKeyUps, setClickable, setDrawingCacheEnabled, setDrawingCacheQuality, setEnabled, setFadingEdgeLength, setFocusType, setFocusable, setFocusableInTouchMode, setFreezeDisabled, setHorizontalFadingEdgeEnabled, setHorizontalScrollBarEnabled, setId, setLayoutParams, setMeasuredDimension, setOnClickListener, setOnFocusChangeListener, setOnKeyListener, setOnLongClickListener, setOnPopulateContextMenuListener, setPadding, setPreferredHeight, setPreferredWidth, setSelected, setTag, setVerticalFadingEdgeEnabled, setVerticalScrollBarEnabled, setVisibility, setWillNotCacheDrawing, setWillNotDraw, startAnimation, thaw, unpress, unscheduleDrawable, unscheduleDrawable, verifyDrawable, willNotCacheDrawing, willNotDraw

I think this shows how much easier it is to be a dictator. Apple dictates everything. There isn't the overhead you have to deal with when you're coordinating lots of different handset manufacturers and trying to avoid forks that lead to incompatibility.

I'm still optimistic about Android because it would be really nice to have an open device with the polish and capabilities of the iPhone. However, Google still has a lot to prove. MS, Apple, BB, and Palm all have shown that their routes work. While Google's Android isn't a radical departure, is the fact that it could be forked enough to put a fork in it? Time will tell.

The biggest problem for android developers is that there is no phone, you don't know when there will be a phone, and you don't know if that phone will be popular at all.

There are a few phones, the phones will be coming for Christmas, but you're right.

The phones were going to be out this Summer (so now) but have been delayed. Who knows if Christmas will slip too

I notice this story features Jean-Baptiste Queru. I worked with him at Be. Even back in those days, he had a reputation as being "outspoken." I guess it's still true!

It's a really bizarre situation. I've talked with some of the Android guys on IRC, and they basically say "we know it's a really bad situation, but we can't change it, and we can't even say why it is like it is". Which is just weird...

John Forsyth, a Symbian exec, was talking about how unsexy it is to support a manufacturuer when launching a phone. Maybe his words can provide some insight to those who jumped to bandwagon too early:

http://news.bbc.co.uk/1/hi/technology/7082414.stm

Well... as a Symbian exec, what else is he supposed to say?

Here's my take on the Android situation:

http://journal.dedasys.com/articles/2008/07/09/google-androi...

What really bugs me is that their lines of communication completely shut down for some reason, which is just bizarre.

Does anybody here have experience with both the iPhone SDK and Android SDK? If so, any thoughts?

I've only been to the Android Developer day, and my impression was that I don't like the Android API at all. I am tired of XML and Java, and I don't see why it has to be enforced. It used to be that you could use all sorts of languages on an operating system. And if Java, why give us yet another API? There are enough Graphics APIs for Java already, I am not motivated to learn another one without any visible benefits over the existing ones.

Reply on news.ycombinator.com