4 ms·

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

32 points by sant0sk1 18y ago

davidw 18y ago
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...
- hcho 18y ago
  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 http://news.bbc.co.uk/1/hi/technology/7082414.stm
  - davidw 18y ago
    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-android-and-the-case-of-the-missing-communication 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.
utnick 18y ago
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.
- omouse 18y ago
  There are a few phones, the phones will be coming for Christmas, but you're right.
  - danw 18y ago
    The phones were going to be out this Summer (so now) but have been delayed. Who knows if Christmas will slip too
ardit33 18y ago
Really good post. http://jbq.livejournal.com/151129.html 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.
- gaius 18y ago
  IIRC the UI isn't a fundamental part of Symbian, it can look like whatever the vendor wants.
  - ardit33 18y ago
    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/ImageButton.html 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
allenbrunson 18y ago
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!
mdasen 18y ago
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.
vizard 18y ago
Does anybody here have experience with both the iPhone SDK and Android SDK? If so, any thoughts?
- Tichy 18y ago
  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.

32 points by sant0sk1 18y ago

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...

hcho 18y ago
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 http://news.bbc.co.uk/1/hi/technology/7082414.stm
- davidw 18y ago
  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-android-and-the-case-of-the-missing-communication 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.

utnick 18y ago

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.

omouse 18y ago
There are a few phones, the phones will be coming for Christmas, but you're right.
- danw 18y ago
  The phones were going to be out this Summer (so now) but have been delayed. Who knows if Christmas will slip too

ardit33 18y ago

Really good post. http://jbq.livejournal.com/151129.html 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.

gaius 18y ago
IIRC the UI isn't a fundamental part of Symbian, it can look like whatever the vendor wants.
- ardit33 18y ago
  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/ImageButton.html 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

allenbrunson 18y ago

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!

mdasen 18y ago

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.

vizard 18y ago

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

Tichy 18y ago
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.