Group items tagged

Current Instapaper and former Tumblr developer Marco Arment wonders out loud if Google Android phones can ever achieve the levels of usability and polish Apple’s iPhone has arguably had since day one

Android will continue to exhibit what Google does best: great low-level engineering and tight integration with Google’s other services. But it’s never going to be Apple-like in user experience, polish, or design. Attention to detail, like most facets of truly good design, can’t be (and never is) added later. It’s an entire development philosophy, methodology, and culture

This is androidpatterns.com, a set of interaction patterns that can help you design Android apps. An interaction pattern is a short hand summary of a design solution that has proven to work more than once. Please be inspired: use them as a guide, not as a law.

An App Widget uses a special display control called RemoteViews. Unlike a regular View, a RemoteViews control is designed to display a collection of View controls in another process. Consequently, you can't simply add a button handler because that code would run in your application process, not in the process displaying the RemoteViews object (in this case, the Home Screen process).

In order to handle user interaction with an App Widget, the following tasks must be performed: Set a unique click handler for each App Widget control Have the click handler send a command to a registered receiver Process the command received and perform any action necessary Update the App Widget to reflect the changes

In portrait orientation, each cell is 80 pixels wide by 100 pixels tall (the diagram shows a cell in portrait orientation)

In landscape orientation, each cell is 106 pixels wide by 74 pixels tall.

RemoteViews can't manipulate a buttons enabled/disabled state, but it can modify its visibility. So the trick is to have two buttons, the real one, and an other which is designed to look like the real one in disabled state, and change witch one is visible.

<Button android:id="@+id/startbutton" android:text="Start" android:visibility="visible"></Button> <Button android:id="@+id/startbutton_disabled" android:text="Start" android:clickable="false" android:textColor="#999999" android:visibility="gone"></Button>   <Button android:id="@+id/stopbutton" android:text="Stop"  android:visibility="gone"></Button> <Button android:id="@+id/stopbutton_disabled" android:text="Stop" android:clickable="false" android:textColor="#999999" android:visibility="visible"></Button>

RemoteViews remoteView = new RemoteViews(context.getPackageName(), R.layout.widget); remoteView.setViewVisibility(R.id.startbutton, View.GONE); remoteView.setViewVisibility(R.id.startbutton_disabled, View.VISIBLE); remoteView.setViewVisibility(R.id.stopbutton, View.VISIBLE); remoteView.setViewVisibility(R.id.stopbutton_disabled, View.GONE); AppWidgetManager.getInstance(context).updateAppWidget(appWidgetId, remoteView);

It allows third-party application servers to send lightweight messages to their Android applications. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the application that there is new data on the server, so that the application can fetch it. C2DM makes no guarantees about delivery or the order of messages. So, for example, while you might use this feature to tell an instant messaging application that the user has new messages, you probably would not use it to pass the actual messages. An application on an Android device doesn’t need to be running to receive messages. The system will wake up the application via Intent broadcast when the the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.

It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.

C2DM imposes the following limitations: The message size limit is 1024 bytes. Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device

Apple tends to do that a lot. It’s deeply ingrained in their culture, priorities, and product development practices. In brief, their philosophy seems to be to ship only what’s great and leave out the rest. That’s why, instead of having a bad copy-and-paste implementation for the iPhone’s first two years, we just didn’t have one at all

Android as a platform, both in hardware and software, doesn’t reflect this. Nearly every hardware and software release has major shortcomings or rough edges. Many details and design decisions are lacking, wrong, or inexplicable. Neither Google nor the current Android device manufacturers embody the part of Apple’s culture that allows them to release a great product on day one. They have a different pattern: It’s always getting better. We’re always supposedly one or two releases from it being really great.

I never make technology-buying decisions based on future promises, rumors, or potential. I let other people be the bleeding-edge extremely early adopters, and I stick with what I know will work and stay out of my way. I don’t buy things that are “getting better”, because they usually don’t. Whatever caused them to be lacking in their current release will usually prevent them from being great in future releases. I buy things that are great today. They’re usually things that have been great since day one. And, more often than not, they’re Apple products.

FrameLayout is designed to block out an area on the screen to display a single item. You can add multiple children to a FrameLayout, but all children are pegged to the top left of the screen. Children are drawn in a stack, with the most recently added child on top. The size of the frame layout is the size of its largest child (plus padding), visible or not (if the FrameLayout's parent permits). Views that are GONE are used for sizing only if setConsiderGoneChildrenWhenMeasuring() is set to true.